You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like the fix from #20 only works when using the KAFKA_REST_ENDPOINT env, but not when using confluentcloud:kafka_rest_endpoint in the Pulumi..yaml
When configuring the Confluent connection in the stacks config file, I still encounter a perpetual diff when applying, because the topic ressource is created with the url from the config-option, but the rest_endpoint-parameter isn't set in the constructor.
We're using the python-SDK in case that's important.
Steps to reproduce
set up your confluent connection in your config file (confluentcloud:kafka_api_key , confluentcloud:kafka_api_secret, confluentcloud:kafka_rest_endpoint)
create a new topic with whatever settings, leave the rest_endpoint-parameter in the constructor empty prompting the provider to use the values from the config instead
pulumi up your stack for the first time, creating the topic
pulumi up your stack a second time
Expected Behavior
If no changes to the config has been made, the topic should just be considered unchanged.
Actual Behavior
The provider will try to replace the topic, since the "rest_endpoint"-parameter is seemingly missing.
Also, replacement seems to fail more often than not, because the provider seems to try to create the replacement before the deletion of the original topic is finished.
Output of pulumi about
CLI
Version 3.41.1
Go Version go1.19.1
Go Compiler gc
Plugins
NAME VERSION
confluent 0.2.2
confluentcloud 1.3.0
kafka 3.3.0
python unknown
Host
OS fedora
Version 35
Arch x86_64
This project is written in python: executable='/usr/bin/python3' version='3.10.7
'
Current Stack: [redacted due to containing company information]
Backend
Name pulumi.com
[...]
Dependencies:
NAME VERSION
ansible 2.9.27
argcomplete 1.12.3
autopep8 1.7.0
Babel 2.9.1
beautifulsoup4 4.11.0
blivet 3.4.4
blivet-gui 2.3.0
Brotli 1.0.9
cached-property 1.5.2
certifi 2021.10.8
chardet 4.0.0
cloudpickle 1.6.0
cupshelpers 1.0.0
dasbus 1.6.0
docker-compose 1.29.2
docker-pycreds 0.4.0
fs 2.4.11
gpg 1.15.1
humanize 0.5.1
inflection 0.5.1
initial-setup 0.3.93
jmespath 0.10.0
kafka-python 2.0.2
langtable 0.0.59
libcomps 0.1.18
lxml 4.6.5
lz4 3.0.2
matplotlib 3.5.3
mdx-gh-links 0.2.0
mkdocs-bootstrap 1.1.0
mkdocs-bootswatch 1.1.0
munkres 1.1.2
nftables 0.1.0
nltk 3.6.2
olefile 0.46.0
paramiko 2.11.0
pexpect 4.8.0
pid 2.2.3
pip 22.1.0
pipreqs 0.4.11
productmd 1.33.0
psutil 5.8.0
ptyprocess 0.6.0
pulumi-confluent 0.2.2
pulumi-confluentcloud 1.3.0
pulumi-kafka 3.3.0
pwquality 1.4.4
py-postgresql 1.2.2
pyasn1 0.4.8
pycairo 1.20.1
pycups 2.0.1
pycurl 7.44.1
PyGObject 3.42.0
pykickstart 3.34.0
pyparted 3.12.0
PySocks 1.7.1
python-augeas 1.1.0
python-manatools 0.0.3
python-meh 0.50.0
pywinrm 0.4.1
requests-file 1.5.1
requests-ftp 0.3.1
rpm 4.17.1
scipy 1.8.0
scour 0.38.1
selinux 3.3.0
sepolicy 3.3.0
setools 4.4.0
simpleline 1.8.2
sos 4.2.0
systemd-python 234.0.0
Pulumi locates its logs in /tmp by default
Additional context
No response
Contributing
No response
The text was updated successfully, but these errors were encountered:
What happened?
It seems like the fix from #20 only works when using the KAFKA_REST_ENDPOINT env, but not when using confluentcloud:kafka_rest_endpoint in the Pulumi..yaml
When configuring the Confluent connection in the stacks config file, I still encounter a perpetual diff when applying, because the topic ressource is created with the url from the config-option, but the rest_endpoint-parameter isn't set in the constructor.
We're using the python-SDK in case that's important.
Steps to reproduce
pulumi up
your stack for the first time, creating the topicpulumi up
your stack a second timeExpected Behavior
If no changes to the config has been made, the topic should just be considered unchanged.
Actual Behavior
The provider will try to replace the topic, since the "rest_endpoint"-parameter is seemingly missing.
Also, replacement seems to fail more often than not, because the provider seems to try to create the replacement before the deletion of the original topic is finished.
Output of
pulumi about
Additional context
No response
Contributing
No response
The text was updated successfully, but these errors were encountered: