I'm not sure if I understand the requirement as well, but I wanted to bring our config management to the table. We have a Salt Master in place (SUSE Manager) which we use to provision servers (hardware or virtualized) via pxe boot and as a repository management, among other functions. Our openstack base images contain cloud-init which is used to inject basic information about the salt master during first boot. Then the salt-minion is started by clout-init and after the VM has booted successfully it connects to the master and registers. From there the defined salt states and pillars ensure the machine is configured according to its role. We use this mechanism to deploy openstack as well. We also made it work with Ubuntu and curtin as well, which lets us provision Ubuntu machines the same way. Regards, Eugen Zitat von Dmitriy Rabotyagov <noonedeadpunk@gmail.com>:
Um, no, that is the template for OpenStack Heat project. So you define the template and create a stack by feeding the template to Heat. And heat does provide basically Infrastructure as a Code - so whole stack of resources is being created and handled by it. You can also define a parameters that Heat will provide as output, it can be IPs, key names, resources UUIDs - basically any parameter. So as a result you will get a fully configured stack with installed software to it. You can also update resources with same sort of template.
You can check for Heat docs here: https://docs.openstack.org/heat/latest/
But maybe I get wrong your idea or just don't fully understand it...
On Mon, Dec 11, 2023, 18:18 <lostghost1@yandex.ru> wrote:
Reading more about it - I feel like it is. The idea I have currently is, say I have a manifest that describes desired system state - and a tool to work with such a template. I pass the template as OS::Heat::SoftwareConfig and deploy with OS::Heat::SoftwareDeployment. From what I gather, this by itself doesn't do anything - my tool has to query this data, act upon it, then signal that the deployment is done. Is this correct? And I can use practically any tool I want as long as it follows this pattern?
I think you already have all tools for doing that kinda. 1. You can use cloud-init for initial system configuration, which can initially bootstrap and configure software for you. For example, you can do smth like Canonical MAAS does to leverage cloud-init + curtin to do
much anything you want. And cloud-init is usually part of most cloud images as of today. 2. You can also leverage Heat to do pretty much the same with CloudConfig resource or even use SoftwareConfig/SoftwareComponent resources to setup and configure software on the provisioned vm right away. Isn't that what you're looking for? On Mon, Dec 11, 2023, 08:57 lostghost1@yandex.ru wrote:
Hi all, Sorry if this has been asked already, but is it feasible to use OpenStack to configure running systems - including virtual instances, containers, and the physical nodes themselves. I know that conceptually OpenStack takes a hands-off approach - it deals with images in abstract and further configuration is delegated to tools such as Ansible. Same for bare
nodes - you provision them with Ironic, flash an image to them, and
Dmitriy Rabotyagov wrote: pretty metal that's
where configuaration ends for OpenStack. At least this is how I understand it, may be wrong. I was thinking about introducing systems configuration as a first-class concept into OpenStack - that means integration with the package manager, writing of config files from templates, filesystem management in general. The most well thought-out "solution" that there is for systems configuration is Nix in my opinion. I could intergrate it into OpenStack, I could write my own package manager. I haven't decided yet, these are just ideas for a pet project. So if I were to do such a thing, how would I go about achieving it? Obviously I would need to write a Horizon console module for the web UI. But beyond that I'd also need integration with other components. What do you all think?