Hi! Thanks for your replies. Let me rephrase what I'm looking for: I'm looking for solutions or experiences with having a Change Management Database (CMDB) as "parameter registry" for Ansible. So in a scenario where Ansible does also application configuration, externals could place their changes in a self-service portal (for example list of FTP users or address for mail notifications...). This portal then writes the changes as parameter into a CMDB and triggers Ansible (or AWX) to run for specified hosts to apply the changed/new parameter.
To answer the question: why not give the externals access to git? I want something more user friendly. At the moment I have about 70 different group files in git, each of them would need specific access for each external. I also don't want to teach them how to use git, commit messages, Merge Requests, YAML Syntax, understand our variables in git etc. Thanks Andreas [email protected] schrieb am Donnerstag, 5. August 2021 um 15:13:23 UTC+2: > If that’s the case why not create a survey that these guys can fill out. > The fields are mapped to extra vars and these can then be supplanted as > parameters into the code. (Using the template module ) > > Get Outlook for iOS <https://aka.ms/o0ukef> > ------------------------------ > *From:* [email protected] <[email protected]> on > behalf of Antony Stone <[email protected]> > *Sent:* Friday, August 6, 2021 12:51:53 AM > *To:* [email protected] <[email protected]> > *Subject:* Re: [ansible-project] Infrastructure as Code vs Self-Service > > On Thursday 05 August 2021 at 14:27:00, 'Andreas Hubert' via Ansible > Project > wrote: > > > Dear Ansible Community, > > > > having your Infrastructure in Code, means you manage the code with a > > version control system (e.g. git). I have a case where I also configure > the > > application we deploy with Ansible with various XML configuration files. > > > > Parts of this application configuration should not be touched by others, > > only by my code. But other parts of it should also be configured by > others > > as well, outside of my code, to provide them with Self-Service. > > I understand so far. > > > So parameters should come from an outside source and not be under > > version control. > > I don't get this bit - just because things are external, why would they > not be > version-controlled? > > > In Ansible this could come from a dynamic inventory. > > It could, yes, but why not simply give these "others" who need > Self-Service > write access to selected parts of the git repository, and then get ansible > to > pull everything in from a version-controlled and documented source? > > I would in fact suggest that it is *more* important to have these > Self-Service > inputs under a version control system, because sooner or later someone is > going to say "why is this machine doing that?" and you can point to the > update > they made to the configuration which made it do it. > > If ansible just pulls in non-versioned XML files from somewhere, you have > no > way of telling when a certain change got made, by whom (or why), nor even > what > it was changed from. > > > Regards, > > > Antony. > > -- > "Life is just a lot better if you feel you're having 10 [small] wins a day > rather than a [big] win every 10 years or so." > > - Chris Hadfield, former skiing (and ski racing) instructor > > Please reply to the > list; > please *don't* CC > me. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c86c7929-5647-48ec-87e3-3b5c9159f30fn%40googlegroups.com.
