/srv/irclogs.ubuntu.com/2020/12/08/#juju.txt

stickupkidmanadart, https://github.com/juju/juju/pull/1241309:11
Alan21Is there a way with Juju to configure an agent on the machines we already have, without providing Juju with SSH access on this machine ? like instead of expecting the OLM to deploy the agent we deploy it ourselves11:14
stickupkidAlan21, not that I'm aware of, but in "theory" it's possible. You'd have to follow the steps of a manual machine.11:34
Alan21What would be nice is to have a PKI where agents can be signed and register themselves in a secure way (mTLS) to Juju, rather than having Juju acting as an orchestration tool for its own agents11:36
Alan21Juju is supposed to be Application Management, therefore it should leave out the agents configuration to configuration management imho11:36
Alan21https://juju.is/docs/manual-cloud here it's all about SSH11:37
stickupkidAlan21, I agree, but we are where we are. Maybe raise a bug and see what happens...11:41
Alan21I'm not criticizing, don't get me wrong, just trying to understand what the community thinks and contribute as much as I can !11:47
Alan21Juju is awesome, I believe in this project a lot, I'm just concerned with a few details, first being this aspect of orchestration and the second one being security. I would like to be able to limit the deployable charms and the actions per user, also to prevent individual contributors from deploying but still allowing them to run a few actions11:48
Alan21there are many opportunities to make Juju a big thing11:48
stickupkidSo I believe the first one is doable, it requires time to just get the steps to do, formalize it and then document it (rinse and repeat until they're commands in their own right)11:49
achilleasaAlan21: also juju (the controller specifically) normally needs ssh access to prepare the machine for the workloads (e.g. install some packages, setup bridges when you deploy containerized workloads etc). While you could argue that an external tool configures the machines as required, juju cannot assume that this is always the case (esp. for bridging purposes when you are using multiple NICs, spaces and stuff11:54
achilleasalike OVS)11:54
Alan21stickupkid do you have the necessary knowledge to guide me through that ?11:56
stickupkidunfortunately I don't have the time right now...11:57
Alan21achilleasa interesting, isn't the agent doing this ?11:57
Alan21no pressure, just someday11:57
Alan21My "vision" is to have Juju behaving like SaltStack but for applications, we have some agents (minions) that are pre-provisioned and we use the OLM to pilot those agents. Those agents should have some signed metadata (grains) that we can use to secure deployments on specific spaces11:59
achilleasaAlan21: turns out I was wrong about the bridging bits. Those are indeed applied by the machine agent12:09
Alan21Ah ok, sounded counter-intuitive :D  So it means the SSH is only there to enable the agent right?12:16
achilleasapretty much12:25
Alan21now the big question is: Does juju add the machine to its inventory when the API is updated with a new machine, or when the juju agent actually registers to the OLM12:26
stickupkidachilleasa, another one https://github.com/juju/juju/pull/1242014:16
manadartstickupkid or achilleasa: https://github.com/juju/juju/pull/1241914:16
stickupkidmanadart, dunno, still waiting for you to review mine ;-) https://github.com/juju/juju/pull/1241314:17
stickupkidmanadart, on it14:17
manadartstickupkid: 12413 need conflict resolution :P14:18
stickupkidas if, all my code is perfect14:18
stickupkiddaaaaaaaaaaaaaaaaaaaaaaaaaaaamn14:18
manadartstickupkid: https://media4.giphy.com/media/l3q2skPbq1YfqaXWo/giphy.gif?cid=ecf05e47y0k27v555csys9p2flb232hnhqgcyjq3ktk9td3z&rid=giphy.gif14:24
stickupkid100%14:24
stickupkidhaha14:24
manadartstickupkid: I'll do your wait-for one next. Haven't forgotten.14:49
stickupkidmanadart, do this one next https://github.com/juju/juju/pull/1242014:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!