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