21:00:39 #startmeeting Product Working Group 21:00:40 Meeting started Mon Dec 7 21:00:39 2015 UTC and is due to finish in 60 minutes. The chair is barrett. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:44 The meeting name has been set to 'product_working_group' 21:00:58 Hi Folks - Who is here for the Product WG team meeting? 21:01:07 I'm hre 21:01:08 here 21:01:12 Hi Carol 21:01:19 o/ 21:01:19 o/ 21:01:20 HI Pete 21:01:43 o/ 21:01:54 o/ 21:02:06 o/ 21:02:35 o/ 21:02:54 o/ 21:03:09 great 21:03:13 #topic Agenda 21:03:25 #link: https://wiki.openstack.org/wiki/Meetings/product-team#December_7.2C_2015_Product_Team_Meeting_Agenda 21:03:34 You can find the agenda for today at the link 21:03:43 #topic User Story Updates 21:04:00 Leong & Kenny - Can you lead off with an update on Rolling Upgrades? 21:04:04 Sure 21:04:11 Thanks 21:04:32 Frankly not much movement since last week. I've been compiling updates to the User Story in the form of a gaps analysis 21:04:37 which has been happening offline 21:04:48 I need to contribute those ammendments 21:05:08 Do you have a target date for the completion of the gaps analysis? 21:05:20 but work is being planned, across versioned object support, schema migration, and live migrate 21:05:33 I'd like to make the ammendments to teh user story on Wednesday. 21:05:35 based on the current product wg workflow, i wondering if we should move this rolling upgrade user stories to "tracked" 21:05:45 #link: https://wiki.openstack.org/wiki/ProductTeam/User_Stories#User_Story_Workflow 21:05:45 o/ 21:05:59 leong I would think we need the gaps analysis first to target what we are tracking 21:05:59 Hi Rockyg 21:06:15 But I agree that we should be able to do that this week 21:06:21 Leong - Great point. 21:06:23 Gap Analysis is in phase "track" 21:06:27 I've broken down what is in flight for the Mitaka release 21:06:31 no phone bridge today? 21:06:33 oh, sorry, I didn't read the link :) 21:06:38 then yes we should promote it to tracked 21:06:47 leong I can do that when I commit the gaps analysis changes 21:06:57 arkady_kanevsky: nope, we're going IRC only for our team meetings starting today 21:07:07 ok 21:07:10 kencjohnston: +1 21:07:12 or we can do it today. It is definitely resourced. 21:07:15 (hi all, sorry for being late) 21:07:17 for Proposed stage, the next criteria to move into "tracked" is commit resource 21:07:22 Hi Shamail 21:07:29 hi shamail 21:07:41 barrett OK, if there isn't any other thoughts I'll plan on doing that. 21:07:45 we are proposing moving "rolling upgrade" into "tracked" 21:07:49 Can I register an action for myself? 21:07:57 so need to be done to move it to tracked? just move from one diretcory to another? 21:08:05 i believe a chair needs to record actions (or chair someone to do it) 21:08:06 kencjohnston: No, but I will do it for you :) 21:08:08 Arkady_Kanevsky correct 21:08:26 #action Kencjohnston move Rolling Upgrades to Tracked folder 21:08:38 actually, for review purposes I'll split them up. 21:08:50 I'll first move it to tracked, since the gaps anayslsis isn't required and we can all review that commit 21:09:04 kencjohnston: +1 21:09:04 then I'll add the gaps analysis so we can comment on that one separately 21:09:09 I'll do the tracked thing tonight. 21:09:36 I'll go ahead and create a fracker template in the repo too... That way we can at least populate the necessary information even if the final place is tbd 21:09:36 kencjohnston: Sounds good. Will the gaps analysis be in a Google doc or are you going to create something that can be posted to repo? 21:09:45 Tracker* 21:09:52 shamail: +1 21:10:08 Shamail oh, great, I was going to do it via text in the user story 21:10:20 Can you please assign that action to barrett? 21:10:29 Shamail process wise? DO I upload a version of the template into the tracked folder? 21:10:32 can the gap analysis be created in repo? 21:10:48 #action Shamail to create a Tracker template and post to repo 21:10:57 It's actually supposed to live outside since the user story can change and others could fall under the same tracker eventually 21:11:10 Yes Leong, makes sense 21:11:28 My first reply was to tracker, not gap analysis 21:11:46 Shamail - I'm confused. Are you going to post a tracker template to the Repo? 21:12:52 Yes barrett... It will have fields like blueprints, specs, market segments, team, etc 21:13:00 Great. 21:13:05 Anything else on Rolling Upgrades? 21:13:16 barrett Shamail I'll get with shamail on the process offline 21:13:23 nothing else for me 21:13:30 do we have a user story for update not upgrade? 21:13:47 that is minor version not major version change? 21:14:03 good question 21:14:13 what is the definition of a minor version? 21:14:17 Arkady_Kanevsky I think they have all been rolled in together 21:14:22 u mean like "patches"? 21:14:23 Arkady_kanevsky: What is the difference? 21:14:43 think of liberty.0 vs. liberty.1 21:15:00 The user story includes "Immediate Upgrade" to capture CVEs and other security patches 21:15:15 some bug fixes do fix schema or ohter things that impact updgrade 21:15:32 but the only version tested for upgrade is GA release 21:15:36 sounds like the intention is to cover them. 21:15:51 agree on intension. 21:15:59 Arkady_Kanevsky: Can you review the user story and add comments where you think there are gaps? 21:16:16 ++ 21:16:19 mmm, bug fixes from where? 21:16:21 give me that AI. 21:16:38 stable branch 21:16:41 I was justing if that is udner upgrade story or we want seperate story for update scenarios. 21:16:41 anything that requires a schema upgrade is more likely part of the "major version" upgrade 21:16:41 that might be cover under Usage Scenario section 21:16:47 yeah but stable branch doesnt allow that 21:16:50 kind of my point 21:17:06 #action Arkday Kanevsky: Review the Rolling Upgrade User story and add comments describing any gaps for updates 21:17:13 #link: http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/rollingupgrades.html 21:17:17 sgordon: +1 and barrett: +1 to comments on user story 21:17:18 thank you 21:17:28 Let's move on.... 21:17:54 Jay/Deric can you give an update on Onboarding Hosts? 21:18:02 sure 21:18:06 Thanks 21:18:14 We added new members from Platform9 as outcome from Tokyo 21:18:22 So we have been taking turns explaining each teams approach to onboarding: Platform9 and IBM PowerVC team 21:18:36 Each team approaches has gaps and advantages 21:18:48 Presentations in Onboarding Google Drive https://drive.google.com/drive/u/0/folders/0B0gXxpcL9MhGMy1tOU5ZbEFjRVU 21:19:29 we decided to split the blueprint drafts into three parts. Cinder changes, Neutron changes and a new project that will interact with Nova 21:19:55 that was just done last week. Unfortunately we have been slow due to RealJob(TM) workloads 21:20:09 :) 21:20:11 so we have the new drafts in the google drive 21:20:42 and will be discussing this Friday. We are still using voice bridge for now, but will be adding IRC 21:20:52 cloudrancher - what is driving separating the overall story? 21:21:09 if anybody could sent a scheduling IRC meetings dummies guide that would be good 21:21:31 is the "onboarding resource" user stories ready to move into "proposed"? 21:21:35 for new platforms is there a requirement for Ironic? 21:21:40 so, overall, taking lots of time and the new project is going to be a real challenge 21:21:42 I thought blueprints were being split, not user story? 21:21:47 no Ironic at this time 21:22:02 Shamail Ahh, I see, sorry I can't read. Makes sense 21:22:16 keeping it simple but Nova was pretty clear we need to be in a new project 21:22:29 and nobody on the team has done that yet 21:22:44 but overall we are makign progress 21:23:18 cloudrancher: what's your timeframe for moving from Draft to Proposed? 21:23:19 thats about it. We will probaly have last meeting this week due to holidays, then restart in Jan. 21:23:39 I think we need to spend more time on the blueprints first 21:23:51 so Jan it probably the best 21:24:20 in reality it is unlikly we will get anything into Mitaka other than PTL awareness 21:24:27 Blueprints aren't required for this per our work flow 21:24:38 sorry... pls correct me if i'm wrong.. based on the "workflow", the "blueprint" is address in "Tracked 21:24:46 yes, but I think we need to get a better idea of what we are trying to do 21:25:03 the Platform9 team had a much broader scope with VMWare 21:25:15 and the IBM team had more SAN and Neutron than Platform9 21:25:28 so - things are moving around a bit 21:25:30 leong: correct... I agree with Barrett about possibly considering a move to proposed... You can still refine items... 21:25:30 Moving from Draft to proposed requires a good user story write-up that describes the requirements, etc. 21:25:34 Not the solution 21:25:53 Barrett: +1 21:25:55 i think at this stage ("draft"), the team should focus on the "stories" or "problem statements" but not so much on "blueprint". 21:25:55 See the work flow here: 21:25:58 #link: https://wiki.openstack.org/wiki/ProductTeam/User_Stories#User_Story_Workflow 21:25:58 right. I'd like to give it a few more weeks because the requirements may change 21:26:37 The intial user story was a one way trip to OpenStack from KVM/other but the Platform9 approach was two way 21:26:56 so, there was lots of value in that and it's not reflected in the User Story right now 21:26:59 if the team thinks that the existing "stories/problem statements" is sufficient, then it can be considered moving into "proposed" or even "tracked" 21:27:02 Isn't that "outboarding"? 21:27:31 If we want to do it bi-directionally, then it should be called migration or something. 21:27:48 FWIW, most of the customers I talk to view it as one-way. 21:27:49 it's interesting because the two way capabiloity allows for leveraging both management interfacs 21:27:55 pchadwick: +1 21:27:57 we may end up there 21:28:05 I wouldn't want that part delaying the rest of it... 21:28:13 shamail: +1 21:28:14 pchadwick: this is about onboarding infrastructure for the purpose of tracking...not onboarding legacy apps 21:28:37 right - and once the infrastructure is there, why would anyone move it back? 21:28:40 I won't think it will, but adding abotu 30% more team is taking some time to integrate views 21:28:50 cloudrancher: pls look over the work flow. If you really need more time to capture the requirements fine. I'd like to see us follow the work flow as much as we can, as we execute through it theses first couple of times to test it out and be ready to refine it at our midcyle in Feb 21:29:00 the current "onboarding infrastructure resources" are leaning towards a "two-way" capabilities rather than just "one-way" migration. 21:29:03 ok. I'll work on 21:29:07 it a bit 21:29:27 I'm just saying we need a bit more time to digest 21:29:40 OK - Any other comments/questions on this one? 21:29:51 nope. thats it for now 21:29:56 Thanks 21:30:09 Next up is Onboarding Legacy Apps - Gerd are you here? 21:30:59 I think that team is still in the forming stage. I will connect with Gerd offline and ask him to send an update on the ML. 21:31:01 Gerd has drafted a Google Doc here to kick start the process. 21:31:05 #link: https://drive.google.com/open?id=122EzpeD2d-ZzpGyoruoOANCNvQv-ms70og6neQCMpsk 21:31:14 Thanks LEong 21:31:30 Next up is Complex Instance Placement - Steve can you give an update? 21:31:47 Ping ago rdon 21:32:01 Ping sgordon 21:32:06 mmmyes 21:32:09 Thanks 21:32:25 although i briefly lost my link, second 21:33:06 so the open review for updates is 21:33:08 #link https://review.openstack.org/#/c/251442/ 21:33:24 i haven't had a chance to integrate the feedback as yet 21:33:51 ok, I think barrett is ready to approve once you and Callum get to a consensus point 21:34:26 kencjohn: +1 It seemed like there was some discussion going on with Arkday 21:35:12 I +1 it already and I am original owner 21:35:29 but I do not have +2 priviliges 21:35:48 Arkady_Kanevsky Actually you -1'd 21:35:52 Are all of the questions resolved sgordon? 21:35:54 ??? 21:35:59 yeah and you arent the original owner 21:36:00 lol 21:36:08 Arkady_Kanevsky: I believe you are referring to lifecycle management, not CIm 21:36:11 it's all from calum 21:36:17 CIM* 21:36:17 with minor edits 21:37:04 Please let us know once you and Calum close the loop. 21:37:11 will do 21:37:13 shamail +1 21:37:28 OK - Any other User Stories to be discussed? 21:37:39 one quick note on the ROlling upgrades 21:37:48 #link ttps://review.openstack.org/254389 21:37:53 is a review to promote to Tracked 21:38:03 one more user story: db_hygience 21:38:14 i think db_hygience is ready to merged into "draft", now pending "core reviewer" approval. 21:38:23 kencyjohn: +1 21:38:23 ack bad link 21:38:23 #link: https://review.openstack.org/#/c/237178/ 21:38:33 Thanks kencjohn_ and me ong 21:38:47 leong* 21:38:54 #link https://review.openstack.org/#/c/254389/ 21:39:00 My mobile IRC client is bad. 21:39:24 Thanks Leong - will check the user story and make comments. 21:39:30 Anything else? 21:40:10 #topic Mid Cycle Planning 21:40:49 As far as I can tell Ops is set on 2/15 & 16 in Manchester 21:41:12 Rackspace has offered to host our Midcycle at their London offices right after that 21:41:13 are we going to meet in Manchester or London? or both? 21:41:19 I had an action to confirm whether Manchester is the "official" ops summit. I sent an email on the ops list but did not hear back... I think based on what I've seen... Manchester is the main one this time 21:41:31 Although others might happen in North America, Asia still 21:41:51 leong I thinkt he idea is yes, Ops meetup in Manchester, three hour train to London and then PWG Mid-Cycle 21:41:57 leong: we would need to do both if we are co-locating 21:42:05 Shamail: I think Manchester is the offical one and satelite ops meetups might happen 21:42:28 i see...need to add that into travel plan for approval.. :-) 21:42:33 kencjohn: That is the proposal 21:42:33 Yep. That's the likely scenario 21:42:53 Who would not be able to make a meet-up in London in Feb? 21:43:12 Do we have better dates on that? 21:43:22 2/17-18 21:43:31 Cool. I can make that. 21:43:34 kencjohn_ +1 21:43:42 I'm doubtful I could go at this point 21:43:54 should be ok for me 21:43:59 I need to put in for approval, so I am tentative at this point 21:44:03 Thanks kencjohn_ 21:44:13 mine also pending approval 21:44:17 I will not be able to make it to Manchester. 21:44:23 cloudrancher: Can you check it with your management? 21:44:26 I can confirm after January but no conflicts 21:44:32 should be able to make it in USA. 21:44:38 Megan: Can you check with your management? 21:44:40 I'll have to check after Jan 21:45:05 I was hoping to nail down date and time by end of next week. 21:45:13 @barrett: I probably won't know until after the holiday - that's the main focus right now 21:45:22 MeganR: Understand 21:45:24 ill try to confirm before then... 21:45:44 MeganR: welcome to retail :) 21:45:53 barrett Should we ask the reverse, who can confirm today? 21:45:58 Megan, Cloudrancher: Getting confirmation in Jan would apply to a UK based midcycle or US base midcycle, right? 21:46:01 or do we want to plan for a USA meet-up, seems like more people can do in USA 21:46:01 :) 21:46:14 i most likely can make it to Manchester 21:46:25 I think co-location withs ops summit is important... 21:46:26 US is better 21:46:32 Maybe we send emissaries to England and meet in US? 21:46:39 @barrett: I am aiming for Manchester - have already mentioned it to mgmt. 21:47:02 We could do 2 things: Have a subset of our team attend Ops in Manchester and then have a US based midcycle immediately afterwards 21:47:05 rockyg: that might make approval for some harder... The "2-in-1" value prop wouldnt exist 21:47:08 Just to be clear, we would attend the Ops Summit and then have the Product meeting? 21:47:14 I'm happy to be the emissary but I likely won't make a US meetup if I travel for the Ops mid-cycle 21:47:17 i believe we had at least two folks who cand make it 21:47:20 *can 21:47:23 pchadwich: +1 21:47:43 what about this: everyone pls check with manegement approval and feedback early Jan (give a date). 21:48:02 if majority people cannot got, then plan for a local USA meetup? 21:48:02 I can 21:48:06 Shamail rockyg_ I'd be affected by the lack of 2-in-1 21:48:21 OK. Good to know. 21:48:49 I could foresee the same... I can easily justify our mid-cycle but would have a hard time making tbe ops summit without it 21:49:00 +1 21:49:20 We can put this on the agenda for 1/11 meeting. Everyone pls work on understanding what they can do ahead of that meeting. 21:49:21 time track.. we have less than 10 minutes 21:49:25 This team meeting would be more important for me as well. 21:49:28 Leong: Thanks 21:49:46 #topic Stable Branch Project 21:49:55 barrett: lets revisit next week? While all of us try to figure out commit for UK? 21:49:55 RockyG - Can you take this one? 21:50:22 Shamail: +1 21:50:29 Yah. So a very quick write up here:https://etherpad.openstack.org/p/Stable_Release_Maintenance_-_Prod_WG 21:50:44 #link: https://etherpad.openstack.org/p/Stable_Release_Maintenance_-_Prod_WG 21:51:19 There are converging interests on getting releases supported beyond the 1 year point 21:51:34 review.openstack.org is not responding. so cannot comment on reviews 21:51:48 rockyg_ In reading the document, why was it deemed that PWG would be a good contributor above say, the Ops or other User Committees? 21:51:53 Minimum for upgrade, but also to reduce work across companies who provide support 21:51:55 Is there any converging interest on picking one release per year to be long term supported? 21:52:15 that is the only real way to reduce the multi-company workload. 21:52:19 Mainly because it's a corporate thing. Companies provide the long support 21:52:31 So, it is pretty much a "product" 21:52:49 with the same planning and support needs 21:53:02 Users and ops are consumers 21:53:14 also, we need business case for it 21:53:27 Hmm, ok, I guess I have some concern with the general approach especially as it relates to Rolling Upgrades. 21:53:41 that's why product WG is a good forum for it. 21:53:44 There is talk of that, but first, we need to figure out how to just extending a release could work 21:53:50 kencjohn_: probably because the main limiting factor will be development resources, therefore asking the majority of contributing companies to get involved is the logical next step. 21:53:51 I think that many view the Product WG as the planning arm for OpenStack - and this is a product planning issue 21:54:02 I realize this stable branch project is moving forward, but I'd rather see this group focus on things that remove the barriers to upgrades instead of adding additional stickiness to any given release 21:54:35 The first focus is how to keep the upgrade tests working. 21:54:36 barrett: +1 21:54:40 Even with rolling upgrades companies like to test and validate new releases 21:54:42 That way new features are in the hands of users more quickly, instead of a multiyear feedback sycle 21:54:45 kencjohn_: I think that finding that balance point will be part of the exercise for defining criteria and process 21:55:01 barrett: ++ 21:55:24 For today, I'd like to get a show of hands of who would be interested in joining a subteam to work on this? 21:55:25 We need to define what "support" means: 21:55:31 accepting bug fix? 21:55:31 Also, if only one company has to backport any patch, the amount of work in each company participating lessens 21:55:40 Target time frame for 1st proposal is end of Jan 21:55:51 o/ 21:55:56 barrett o/ 21:55:59 Thanks Rockyg 21:56:02 w.r.t. development resources i would think these showing up to help maintain stable 21:56:08 Thanks Kencjohn_ 21:56:16 would be a precursor to extending the lifecycle 21:56:20 sgordon: ++ 21:56:31 yes - but most of us already do it. 21:56:32 Likely some framework effort, too. 21:56:42 pchadwick, well that's kinda what im getting at 21:56:52 we do in fact have multiple working on upstream stable 21:57:01 Anecdotally, the problem is that the core teams are sometimes slow to accept backports. 21:57:01 this conversation is posited on the fact that others dont 21:57:03 so why is that? 21:57:23 sgordon: exactly. if we each contribute directly, not only does the workload go down for each, but we get credit for it in the community 21:57:27 im skeptical that it's just because the branch closes 21:57:34 because they aren't there before that either 21:57:44 rockyg_: +1 21:57:46 Folks - Don't mean to cut-off discussion, but we've got 3 mins left. Let's get a team formed where there can be more discussion to create a proposal. Then they can bring it back into this group for review/feedback. OK? 21:57:47 The stable team will be doing the accepting of the backports 21:58:01 barrett: +1 21:58:03 barrett: +1 21:58:07 +1 21:58:13 +1 21:58:14 barrett +1 21:58:18 I can work on the team. 21:58:23 sgordon: lots more. Rolling python package cahnges makes old code break 21:58:28 Thanks pchadwick 21:58:32 barrett: I'd like to defer the CPL topic to next week but I'll send an email to the ML this week on it. 21:58:40 rope me in too 21:58:48 Kewl. 21:58:53 Rockyg: Will you take the action to pull together the interested folks for an initial meeting? 21:58:59 cloudrancher "rope" nice :) 21:59:01 Sure. 21:59:09 kencjohn_: lol 21:59:12 21:59:39 This will likely dovetail into some of the other rolling upgrades/updates 21:59:46 #action RockyG setup kick off meeting for Stable Branch team with Kenny, Jay, Pete, Carol. 21:59:49 cloudrancher I could hear the Texas drawl through my screen 22:00:00 Great 22:00:00 One interesting question for the mid-cycle ops is how many ops will really do regular upgrades 22:00:02 sorry - I really do talk that way sometimes 22:00:09 i would also like to be involved in framing the plan for stable 22:00:15 vs most of my customers wanting to wait 12 months minimum 22:00:20 as a rep of a distributor who already has people contributing to stable... 22:00:28 #action Rocky Include Steve in the kickoff meeting too 22:00:32 which is where a lot of my questions are coming from 22:00:36 Thanks folks - we 22:00:39 I think the 12 months minimum is pretty standard at customer sites 22:00:41 We're out of time for today. 22:00:46 barrett: i have to leave but did my plan on CPL sound good? 22:01:00 shamail: +1 22:01:09 shamail: +1 22:01:15 +1 22:01:15 Shamail: Is the plan to address at midcycle? 22:01:34 No, ill send to ML and would like to have it on agenda next week 22:01:42 Good. 22:01:45 Shamail - OK. 22:01:53 #endmeeting