16:01:50 <spotz> #startmeeting openstack_ansible_meeting
16:01:50 <spotz> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:50 <spotz> #topic Roll Call
16:01:51 <openstack> Meeting started Thu Sep 28 16:01:50 2017 UTC and is due to finish in 60 minutes.  The chair is spotz. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:55 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:02:13 <evrardjp> o/
16:02:25 * hwoarang is around
16:02:33 <evrardjp> in da place even!
16:03:23 <spotz> Let's see if we get anyone else as it's a short agenda
16:04:30 <evrardjp> well I have things to say, let's hope at least some ppl will listen :p
16:04:53 <logan-> o/
16:04:55 <spotz> :)
16:05:35 <spotz> hehe I was getting my reping ready:)
16:05:50 <jmccrory> o/
16:06:07 <evrardjp> works apparently :)
16:06:21 <spotz> #topic Forum @ Sydney Summit - 6-8 November - Sydney, AU
16:06:38 <spotz> #link https://etherpad.openstack.org/p/osa-sydney-summit-planning
16:06:57 <evrardjp> ok for the forum, I proposed a generic "ops" session
16:07:28 <spotz> Makes sense, there going to be onboarding again?
16:07:32 <evrardjp> please don't hesitate to add the things you'd like to talk/have a feedback about (whether you can attend or not)
16:07:39 <evrardjp> I don't know
16:07:46 <evrardjp> there is a hackathon before
16:08:02 <evrardjp> But it seems it's already organized and I am not sure we can simply join
16:08:08 <cloudnull> o/
16:08:11 <prometheanfire> o/
16:08:54 <evrardjp> I think that's all we can say
16:09:10 <evrardjp> next topic?
16:09:29 <spotz> evrardjp: hackathon is different there is the Upstream Institute before hand which is more open intro and some onboarding as well
16:09:48 <spotz> #topic Release Planning and Decisions
16:09:53 <spotz> that's you:)
16:10:21 <evrardjp> yeah that's a big topic
16:10:24 <evrardjp> at least today
16:10:32 <evrardjp> let's start with the easy things
16:10:41 <cloudnull> re: sydney, I talked to robin from ansible the other day
16:10:49 <evrardjp> cloudnull: go ahead
16:10:52 <cloudnull> they're planning an ansible day
16:10:58 <cloudnull> it be good to contribute
16:10:58 <evrardjp> oh great
16:11:06 <evrardjp> yes indeed. Let's be present!
16:11:12 <cloudnull> they're also going to do a couple talks/meetups
16:11:18 <cloudnull> itd be good to participate there too
16:11:36 <spotz> Definitely
16:11:37 <evrardjp> thanks for the networking cloudnull! :D
16:11:38 <cloudnull> I think they're still looking for folks to join pannels etc
16:12:02 <evrardjp> if you know more, ping me. I will deal with it :)
16:12:25 <evrardjp> ok to go back to releases
16:12:36 <prometheanfire> isn't she still around castle today?
16:13:16 <evrardjp> I have submitted releases for Pike and Ocata, which are right now stuck in infra/releases limbo. I will track that to get a release soon
16:13:31 <evrardjp> Newton will get the same treatment
16:13:39 <evrardjp> this way we have aligned releases
16:13:53 <prometheanfire> is this the last newton, or does osa have one more?
16:13:58 <spotz> What are we going to do about newton-EOL, will that affect the COA as it uses our stuff
16:13:59 <evrardjp> (I will come back to that later)
16:14:12 <logan-> is the virt type fix in this ocata tag?
16:14:15 <evrardjp> so, before that
16:14:37 <evrardjp> P and O have will have a tag that includes libvirt qemu instead of kvm fix
16:14:56 <evrardjp> however they won't have the centos fix you included logan-
16:15:01 <logan-> ok
16:15:25 <logan-> cool
16:15:43 <evrardjp> I'd rather leave the patches as is, and if we consider it critical, bump directly in the integrated repo, this way it's included for next release for sure
16:16:04 <evrardjp> the current "release" patches as is
16:16:21 <evrardjp> so it brings me to the big topic I wanted to discuss about releases
16:16:29 <evrardjp> How we will do releases in the future
16:16:49 <evrardjp> In the future, we'll continue to have 2 week's release schedule
16:17:10 <evrardjp> and we can continue to submit "emergency" releases in case of security issues
16:17:24 <evrardjp> but I'd like this process to be straightforward for anyone
16:17:47 <evrardjp> so I am cleaning the release process, in order for anyone to be able to submit a release.
16:17:59 <evrardjp> This way, no bus factor or anything :p
16:18:39 <evrardjp> In the future, the two week schedule should be aligned with the end of month
16:19:09 <evrardjp> this way we'll always release before end of month, and people at the beggining of the month can consume a new OpenStack-Ansible
16:19:54 <evrardjp> There will still be room at the community meeting to discuss about the "end of month" release
16:20:10 <evrardjp> but these discussions should be fairly limited
16:20:26 <evrardjp> the idea behind all of that is:
16:20:48 <evrardjp> - We have a fixed scheduled train, so we don't ask ourselves questions, it's simple, and no need to think about it
16:21:05 <evrardjp> - We shouldn't even discuss it because everything is on rails :)
16:21:09 <evrardjp> (toot toot)
16:21:50 <hwoarang> hehe
16:21:55 <evrardjp> There would be sometimes exceptions to this 2 week release train, like next week for newton EOL
16:22:30 <evrardjp> (or maybe it will be after next week)
16:22:33 <hwoarang> sounds reasonable to me. so basically you propose some kind of 'automated' 2 week release unless something major blocks it
16:22:44 <cloudnull> ++ that'd be great
16:23:20 <evrardjp> no it's automated 2 week release train, let's not think about major blocking :)
16:23:26 <evrardjp> but we can have extra ones
16:23:30 <evrardjp> for special cases
16:23:41 <evrardjp> (EOL, security)
16:23:57 <evrardjp> but also simplified for everyone and documented
16:24:57 <hwoarang> ok
16:25:10 <evrardjp> we still need human intervention to qualify what a release is, because we are using semver, and we don't auto bump to a minor instead of a patch with our code
16:25:46 <evrardjp> anyway, long story short, except mid month and end of month releases, and we discuss those EOM
16:26:35 <hwoarang> ok
16:27:03 <evrardjp> prometheanfire: so to answer your question, newton will still get one now, and we should have one when the other projects are EOL, to consume EOL projects.
16:27:10 <odyssey4me> the reason for not doing that and for having the PTL do the release requests has been because the release process is manual and needs human judgment here and there
16:27:23 <evrardjp> agreed
16:27:27 <prometheanfire> evrardjp: cool
16:27:35 <evrardjp> but that knowledge need to be spread
16:27:42 <odyssey4me> if we make the scripts less clunky, more reliable, etc then we could probably just automate it
16:27:47 <logan-> ++ sounds great
16:27:51 <evrardjp> I am working on that already
16:28:04 <evrardjp> simple functions, with a documentation that could go to our release guidelines
16:28:14 <odyssey4me> sounds good
16:28:22 <odyssey4me> don't work yourself to death ;)
16:28:38 <evrardjp> technically only PTL and liaisons should request releases, but this way we have guidelines
16:28:39 <logan-> i have a python thing that will bump ansible-role-requirements to the head of branches and maintain comments in the format we have like "HEAD of XXXX as of <date>" would be happy to share that evrardjp
16:28:59 <evrardjp> odyssey4me: well in case of death, you'd have something that help you releasing :p
16:29:29 <evrardjp> we already have some in our code tree too logan-, but definitely worth checking with you
16:29:40 <evrardjp> I think I quickly drafted this this morning though :p
16:29:53 <evrardjp> let's move to another topic :)
16:30:04 <evrardjp> (but thanks logan- :) I will have a look! )
16:30:15 <logan-> sure
16:31:04 <odyssey4me> logan- I think you may have meant to refer to the git sources for the service projects, not a-r-r ?
16:31:12 <logan-> both odyssey4me
16:31:18 <odyssey4me> oh neat
16:31:26 <logan-> actually no, I don't think ti would support the service projects yet but it could be made to do so easily
16:31:28 <odyssey4me> anything to replace my crufty bash script :p
16:31:53 <cloudnull> yay crufty bash  !
16:31:57 <evrardjp> odyssey4me: I already wrote something in python that is now handling ordered dict for YAML loading for easier reviews. Works already for A-R-R
16:32:01 <logan-> #link https://gist.github.com/Logan2211/f8ad9a03502e69971d2eee96049719d7
16:32:03 <spotz> When newton goes EOL are they going to still be able to access it for the COA?
16:32:21 <spotz> #topic Blueprint work
16:32:22 * cloudnull a fan of cruft bash :D
16:32:29 <evrardjp> spotz: yeah it's just becoming a tag instead of a branch
16:32:42 <spotz> evrardjp: ok I'll give Anne a heads up
16:32:47 <odyssey4me> spotz yes, it will still work for as long as the git repo exists
16:33:09 <spotz> I figured it would but I know devstack and packstack break when EOL
16:33:19 <spotz> Blueprints!
16:33:39 <evrardjp> for blueprint work, I think there are 4 things that I find very important right now
16:34:08 <evrardjp> The first two are odyssey4me and cloudnull's
16:34:18 <evrardjp> one for hyperconverged
16:34:31 <cloudnull> i'd like to see https://review.openstack.org/#/c/499882/ get in --cc jmccrory
16:34:33 <evrardjp> and one (well two basically) to change the build process
16:35:13 <evrardjp> cloudnull: on the hyper converged stuff, we need to make sure the periodics don't break ;)
16:35:17 <evrardjp> I trust you!
16:35:32 <evrardjp> I'd hate revert again...
16:35:42 <cloudnull> and https://review.openstack.org/#/c/476121/ -- is very interesting from a tech perspective
16:35:48 <odyssey4me> from what I saw this morning, the periodics are still not quite there yet - upgrades are still busted
16:35:59 <evrardjp> only for ceph
16:36:12 <cloudnull> evrardjp: I would not lie to you
16:36:14 <cloudnull> :D
16:36:27 <evrardjp> well we can discuss the false positives on openstack health dashboard another time :)
16:36:36 <odyssey4me> evrardjp you may not have seen yet, but cloudnull has revised the spec with the promise to provide upgrade tooling to clean up the inventory
16:36:42 <evrardjp> so cloudnull and odyssey4me if you need any help
16:36:45 <evrardjp> just ping
16:36:53 <cloudnull> yes i have
16:37:02 <odyssey4me> thanks for doing that cloudnull :)
16:37:12 <evrardjp> yeah. I will review it as soon as possible
16:37:19 <cloudnull> tyvm
16:37:21 <evrardjp> I didn't see that
16:37:23 <evrardjp> so thank you!
16:37:33 <evrardjp> for the rest of the blueprints
16:38:20 <evrardjp> there are a few interesting ones, like the ovs, the messaging changes but also the inventory cleaning and the uwsgi
16:38:47 <odyssey4me> I looked through the specs repo this morning - it looked like some needed an update after the PTG... and for the sake of my own sanity I'm staying away from the networking ones. :p
16:38:50 <evrardjp> I didn't got the chance to work on uwsgi
16:39:06 <evrardjp> haha
16:39:07 <evrardjp> ok
16:39:24 <evrardjp> well like I said, for this cycle, you two have prio
16:39:27 <odyssey4me> whoh agreed to put together that uwsgi/load balancing spec? was it jmccrory and logan- ?
16:39:44 <spotz> 20 minute warning with only open discussion left
16:39:46 <evrardjp> jmccrory: logan- and I
16:39:51 <evrardjp> will be working on that
16:39:57 <evrardjp> but anyone free to join :)
16:40:16 <evrardjp> a quick update for the inventory cleaning work
16:40:21 <odyssey4me> ah ok, that'll be interesting although not entirely essential - I think cloudnull might be ineterested to know more about it though so get the spec up soon :)
16:40:56 <jmccrory> think andymccr's spec for initial uwsgi+nginx may still be out there, some of that could probably be split out to start this new one
16:41:16 <evrardjp> I'd rather work on the priorities right now, but yes if logan- or jmccrory could spend some cycles on uwsgi fast router that would be great
16:41:34 <evrardjp> (according to what we said @ the PTG)
16:42:18 <odyssey4me> hmm, that's weird - nothing published since newton apparently: http://specs.openstack.org/openstack/openstack-ansible-specs/
16:42:22 <evrardjp> what we've said at the ptg was discussing the position of LB + uwsgi for "new kind" of apps, and still remain with "old kind" if need be. So we'd need a new spec
16:43:03 <evrardjp> I am only checking on https://github.com/openstack/openstack-ansible-specs :D
16:43:32 <spotz> ok email heads up sent to Anne at the foundation
16:44:08 <logan-> yeah my focus was more on replacing our haproxy role with something less rigid. i don't know much about the uwsgi stuff
16:44:31 <evrardjp> jmccrory: FYI I didn't got the chance to push changes since our last convo about the inventory. But It's very cleanable, and we are close to have an ansible ready static inventory that's generated from our thing.
16:45:07 <evrardjp> logan-: that's great and that's completely appropriate!
16:45:20 <evrardjp> I heard ppl hoping for that
16:45:47 <evrardjp> anyone has something to ask about specs?
16:45:52 <evrardjp> Or to raise?
16:46:14 <odyssey4me> I have something to raise, but it's not related to specs - more open discussion.
16:46:18 <evrardjp> odyssey4me: I will not chase this web page. It's not easy to find by contributors anyway :p
16:46:21 <evrardjp> ok
16:46:29 <evrardjp> let's move to that topic then!
16:46:40 <evrardjp> #topic open discussion
16:46:42 <odyssey4me> evrardjp no worries, it looks like the specs pages for other projects are fine so it's likely our job broken or something - I'll check it out
16:46:51 <spotz> #topic open discussion
16:46:57 <spotz> *phhbts*
16:47:02 <odyssey4me> :)
16:47:02 <evrardjp> :)
16:47:27 <odyssey4me> alrighty - I've sent http://lists.openstack.org/pipermail/openstack-dev/2017-September/122794.html to the ML related to a little thing I'm doing on the side to try and cut down some of our tech debt
16:47:49 <odyssey4me> I'm hoping we get a more positive response from the packagers than previously.
16:47:51 <evrardjp> oh yes it had an impact on release's toolkit :D
16:48:02 <odyssey4me> So far the RDO crew via reviews have been very welcoming.
16:48:12 <evrardjp> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122794.html
16:48:34 <evrardjp> I love the effort
16:48:36 <evrardjp> thank you
16:48:52 <spotz> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122794.html
16:49:00 <spotz> ok no diff:)
16:49:13 <odyssey4me> looks like gerritbot might be broken or something
16:49:39 <spotz> :(
16:49:47 <odyssey4me> anyway, I thought I'd just raise it as a heads-up
16:50:05 <odyssey4me> the hope I have is that we can kill templates and the git sourcing and keep it simpler
16:50:24 <odyssey4me> if we can't do that, then the build process for packages is going to have to carry it, which isn't nice
16:50:56 <evrardjp> but I don't understand how you want to do that, like template it at the destination?
16:51:10 <evrardjp> or a push pull mechanism?
16:51:17 <evrardjp> pull/push*
16:51:30 <evrardjp> but I like the idea of having it uniform and not in three
16:51:33 <evrardjp> tree*
16:51:48 <evrardjp> so thanks!
16:52:35 <spotz> 8 minute warning
16:52:41 <logan-> thanks odyssey4me
16:52:45 <evrardjp> On open discussion I have something to add, I have made a ics (google agenda) with what will happen in this cycle for OSA that's not already in the standard dev calendar
16:52:53 <logan-> nice to see many projects are merging it
16:52:57 <odyssey4me> yeah, not sure yet - those details can be figured out once we have the upstream stuff done
16:53:21 <evrardjp> odyssey4me: if we build on localhost problem is solved :p
16:53:34 <odyssey4me> evrardjp not entirely
16:53:44 <evrardjp> I know ;)
16:53:58 <odyssey4me> if it's not in the wheel we're forced to git clone - if it's in the wheel, no git clone needed :)
16:55:29 <evrardjp> ok on another topic
16:55:51 <evrardjp> I will appoint liaisons soon, I will send a series of mails next week
16:55:51 <spotz> 5 minute warning:)
16:56:14 <evrardjp> if you're interested by taking more work, ping me anytime :D
16:56:24 <odyssey4me> alright, nothing more from me - I'm hoping to find some time to get cracking on revising a role or two based on the specs now that they're merged
16:56:59 <odyssey4me> any thoughts on milestones we'd like to see major changes stop at ?
16:57:00 <odyssey4me> M3?
16:57:03 <evrardjp> I've said a lot today, I'm good
16:57:03 <odyssey4me> or RC1?
16:57:15 <evrardjp> it's m3 according to agenda I think
16:57:43 <odyssey4me> yes, the standard upstream schedule puts feature freeze at M3
16:57:45 <evrardjp> but before m3 it's packed with small breaking updates too , so let's play it by ear.
16:57:48 <evrardjp> Let's focus on m3
16:58:17 <spotz> 2 minutes:) We haven't run this long in ages:)
16:58:24 <evrardjp> https://docs.openstack.org/openstack-ansible/latest/contributor/contribute.html#development-cycle-checklist
16:58:29 <odyssey4me> are we holding back on major changes up to M1 to allow easier backports, or are we going ahead straight away?
16:59:16 <evrardjp> Because M1 is kinda nice and easy for us, we could move our deliverables from M2 into M1 then do these massive changes
16:59:54 <spotz> 1 minute
16:59:55 <evrardjp> but I don't think this should be an objection on your 2 big specs odyssey4me and cloudnull
17:00:02 <dianyu> Hi, I recently hit an error when launch instance on horizon as following: Error: No sql_connection parameter is established with newest networking master and devstack stable/pike. Anyone met the similar problem?
17:00:10 <openstack> LouisF: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
17:00:13 <odyssey4me> I'd suggest moving all the M2 stuff to M1, and make M2's goal to be features like M3
17:00:14 <evrardjp> let's wrap up!
17:00:18 <spotz> Times up gang
17:00:22 <spotz> #endmeeting