16:30:28 <sdake> #startmeeting kolla
16:30:29 <openstack> Meeting started Wed Mar 23 16:30:28 2016 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:32 <openstack> The meeting name has been set to 'kolla'
16:30:35 <sdake> #topic rollcall
16:30:39 <vhosakot> o/
16:30:43 <SamYaple> o/
16:30:44 <sdake> \o/
16:30:47 <rhallisey> hi
16:31:05 <SamYaple> pbourke: ping
16:31:09 <pbourke> o/
16:31:18 <inc0> o/
16:31:23 <akwasnie1> hi
16:31:34 <jpeeler> hey
16:31:37 <nihilifer> hi
16:32:17 <sdake> #topic announcements
16:32:35 <sdake> mitaka branch was created
16:32:57 <sdake> i proposed onthe mailing list creating an rc2 this friday
16:33:05 <sdake> and heard no complaints
16:33:05 <sdake> so thats happening ;)
16:33:25 <sdake> rc3 will still be end of march-april2ndish
16:33:40 <sdake> any other announcements folks have?
16:34:06 <inc0> how do we look like on 1.1.0 front?
16:34:15 <sdake> that is in the agenda inc0
16:34:58 <sdake> #topic  Liberty backport status
16:35:21 <sdake> SamYaple any progress?
16:35:40 <sdake> i think this work is sort of blocked on teh fact that percona broke our gating
16:35:40 <SamYaple> since the last meeting i have not touched liberty due to mitaka needing love
16:36:05 <SamYaple> i havent tested centos, but the ubuntu stuff should be done by end of week assuming mitaka needs no more love
16:36:21 <SamYaple> my proirity is mitaka atm though
16:36:28 <sdake> agree mitaka is the priority
16:36:42 <dave-mccowan> o/
16:36:52 <sdake> we have `50 bugs in various states of being worked on
16:37:13 <sdake> #topic Bug tracking process [timebox 20 minutes]
16:37:28 <sdake> I'm not sure if evyerone reads the mailing list
16:37:32 <sdake> so I will just cut and paste my email here
16:37:34 <sdake> just  a moment
16:37:47 <SamYaple> please paste link :)
16:38:07 <sdake> Thierry (ttx in the irc log at [1]) proposed the standard way projects typically handle backports of newton fixes that should be fixed in an rc, while also maintaining the information in our rc2/rc3 trackers.
16:38:08 <sdake> Here is an example bug with the process applied:
16:38:09 <sdake> https://bugs.launchpad.net/kolla/+bug/1540234
16:38:11 <openstack> Launchpad bug 1540234 in kolla mitaka "rabbitmq cluster does not work with dashes in the hostname" [Critical,Confirmed] - Assigned to weiyu (weiyu)
16:38:11 <sdake> To apply this process, the following happens:
16:38:11 <sdake> Any individual may propose a newton bug for backport potential by specifying the tag 'rc-backport-potential" in the Newton 1 milestone.
16:38:12 <sdake> Core reviewers review the rc-backport-potential bugs.
16:38:13 <sdake> CR's review [3] on a daily basis for new rc backport candidates.
16:38:13 <sdake> If the core reviewer thinks the bug should be backported to stable/mitaka, (or belongs in the rc), they use the Target to series button, select mitaka, save.
16:38:15 <sdake> copy the state of the bug, but set thte Mitaka milestone target to "mitaka-rc2".
16:38:15 <sdake> Finally they remove the rc-backport-potential tag from the bug, so it isn't re-reviwed.
16:38:17 <sdake> The purpose of this proposal is to do the following:
16:38:17 <sdake> Allow the core reviewer team to keep track of bugs needing attention for the release candidates in [2] by looking at [3].
16:38:19 <sdake> Allow master development to proceed un-impeded.
16:38:19 <sdake> Not single thread on any individual for backporting.
16:38:21 <sdake> I'd like further discussion on this proposal at our Wednesday meeting, so I've blocked off a 20 minute timebox for this topic.  I'd like wide agreement from the core reviewers to follow this best practice, or alternately lets come up with a plan b :)
16:38:21 <sdake> If your a core reviewer and won't be able to make our next meeting, please respond on this thread with your  thoughts.  Lets also not apply the process until the conclusion of the discussion at Wednesday's meeting.
16:38:23 <sdake> woops too late ;)
16:38:24 <sdake> so lets talk about this in mor edetail
16:38:28 <sdake> after irc catches up
16:38:38 <inc0> really sdake...? not even paste.openstack.orh?
16:38:41 <SamYaple> ugh
16:38:48 <sdake> inc0 sorry - failure on my part ;(
16:38:50 <SamYaple> you didnt paste link
16:39:33 <sdake> ok, so everyone read throug hthat please
16:39:57 <sdake> the basic idea is we are going to use bug tracking as defined by best practices of the general openstack community
16:40:07 <sdake> that email lcontains the details of what those best practices are
16:40:36 <sdake> this is a proposal not a mandate
16:40:45 <sdake> so I'd like discussion around the idea
16:40:55 <sdake> and wide agreement that thee core reiviewers are on board
16:41:10 <sdake> i've been using the process for 1-2 days, and it works very well for my needs
16:41:20 <jpeeler> perhaps a bit clearer: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090146.html
16:41:24 <sdake> one of the nice htings is it gets rid of single threading
16:41:26 <sdake> thanks jpeeler
16:41:32 <sdake> apologies for not linking that
16:41:37 <sdake> cafeeine free diet ftl
16:42:25 <sdake> are there any questions on the process?
16:43:22 <sdake> hey sbezverk welcome to our meeting :)
16:43:35 <sdake> nobody has a single question?
16:43:37 <sbezverk> Hi sorry keep loosing channel name
16:44:01 <vhosakot> sbezverk: https://wiki.openstack.org/wiki/Meetings/Kolla
16:44:21 <jpeeler> isn't there some magic that happens if the commit message containers the backport potential tag? perhaps having to skip setting it in launchpad?
16:44:32 <jpeeler> containers lol, contains
16:44:36 <sdake> jpeeler no not at this time
16:44:43 <vhosakot> sdake: so, "rc-backport-potential" is needed to backport changes to Mitaka or to Liberty ?
16:44:48 <sdake> the commit message doens't contain a backport potnetial flag
16:44:52 <sdake> the bug tracker is set with that
16:45:01 <inc0> we could perhaps write some magical filter to gerrit that will work
16:45:05 <sdake> vhosakot only for people in the core review team
16:45:07 <sdake> not in the drivers team i mean
16:45:12 <vhosakot> sdake: ah ok
16:45:15 <vhosakot> cool
16:45:23 <sdake> the drivers team goes straight past that step vhosakot
16:45:39 <vhosakot> sdake: ah ok
16:45:40 <sdake> rc-backport-potential is meant for people outside the drivers team
16:45:52 <vhosakot> sdake: didn't know there are two teams :)
16:46:05 <sdake> ya drivers team is responosible for launchpad
16:46:11 <vhosakot> ah ok
16:46:19 <sdake> core review team is responsible for reviews and policy setting
16:46:33 <vhosakot> cool
16:46:38 <sdake> drivers team contains all core reviewers
16:46:40 <sdake> or it should :)
16:46:54 <sdake> as well as anyone else who shows an interest in the project
16:47:21 <sdake> ay more questions?
16:47:47 <sdake> I'd like a rollcall vote of the core reviewers present here
16:47:57 <SamYaple> ==
16:47:59 <inc0> <<
16:48:07 <sdake> i am +1 for the proposal as worded in the email
16:48:28 <pbourke> sdake any chance you could do it on the ML?
16:48:40 <sdake> pbourke i can but i want to ge tthe ball rolling
16:48:44 <pbourke> np
16:48:51 <sdake> we need this right now not in a week
16:49:05 <sdake> i will follow up with a formal vote
16:49:12 <sdake> on the mailing list with a  1 week expiration
16:49:16 <sdake> if you want
16:49:27 <sdake> but id' like a vote on irc now
16:49:28 <rhallisey> hi
16:49:40 <sdake> sounds like we have 3 in favor sdake, SamYaple inc0
16:49:42 <sdake> any others?
16:49:50 <nihilifer> +1 fro me
16:49:53 <jpeeler> +1
16:49:56 <rhallisey> yes
16:50:05 <sdake> need 1 more
16:50:23 <pbourke> can people not just submit a review targeted at the branch
16:50:33 <pbourke> and core +/- 1 the usual way
16:50:40 <inc0> +1 from me
16:50:43 <akwasnie1> +1
16:50:44 <SamYaple> pbourke: this is about bugs specifically
16:50:45 <sdake> pbourke the problem is around tracking
16:50:46 <elemoine_> +1
16:50:48 <inc0> I was part of initial discussion
16:51:05 <sdake> ok we have 7 votes os thats a majority
16:51:12 <sdake> but i wan tto make sure pbourke 's concerns are discussed
16:51:20 <SamYaple> for those wondering why this sounds, this was also discussed back in Dec, without the rc-backport tag
16:51:45 <SamYaple> so this just formalizes it all
16:51:55 <sdake> pbourke this process results in a way to track a patch for master, as well as mitaka as well as liberty
16:52:40 <sdake> pbourke if devs use cherry-pick only for backports there is no priortiization no tracking, no definition of done
16:52:51 <sdake> which means backports get lost
16:52:59 <sdake> which is precisely what happened in liberty
16:53:07 <pbourke> im sure its fine
16:53:09 <sdake> this process should fix that
16:53:23 <sdake> and its relaly only onerou on the ptl
16:53:34 <sdake> eveyrone else has minimal extra buttons to click during bug triage
16:53:39 <sdake> one thing id' ask
16:53:50 <sdake> when doing reviews, click through the link kto the bug
16:53:55 <sdake> and decide if it should be backported
16:54:35 <sdake> if it should, mark it for mitaka
16:54:35 <sdake> lets try notot bakcport the universe
16:54:38 <sdake> but any bug is fair game
16:54:53 <sdake> ok any last thoguhts from anyone?
16:55:23 <sdake> #topic Brainstorming problems people have seen in etherpad [timebox 15 minutes]
16:55:36 <sdake> this is going to be a little bit of  a wierd session
16:55:42 <sdake> i've never done anything ike this in the past
16:55:52 <SamYaple> we should all vote on the issues!
16:55:53 <sdake> but I keep hearingabout all sorts of random faiure scenarios that people know about
16:55:59 <sdake> no voting :)
16:56:04 <SamYaple> :{
16:56:22 <sdake> so what I'd like is for people to write down in a lightweight  fashion any kind of oddness they find
16:56:29 <rhallisey> SamYaple, new voting?
16:56:35 <sdake> using a etherpad
16:56:49 <SamYaple> rhallisey: i think you mean "voting"
16:56:54 <sdake> https://etherpad.openstack.org/p/kolla-mitaka-oddities
16:57:11 <inc0> you want us to use etherpad to write down why etherpad isn't working?
16:57:46 <vhosakot> sdake: is this etherpad for cores ?
16:57:56 <sdake> no anyone can participate
16:57:59 <vhosakot> cool
16:58:13 <sdake> vhosakot nothing is excluded from participation by others in our meetings except policy votess
16:58:21 <vhosakot> ah cool!
16:58:38 <sdake> if you wnt to vote on the midcycle sessions as well, feel free ;)
16:58:46 <vhosakot> ah ok
16:59:08 <sdake> ok we have until 15 after to finish this session
16:59:14 <sdake> nothing may come of it
16:59:24 <sdake> but please try to think back to any of those one off fialure casess you hae had
17:05:42 <sdake> ok 10 minutes left
17:06:05 <sdake> i'mg oing to gie it another 5 for foks to put in ideas
17:06:14 <sdake> if we have run out of iideas by then, we ca nmove on
17:06:19 <sdake> so please keep going ;)
17:06:37 <vhosakot> should the multinode issue where nuetron hosts must be present in a specific order due to Ansible bug be mentioned as an oddity ?
17:06:46 <sdake> vhosakot yes
17:07:05 <sdake> folks this is brainstomring
17:07:09 <sdake> even if your not sure, write it down :)
17:10:42 <sdake> ok i'm going t o file bugs on these issues
17:10:52 <sdake> and bring them into mitaka rc series
17:10:59 <sdake> we can kick them out later if we want
17:11:11 <sdake> they will start out in triaged state
17:11:17 <vhosakot> are we moving to Ansible 2.0 in Newton ?
17:11:23 <SamYaple> vhosakot: yes
17:11:25 <sdake> vhosakot thats been discussed
17:11:27 <vhosakot> cool
17:11:28 <inc0> that is the plan
17:11:36 <vhosakot> cool, just checking
17:12:23 <sdake> #topic format of globals.yml
17:12:36 <sdake> there have been lots of reviews about globals.yml
17:12:44 <sdake> changing things back and forth
17:12:52 <sdake> i'd like to settle on a standard and get it in mitaka
17:13:05 <sdake> since its a critical piece of documentation
17:13:33 <sdake> the debate that came up in the review was whether the defaults should be listed
17:13:45 <SamYaple> useful defaults*
17:13:47 <sdake> and if the default commented value should be the same as the default or opposoite
17:14:05 <sdake> opposiet allows for easy config by remvoing a comment and space
17:14:18 <sdake> SamYaple agree, we dont want to expose everything
17:14:25 <sdake> i am thinnking things like 'enable_heat"
17:14:28 <sdake> which is in globals.yml
17:14:35 <sdake> but enable_swift is not
17:14:36 <SamYaple> comments in config files across all stable software show the default
17:14:37 <sdake> or maybe it was added
17:14:39 <sdake> but you get the idea
17:14:58 <sdake> ok that is a good attern to follow then
17:15:08 <sdake> i'd ike to be consistent with other openstack projects
17:15:32 <sdake> but do we want the commented item to be the default or the opposite?
17:15:37 <sdake> for example we could do something like
17:15:41 <sdake> # Descritpion
17:15:45 <sdake> #  The default is XYZ
17:15:53 <sdake> # enable_heat: yes
17:15:59 <sdake> rather the default is no
17:16:34 <vhosakot> should a single variable be in all three files ? in globals.yml, all.yml and <service name>/defaults/main.yml ?
17:16:35 <sdake> atm we have comletely incosnsitency in thsi file
17:16:38 <sdake> and its 1 of 2 of our go to documents
17:16:56 <sdake> vhosakot yest hat is normal, globals.yml is for an ovveride
17:17:05 <inc0> I think way everyone do this is to comment on default
17:17:09 <inc0> # enable_heat: no
17:17:16 <SamYaple> inc0: correct
17:17:25 <SamYaple> though the eefault for heat is yes i believe
17:17:33 <vhosakot> inc0: yes, that is good... and make globals.yml dictate the final values
17:17:34 <SamYaple> but yes, everyone comments out values that are defaults
17:17:45 <sdake> i think we took heat out of yes default
17:17:49 <sdake> so maybe heat is a bad example
17:17:54 <sdake> lets use manila instead  :)
17:17:59 <SamYaple> there ya o
17:18:00 <SamYaple> go*
17:18:15 <vhosakot> yes, manila has good variables separation..
17:18:35 <sdake> ok folks
17:18:36 <sdake> we are discussing multipe lthings
17:18:39 <sdake> lets focus on one thing now
17:18:42 <sdake> enable_service
17:19:05 <sdake> should the # enable_service be the default or opposite
17:19:25 <sbezverk> would it not be more straight forward not to rely on defaults but on explicitely enabled service?
17:19:37 <inc0> we can also point in docs that defaults are here: https://github.com/openstack/kolla/blob/master/ansible/group_vars/all.yml
17:20:11 <inc0> so we won't do commented all.yml in globals.yml
17:20:21 <vhosakot> sdake: I like all commented out variables _not_ default so that way an operator sees a different behavior when the comments var in uncommented
17:20:33 <inc0> it will also be good documentation for what people can change
17:20:37 <sdake> vhosakot i agree with that line of thinking
17:20:52 <sdake> inc0 ddocumenting defaults as a link wfm
17:21:06 <SamYaple> vhosakot: sdake then the operator has no idea what the default it
17:21:15 <SamYaple> what if there are three options?
17:21:17 <vhosakot> sdake: otherwise, the opearator not only has to uncomment, but also find out what non-deafalt value must be used after uncommenting to see new behavior
17:21:19 <inc0> I'm -2 for commenting oposites
17:21:26 <SamYaple> inc0: agreed -2
17:21:28 <inc0> this is now how ini configs works usually
17:21:37 <SamYaple> we have 2 places where we do it, and that should be fixed
17:21:50 <sdake> SamYaple please expand
17:21:51 <inc0> if operator wants to see a change, it should be because he explicitly changed it
17:22:06 <SamYaple> sdake: we have two places in globals.yml where we comment opposite, we should correct that
17:22:28 <sdake> SamYaple i agree its inconsistent
17:22:35 <inc0> SamYaple, which ones? I think that was the question;)
17:22:37 <vhosakot> ah ok
17:22:40 <sdake> the purpose of this discussion is to come up with the definition of what consistent is
17:23:05 <SamYaple> as stated several times, the _normal_ way to do this is to have a comment with teh default values
17:23:07 <sdake> i like the commenting opposite personally
17:23:10 <inc0> I think we should have commented defaults of most commonly changed options in globals.yml
17:23:12 <sdake> but understand inc0's pov
17:23:15 <inc0> and point to all.yml
17:23:26 <pbourke> can we autogen gloabls in the same way as the build conf?
17:23:38 <vhosakot> let us follow what neutron. nova. glance, etc do for their *.ini files...
17:23:40 <SamYaple> pbourke: not really. because its not jsut from all.yml
17:23:53 <SamYaple> pbourke: its _all_ of ansible and that includes some vars set by tasks
17:23:54 <sdake> vhosakot which is what?
17:23:55 <pbourke> i see
17:24:04 <inc0> vhosakot, and that is commented defaults
17:24:09 <pbourke> that said it should follow the same convention default wise
17:24:17 <sdake> heres the deal, i am super keen to be consistent with other openstack projects
17:24:25 <SamYaple> then defaults it is
17:24:33 <vhosakot> sdake: don't know.. need to check... inc0 confirmed that they comment out defaults
17:24:44 <sdake> ok, then decision made
17:24:45 <inc0> when I said everyone else does that, I meant it;)
17:24:46 <SamYaple> https://review.openstack.org/#/c/294392/
17:24:53 <SamYaple> that review solves all of this conversation
17:25:05 <sdake> thanks for that - now we all are on same page re how globals.yml should work :)
17:25:10 <sdake> I hope folks enforce that
17:25:27 <sdake> #topic open discussion
17:26:15 <sdake> i am working on getting us to be able to apply for the assert upgrade tags in the governance repo
17:26:27 <inc0> duh...
17:26:32 <inc0> so this is tricky
17:26:35 <sdake> it requires alot of change to the governance repo and voting by the tc ;)
17:26:45 <sdake> but its in progress
17:26:48 <inc0> because afaik it's based whether or not we upgrade using grenade
17:27:06 <sdake> inc0 the governance repo has not seen the end of my change reviews
17:27:18 <sdake> those documents are not final, they can be modified by anyone in the community
17:27:27 <inc0> and well, we do not and never be, nor we should
17:27:32 <sdake> atm we are stuck on requriement 1: must be a type:service project
17:27:52 <inc0> that being said
17:27:58 <inc0> we don't really ugrade ourselves per se
17:28:04 <inc0> nor support upgrade of kolla
17:28:13 <inc0> we just...git reset --hard
17:28:24 <sdake> inc0 perhaps a new assertion tag is needed
17:28:30 <inc0> yeah
17:28:35 <sdake> inc0 i'll sort it out
17:28:42 <inc0> let me know if you need any help
17:28:42 <sdake> also going on, the vmt requires architecture diagrams
17:28:53 <sdake> i do need help wit hthe architecture diagrams
17:29:05 <sdake> I am using a web service called gliffy for shared document creation
17:29:13 <sdake> the downside of gliffy is you hae ot pay for it
17:29:25 <sdake> the upside is documents can be share-edited
17:29:42 <sdake> these arch diagrams are needed for the VMT tagging
17:29:59 <sdake> i create some rough ones and send links out
17:30:12 <sdake> if people want to help and dont mind paying for gliffy, you can contribute
17:30:20 <sdake> i know the pay bar sucks
17:30:28 <sdake> its not meant to exclude people
17:30:30 <inc0> google docs are free..
17:30:35 <sdake> I just dont have a bettter way
17:30:37 <sdake> google docs doesn't diagram
17:30:41 <pbourke> google slides
17:30:44 <sdake> anyway meeting time is up
17:30:52 <sdake> google slides diagramming tools are bad pbourke compared to gliffy
17:30:59 <sdake> its nto super expensive
17:31:01 <pbourke> fair enough
17:31:05 <sdake> 10 bucks a month or something
17:31:08 <sdake> anyway our time is up
17:31:12 <sdake> lets overflow into #kolla
17:31:14 <sdake> #endmeeting