Adding basic etcd capability to system #854
Conversation
| @@ -35,8 +35,10 @@ | |||
| <orderEntry type="library" name="Gradle: commons-cli:commons-cli:1.5.0" level="project" /> | |||
| <orderEntry type="library" name="Gradle: com.google.cloud:google-cloud-logging:3.14.9" level="project" /> | |||
| <orderEntry type="library" name="Gradle: io.github.clearblade:clearblade-cloud-iot:1.0.5" level="project" /> | |||
| <orderEntry type="library" name="Gradle: io.etcd:jetcd-core:0.6.1" level="project" /> | |||
There was a problem hiding this comment.
Out of curiosity, is it intended that IntelliJ files are committed? In general I recommend excluding the IntellIJ configs, because they can be regenerated from Gradle, and it tends to clog up the repository.
It's not a huge problem, but it might be cleaner to deleted them.
There was a problem hiding this comment.
Yes -- I generally follow the IDEA guidelines on this... include everything except the workplace files. They've sequestered the "individual specific" stuff in one place. I've never seen it actually clog up the repository... (yes, it's redundant but mostly the tools don't care and the churn is pretty low". If it's causing a problem somewhere let me know and we can address (sometimes personal paths creep their ways in), but ultimately it's generally useful for sharing some things like run/debug configurations etc...
| spec: | ||
| containers: | ||
| - name: etcd-set | ||
| image: quay.io/coreos/etcd:latest |
There was a problem hiding this comment.
consider pinning this to a specific version, such as the one set above. In general, for security and compatibility reasons it is recommended to pin container images to a specific version. Observability tools and such can provide information that the container is out of date.
For the CoreOS etcd image it may not be a big deal, but if you were to say, pull a container image from a random outsider, they could attack any infra by pushing new versions to latest.
There was a problem hiding this comment.
sure -- it's what I usually do, this was just cut-and-paste stuff I wasn't paying attention to... Usually I find it's not security or compatibility reasons, but rather stability and consistency -- without a pinned version things can randomly change and randomly introduce bugs that are then really confusing as to why things suddenly started to behave differently.
There was a problem hiding this comment.
Well then. It turns out that the "latest" tag is actually 6 years old, and that the more recent versions don't have a shell in them... it's possible, but would require rejiggering this a bit to get the initial etcd startup to work -- not something I would like to tackle just now. So, gonna put it on "the list" of things to do. Likely need to setup a config-map for the cmdline parameters is all. This of course will all come back to haunt me horribly when they do change the "latest" tag for some reason and everything suddenly decides to break...
No description provided.