[09:11] manadart, https://github.com/juju/juju/pull/12413 [11:14] Is 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 ourselves [11:34] Alan21, not that I'm aware of, but in "theory" it's possible. You'd have to follow the steps of a manual machine. [11:36] What 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 agents [11:36] Juju is supposed to be Application Management, therefore it should leave out the agents configuration to configuration management imho [11:37] https://juju.is/docs/manual-cloud here it's all about SSH [11:41] Alan21, I agree, but we are where we are. Maybe raise a bug and see what happens... [11:47] I'm not criticizing, don't get me wrong, just trying to understand what the community thinks and contribute as much as I can ! [11:48] Juju 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 actions [11:48] there are many opportunities to make Juju a big thing [11:49] So 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:54] Alan21: 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 stuff [11:54] like OVS) [11:56] stickupkid do you have the necessary knowledge to guide me through that ? [11:57] unfortunately I don't have the time right now... [11:57] achilleasa interesting, isn't the agent doing this ? [11:57] no pressure, just someday [11:59] My "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 spaces [12:09] Alan21: turns out I was wrong about the bridging bits. Those are indeed applied by the machine agent [12:16] Ah ok, sounded counter-intuitive :D So it means the SSH is only there to enable the agent right? [12:25] pretty much [12:26] now 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 OLM [14:16] achilleasa, another one https://github.com/juju/juju/pull/12420 [14:16] stickupkid or achilleasa: https://github.com/juju/juju/pull/12419 [14:17] manadart, dunno, still waiting for you to review mine ;-) https://github.com/juju/juju/pull/12413 [14:17] manadart, on it [14:18] stickupkid: 12413 need conflict resolution :P [14:18] as if, all my code is perfect [14:18] daaaaaaaaaaaaaaaaaaaaaaaaaaaamn [14:24] stickupkid: https://media4.giphy.com/media/l3q2skPbq1YfqaXWo/giphy.gif?cid=ecf05e47y0k27v555csys9p2flb232hnhqgcyjq3ktk9td3z&rid=giphy.gif [14:24] 100% [14:24] haha [14:49] stickupkid: I'll do your wait-for one next. Haven't forgotten. [14:49] manadart, do this one next https://github.com/juju/juju/pull/12420