Open Stack

On Tue, May 28, 2019 at 10:50 AM Donny Davis <donny at fortnebula.com> wrote:

> Wouldn't it be easier just to use OSA once things get past laying down the
> OS and the relevant configs for the network interfaces. It seems like
> building it all in ansible has already been done, and much of the work
> could be used. I understand that both have different opinions on how to
> deploy openstack, but it would lower the lift in getting an ansible based
> deployment operational much sooner.
>
>
>
>
It's not easier because we then have to translate our current puppet/hiera
configuration into their ansible vars.  We're trying to come up with a
generic construct that still allows end users to override specific
configuration items without having to continue to use puppet to lay down
the configuration.   The proposed format maps more to what oslo.config
needs and less about the implementation of what is ultimately doing the
configuration writing. We still also need to support backwards
compatibility to a certain extent. We unfortunately cannot just drop in OSA
because we have our own opinionated assumptions about how we do
containers/orchestration so for this conversation it's just about
simplifying or reorganizing the configuration bits.  In the longer term if
we decided that we wanted to stop using configuration files and switch to
"something else", we wouldn't then need to figure out how to rip out OSA
(if they don't support the "something else").

Thanks,
-Alex


>
>
> On Tue, May 28, 2019 at 12:17 PM Clark Boylan <cboylan at sapwetik.org>
> wrote:
>
>> On Mon, May 27, 2019, at 4:36 PM, Emilien Macchi wrote:
>> > (First of all: thanks to Alex Schultz who initiated the discussion
>> > during the last PTG).
>> >
>> > Context:
>> > With the containerization of the services in TripleO, our usage of
>> > Puppet is pretty much limited to laying down parameters into
>> > configuration files.
>> > Our long term goal is to reduce our number of tools in TripleO and
>> > converge toward more Ansible and we are currently investigating how to
>> > make it happen for Configuration Management, in a backward compatible
>> > and non-disruptive way.
>> >
>> > Problems:
>> > - Our current interface to configure things is very tight to Puppet and
>> > Hiera, which would make it complicated to bind it with Hiera. Some of
>> > us have tried (to create some Hiera module in Ansible) but clearly this
>> > is not the path we want to take as far I know.
>> > - We don't use the logic (generally) in the Puppet modules and again
>> > only care about the configuration providers (in puppet-openstacklib and
>> > for some services, templates files), so the Puppet modules now do too
>> > much for what we need in TripleO.
>> >
>>
>> snip
>>
>> I'm not sure if this is useful but what the Infra team did was to
>> transplant all of its hiera data into /etc/ansible/hosts/host_vars and
>> /etc/ansible/hosts/group_vars. Then we updated our puppetry to pull hiera
>> data out of there. This means that puppet and ansible read the same data
>> sources which has made transitioning things easy for us.
>>
>> Though I think the ansible-role-puppet role copies hiera data sources
>> from /etc/ansible/hosts to the appropriate puppet hiera location on the
>> remote source. But you mostly don't have to think about that and there is
>> no double accounting from an ops perspective.
>>
>> Clark
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190528/50abc531/attachment.html>