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