16:01:40 <mnaser> #startmeeting openstack_ansible_meeting
16:01:40 <openstack> Meeting started Tue Mar  5 16:01:40 2019 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:43 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:51 <mnaser> #topic rollcall
16:01:54 <mnaser> o/
16:01:58 <spotz> o/
16:02:14 <evrardjp> o/
16:02:35 <guilhermesp> o/
16:03:54 <miloa> o/
16:04:44 <raukadah> \o/
16:05:02 <mnaser> #topic office hours
16:05:10 <mnaser> more of an office hours style.  we're down a lot of people
16:05:35 <mnaser> how's everyone's overall time commitments?
16:05:57 <evrardjp> good question
16:06:21 <evrardjp> I think I might have missed a sentence of you mnaser
16:06:49 <evrardjp> my commitment is that I take a few hours of my personal time for this, when I can.
16:07:09 <mnaser> i really appreciate that time you put in evrardjp
16:07:13 <mnaser> release stuff helps, a lot
16:07:22 <evrardjp> I think if we all do that would help :)
16:07:39 <chandankumar> I am putting most of the time on os_tempest stuff currently! cannot say about future!
16:07:39 <guilhermesp> I've been trying to dedicate more and more with reviews and osa related stuff
16:07:59 <CeeMac> tsip, yeah see how that goes, but that error you posted looks like it could be it
16:08:12 <evrardjp> chandankumar: thanks for the work there :)
16:08:28 <chandankumar> evrardjp: you are welcome :-)
16:08:44 <mnaser> yeah, having those convos is very useful
16:10:12 <mnaser> i'm getting a bit concerned that we won't be able to hit much of the goals that we aimed to discussed over the ptg
16:10:27 <mnaser> the work on the venv build stuff has pretty much stopped and i don't expectr it to make any progress
16:11:11 <mnaser> i don't know if we should start to slow down a bit and focus on stablizing things and focusing on a much smaller subset of support architecture
16:11:42 <mnaser> that way, the roles are very unopinionated, but the 'distro' of OSA is much more opinionated
16:14:09 <chandankumar> mnaser: can openstack TC/ foundation can help on these issues?
16:15:01 <mnaser> i don't know how much the tc or foundation can help in this, we're just.. lacking resources.
16:15:55 <evrardjp> there is no magic wand to get people to work on things
16:16:45 <evrardjp> I would wave that one every day
16:16:47 <evrardjp> :D
16:17:08 <mnaser> yepppppp
16:17:09 <chandankumar> mnaser: evrardjp may we can ask from project specific ptl to ask for laision for helping installers!
16:17:42 <chandankumar> *deployment tools
16:18:11 <mnaser> yeah.  we need to get this part figured out
16:18:53 <evrardjp> chandankumar: that's an interesting view
16:19:04 <chandankumar> resources problem is common for I think all openstack projects, I think helping each other will solve the issue!
16:23:00 <mnaser> i'm tempted to export the containers infrastructure outside osa base
16:23:09 <mnaser> so you create your container infra using $some_role
16:23:18 <mnaser> and then use that inventory to provide to osa if you need be
16:24:11 <evrardjp> could you clarify this?
16:24:29 <evrardjp> "export containers infrastructure outside osa base"
16:25:03 <mnaser> openstack-ansible deploys against an inventory "file" only
16:25:17 <mnaser> how you get that inventory file .. you can either use $foo to generate a bunch of containers and feed it to it
16:25:24 <evrardjp> yeah
16:25:26 <mnaser> or you can just run it on your own existing thing
16:25:28 <evrardjp> that was my general plan
16:25:43 <evrardjp> with mitogen you can delegate connections too
16:25:59 <evrardjp> and there are many ppl which generate their inventory like jrosser
16:26:13 <evrardjp> mnaser: the structure is there basically now
16:26:33 <evrardjp> We should reduce tech debt though, by making the things simpler.
16:26:43 <evrardjp> "you need to have the following groups defined"
16:26:51 <mnaser> yeah
16:26:52 <evrardjp> vs "configure your groups"
16:26:56 <mnaser> we need to simplify more and more
16:27:03 <mnaser> with our position right now
16:27:09 <evrardjp> I agree
16:27:37 <mnaser> i think the idea of "labour of love" has finally come time to sunset, unfortunately
16:27:43 <mnaser> we're just not enough
16:28:11 <evrardjp> I think that's fair
16:28:35 <evrardjp> we can sunset all the tooling we have into a different repo like ops
16:28:52 <evrardjp> but I am afraid this would be very impactful for the userfriendliness
16:28:58 <evrardjp> which could have a bad impact on us too
16:28:59 <mnaser> if you ask me
16:29:07 <mnaser> i think the whole thing where we run our own tooling
16:29:20 <mnaser> makes it a lot less user friendly for the person whos like "oh i wanna use ansible to deploy openstack"
16:29:34 <evrardjp> I totally agree with you
16:29:46 <mnaser> "what is this user config file, what is is this user variables file, why am i putting network cidrs, what are these containers, wat"
16:29:52 <evrardjp> that's why I wanted to simplify this and make the inventory totally independant. Now that it's done -- we just have to continue on this path
16:29:53 <mnaser> in my mind, i have an inventory, i want a playbook
16:30:20 <evrardjp> We should just say, your inventory needs to contain x and you need to provide a vip for this.
16:30:26 <evrardjp> it's fair.
16:30:35 <chandankumar> what about treating role as a library let's user decide how they want to run it?
16:30:45 <mnaser> we already do that
16:30:48 <evrardjp> they are like that
16:30:51 <evrardjp> :)
16:30:58 <mnaser> os_tempest is a role that you can clone and do your own thing with
16:31:57 <chandankumar> mnaser: but the problem I am facing currently when we explictily say ansible to use custom ansible.cfg
16:32:13 <mnaser> what are the ansible.cfg changes you're having to implement?
16:32:19 <mnaser> config_template ?
16:32:28 <mnaser> if you install both into /etc/ansible/roles .. it should just work™
16:32:37 <chandankumar> may be mazer can solve most of the issue
16:32:46 <evrardjp> chandankumar: as said earlier, I am consuming roles, including config_template, and don't have a need to change ansible.cfg
16:32:56 <mnaser> mazer could help, but that's still early
16:33:19 <chandankumar> mnaser: because of this https://github.com/openstack/tripleo-quickstart/blob/master/ansible.cfg
16:33:53 <mnaser> that sounds like a tripleo problem
16:33:54 <chandankumar> mnaser: I am working with the tripleo to get it fixed and reuse ansible provided ansible.cfg
16:33:54 <mnaser> :P
16:34:12 <mnaser> tripleo should check `/etc/ansible/roles`
16:34:15 <mnaser> that's the OS default
16:34:21 <chandankumar> mnaser: but once I create rpm package of those, I will be done
16:34:40 <mnaser> IMHO: the packages should dorp stuff in /etc/ansible/roles/ that's the default ansible path
16:34:48 <chandankumar> mnaser: and another path /usr/share/ansible
16:34:50 <mnaser> any mucking around of paths should happen in the rpm layer
16:34:55 <evrardjp> mnaser: alternatively, if they override action plugins location, they could just add the roles path of ansible-config_template to work.
16:35:06 <chandankumar> mnaser: rpm packages dumps stuff in /usr/share
16:35:16 <mnaser> is /usr/share/ansible the default path from ansible?
16:35:24 <chandankumar> mnaser: yes
16:35:29 <evrardjp> that kinda links me to a topic -- releasing of ansible-config_template, ansible-hardening, and releasing of other roles
16:35:40 <mnaser> chandankumar: what about /etc/ansible/roles ? i thought that was the default
16:35:41 <evrardjp> can we talk about that now?
16:35:53 <evrardjp> mnaser: it is until overriden :)
16:35:54 <chandankumar> mnaser: evrardjp https://github.com/ansible/ansible/blob/devel/lib/ansible/config/base.yml#L974
16:36:07 <mnaser> interesting
16:36:19 * mnaser click git blame
16:36:20 * chandankumar read the whole code of ansible
16:36:40 <chandankumar> it is just like another python project
16:36:43 <mnaser> well its been there for at least 2 years
16:36:53 <evrardjp> chandankumar: let me rephrase that for you: If tripleO overrides its config, you need to adapt where you get your ansible roles to match that config
16:36:55 <evrardjp> that's just it
16:37:19 <chandankumar> evrardjp: mnaser https://review.openstack.org/#/q/topic:ostempest_packaging+(status:open+OR+status:merged)
16:37:34 <chandankumar> these will dump stuff at /usr/share location
16:38:00 <chandankumar> evrardjp: ansible.cfg tripleo thing I am working on fixing it!
16:38:49 <mnaser> yeah im ok with dumping it to a default path
16:39:20 <chandankumar> mnaser: I am recently started working on fixing ansible.cfg path
16:39:28 <mnaser> reasonable
16:39:36 <mnaser> evrardjp: you were talking about reeases?
16:39:37 <mnaser> releases?
16:40:11 <evrardjp> yes
16:40:13 <evrardjp> two things
16:40:16 <evrardjp> first
16:40:22 <evrardjp> releasing openstack-ansible
16:40:34 <chandankumar> one another thing, I am thinking to propose ansible to should recognize stuff from virtualenv created path
16:40:35 <evrardjp> I would like to freeze roles, like we usually do for a milestone
16:40:41 <evrardjp> then unfreeze them
16:40:45 <chandankumar> if it is done on ansible side it would be awesome
16:40:46 <evrardjp> I will probably do that on friday
16:40:49 <chandankumar> what you say?
16:41:03 <mnaser> chandankumar: if you can chase that down in ansible, that'd be nice
16:41:10 <mnaser> evrardjp: i don't see why we wouldn't do that
16:41:13 <mnaser> you mean about talking master?
16:41:16 <evrardjp> yes
16:41:27 <mnaser> any specific reason we want to cut releases off master?
16:41:33 <chandankumar> mnaser: evrardjp I know few ansible people in my local office I can hunt them down!
16:41:46 <mnaser> chandankumar: go for it, maybe they might have some good insight :)
16:42:03 <evrardjp> we used to do it, we don't have to do it anymore ... yet, the change to automatically fetch versions with pbr gets us to previous version number + a serious amount of patches
16:42:09 <evrardjp> this would get us to a more normal number
16:42:19 <slin> re
16:42:36 <evrardjp> also I think it's the only one we would produce before rc1
16:42:42 <evrardjp> we'll still produce a rc1 for branching
16:42:56 <chandankumar> ah time to start a new email thread on where to place stuff related to ansible stuff with respect to kolla-ansible
16:42:58 <mnaser> evrardjp: i'm wondering if there's value in doing that
16:43:03 <mnaser> chandankumar: ++
16:43:10 <evrardjp> mnaser: alternatively we can just do a pbr patch
16:43:33 <evrardjp> I mean an empty commit to bump pbr version, not patching pbr
16:43:42 <evrardjp> pbr recognized version*
16:44:02 <evrardjp> but I think it's better to have a real commit to freeze a-r-r
16:44:14 <evrardjp> because the code would match that version of the roles forever
16:44:18 <mnaser> wasnt pbr version bumped when we released automatically?
16:44:34 <evrardjp> master is not released automatically every two weeks
16:44:45 <evrardjp> because the roles are not frozen
16:44:52 <evrardjp> for agility with devs
16:45:02 <evrardjp> (still want master)
16:45:03 <mnaser> right, but i'm wondering if we even need to release master every 2 weeks
16:45:14 <evrardjp> that's not what I meant :)
16:45:18 <evrardjp> ok let me rephrase
16:45:20 <mnaser> okay, i'll try to listen :)
16:45:32 <evrardjp> master has to be released at least once
16:45:55 <evrardjp> in this cycle, with our changes to automatically find version, it would be smart to do it twice
16:46:00 <evrardjp> one now
16:46:04 <evrardjp> and then one in rc1.
16:46:16 <evrardjp> why one now:
16:46:27 <evrardjp> Because it's more explicit than an empty commit
16:46:40 <evrardjp> (to bump pbr recognized version)
16:46:55 <evrardjp> Because it will allow us to release at least an alpha of stein
16:47:18 <evrardjp> Because I think we should at least have one before rc1.
16:47:39 <evrardjp> not that we must, but that makes sense to have one in all those milestones
16:47:40 <mnaser> i think i am seeing us resolving the problem in another way
16:47:51 <evrardjp> ok
16:47:56 <evrardjp> listening :)
16:47:58 <mnaser> we stop putting master in integrated repo and do automatic version bumping of sha in gate
16:48:09 <evrardjp> ahah
16:48:12 <evrardjp> I have the code for that
16:48:14 <mnaser> so master is always a functional set of commits
16:48:21 <evrardjp> I am fine with that
16:48:30 <mnaser> it will also make our gate much more stable
16:48:34 <evrardjp> it would mean all the branches match.
16:48:47 <evrardjp> I was told this would be a pain for devs
16:49:10 <evrardjp> in fact it could be if we don't test a role patch with integrated
16:49:42 <evrardjp> i am fine with making this more stable in master, but I think we need to test patches with integrated to ensure the next bump wouldn't fail
16:49:54 <evrardjp> things can go through cracks easier though.
16:50:07 <mnaser> right
16:50:19 <evrardjp> but I think it's fine, as it would leave us a week or two to get the ball rolling
16:50:21 <mnaser> if we do that though, then wee can technically always point to master?
16:50:32 <evrardjp> what do you mean?
16:51:07 <evrardjp> you mean have an a-r-r tracking master branch, but have a freeze updated every two week in master?
16:51:16 <mnaser> there isn't a point in freezing if we test every commit against integrated
16:51:21 <mnaser> because master technically always works?
16:52:23 <evrardjp> Yes I think it's a bad idea to test integrated all the time anyway, that's what we used to do
16:52:39 <evrardjp> it was painful
16:52:55 <mnaser> will it be just as painful... if... we're always using metal
16:52:55 <mnaser> :p
16:53:10 <evrardjp> everything is better with metal
16:53:17 <evrardjp> (joke)
16:53:26 <mnaser> haha
16:53:52 <evrardjp> should we just propose this on the ML?
16:54:19 <evrardjp> I think we still need to do a release though, and discuss how to improve the future later
16:54:29 <evrardjp> for that release, I believe it would be best to freeze roles
16:54:37 <mnaser> that seems fine, and i agree with freezing if we will release
16:54:40 <evrardjp> I am just informing you I will do that :)
16:55:23 <evrardjp> ok on that point we agree -- I still want to raise something else
16:55:44 <evrardjp> should we regularily release ansible-config_template, ansible-hardening and (maybe) others?
16:55:48 <evrardjp> We currently don't
16:55:56 <evrardjp> just running from their branch
16:56:09 <evrardjp> I would prefer not to do any more work
16:56:41 <evrardjp> but if people start to ask for pip installable roles, we should probably release them in a certain cadence?
16:59:13 <mnaser> evrardjp: i think maybe we can treat them as actual project
16:59:22 <mnaser> we can review changes and then release on demand?
16:59:26 <evrardjp> yeah so independently released
16:59:33 <chandankumar> evrardjp: if we release config_template as a pip stuff, it will help reducing copying script as it is done in ceph-ansible
17:00:16 <slin> is 172.29.236/22 hardcoded anywhere?  I set different container nw in the deployment but my haproxy refers to this :(
17:00:23 <chandankumar> that bring me an instesting idea for mazer if a module is released on pip ho to install at custom path!
17:00:30 <chandankumar> *how
17:00:31 <evrardjp> mnaser: that's a change in mindset, and I am fine with that model. As long as we keep the roles and the pip versions decoupled, I think we are good.
17:00:41 <mnaser> evrardjp: +++ i agree
17:00:42 <mnaser> #endmeeting