08:58:47 <ttx> #startmeeting ptl_sync
08:58:48 <openstack> Meeting started Tue Nov 18 08:58:47 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:58:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:58:51 <openstack> The meeting name has been set to 'ptl_sync'
08:58:52 <ttx> #topic Heat
08:59:14 <ttx> asalkeld: o/
08:59:27 <asalkeld> hey, first timer here
08:59:34 <asalkeld> be gentle
08:59:38 <asalkeld> :-)
08:59:45 <ttx> My first question would be, do you plan to follow release management stuff directly, or would you prefer to delegate that to a release management liaison
08:59:46 <ttx> ?
09:00:01 <asalkeld> for now, me
09:00:09 <ttx> cool.
09:00:10 <asalkeld> we are having a weekly meeting
09:00:17 <asalkeld> and i'll bring it up
09:00:28 <asalkeld> (if anyone else wants to do it)
09:00:50 <ttx> Second question -- about how we curate the blueprint list in LP
09:01:23 <asalkeld> ok, I think i need to tweek some
09:01:25 <ttx> As you know we use the "milestone target" field to curate per-milestone list of stuf being done
09:01:38 <ttx> problem is, Launchpad lets anyone set that field
09:01:51 <ttx> so we use a combination of priority *and* target milestone
09:02:00 <ttx> only project drivers can set priority
09:02:23 <ttx> so I have a script that will automatically remove from the milestone any unprioritized blueprint
09:02:30 <asalkeld> i think i need to read this: https://wiki.openstack.org/wiki/PTL_Guide#Blueprints
09:02:43 <ttx> For example, on https://launchpad.net/heat/+milestone/kilo-1 ... there are 3 undefined
09:02:59 <ttx> (two of them implemented, so probably safe :)
09:03:30 <ttx> I can run that script on a crontab, and it will automatically clean up the list
09:03:39 <ttx> so that only the stuff you vet appears there
09:03:45 <asalkeld> ttx, does anything automatically happen when a spec is approved?
09:04:15 <asalkeld> or is there a way for me to figure out what is out of sync
09:04:18 <ttx> asalkeld: nothing at thius point. I have another script that can set the blueprint fields for you on spec approval
09:04:29 <asalkeld> nice
09:04:35 <ttx> but it's not trigfgered automatically
09:04:41 <ttx> and I need to rebase it
09:04:55 <ttx> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/spec2bp.py
09:04:58 <asalkeld> checking all the bp's is going to get old fast
09:05:24 <ttx> yes, and having two parallel paths is also a bit painful
09:05:38 <ttx> which is why I wrote the autokick script to autoclean things up
09:05:45 <asalkeld> ok, that should help
09:05:59 <asalkeld> do I run that or you?
09:06:00 <ttx> My question would be, do you want that script running for Heat (like it did in the past ?)
09:06:21 <asalkeld> yes, if it can run automatically
09:06:26 <ttx> It usually simplifies a lot (you choose what appears on the list, rather than have to curate it all the time)
09:06:40 <ttx> yes I run it on a crontab from some server in the cloudTM
09:06:51 <asalkeld> yes, please that amazing:-)
09:07:07 <ttx> ok, let me tell you what happens if I run it now
09:07:38 <ttx> so that you can check it's not crazy
09:08:10 <asalkeld> i'd expect some need setting to approved
09:08:20 <ttx> http://paste.openstack.org/show/134302/
09:08:40 <ttx> If I run the script, it would remove the milestone targets for both of those
09:08:51 <asalkeld> that sounds right
09:08:59 <ttx> so you may want to set a priority for them if you want them to stay
09:09:16 <asalkeld> ok, makes sense
09:09:22 <ttx> asalkeld: the general goal here is to use the milestone pages to communicate the main things being worked on
09:09:30 <ttx> like a report
09:09:51 <asalkeld> ok, I'll try keep on that
09:10:02 <ttx> obviously once storyboard is everywhere it will be all integrated :)
09:10:30 <asalkeld> ttx that spec2bp.py - I need to run that?
09:10:32 <ttx> ok, script is running now
09:10:55 <ttx> asalkeld: so spec2bp just helps if you want to set the fields when a spec is approved
09:11:07 <ttx> I can send you an email about it
09:11:18 <asalkeld> thanks, that would help
09:11:19 <ttx> #action ttx to send aslakeld info about spec2bp
09:11:30 <ttx> I have another version up for review that I need to rebase
09:11:36 <ttx> and then I'll advertise it again
09:11:50 <asalkeld> it would be nice if that ran on approval
09:12:27 <ttx> asalkeld: how representative would you say https://launchpad.net/heat/+milestone/kilo-1 is?
09:12:38 <ttx> is is missing a lot of stuff that is being worked on ?
09:13:07 <ttx> asalkeld: the main issue with spec2bp is that there is no way to CREATE the damn spec using launchpad api
09:13:21 <ttx> so the spec has to be manually created
09:13:26 <asalkeld> well there are people working on unapproved specs
09:13:26 <ttx> err.. the bp
09:13:35 <asalkeld> but that is ok
09:13:46 <asalkeld> we should be approving some specs soon
09:13:51 <asalkeld> and i'll clean up
09:14:17 <asalkeld> (small'ish specs)
09:14:47 <asalkeld> https://review.openstack.org/#/q/status:open+project:openstack/heat-specs,n,z
09:14:49 <ttx> I think at some point we said we could track the "not approved yet" specs as "Blocked"
09:14:52 <asalkeld> quite a heap
09:14:58 <ttx> if they are part of the plan
09:15:31 <asalkeld> not sure that is so nice
09:15:54 <ttx> asalkeld: ok, I guess you should add the BP as the specs get approved. Don't forget to set a priority if you want them to survive the script. We'll review progress there next week
09:16:13 <ttx> and I'll send you that email about the script
09:16:17 <asalkeld> ok, thanks ttx
09:16:26 <ttx> any topic for the cross-project meeting tomorrow morning ?
09:16:35 <asalkeld> i don't think so
09:16:44 <ttx> ok then, talk to you later!
09:16:49 <asalkeld> later
09:16:53 <ttx> mikal, johnthetubaguy: around?
09:17:04 <mikal> I am!
09:17:22 <johnthetubaguy> yes, but kinda busy with a deploy right now :(
09:17:26 <ttx> #topic Nova
09:17:44 <johnthetubaguy> kilo-1 is a mess that I hope to sort out last friday, but hopefully this afternoon now
09:17:46 <SergeyLukjanov> ttx, hey, any chance to sync earlier today? (/me travelling and will be available for ~ hour today)
09:17:57 <ttx> SergeyLukjanov: sure, just after Nova ?
09:18:22 <SergeyLukjanov> ttx, awesome, thx!
09:18:50 <ttx> mikal: as far as release management liaisons are concerned, I think we can safely say that John is the liaison for Nova, but you inteznd to still follow the release syncs and all ?
09:19:13 <mikal> ttx: well, that's a little bit up to johnthetubaguy
09:19:24 <mikal> ttx: he's our release guy, and I'll attend these if he finds value in me doing so
09:19:36 <mikal> I guess I need to anyways as prep for tomorrow's release meeting?
09:19:38 <ttx> mikal: trying to abuse him while he is busy with the deploy
09:20:15 <mikal> I'm not sure johnthetubaguy attended release meetings in juno? Just the syncs?
09:20:21 <ttx> mikal: the cross-project meeting might turn into a busy meeting for all PTLs and cross-project liaisons
09:20:31 <mikal> Ahhh, ok.
09:20:34 <mikal> That would make sense
09:20:42 <mikal> So yeah, perhaps this is the john / ttx syncup then
09:20:44 <mikal> I'd be fine with that
09:21:15 <ttx> we can discuss that next time
09:21:38 <mikal> Sure
09:21:39 <ttx> #action johnthetubaguy/mikal to clarify formal release management liaison delegation
09:21:40 <johnthetubaguy> OK, its more a super bad time for me, that cross project meeting, but yeah
09:21:55 <mikal> johnthetubaguy: I can cover for you in that one if I know what you need done there
09:21:56 <johnthetubaguy> I am happy to be release liaison, if that makes sense
09:22:06 <mikal> johnthetubaguy: yeah, you're totally on the hook for that
09:22:09 <ttx> johnthetubaguy: you don't *have to* attend the other one, the PTL can represent
09:22:12 <johnthetubaguy> mikal: cool, we need to sync anyways
09:22:19 <mikal> johnthetubaguy: agreed
09:22:41 <ttx> I'm just trying to empower the CPLs (cross project liaisons) to encourage people to step up
09:23:28 <ttx> mikal, johnthetubaguy: that's what would get kicked off milestones if I enabled the adjust script right now: http://paste.openstack.org/show/134304/
09:23:43 <ttx> (remedmber: script kills all unprioritized stuff)
09:24:11 <ttx> you may want to do a tour and ping me when I can enable the script
09:24:17 <ttx> doesn't have to be just now
09:24:26 <mikal> Huh, there's some weird stuff targetted and in that list
09:24:43 <johnthetubaguy> ttx: thats cool with me, I think, I haven't looked at that list since the summit, so it gonna be a bit odd right now
09:24:44 <ttx> mikal: yeah, same issue as always, anyone can set the milestone is LP
09:24:47 <mikal> Remind me what criteria the script uses to kick things?
09:24:50 <johnthetubaguy> there are approved specs I need to deal with, etc
09:24:54 <ttx> which is why we use the prio/milestone combo
09:25:05 <mikal> Yeah, I agree we should wait for John
09:25:09 <ttx> mikal: the script removes unprioritized stuff
09:25:15 <mikal> But that script looks like a good thing to enable after that
09:25:24 <johnthetubaguy> I am good turning that on, it worked well last release
09:25:52 <ttx> #action johnthetubaguy to do a final tour of milestones before pinging ttx to enable autokick
09:26:11 <johnthetubaguy> sure, will do, this afternoon hopefully
09:26:24 <ttx> I'll rework spec2bp soon to help with setting fields
09:27:29 <ttx> mikal, johnthetubaguy: is "<johnthetubaguy> I am happy to be release liaison, if that makes sense" a "yes" ?
09:27:38 * ttx can update the CPL page
09:27:57 <mikal> ttx: yes
09:27:57 <johnthetubaguy> I am good with that being a yes
09:28:05 <ttx> #info johnthetubaguy will be release liaison for Nova
09:28:08 <mikal> johnthetubaguy is the CPL for Compute / Nova / Whatever we're called
09:28:23 <ttx> the Nova thing
09:28:49 <ttx> ok, any topic you want to raise for the cross-project meeting?
09:29:51 <mikal> Not that I can think of, apart from that I'd like to see projects who intend to have mid-cycles announce dates ASAP
09:30:26 <ttx> ok, we can talk a bit about those tonight
09:31:04 <mikal> Ta
09:31:14 <ttx> Anne and I would like to understand why people organize them, too, see if anything can be done to reduce the need for them
09:31:24 <ttx> so that can be discussed tonight/tomorrow
09:31:39 <ttx> mikal, johnthetubaguy: ok, talk to you later!
09:31:43 <mikal> Yep, I am getting a lot of push back from a small number of companies about having one at all
09:31:55 <johnthetubaguy> ttx: cool, thanks
09:31:59 <mikal> I do think its nessesary for Nova at the moment, but we're working to make that less true in the future
09:32:32 <johnthetubaguy> mikal: we could try a remote one, but yeah, its tricky, means someone is up late at somepoint
09:32:33 <ttx> mikal: I think they fear that too many decisions would be made there, rather than just work getting done
09:32:52 <ttx> hackathons/social gatherings are fine
09:33:11 <ttx> "Core secret meeting", they kind of have to attend it
09:33:13 <mikal> Hmmm
09:33:25 <mikal> Its complicated
09:33:29 <ttx> it is indeed
09:33:45 <ttx> especially when you factor the delays for organizing travel in
09:33:46 <mikal> Nova is under a lot of pressure to deliver a lot, and that's very hard to do without keeping people in sync
09:33:58 <mikal> But some of the same people applying that pressure don't want to sync up
09:34:02 <ttx> i.e. predicting 3 months in adfvance you'll need one
09:34:10 * ttx needs to run quickly for an errand
09:34:17 <mikal> Fair enough
09:34:17 <ttx> SergeyLukjanov: be right back
09:34:20 <mikal> We can talk more later
09:34:25 <ttx> yes, at that meeting :)
09:34:33 <SergeyLukjanov> ttx, ok
09:45:16 <ttx> SergeyLukjanov: ready now
09:45:24 <SergeyLukjanov> ttx, me too
09:45:29 <ttx> #topic Sahara
09:45:57 <ttx> IIRC you said you would handle release liaison directly
09:46:08 <SergeyLukjanov> ttx, yup
09:46:19 <ttx> #info SergeyLukjanov will handle release liaison directly
09:47:05 <ttx> Should I enable the script that clears out unprioritized targeted blueprints ?
09:47:15 <ttx> at this point it appears it wouldn't kick anything out
09:47:27 <SergeyLukjanov> ttx, yup
09:47:40 <SergeyLukjanov> ttx, if we have something unprio than we need to pull it out
09:47:57 <ttx> ok, the script will now do that automatically
09:48:31 <SergeyLukjanov> ttx, ack
09:48:32 <ttx> SergeyLukjanov: how complete is k1 ?
09:48:49 <SergeyLukjanov> ttx, I think it's on a good shape
09:48:52 <ttx> does it represent most stuff you plan to work on ? Or just a very partial view at this point ?
09:48:52 <SergeyLukjanov> #link https://launchpad.net/sahara/+milestone/kilo-1
09:49:17 <SergeyLukjanov> ttx, due to the summit and vacations after it - it's partial IMO
09:49:29 <SergeyLukjanov> ttx, we probably have some other stuff that'll be included
09:49:31 <ttx> ok, we'll refine it as we get closer
09:49:53 <SergeyLukjanov> ttx, I'm on vacation this week too, so, will se next week I think
09:50:33 <ttx> ok
09:50:47 <ttx> anything you want to discuss at meeting today?
09:50:58 <SergeyLukjanov> ttx, I think no, everythong is going ok
09:51:15 <SergeyLukjanov> ttx, horizon stuff is in a good progress too
09:51:16 <ttx> alright then, ttyl
09:51:21 <SergeyLukjanov> ttx, thx!
13:00:04 <eglynn> ttx: knock, knock, ready when you are
13:02:16 <ttx> yep ,just a sec
13:02:55 <ttx> finishing an email, 1 min
13:03:19 <eglynn> cool, no rush
13:04:34 <ttx> eglynn: o/
13:04:37 <ttx> #topic Ceilometer
13:04:44 <eglynn> #link https://launchpad.net/ceilometer/+milestone/kilo-1
13:04:45 <ttx> sorry about that
13:04:49 <eglynn> np!
13:04:58 <eglynn> so we're begining to flesh out kilo-1
13:05:03 <eglynn> but early days yet
13:05:10 <eglynn> lots of specs reviews in flight
13:05:15 <eglynn> and more to come I expect
13:05:25 <ttx> If I turn on the autokick script, it will kick out kafka-publisher (from kilo-1)
13:05:31 <ttx> because it has no priority set
13:05:45 <ttx> Should you fix it before I turn it on ?
13:05:46 <eglynn> yeah the spec hasn't landed yet
13:05:51 <ttx> ah, hm
13:06:02 <eglynn> I'll manually kick, not sure how got targetted
13:06:10 <eglynn> I'll manually kick *it, not sure how *it got targetted
13:06:19 <ttx> ok, cal I enable the script crontab for ceilometer now ?
13:06:35 <ttx> can*
13:06:47 <eglynn> yep
13:06:51 <eglynn> please do
13:06:58 <ttx> ok done
13:06:59 <eglynn> so on the specs process for kilo
13:07:13 <eglynn> I missed this session at summit https://etherpad.openstack.org/p/kilo-crossproject-specs
13:07:41 <ttx> we mostly said that would be used only for truly cross-project specs (i.e. likely to affect everyone)
13:07:41 <eglynn> but I take there was some unease at how spec across the board worked in juno?
13:08:14 <eglynn> so the practice within individual projects will remain as-was?
13:08:19 <ttx> It felt like people were happy with it and wanted to standardize
13:09:27 <ttx> The TODO in that etherpad translate what we'd like to try pretty well
13:09:49 <eglynn> I guess the key question in my mind is "not all blueprints need a spec?"
13:10:03 <eglynn> from the etherpad it seems that wiggle room was closed off somewhat?
13:10:15 <ttx> I would say, not all features need a spec, and not all features need a blueprint
13:10:33 <ttx> no, projects can still very much set the bar where they want
13:10:53 <ttx> as far as "integrated release" is concerned, it's the blueprint view (i.e. the subset of features that we track for release purpose) that matters
13:11:30 <eglynn> cool, it's the set different of those two categories above that I was wondering about
13:11:55 <eglynn> i.e. features that do need a BP (for tracking) but not necessarily a spec (as the way forward is self-evident)
13:12:19 <eglynn> set *difference
13:12:27 <ttx> my view on it is... use spec for stuff which requires design/choice, and/or use blueprint for stuff that makes sesne to track as part of the release cycle
13:12:36 <eglynn> cool, got it :)
13:12:47 <ttx> there may be smallish stuf that falls between the cracks
13:12:59 <ttx> in which case the commit message should be self-explaning
13:13:33 <ttx> I assume you will handle release management directly ? No release management liaison ?
13:13:55 <eglynn> yep
13:14:17 <eglynn> I'm also down as stable-maint liaison for now
13:14:29 <eglynn> no one jumped at the call for volunteers
13:14:57 <eglynn> a lot of the more active cores are already liaising on something
13:15:10 <eglynn> (oslo, docs, qa etc.)
13:15:14 <ttx> Note that if they are part of your roadmap, you can also track "features that are waiting for spec approval" in blueprints using "Blocked" status
13:15:31 <eglynn> cool, I'll adopt that practice
13:15:33 <ttx> i.e. if those are a priority in your release plans
13:15:39 * dhellmann makes a note of that, too
13:15:46 <ttx> Working on https://review.openstack.org/#/c/108041/
13:16:14 <eglynn> cool
13:16:29 <ttx> that way blueprints are truly a reporting tool, disconnected from spec status
13:16:36 <ttx> reporting/planning
13:16:40 <eglynn> nice :)
13:16:54 <ttx> would be nice if only Launchpad could create a blueprint from the API
13:17:15 <ttx> ok, I think I've got the urgent points covered
13:17:28 <eglynn> yep, thanks for your time :)
13:17:36 <ttx> #info Eoghan will do release management duties directly
13:17:47 <ttx> eglynn: anything to add to agenda for meeting tonight ?
13:17:52 <eglynn> nope
13:18:12 <ttx> ok then
13:18:26 <ttx> adding you to https://wiki.openstack.org/wiki/CrossProjectLiaisons
13:18:56 <ttx> dhellmann: ready?
13:19:01 <dhellmann> ttx: here
13:19:05 <ttx> #topic Oslo
13:19:27 <ttx> I suspect you'll stay the release management liaison for Oslo, whatever that means ?
13:19:37 <ttx> i.e. you'll be the one attending this sync ?
13:19:39 <dhellmann> yes, I think that's going to be simplest
13:19:57 <dhellmann> I'll put myself on the list
13:20:02 <ttx> we don't exactly discuss the same things as other projects, but I think we still benefit from a sync
13:20:06 <ttx> I'm on it
13:20:08 <dhellmann> ok
13:20:50 <ttx> Looking to the autokick script, not sure it makes sense in Oslo world
13:20:51 <dhellmann> I've asked for volunteers for stable maint and documentation liaisons, too, but no one raised their hand
13:21:13 <dhellmann> that's the thing that removes blueprints if they don't have a priority set?
13:21:13 <ttx> that's the script which will remove unprioritized blueprints from kilo milestones
13:21:29 <dhellmann> I'd be happy to have that running to help keep us honest
13:21:43 <ttx> we'd have to list all the launchpad projects
13:21:53 <dhellmann> oh, so it wouldn't run against the project group?
13:22:04 <ttx> hmmm, worth a try
13:22:11 <dhellmann> if not, it's not a big deal
13:22:22 <ttx> https://api.launchpad.net/devel/oslo object has no attribute 'getSeries'
13:22:41 <ttx> I would have to hack the script to dereference the projectgroup
13:22:43 <dhellmann> I've explained to everyone about using the new release tool, so we shouldn't get too cluttered
13:22:47 <ttx> I guess it's doable
13:22:56 <dhellmann> if you find time, fine, otherwise don't worry about it
13:23:17 <ttx> #action ttx to look into supporting projectgroups in autokick.py, so that we can apply it to Olso
13:23:28 <ttx> in the mean time it won't run
13:23:32 <dhellmann> ok
13:23:48 <ttx> I wanted to read https://wiki.openstack.org/wiki/Oslo/ReleaseProcess and comment
13:23:57 <ttx> maybe I can do that now
13:23:58 <dhellmann> please do!
13:24:13 <ttx> I'll ping you in 5 min once I read it ?
13:24:30 <dhellmann> I'm going to the bakery for breakfast right after we're done, but I'll be back in 20 min
13:24:52 <ttx> OK, let's close the 1:1 first
13:24:56 <dhellmann> sure
13:25:01 <ttx> anything to add for todays meeting agenda ?
13:25:18 <dhellmann> I don't think so
13:25:28 <dhellmann> is it worth mentioning the alpha version decision?
13:25:42 <dhellmann> that's the only thing that really comes to mind for me
13:26:14 <ttx> dhellmann: I think the only person who I can remember opposing a part of it (stable dep capping) would be markmc
13:26:25 <dhellmann> ok
13:26:35 <ttx> so not sure disucssing it in meeting would help/change
13:26:47 <dhellmann> I have a note to myself to propose the cap change in the stable global requirements list, so I'll try to do that today
13:26:48 <ttx> although pinging him could be seen as a courtesy
13:26:55 <dhellmann> yeah, I'll do that, too
13:27:08 <ttx> ok then, go to bakery, buy croissants, ping me when back. I'll read that page in the next 5 min
13:27:31 <ttx> and we can quickly discuss it when you're back
13:27:33 <dhellmann> ok, bbiab
13:33:21 * ttx braindumps random remarks
13:34:20 <ttx> - the main goal of the "fix leftover bugs" stop is to let people try to manually fix the bugs Launchpad is timeouting on, could be good to mention that
13:35:38 <ttx> - the email example is using an alpha pre-release, would be good to switch to a "normal" release template
13:36:30 <ttx> - Would be cool to add the link to the Launchpad milestone page, since we build one
13:36:47 <ttx> Otherwise looks good.
13:44:36 <dhellmann> ttx: back
13:44:48 <dhellmann> points 1 and 2 ack, I'll do that today
13:44:54 <dhellmann> not sure what you mean for point 3?
13:46:31 <ttx> the announcement email doesn't include a link to the Launchpad milestone page that oslo_release.sh helps build
13:46:41 <dhellmann> ah, ok, that makes sense
13:46:58 <dhellmann> I need to automate generating that email body more anyway
13:48:40 <ttx> ack
15:03:39 <mestery> ttx: Here when you're ready!
15:04:19 <ttx> mestery: hi
15:04:24 <ttx> #topic Neutron
15:04:51 <ttx> mestery: you fine with being the release management liaison for kilo, or would prefer to delegate that ?
15:05:07 <mestery> ttx: Ack, I'm good with that.
15:05:25 <ttx> Been looking into enabling autockick for Neutron/kilo
15:05:35 <ttx> http://paste.openstack.org/show/134396/ shows what would happen
15:05:39 <mestery> Please do! I thought that was very useful during Juno.
15:05:42 * mestery looks
15:05:54 <ttx> you might want to fix those by hand before I enable the crontab
15:05:54 <mestery> Looks good to me
15:06:07 <ttx> ok, enabling
15:06:10 <mestery> Thanks!
15:06:17 <mestery> I had been manually kicking a bit the past few weeks already ;)
15:06:27 <ttx> updating wikipages
15:07:09 <ttx> ok done
15:07:12 <mestery> Thank you!
15:07:21 <ttx> #info Kyle will handle release management directly
15:07:35 <ttx> https://launchpad.net/neutron/+milestone/kilo-1
15:07:54 <ttx> feels like this is incomplete at this point
15:07:57 <mestery> This will be changing over the next week as we start approving specs
15:08:10 <mestery> We're in the process now, people are spending lots of time reviewing specs
15:08:17 <ttx> Note that if you want to track specs-still-needing-approval as part of your milestone roadmap, you can use "Blocked"
15:08:28 <mestery> Ah, right, I'll do that!
15:08:34 <ttx> useful for tracking essential stuff
15:08:40 <ttx> that you know you need to do anyway
15:08:51 <mestery> Perfect
15:08:57 <ttx> We'll discuss meetups in general at the cross-project meeting today
15:09:06 <ttx> anything else you'd like to add ?
15:09:47 <mestery> That's about it! markmcclain and I are in the process of proposing the advanced services spin-out from neutron now
15:09:54 <ttx> ack
15:09:56 <mestery> We'll be emailing hte list and gettingthat on a TC agenda soon
15:10:11 <mestery> We have our mid-cycle Dec 8-10 as well, may be worth noting that in the logs here.
15:10:25 <ttx> #info Neutron mid-cycle Dec 8-10
15:10:39 <mestery> Otherwise, that's it for now! Hopefully next week I'll have more interesting BPs in kilo-1 ;)
15:10:51 <ttx> ok then, have a good day!
15:10:55 <mestery> you too, thanks ttx!
15:16:13 <ttx> nikhil_k: ready when you are
15:16:23 <nikhil_k|afk> ttx: ready
15:16:26 <ttx> #topic Glance
15:16:41 <nikhil_k> have one item from my side
15:16:49 <ttx> nikhil_k: sure, shoot
15:17:07 <nikhil_k> ttx: the author of this commit https://review.openstack.org/#/c/133858/
15:17:15 <nikhil_k> requested it to be in juno
15:17:41 <nikhil_k> ttx: wanted to see if we can get that one in and what was "general" process of allowing such changes in stable/*
15:18:01 <nikhil_k> do we delegate to the stable maintainers? (now per project)
15:18:45 <ttx> nikhil_k: feels like it should be acceptable per stable rules
15:19:06 <ttx> if stuck, you can raise a thread on -dev with [stable] prefix
15:19:22 <ttx> you can also reach out on #openstack-stable
15:19:33 <nikhil_k> sure, I'll remove the -2 and make it +2 then
15:19:36 <nikhil_k> ah nice, sure
15:19:49 <ttx> nikhil_k: I assume you'll be handling release management liaison duties for Glance ?
15:20:12 <nikhil_k> ttx: yes
15:20:27 <ttx> #info Nikhil will do relmgt liaison for Glance
15:20:56 <ttx> The other thing I wanted to discuss are autocleaning of milestone plans
15:21:17 <ttx> We are using blueprints and target milestone to communicate which features are likely to land in which milestone
15:21:31 <ttx> it's like a roadmap that is communicated outside the project
15:21:49 <ttx> so we maintain pages like https://launchpad.net/glance/+milestone/kilo-1
15:22:14 <ttx> BUT launchpad unfortunately doesn't restrict who can set "starget milestone" on a blueprint
15:22:29 <nikhil_k> sure, I'm aware (for the most part at least) :)
15:22:31 <ttx> so we use a combination of priority being set AND milestone
15:22:45 <nikhil_k> ah ok
15:22:50 <ttx> and I have a script that will remove any unprioritized stuff from milestone
15:23:03 <ttx> so that nobody can sneak stuff in without the project drivers approval
15:23:19 <ttx> That script is not enabled yet for glance in kilo
15:23:24 <ttx> but I can enable it
15:23:26 <nikhil_k> sure, the thing is in Glance we use specs
15:23:33 <ttx> (it wouldn't have any effect right now)
15:23:37 <nikhil_k> so just wanted to get some of you thoughts on it
15:23:45 <ttx> So, you can use spec to vet for design
15:23:53 <ttx> and blueprints to communicate a roadmap out
15:24:11 <ttx> I have another script called spefc2bp that can be used to sync status between spec and bp
15:24:24 <nikhil_k> this would be an issue after a spec is approved right?
15:24:38 <ttx> but unfortunately that script can't create a blueprint, so you still have to create it byu hand
15:24:42 <nikhil_k> that script sounds nice
15:24:57 <ttx> you can track a feature in blueprints even befgore the spec is approved
15:25:07 <nikhil_k> sure, that's ok. BP are only for bookkeeping anyways with most design details in the spec
15:25:12 <ttx> if you know a specific spec is really on the roadmap
15:25:25 <nikhil_k> ohk, that issues sounds bad
15:26:01 <ttx> Imagine you have a key feature you want delivered in Kilo release, you can add a blueprint to track it even before the spec is approved
15:26:09 <ttx> just set status to "Blocked"
15:26:31 <ttx> I'll rebase my spec2bp script and land it, then send an email about it
15:26:33 <nikhil_k> gotcha
15:26:35 <ttx> more about that next week
15:26:42 <nikhil_k> sure
15:27:05 <ttx> #action ttx to also clearly explain difference between spec (design) and blueprint (tracking)
15:27:29 <nikhil_k> also, if you could help me understabd where do we set the priority
15:27:32 <nikhil_k> ?
15:27:33 <nikhil_k> in th BP?
15:27:56 <ttx> yes, you set priority in the blueprint
15:28:09 <ttx> for example https://blueprints.launchpad.net/glance/+spec/refactoring-glance-logging is set to "Low"
15:28:14 <ttx> nikhil_k: next week we'll aslo start looking at kilo-1 goals, so you might want to populate that with accepted specs you want on your roadmap (currently a bit empty)
15:28:43 <ttx> That's all for this week anyway, anything you want to add to the meeting agenda for today ?
15:28:55 <nikhil_k> ttx: yeah, I thought that before spec is approved we prolly don't want to do that.. though this makes sense
15:29:14 <ttx> you don't want to list random specs before they are approved obviously
15:29:26 <nikhil_k> ttx: just wanted to say that we've a volunteer from glance for the role of stable-maint* liaison
15:29:27 <ttx> only key priorities that you already know will have to make it
15:29:39 <nikhil_k> ttx: yeah, def
15:29:52 <ttx> cool! Just edit https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch directly
15:29:58 <nikhil_k> (situation is still a bit wonky atm)
15:30:07 <nikhil_k> ah ok, sure
15:30:20 <ttx> any last minute question ?
15:30:30 <nikhil_k> ttx: no, thank you!
15:31:06 <ttx> #topic Cinder
15:31:09 <ttx> thingee: o/
15:31:13 <thingee> o/
15:31:19 <ttx> sorry for the wrong channel name
15:31:23 <thingee> that's ok
15:31:44 <ttx> thingee: I take it you intend to fill release management liaison duties directly ?
15:31:53 <thingee> ttx: yes
15:32:03 <thingee> ttx: so 28 bps. this is because of the rush deadline of drivers.
15:32:15 <ttx> #info Mike will cover Cinder release management directly
15:32:30 <ttx> https://launchpad.net/cinder/+milestone/kilo-1
15:33:12 <ttx> thingee: that's fine :)
15:33:18 <ttx> better rush at k1
15:33:26 <thingee> ttx: luckily majority of bps are in code review.
15:33:39 <ttx> thingee: as you may know, we are using a combination of priority and target milestone to build those pages
15:33:54 <ttx> (we require prio to be set, because otherwise anyone can add to milestone)
15:34:12 <ttx> I have a script that will autokick things out if they miss prio
15:34:29 <ttx> that avoids having to keep an eye on the list for intruders all the time
15:34:44 <ttx> If I enabled the script right now, it would kick out:
15:34:48 <ttx> KICK kilo-rbd-driver-feature-enhancement (from kilo-1)
15:34:48 <ttx> KICK filtering-weighing-with-driver-supplied-functions (from kilo-1)
15:35:04 <ttx> if you want to keep them in you might want to set a priority for them
15:35:06 <thingee> ok those are fine. I will fix priorities now
15:35:28 <ttx> ok, let me know when I can set the script to run on crontab for cinder
15:35:34 <thingee> done
15:35:48 <ttx> ok script enabled
15:35:55 <thingee> thank you
15:36:18 <ttx> I guess you don't expect much more to be added to k1? That's already a lot by Cinder standards :)
15:36:51 <thingee> definitely. I have spoken to core on drivers get priority this milestone. that's the benefit to vendors working hard to getting in this milestone.
15:37:24 <ttx> alright then. Anything you'd like to se discussed at the cross-project meeting today at 21:00 ?
15:37:28 <ttx> see*
15:38:20 <thingee> I'm mostly interested in the oslo object version work, but I don't know if it makes sense to get a progress report on where that's going.
15:38:45 <ttx> I guess you can ask during open discussion then, if you're around
15:38:45 <thingee> since it was at the summit we discussed things. not a lot of time to make progress.
15:38:50 <thingee> will do
15:38:55 <ttx> Questions before we close ?
15:39:05 <thingee> I'm good.
15:39:15 <ttx> thingee: alright then, have a good day!
15:39:20 <ttx> david-lyle: around?
15:39:23 <thingee> and you have a good evening
15:41:46 <david-lyle> ttx: here
15:41:52 <ttx> #topic Horizon
15:42:13 <ttx> david-lyle: do you plan to handle release liaison directly, or delegate that ?
15:42:28 <david-lyle> I'll handle it
15:42:30 <ttx> #info David will fill release liaison duties for Horizon
15:43:06 <ttx> david-lyle: last cycle IIRC we did not enable autokick for Horizon (the automatic kick out for unprioritized blueprints in a milestone)
15:43:22 <ttx> would you like to enable it for this cycle ?
15:43:31 <ttx> Do you use specs now ?
15:43:50 <david-lyle> we don't use specs, but have changed the blueprint process a little
15:44:16 <david-lyle> autokick would just remove unprioritized bp from milestones/
15:44:17 <david-lyle> ?
15:44:38 <ttx> yes, to makes ure you can curate the list without people randomly adding stuff
15:44:54 <david-lyle> ooh, that sounds nice :)
15:45:17 <ttx> but then you can't use the milestone page as part of a blueprint approval workflow
15:45:26 <david-lyle> true
15:45:28 <ttx> i.e. only things you vet will appear there
15:45:37 <david-lyle> let's leave it off for now
15:45:46 <ttx> so you need another way to get a list of "candidates"
15:45:47 <david-lyle> we may move to the specs process next release
15:46:29 <ttx> if you use specs, approval/design happens there, so BPs are only used for rodamp, tracking, communication
15:46:33 <ttx> roadmap*
15:46:41 <david-lyle> I get enough surprise bps at the end of a release as it is
15:46:58 <ttx> but if you don't use specs yet, approval still kind of happens in launchpad
15:47:13 <ttx> so you need some way for people to propose their stuff for a milestone
15:47:35 <ttx> and kicking stuff out aggressively might destroy that :)
15:47:42 <david-lyle> yeah, let's leave it for now
15:48:00 <ttx> #info Horizon to stay out of autokick at this point (doesn't use specs yet)
15:48:29 <ttx> david-lyle: so that means you'll have to watch the unprioritized stuff on https://launchpad.net/horizon/+milestone/kilo-1
15:48:41 <ttx> and either untarget it, or set some priority if you approve of it
15:49:11 <ttx> your k1 looks pretty good though already
15:49:32 <david-lyle> yeah, been working through it
15:50:02 <ttx> ok, anything you want to discuss at meeting today?
15:50:19 <david-lyle> no, I don't think so
15:50:21 <ttx> Any last-minute question before we close ?
15:50:53 <david-lyle> no, I'm good
15:51:08 <ttx> david-lyle: alright then, have a good day!
16:50:41 <ttx> notmyname: o/
16:50:45 <notmyname> ttx: hi!
16:50:47 <ttx> #topic Swift
16:50:50 <ttx> Welcome back
16:50:53 <notmyname> thanks
16:51:10 <notmyname> I'm still getting my head around what's going on, in general.
16:51:22 <ttx> Probably a bit early for plans, but do you have an idea of the next release timeframe ?
16:51:27 <notmyname> I'm working on refreshing our priority reviews
16:51:29 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
16:51:32 <notmyname> no clue
16:51:47 <notmyname> and seagate has contributed a full chinese translation
16:51:48 <notmyname> #link https://www.transifex.com/projects/p/swift/
16:52:01 <notmyname> just waiting on the cron to run and propose it
16:52:11 <ttx> ok
16:52:25 <notmyname> most of my focus is looking at the EC work
16:52:40 <ttx> I take it you'll be doing release management liaison for Swift this cycle ?
16:52:44 <notmyname> I suspect we'll have a release around the end of the year (ish). but that's just a guess for now
16:52:58 <notmyname> ya
16:53:40 <ttx> #info John will do release management liaison for Swift in kilo
16:54:24 <ttx> ok, not much to discuss then
16:54:30 <notmyname> what other logistical stuff needs to happen?
16:54:33 <ttx> any topic to add to meeting agenda for today?
16:55:28 <ttx> notmyname: what do you mean by other logistical stuff?
16:55:49 <notmyname> boilerplate things at the start of an integrated release cycle
16:56:04 <ttx> nothing that I can think of
16:56:26 <notmyname> no, I don't think I have anything for the meeting. I'm interested in the TC discussions around core/integrated/tent/cats
16:56:30 <ttx> If you add blueprints to next-kilo they should appear on http://status.openstack.org/release/
16:56:50 <ttx> but nothing special required
16:56:53 <notmyname> ok
16:57:16 <ttx> ok then, I'll talk to you later then
16:57:33 <notmyname> bye
16:57:36 <ttx> morganfainberg: ready when you are
16:57:39 <ttx> notmyname: thx!
16:58:18 <morganfainberg> Ttx o/
16:58:24 <ttx> #topic Keystone
16:58:43 <ttx> morganfainberg: I assume you'll be filling release management liaison duties for the kilo cycle ?
16:58:53 <morganfainberg> Yes.
16:59:02 * ttx adds morganfainberg to https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
16:59:53 <ttx> next question about enabling autokick for your blueprints, let me explain a bit
17:00:27 <ttx> anyone can set milestone target in launchpad, which messes up our usage of launchpad blueprint page as a roadmap communication tool
17:00:36 <ttx> since random people wil add stuff
17:00:39 <morganfainberg> Yep.
17:00:50 <ttx> so instead we use priority + target milestone
17:01:07 <ttx> since priority can only be set by project drivers
17:01:11 <morganfainberg> Makes sense.
17:01:21 <ttx> I have a script that will automatically remove unprioritized stuff from milestone
17:01:36 <ttx> so that you don'ty have to watch the list for intruders all the time
17:01:38 <morganfainberg> I'm a fan of that.
17:01:49 <ttx> I'll take that as a "yes, enable it now"
17:01:59 <morganfainberg> Please do enable it :)
17:02:02 <ttx> done.
17:02:24 <ttx> quick check @ https://launchpad.net/keystone/+milestone/kilo-1
17:02:42 <ttx> I suppose it's at the very early stages
17:03:01 <morganfainberg> Yeah. I was planning on starting the classification this week
17:03:07 <ttx> remember you can track specs that have not been approved yet (if they are key milestone objectives) by setting status to Blocked
17:03:10 <morganfainberg> And targeting.
17:03:19 <morganfainberg> Great. Will do so.
17:03:33 <ttx> that makes it much more useful as a tracking tool, rather than a painful duplication of effort
17:03:42 <morganfainberg> Yep.
17:03:54 <ttx> Ok, that's all I had for this week
17:04:03 <ttx> Anything you'd like to discuss at meeting today?
17:04:17 <morganfainberg> Nope. Most everything is just moving along.
17:04:19 <ttx> Any last-minute question ?
17:04:43 <morganfainberg> Nope. Thanks.
17:05:01 <ttx> devananda: does your plane have wifi ?
17:10:50 <devananda> ttx: oh hai!
17:10:57 <ttx> devananda: oh!
17:11:03 <ttx> #topic Ironic
17:11:26 <devananda> smoehow this was on my calendar for yesterday
17:11:32 <ttx> devananda: do you plan to do release management liaison work, or do you plan to delegate that to a trusted monkey?
17:11:42 <devananda> so I don't have anything prepared ...
17:11:48 <ttx> that's fine
17:12:02 <devananda> for now, I will continue to do that, but lucas has expressed some interest
17:12:12 <devananda> and I'm happy if he wants to start doing it as the cycle progresses
17:12:12 <ttx> nothing really requiring prep at this point
17:12:12 <ttx> just a few questions and info bits
17:12:37 <ttx> ok, makes sense
17:12:47 <ttx> #info Deva will do release management liaison for the time being
17:13:35 <ttx> devananda: as explained above...
17:13:45 <ttx> next question about enabling autokick for your blueprints, let me explain a bit
17:13:51 <ttx> anyone can set milestone target in launchpad, which messes up our usage of launchpad blueprint page as a roadmap communication tool
17:13:59 <ttx> since random people will add stuff
17:14:05 <ttx> so instead we use priority + target milestone
17:14:10 <ttx> since priority can only be set by project drivers
17:14:15 <ttx> I have a script that will automatically remove unprioritized stuff from milestone
17:14:23 <ttx> so that you don'ty have to watch the list for intruders all the time
17:14:28 <devananda> ++
17:14:33 <ttx> would you like that to be enabled for ironic ?
17:14:39 <devananda> sure
17:14:49 * ttx enables
17:15:05 <ttx> the only downside is people complaning to me why I untarget their stuff
17:15:10 <ttx> at 3am in the morning
17:15:14 <devananda> heh
17:15:26 <devananda> is it part of release-tools?
17:15:28 <devananda> I can also run it
17:15:34 <devananda> so they complain to me :)
17:16:02 <ttx> I run it on a crontab
17:16:15 <ttx> so that it never sticks
17:16:42 <ttx> #action ttx to post autokick.py in some repo
17:17:07 <devananda> also, we are changing the format of our weekly meetings, and adding an alternate time slot
17:17:16 <ttx> devananda: given how much time you spent home so far, I suspect https://launchpad.net/ironic/+milestone/kilo-1 is still WIP ?
17:17:34 <ttx> (as far as completeness goes)
17:17:36 <devananda> yea
17:17:50 <devananda> if by WIP you mean untouched by me since the summit :)
17:18:05 * devananda adds that to his backlog of tasks
17:18:14 <ttx> note that you have the option to track yet-unapprover-specs-but-still-in-our-priority-roadmap stuff by having "Blocked" blueprints in your milestone
17:18:22 <ttx> unapproved*
17:19:02 <ttx> that makes the milestone page slightly beter at predicting what will likely happen in a milestone
17:19:20 <ttx> anything you'd like to discuss at meeting today ? Any last-minute question ?
17:20:16 <devananda> just noting that we'll be changing our meeting time in two weeks
17:20:35 <devananda> I'll announce once everyone has finished voting on the new slots
17:20:49 <ttx> ok cool
17:21:00 <ttx> #info Ironic will be changing our meeting time in two weeks
17:21:06 <ttx> SlickNik: around?
17:21:12 <ttx> devananda: thanks for your time!
17:21:14 <SlickNik> ttx: o/
17:21:17 <ttx> #topic Trove
17:21:19 <devananda> ttx: cheers, thank you!
17:21:50 <ttx> SlickNik: same questions for you. Do you plan to fill release management liaison duties during kilo ? Or delegate ?
17:22:28 <SlickNik> ttx: I'll be on the hook for release management duties.
17:22:36 <ttx> #info Nikhil will do relmgt liaison
17:22:50 <SlickNik> ttx: I'll update the wiki page.
17:22:57 <ttx> SlickNik: already done
17:23:02 <SlickNik> ttx: thanks!
17:23:02 <ttx> You are switching to specs this cycle
17:23:11 <SlickNik> Yes, we already did.
17:23:14 <ttx> As explained above...
17:23:35 <ttx> you can read what I said to devananda 10 minutes ago
17:23:52 <SlickNik> doing that right now.
17:23:53 <ttx> and let me know if you'd like said script to be activated for Trove as well
17:24:22 * ttx dry-runs the script to test effect
17:24:38 <ttx> $ ./autokick.py --dryrun trove kilo
17:24:38 <ttx> KICK cassandra-cluster (from kilo-2)
17:24:39 <ttx> KICK clustering-replicasets (from kilo-1)
17:24:39 <ttx> KICK guest-rpc-ping-pong (from kilo-1)
17:24:50 <ttx> that's what would happen if I ran it now ^
17:25:09 <ttx> you might want to fix those if you want to keep them in
17:25:14 <SlickNik> Yes, I don't have the priority set for those right now, which I will follow up on.
17:25:18 <ttx> (fix = give them a priority)
17:25:38 <SlickNik> Got it.
17:25:48 <ttx> SlickNik: point is, once the script runs on crontab, those would have been removed automatically
17:26:03 <ttx> so only what you add (with a priority) will stick in the list
17:26:18 <ttx> taht's usually the workflow you want once you switched to spec for design/approval part
17:26:42 <ttx> you want to curate a list for comunication/tracking purposes without everyone using it as their playground
17:26:54 <SlickNik> Got it, I'll make sure we're setting the priority for the BPs.
17:27:02 <SlickNik> going forward.
17:27:12 <ttx> OK, let me know when you fixed them, and I'll enable the script
17:27:27 <ttx> #info Waiting on SlickNik's ping to enable autokick for Trove
17:27:50 <SlickNik> I had another question wrt specs.
17:27:59 <ttx> sure, shoot
17:28:31 <SlickNik> Should the actual spec review in gerrit get +2 and merged when the spec is approved, or when the feature actually lands.
17:28:48 <ttx> general process is when the design is approved
17:28:59 <SlickNik> I think it's the former, but some folks seemed to think it's the latter, so I wanted to double check.
17:29:09 <ttx> feature completion is tracked in Launchpad blueprints basically (if you care)
17:29:17 <ttx> so yes, the former
17:29:48 <SlickNik> Roger that. Thanks for the clarification.
17:30:08 <ttx> specs are a way to iterate on design and track approvals. We still use Launchpad for tracking the implementation and when that lands in our cycle
17:30:37 <ttx> ok, unless you have another question, we can close for this week
17:31:10 <SlickNik> That's it from my end. I'll update the LP BPs and ping you to enable the kick-script.
17:31:15 <SlickNik> Thanks ttx!
17:31:21 <ttx> SlickNik: awesome thx
17:31:31 <ttx> #action slicknik to prio BPs and ping ttx when done
17:31:33 <ttx> #endmeeting