11:45:15 #startmeeting ptl-sync 11:45:16 Meeting started Tue May 20 11:45:15 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:45:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 11:45:20 The meeting name has been set to 'ptl_sync' 11:45:30 eglynn: around? 11:45:32 ttx: knock, knock again 11:45:44 ... got home safe from ATL I trust? 11:45:46 #topic Ceilometer status (eglynn) 11:45:51 indeed yes 11:46:06 You back in Europe ? 11:46:17 yep I sure am, since Sat evening 11:46:21 so, pending buy-in from the core team, here's the over-arching plan I had in mind for J ... 11:46:33 * front-load early progress on the TC manadated actions from gap analysis 11:46:40 #link https://etherpad.openstack.org/p/ceilometer-integration-gap-analysis-coverage-plan 11:46:58 ... in particular: incremental improvement in viability of sql-a driver 11:47:04 grenade participation 11:47:09 and tempest coverage 11:47:17 (all with an eye to J1) 11:47:32 * while a portion of the team works in parallel on the more forward-looking v3/gnocchi stuff 11:47:39 #link https://etherpad.openstack.org/p/ceilometer-tsdaas 11:47:40 I wonder.. did we ever review that plan at TC meeting itself ? 11:47:52 yep we did 11:47:56 * eglynn digs for link 11:48:13 OK, I should probably add it to the wiki page at https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 11:48:32 #link http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-04-15-20.03.html 11:48:49 #action ttx to translate https://etherpad.openstack.org/p/ceilometer-integration-gap-analysis-coverage-plan into a wiki coverage plan on https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 11:49:17 the v3 work is more with an eye to J2/J3 11:49:23 ok 11:49:39 * also in parallel restart the conversation with the stacktach folks 11:49:47 (with an eye to K) 11:49:54 eglynn: are you planning to use a ceilometer-specs repo for J planning ? 11:50:13 yep, expecting a flood of BPs once this puppy lands https://review.openstack.org/94044 11:50:49 (already +1'd, just needs some more infra-love to get it over the line) 11:51:05 How exclusive should that process be ? Will you tolerate features that don't go through it ? 11:51:22 Trying to see how/when we'll translate it into blueprints 11:51:41 I want to mandate it strictly for *new* BPs 11:51:45 #info Ceilometer will use a -specs repo for Juno 11:52:12 but may apply latitude for pre-existing BPs that were already started on 11:52:18 So when a spec is approved, you add it as a Launchpad blueprint and target it ? 11:52:50 but you may also have specs in there that didn't follow that process 11:52:51 well I had more in mind that the spec approval is sync with the Specification URL on the LP blueprint being set 11:53:06 so the LP BP can be created in advance as a placeholder 11:53:20 e.g. this one I filed earlier https://blueprints.launchpad.net/ceilometer/+spec/grenade-upgrade-testing initially 11:53:30 hmm... trying to see what would be the most convenient 11:53:48 do you know how the nova folks manage that? 11:53:52 eglynn: here is how we used to do it... 11:54:08 eglynn: people would file blueprints and you would use the priority field to "triage" them 11:54:19 it usually results in a neverending flow of untriaged blueprints 11:54:32 and us spending the whole 15minute sync time to sort through them 11:54:51 If the entry point now is the proposed spec in -specs... 11:54:55 so that's what we want to avoid, right? 11:55:05 it might make sense to only create a blueprint when we want to start tracking it 11:55:14 a-ha, k, got it 11:55:16 i.e. the PTL should create them, not the proposer 11:55:25 you can still create placeholders... 11:55:44 but in general, idea delay creation in LP until corresponding spec is approved? 11:55:48 but we would no longer use blueprints as an entry point 11:55:54 eglynn: yes 11:55:54 k 11:55:58 just a proposal 11:56:06 sounds sane 11:56:11 but I think that may result in less status sync hassle 11:56:28 so https://blueprints.launchpad.net/ceilometer/+spec/grenade-upgrade-testing is kind of a special case 11:56:36 we could even autoremove blueprints that are randomly targeted to a milestone unless they are "approved" 11:56:49 ... as I wanted to capture some detail for new Red Hat joiner Chris Dent who is gonna work on it 11:57:09 ... so that he can get up to speed quickly on what needs to be done 11:57:22 I think it's fine to use blueprints to track stuff that YOU as PTL would like to see speced 11:57:32 cool, got it 11:57:46 the idea is to avoid the "triage" step that would duplicate the work on -specs imho 11:57:55 yep, that makes sense 11:58:10 one trick will be to not let anything from aproved -specs fall into the cracks, not sure how to best avoid that 11:58:27 (i.e. approved spec with no blueprint corresponding) 11:58:52 yeah, good point 11:59:00 manual reconciliation for now I guess? 11:59:27 eglynn: yeah... the other trick is to find a way to autoremove stuff that others target 11:59:45 we'll have to use some protected field in the blueprint for that. Maybe priority 12:00:13 yeah, makes sense 12:00:14 i.e. anything without a prio and with a milestone set should get removed with a "file specs first" note 12:00:34 ideally we'd use the "approved" field, need to check it's protected 12:00:52 anyway, I'll work on that this week and propose process 12:00:58 in summary: 12:01:39 #info Ceilometer uses -specs, drivers may create extra blueprints that have no specs, random blueprints should be untargeted 12:01:39 it'll take a bit of bedding in, but I think that kind of process has potential to be a lot better than the prior free-for-all 12:01:54 Oh, we could use the series goal. That would make sense 12:02:04 yeap 12:02:31 Let's first see who wants to follow that 12:02:39 Anything to discuss at meeting later today ? 12:02:57 nope, nothing pressing 12:03:24 did ceilo make use of their pod at summit ? Would you like one for the next ? 12:03:41 yes and most definitely yes! 12:03:46 Any other feedback from the Ceilometer track, while it's hot ? 12:03:56 #info Ceilometer used their pod, would like one next time 12:04:21 persistant fuzziness around the project mandate 12:04:37 * eglynn would like to see the mission statement patch land in governance 12:04:46 ok 12:04:49 ... it's on the agenda for the TC meeting this evening 12:04:52 cool 12:04:58 eglynn: ok great, ttyl 12:05:13 ttx: cool, thank you for your time! 12:05:15 #topic Sahara (SergeyLukjanov) 12:05:25 SergeyLukjanov: aren't you supposed to be on vacation ? 12:05:28 ttx, hey 12:05:35 and ona non-comatible tz ? 12:05:39 +p 12:06:01 ttx, yup, on vacation, but it's 8am here, so, it's compatible ;) 12:06:19 SergeyLukjanov: ok, is Sahara planning to use a -specs repository for Juno ? Or keep old LP planning until at least K ? 12:06:42 ttx, I'm unable to go to the project meeting today - I'll be already on the plane 12:07:11 SergeyLukjanov: not a problem -- check the release schedule and let me know if you have issues with it before 12:07:19 ttx, not so far, I think we'll keep lp for J 12:07:23 https://wiki.openstack.org/wiki/Juno_Release_Schedule 12:07:43 * SergeyLukjanov looking 12:07:45 #info Sahara keeping launchpad-driven workflow for Juno 12:08:33 SergeyLukjanov: ok, so we'll work with the old-style workflow for you: look at targeted specs and triage them by setting a priority (or remove the milestone target when inappropriate) 12:09:21 ttx, yup, that's my plan for the next week 12:09:45 we'll start reviewing that next week. 12:10:06 Any summit feedback from Sahara track ? 12:10:36 ttx, release schedule wfm 12:10:49 ttx, I'll do it before the next relmgr meeting 12:11:22 SergeyLukjanov: did you make use of the Sahara pod ? Would you like one such pod in Paris summit ? 12:11:42 ttx, program pods are awesome, we've been actively using them, especially at the first days of summit and really want to have one on the next summit 12:12:18 #info Sahara used their pod, and would like one next time 12:12:29 SergeyLukjanov: ok, any other feedback ? 12:12:30 ttx, and there were enough design summit session slots to discuss mostly everything that we need (+ pods) 12:12:39 ok. good 12:12:49 SergeyLukjanov: go for breakfast now :) 12:12:55 ttx, I think no more feedback atm 12:13:05 Thanks for showing up! 12:13:12 ttx, thanks! 12:14:13 ttx, are there any other projects that are planning to keep the lp for J? 12:14:23 SergeyLukjanov: I think so, yes 12:14:37 SergeyLukjanov: I'll use today to actually check on that. 12:14:51 SergeyLukjanov: If you are the only one not to use it, I think it would make sense to just adopt it 12:15:02 ttx, exactly 12:15:04 But then I think this "experiment" is quickly turning into a norm 12:15:15 and I would like it to be an "experiment" still :) 12:15:34 ttx, massive experiment ;) 12:15:36 so if >=2 projects don't use them, I'm fine with them :) 12:16:19 dhellmann_: I suspect you are not around, since you mentioned you would miss the meeting today 12:16:32 ttx: I'm here this morning, just for you :-) 12:16:37 oooh, nice :) 12:16:46 #topic Oslo (dhellmann) 12:16:47 I wouldn't miss our little chats for anything 12:17:07 So first question, are you planning to use some oslo-specs repo ? 12:17:17 yes, we have a specs repo set up 12:17:37 OK. How exclusive is it ? Do you tolerate blueprints without a spec ? 12:17:50 ttx, we've not discussed this question really good with team before, because there were no feeling of the lack of "info" for blueprints, but it could increase their usability and info value a lot, so, I'll add it to the next Sahara meeting agenda to re-check 12:17:51 Does it affect all oslo* ? 12:18:15 I expect us to have a few bp where a spec would not be needed 12:18:21 SergeyLukjanov: maybe wait for the result of my investigation. i'll let you know if you're one of very few 12:18:31 and yes, it is for all of oslo 12:18:38 ttx, ok, thx 12:18:54 dhellmann: would you feel OK filing those yourself ? The idea would be to ditch the LP-driven blueprint proposal/triaging process altogether 12:19:07 and use it only as a reporting tool 12:19:08 ah, interesting 12:19:16 reporting/scheduling/tracking progress 12:19:38 well, that's what I expected to do, so I'm not sure how what you're suggesting is different? 12:19:55 so we would basically autodrop anything directly proposed to LP, unless it has a prio set (or some other field you are the only one (with all LP drivers) tp set 12:20:27 "autodrop" means "remove from juno" or "remove from launchpad"? 12:20:48 dhellmann: that would mean "remove from juno" since there is no way to delete a blueprint in LP (don't ask) 12:21:10 dhellmann: in previous cycles we used Lp as the entry point 12:21:22 dhellmann: so you had to review stuff that would be proposed and decide what to do with it 12:21:32 now that would conflict with the -specs approval workflow 12:21:39 ok, got it 12:21:44 so i'd rather just ditch the LP-driven approval process 12:21:52 and just have "approved" blueprints in LP 12:22:01 well, targeted to a milestone in LP 12:22:17 yeah, we have one bp already implemented without a spec so as long as we don't lose that one I think we're ok 12:22:24 I can go through and approve the others 12:22:38 so we could just look at targeted stuff and actively remove it from the Lp milestone if it wasn't approved/prioritized properly already 12:22:44 I brought a cold home from the summit, so I haven't looked at any of that yet 12:23:06 but I should be able to start updating them tomorrow 12:23:12 no hurry 12:23:22 just brainstorming on how we'll sync 12:23:43 I think considering Launchpad to be the "plan" rather than the entry point will simplify a lot of those sync points 12:24:01 and more importantly, no parallel approval processes 12:24:13 yes, that's more or less what I expected 12:24:20 just need to check that it would work for all "-specs" early adopters 12:24:43 and then build the script that will gently point people that propose blueprints on LP to the new process 12:25:04 the trick being... finding a way to avoid approved -specs from not being targeted in LP 12:25:11 so that everything is tracked 12:25:44 You'll miss meeting today, maybe check that the release schedule is fine by you 12:25:45 so you want to automatically notify people who open new blueprints that they should use the specs process? 12:26:10 yeah, I'll look over the schedule and email you if I see any issues 12:26:15 dhellmann: I want to remove any target milestone that they may set. Redirecting them to the -specs process would be a nice addition 12:26:42 the goal being to avoid polluting target milestones with unapproved specs 12:26:50 and having to go through them every week 12:26:51 +1 12:27:30 ok, summit feedback... 12:27:51 Did you make any use of the Oslo pod ? Do you think it makes sense at next summit ? 12:28:15 * ttx thinks it's not that necessary for horizontal projects, we're busy all the time 12:28:21 as far as I know we did not use it this time 12:28:39 I think being able to share with other projects as we discussed would meet our needs very well 12:28:45 #info Oslo uses -specs repo for Juno planning 12:29:17 #info Oslo did not use pod - could share one 12:29:32 ok, any other feedback ? 12:30:41 not really -- the summit went well & we had enough time to talk about what we needed to work out 12:30:48 dhellmann: ok 12:31:46 OK... talk to you later ? 12:32:05 I'm going to miss both meetings this afternoon (prior commitment) 12:32:33 no problem! 14:01:11 dolphm: o/ 14:02:11 ttx: o/ 14:02:23 #topic keystone (dolphm) 14:02:46 dolphm: do you plan to use a keystone-specs repo for Juno features ? 14:03:09 or wait for the end of experiment and reconsider for K ? 14:03:12 ttx: yes, but after some conversation (and confusion due to the existing repos) it's currently in review as 'identity-specs' 14:03:17 https://review.openstack.org/#/c/94119/ 14:03:33 yay confusion! 14:04:01 ok... is that exclusive ? i.e. will all features go through specs ? 14:04:26 yes, but we'll start requiring it for for J2 forward 14:05:11 OK... I have a process that I discussed earlier in the 1:1s with others, about using blueprints as a drovers-maintained communication tool 14:05:15 drivers* 14:05:15 and we landed on the name 'identity' to better accommodate client-side specs, which we'll have a separate directory for, and just move the into versioned directories as they are released? 14:05:31 it seemed odd to us to use 'juno' for client-only work, etc 14:05:38 i.e. you would create a LP blueprint for approved specs, so that we track milestone targets and implementation status 14:05:52 oh that'd be much better 14:06:12 the idea being to NOT use LP as an entry point requiring triaging anymore 14:06:15 so at end of j1, we'd close all stale bp's? 14:06:31 and if any are proposed, untarget them automatically 14:06:50 There can be stale BPs, as long as they are not targeted 14:06:56 (LP can't delete BPs anyway) 14:07:02 basically no one uses targeting on their own anyway 14:07:18 i meant marking them as obsolete until a spec lands 14:07:19 that means you (or other keystone drivers) would maintain the milestone targeting 14:07:35 and we'd use the resulting board as a communication tool 14:07:49 with release management but also downstream consumers 14:07:56 is there an option to prevent blueprints from being filed from non-drivers? 14:08:11 just a sec, call interrupting 14:08:40 ack 14:09:11 ok back 14:09:38 dolphm: I'd make a script that would remove from milestone target anything that's not "approved" 14:09:52 we'd probably use "priority" to signify approval 14:10:11 since random people can't set it 14:10:39 that way there is no triaging needed anymore in LP 14:10:46 it's all done on the -specs repo 14:11:20 also doesn't prevent to track work without a spec, for corner cases, as long as YOu create it 14:11:45 only drawback is how to prevent some approved -specs from falling into the cracks and not have blueprint 14:11:55 but I guess we can make a report for that 14:12:13 #info keystone will use identity-specs repo starting with j-2 14:12:17 that's sort of how we were doing it anyway, we stopped bothering with 'approved' long ago 14:12:37 dolphm: are you comfortable with building the j-1 list manually and apply same rules ? 14:12:58 i.e. we'd triage them BEFORE we enable the rejection script 14:13:00 i think so, i was going to do that this week anyway 14:13:12 ok, sounds good 14:13:25 Anything to discuss at meeting later today ? 14:13:28 maybe the threat of specs in j2 will encourage some people to land features earlier :) 14:13:50 not off the top of my head 14:14:02 Feedback from design summit ? Did the keystone team make use of its pod ? Want one next time ? 14:14:22 we used our pod everyday and definitely want another one 14:14:35 #info keystone used its pod every day. Wants one next time! 14:14:36 barbican did as well, docs didn't seem to as much 14:14:55 yes, I think horizontal projects did not, in general 14:15:00 neutron needs two pods, as they overflowed from the next room to our table 14:15:03 we could all just share one table 14:15:12 (they really needed 3 for the number of people they had involved in discussions down there!) 14:15:26 heh 14:15:43 i'm also happy we had more users in the design sessions 14:15:46 jgriffith: around ? 14:16:32 dolphm: ok, thx, talk to you later! 14:16:36 ttx: /salute 14:23:23 jgriffith: not around? 14:43:54 david-lyle: o/ 14:44:02 ttx: o/ 14:44:15 bit late, you were scheduled at 4:30 :) let's do it quick 14:44:35 david-lyle: does horizon use a -specs repo for Juno ? 14:44:38 last week of dropping off kids, more reliable starting next week 14:44:47 ttx: we don't 14:45:03 ok. I assume we'll use the same LP-driven process as for icehouse then ? 14:45:32 yes, we talked about the -specs, but didn't see a real value for Horizon at this time 14:45:40 i.e. triage incoming milestone-targeted blueprints by setting priority (if you like them) or remove milestone targeting (if you don't) for them ? 14:46:07 OK, we'll start looking at the result next week 14:46:12 that was the plan 14:46:21 Oops, forgot to set topic 14:46:25 sure, still some planning to do 14:46:29 #topic Horizon (david-lyle) 14:46:37 #info Horizon not using -specs for Juno 14:46:49 Anything you'd like to discuss at meeting later today ? 14:47:31 no, we have general questions around 3rd party integration and ceph integration, but I think that's more a TC topic 14:47:39 ack 14:47:40 Feedback from design summit ? Did the horizon team make use of its pod (ISTR you told me yes)? Want one next time ? 14:48:03 we did use it, and would like one next time 14:48:16 david-lyle: in preparation for the TC meeting today, you can copy te requirements list in an etherpad and prepare answers to each requirement 14:48:32 https://etherpad.openstack.org/p/horizon-gap-analysis 14:48:37 #info Horizon used its pod and would like one next time 14:48:46 david-lyle: great! see you there then! 14:48:52 mestery: around? 14:48:54 sounds good, 14:48:57 ttx: o/ 14:49:05 #topic Neutron (mestery) 14:49:30 mestery: I was in the session where you discussed the -specs repo so I assume you are using it for Juno ? 14:49:48 Yes, that's the plan, the team has been actively using it for a few weeks now, the results so far are good. 14:49:50 #info Neutron using -specs for Juno planning 14:50:29 mestery: I discussed this with others in previous 1:1s and I think we have a process to work with blueprints now 14:50:50 ttx: Do you mean the process of combining specs repos with LP? 14:50:55 mestery: the idea would be to use LP blueprints as a communication tool to communicate milestone target and implementation status, while linking to approved spec 14:51:20 ttx: Perfect! That's what I've been trying to do so far with specs which we've already approved. I like this plan. 14:51:23 do all your features go through specs ? Or do you plan to still accept LP submissions ? 14:51:43 We're focusing only on the specs repo now, that's the message I've been giving contributors as well. 14:52:01 ttx: https://wiki.openstack.org/wiki/Blueprints#Neutron 14:52:03 mestery: OK, so the idea would be to drop completely usage of LP as an entry point for features 14:52:15 we'd autoclean anything directly proposed there 14:52:18 ttx: Yes, correct. We only use LP to track against milestones as you indicate. 14:52:30 you can create a blueprint when a feature is approved (and/or doesn't need spec) 14:52:43 Yes 14:52:54 if you set "priority" and "milestone target" it should not be touched by the autoremove script 14:53:11 only drivers can set priority, which should protect against random addition 14:53:23 OK, got it, thanks! Just curious, are others going "specs only" like we are? I think nova is, right? 14:53:25 so we don't need to go through "blueprint triaging" every week 14:53:33 perfect 14:53:36 most of them are, yes 14:53:47 all "triaging" is done at spec review level, basically 14:53:48 OK, good, happy to be aligned with the rest of the projects then! 14:53:59 Regarding triaging, that makes sense. 14:54:01 and you use blueprint to communicate your objectives and their completion to the rest of the world 14:54:15 Got it, makes sense. 14:54:26 we'll have to figure out a way to make sure work in progress gets properly tracked, but one problem at a time :) 14:54:33 :) 14:54:47 Need to work on that autokick script :) 14:55:17 OK, anything you'd like to discuss in cross-project meeting later today ? 14:55:25 Nothing at this time, no. 14:55:33 Summit feedback ? 14:55:49 It was organized really well, thanks to all who put in the work there! 14:55:57 The pods were a huge hit too, we used ours everyday. :) 14:56:03 * mestery thinks we may have spilled into other pods as well. 14:56:09 OK, I assume you'd like one for next time ? 14:56:14 Yes please! 14:56:24 #info Neutron used their pod and would like one next time 14:56:41 OK then... Anything else ? 14:56:51 We'll start looking into specs and blueprints starting next week 14:56:53 Nothing else this week. 14:56:56 now is a bit early 14:56:58 OK, cool! 14:57:04 Agreed, still organizing post-summit. :) 14:57:07 OK then, talk to you later! 14:57:14 Thanks ttx! 14:57:26 * ttx hasn't even started to extract actions from summit yet... :/ 14:57:34 busy catchup 14:57:47 Same here, still triaging things and threads from last week :) 15:30:44 notmyname: o/ 15:31:07 ttx: hi 15:31:23 #topic Swift (notmyname) 15:31:33 I implemented your logging idea 15:31:39 we'll see how that goes 15:31:49 cool! 15:32:08 notmyname: IIRC from that Swift session, you plan to use a swift-specs repo at some point in the Juno cycle ? 15:32:18 we're working on getting it set up now 15:32:28 patches are in -infra config right now 15:32:44 #info Swift will use a -specs repo starting in Juno cycle 15:33:02 I hope to have it all set up this week 15:33:06 how exclusive will it be ? All features will have to go through it ? Or lesser features might still go in without one ? 15:33:41 it's unlikely that it will be a requirement for every patch. that's still something we need to figure out what works best for us 15:33:47 ok 15:34:01 there's a lot of support for it right now, so we'll see :-) 15:34:36 Note that with the introduction of -specs repos most other projects will start using Lp as a communication tool (when is something expected to land and how complete it is) rather than a feature approval tool 15:34:45 which makes it closer to the way you've always been using it 15:34:52 that makes sense. and yes :-) 15:35:33 To that effect I plan to create a tool that will automatically untarget stuff randomly proposed to milestones, so that it can be really used a communication tool without interference 15:35:43 are you comfortable with that ? 15:36:06 will be a variant of my "align milestone to series" script 15:36:16 how do you define "randomly proposed to milestones"? 15:36:42 we'll probably use "absence of priority" to define if it's blessed or not 15:36:52 since priority is a field that can only be set by "drivers" 15:37:04 so anythign that has a priority will stay in the milestone 15:37:09 ok 15:37:25 anything that doesn't will be assumed to have been added by someone else 15:37:45 still barinstorming it, but sounds like the most convenient 15:37:47 and "priority" is redefined within openstack to mean "likelihood of actually landing in this timeframe"? 15:37:49 brain* 15:38:12 notmyname: yes, or "release priority" 15:38:17 ok 15:38:38 so your script idea sounds fine to me 15:38:39 OK, all sounds good. Anything you'd like to add to agenda for meeting today ? 15:38:53 no, but a few other things to let you know 15:39:04 ok, feel free to use #info liberally 15:39:08 #info swiftclient is now gated on py3 15:39:37 #info swift py3pep8 job has been proposed to keep syntax. note no actual code execution under py3 at this time 15:40:09 #info swift feature freeze during the storage policy merge period will likely be next week 15:40:24 I expect storage policy patches to be proposed in the 2nd half of this week 15:40:38 then next week spend a lot of time reviewing them 15:40:55 Summit feedback ? I know you heavily used your pod, I assume you'd like one next time ? 15:40:56 freeze will last until they land, so I hope it's just a week. but it might stretch to two weeks 15:41:17 the pod was a good idea. I didn't spend as much time there as I would have liked, but I know it was heavily used 15:41:22 #info Swift used their pod, would like one next time 15:41:53 the general idea of "common area with a specific theme [ie swift]" is what we liked, I think 15:42:18 right 15:42:19 if that's a table next time, good. if it's something else, it would still work. just depends on the paris facilities 15:42:36 yep, will visit again next week with pods in mind 15:42:41 as I mentioned, cinder and swift shouldn't overlap next time 15:42:58 makes sense, actually, if you think about "storage people" attending 15:43:04 #info please do not overlap Cinder and Swift tracks next time 15:43:31 first time I've gotten that feedback, but I think it's because of the bigger audience and more users that are attending now 15:43:40 so I consider it a positive 15:44:04 what's the topic for the meeting today? 15:44:18 we have the release schedule to approve 15:44:22 that's about it 15:44:31 ok 15:44:48 If you can't attend, let me know if you have problems with it off-meeting 15:45:04 zaneb: around? 15:45:06 ttx: I'll try to be there, but I may miss it 15:45:10 o/ 15:45:13 notmyname: ok, thx! 15:45:20 #topic Heat (zaneb) 15:45:56 Hi! So I was wondering, does heat plan to use a -specs repository ? Or wait for other projects to play with the concept first ? 15:46:13 I added that to the agenda for our meeting tomorrow 15:46:22 so, undecided yet ? 15:46:24 but I hate launchpad, so... 15:46:30 I'm thinking yes ;) 15:46:42 #info Heat MAY use a -specs repository for Juno planning 15:47:07 OK, so depending on the answer we would either use LP to parse incoming proposed stuff, or the -specs repo 15:47:22 in the latter case, we'd use LP only to communicate target milestone and completion 15:47:34 from discussions I had at summit, support is strong for a specs repo 15:47:54 hopefully it doesn't become _too_ formal 15:48:07 ack 15:48:23 So we'd drop using LP as an entry point, so no need to triage incoming crap being proposed to it 15:48:36 ok, cool 15:48:48 a script would weed out all stuff that would be targeted without a proper priority set (drivers would set these) 15:49:21 who has a good template to start from for that repo? 15:49:22 Your work (with fellow heat-drivers) would be to add the blueprint once you know when it's targeted, and set a prio to reflect how likely it is to make it 15:49:41 I may do a CLI script to do that, now that I'm thinking of it 15:50:00 $ lp-push heat-new-templates juno-1 medium 15:50:01 that sounds excellent :) 15:50:16 that would ONLY timeout 50% of the time ! 15:50:23 lol 15:50:40 anyway, that's how we'd do it if you opt for specs 15:50:55 doesn't prevent drivers to file blueprints for stuff that doesn't need a spec 15:51:09 but in most cases they would have an approved spec linked 15:51:29 Keep me posted on the Heat meetign decision 15:51:30 ok, and we'd disable non-drivers from being able to create blueprints? 15:51:41 or just ignore them? 15:51:57 zaneb: they can still create them, but we would undo the targeting if they tried to pollute our milestone targets with those 15:52:14 I still need to work out the details 15:52:28 Might attach a message redirecting to the -specs 15:52:29 imo a lot of blueprints don't need *detailed* specs, just want to avoid people accidentally posting to /dev/null without knowing it ;) 15:52:57 just had the idea today, so it's pretty raw, checking that it makes sense with everyone first 15:53:15 ok, cool 15:53:24 Anything you'd like to discuss at meeting today ? 15:53:28 we are at an early stage also, so I'll keep you posted 15:53:57 nothing in particular :) 15:54:09 Summit feedback ? Did you guys make use of your pod ? 15:54:16 * zaneb has only just recovered from summit ;) 15:54:34 we did use the pod, but not until later in the week 15:54:54 zaneb: would you like one next time ? 15:54:55 it was lacking signage from the dev lounge, but you know about that 15:55:11 I would if possible 15:55:13 #info heat used their pod, could use one next time too 15:55:30 we used it to have a follow-up heat/murano/solum session 15:55:38 so that was *really* helpful 15:55:46 OK ok sounds good. We'll start looking into proposed stuff next week, once you have your decision and the release schedule is approved 15:56:13 nothing worse that being at the summit for a week with all the right people and only 1 hour to actually talk to them 15:56:14 anything else to add ? questions ? 15:56:32 nope, sounds good 15:56:35 yep, that's one of the things the pods were for... continuing collaboration 15:56:41 ok, great, ttyl 15:56:47 markwash: ready when you are 15:56:48 thanks ttx 15:56:58 well then we'll never get started 15:57:02 #topic Glance (markwash) 15:57:19 markwash: howdy 15:57:26 ttx: greetings 15:57:42 markwash: does Glance plan to use a -specs thing to plan Juno ? or good old LP is enough ? 15:57:50 -specs 15:57:58 I think we have our repo, but maybe it doesn't have a template in place yet 15:58:07 #info Glance using -specs repo for Juno planning 15:58:26 OK, did you follow the discussion I just had with zaneb ? 15:58:35 ah, no, sorry I did not 15:58:42 ok, no worry, I can retype 15:58:54 It's about how we'll use LP in a -specs world 15:59:07 Do you plan to have all your features go through -specs ? 15:59:25 I'm not so sure about that aspect 15:59:39 let me ask it differently 15:59:58 Do you plan to still use LP as an entry point for features ? 16:00:17 Anything before that was a blueprint will need a specs entry as well 16:00:18 (i.e. require triaging of randomly-proposed blueprints there ?) 16:00:20 that was the thought 16:00:29 right 16:00:47 randomly proposed stuff in lp will continue to be mostly ignored 16:00:50 so we can drop the "triaging of LP blueprints" part 16:01:17 The idea would be to use LP only as a way to track target milestone and implementation compltion 16:01:23 for approved specs 16:01:29 sounds great 16:01:51 so you would just create a LP blueprint when you have an approved spec (or when the thing doesn't require a spec) 16:02:09 We would automatically untarget stuff that would be proposed to a milestone without a spec 16:02:20 well, not exactly 16:02:42 we'd untarget stuff that doesn't have a prio set. Prio can only be set by glance-drivers Lp team 16:02:59 so YOu can still create a blueprint that doesn't have a -specs attached 16:03:07 but random people cannot 16:03:19 the goal being to avoid the whole fun of triaging incoming blueprints in LP 16:03:27 since you'll kinda do all that fun in -specs repos 16:03:36 no need to duplicate the fun 16:03:38 this approach sounds perfect 16:04:08 yes, let me reuse the reporting bits for release management, clean interface between PTL and RelMgt too 16:05:00 anyway, that's the plan. Will create a script to autofix the random blueprints, and probably a CLI tool to autocreate blueprints from accepted specs 16:05:28 $ lp-push glance-public-policy juno-1 medium 16:05:38 okay great 16:05:48 now that would be nice... just unsure LP API allows it :) 16:05:58 so people can just show up with a spec and we can automatically create the appropriate blueprint 16:06:10 yes, reduce friction there 16:06:27 what about existing blueprints that are only partially abandoned in LP? 16:06:40 just let those migrate over to specs as folks regain interest? 16:07:09 they wil lstay around. You can salvage them and use them in your milestone targeting 16:07:21 if they make sense 16:07:34 but yeah, globally we'll ignore them 16:07:41 but there is no rush to clean them up at this time at least 16:07:56 no. If they are not targeted they won't interfere 16:08:04 so no need for active cleanup 16:08:05 Anything you want to discuss at meeting later ? 16:08:17 not in particular 16:08:21 there is one question I have for you now 16:08:25 Summit feedback -- did you guys make use of your pod ? 16:08:30 markwash: ask 16:08:51 not a ton of use of the pod, I hung out there a bit, but ours was not dedicated (it was partly for nova as well) 16:09:02 it was very nice to have a "quiter" dev lounge 16:09:11 s/quiter/quieter/ 16:09:27 #info Glance did not make use that much of the shared pod with Nova. Quiet area was very nice though. 16:09:50 so my question is about sharing the responsibility for client tagging 16:09:50 what was your question ? 16:09:53 ah 16:10:09 I am hoping to delegate that responsibility, imagining that it could not possibly be worse than with me in charge :-) 16:10:20 indeed! 16:10:31 I'm fine with that 16:10:36 AFAICT the only need is for permission to push tags to the client repo 16:10:48 I think gerrit would support it if you add someone to glance-ptl group 16:10:52 which is part of the gerrit glance-ptl group 16:10:53 yes 16:11:05 if that's okay by you, and I can add someone to the group, that would be great 16:11:12 unless -infra objects, sounds good to me 16:11:23 okay cool 16:11:35 and is there a log of this conversation going to eavesdrop? 16:11:49 yes, wil post it at meeting today 16:12:02 great 16:12:14 you can use #info during the sync so that it will be highlighted in the resulting report 16:12:22 SlickNik: around? 16:12:28 markwash: thx! 16:12:30 ttx thanks! 16:12:33 ttx: here 16:12:43 How's it going? 16:12:49 #info ttx agrees with expanding the glance-ptl group to more than one person 16:13:02 #topic Trove (SlickNik) 16:13:11 SlickNik: going well, thank you 16:13:18 better than Sunday and Monday :) 16:13:44 markwash: fwiw, the trove-ptl group on gerrit has a few cores to help with client releases (so the ptl is not a single point of failure). 16:13:50 ttx: I hear ya! 16:13:52 Sooooo.... is trove planning to use a -specs repo for Juno planning ? 16:14:10 SlickNik: thanks for the heads up 16:14:12 ttx: we're in "wait and watch" mode right now. 16:14:17 fine by me ! 16:14:23 So we're still doing things the old way in LP. 16:14:28 * ttx doesn't like so many eggs in the same experimental basket 16:14:52 And waiting for a consistent "OpenStack" way of using the specs-repo to emerge. 16:15:03 #info Trove will keep using LP for feature planning for the time being 16:15:21 OK, that means we'll still use LP as the feature entry point 16:15:31 ttx: yes, that sounds good. 16:15:49 and you'll triage incoming blueprints by setting a priority if you like them) or removing them from the milestone (if you don't) 16:15:56 sounds good 16:16:15 We'll start looking into that starting next week, no use to look at anything right now 16:16:36 ttx: roger that. FYI we have a BP meeting in #openstack-trove on Mondays where we go over some of the new BPs in shape. 16:16:41 SlickNik: Anything you'd like to discuss at cross-project meeting at 21:00 UTC ? 16:17:04 ttx: FYI https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting 16:17:17 #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting 16:17:23 ttx: nothing at the moment. 16:17:33 SlickNik: Summit feedback -- did yo uguys make use of your pod ? 16:17:55 ttx: YES! We made extensive use of it. 16:17:59 and I'm so glad we did. 16:18:05 would like one next time if possible ? 16:18:13 Definitely. 16:18:15 #info Trove made use of their pod and would like one next time 16:18:23 any other summit feedback ? 16:18:33 And also a big thanks to whoever came up with that idea. 16:18:47 SlickNik: that would be me 16:19:13 SlickNik: but then agility on the summit organizers front made it actually possible :) 16:19:32 SlickNik: anything else ? 16:19:38 ttx: Thanks! It seriously was a big help to reach consensus for more than one topi/discussion. <3 16:19:52 ttx: That's all i got. 16:20:05 ttx: Nice job on the summit! 16:20:05 awesome. Talk to you later, then! 16:20:28 That concludes the 1:1 syncs for the day. 16:20:31 #endmeeting