16:00:03 <mnaser> #startmeeting openstack_ansible_meeting
16:00:04 <openstack> Meeting started Tue May  7 16:00:03 2019 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:05 <mnaser> #topic office hours
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:07 <mnaser> o/
16:00:08 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:13 <noonedeadpunk> o/
16:00:29 <mnaser> hey noonedeadpunk how's it goin
16:00:32 <mnaser> you were missed at the summit :)_
16:01:17 <noonedeadpunk> Yeah, I was reading yours twitter and was really kinda jealous about missing it...
16:01:56 * noonedeadpunk looking for flights to Shanghai
16:03:04 <noonedeadpunk> btw extra congrats with superuser awards:)
16:05:34 <noonedeadpunk> so, what I've missed regarding train plans and new collaborations?:)
16:08:23 <mnaser> thanks noonedeadpunk  :D
16:08:27 <mnaser> did you check out the ether pad?
16:10:11 <noonedeadpunk> oh, it was updated. Will look trough it today
16:10:19 <mnaser> yep!
16:10:25 <mnaser> tons of good discussion
16:11:29 <noonedeadpunk> Yeah, I was pretty excited about a letter from kolla-ansible team, regarding collaboration.
16:16:07 <noonedeadpunk> personally I feel, that containers are good thing, and we probably shouldn't fully drop their support
16:17:43 <logan-> o/
16:22:25 <logan-> yep, agreed on not dropping machine container support. the migration path would be painful for a lot of deployers. switching the default deployment to metal seems like a reasonable thing, but it'll be interesting to review a spec about that
16:26:01 <mnaser> yeah
16:26:27 <mnaser> logan-: noonedeadpunk I wonder if there would be a way to handle machine container management outside OSA
16:27:01 <logan-> the first step to that I think is to define the group structure in a yaml inventory and shift it out of the dynamic inventory
16:28:09 <logan-> ansible-inventory can be useful for analyzing how we currently structure it, but it outputs pretty garbage inventory structures for complex inventories, so I don't think you'd want to just dump ansible-inventory yaml output to shim out groups and call it a day
16:28:49 <logan-> but getting the group tree as a base inventory layer, and then adding hosts on top of that with additional inventories (whether metal or container) is a good direction imo
16:29:42 <mnaser> logan-: yeah I think we need a 'defined' inventory api so to speak
16:29:58 <logan-> yep
16:33:59 <mnaser> we have a lot of work, but I'm not sure how much of it we can get done this cycle
16:34:03 <mnaser> most folks seem busy
16:35:16 <noonedeadpunk> yep, etherpad seems really filled
16:35:31 <logan-> yeah. and this inventory thing has been a topic for idk 3-4 ptgs in a row now. it seems no one has time to go fishing around that mess of dynamic inventory we have.
16:39:33 <noonedeadpunk> the problem of baremetal is that distro packages of different services may actually have conflicts, which are hard to resolve...
16:48:37 <NobodyCam> would this be a good time to see if https://docs.openstack.org/openstack-ansible/latest/admin/scale-environment.html could be reviewed, I've been attempting to add a new shared infra node node and encountered several issues
16:55:08 <mnaser> noonedeadpunk: how so?
16:57:25 <noonedeadpunk> So I have one non-OSA deployment, installed from packages on Ubuntu. And all services are without containers on bare metal. And touching some python package usually results in upgrading everything.
16:58:24 <noonedeadpunk> So in if you would like just to add some new service to the node? or just update single python package, you should be ready for the full upgrade
17:00:58 <noonedeadpunk> so I don't feel that bare metal distro installs are really good idea, as they are pretty hard to maintain, imo
17:14:11 <mnaser> Yeah bare metal distro is an exploding upgrade
17:14:16 <mnaser> That’s just part of that decision
17:14:28 <mnaser> #endmeeting