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