Tuesday, 2014-09-02

*** mestery has quit IRC01:48
*** mestery has joined #openstack-relmgr-office03:41
*** mestery has quit IRC04:08
*** flaper87|afk is now known as flaper8706:26
*** flaper87 is now known as flaper87|afk07:43
*** flaper87|afk is now known as flaper8707:48
*** zz_johnthetubagu is now known as johnthetubaguy07:56
ttxjohnthetubaguy: ready when you are07:59
ttx#startmeeting ptl_sync08:00
openstackMeeting started Tue Sep  2 08:00:09 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.08:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:00
openstackThe meeting name has been set to 'ptl_sync'08:00
ttx#topic Nova08:00
ttx#link https://launchpad.net/nova/+milestone/juno-308:00
johnthetubaguyso, yeah, blueprints, yuck08:00
ttx#info 15 implemented, 45 in review08:00
johnthetubaguyso some improvements08:01
ttxThat's only +7 in one week, and we have 0-2 days to go08:01
johnthetubaguymikal has been pinging people directly to review the top few08:01
johnthetubaguythere are one or two almost there, the rest, well we probably should start to chop them I think08:01
johnthetubaguyI guess anything without a +2 at this point, is not going to make it, bar a miricle08:02
ttxYes, we should allow the last 2 days for gate processing08:02
johnthetubaguy(+7 in one week is probably the best we have managed all release, buy yeah...)08:02
ttxSo looking at the top ones...08:03
*** mestery has joined #openstack-relmgr-office08:03
johnthetubaguyI am told its closer than it looks08:03
ttxok, so we keep it on the j3 list08:04
johnthetubaguyI think we have to, at this point08:04
ttxThis one we have to consider "complete at some point08:04
johnthetubaguyyeah, this one is ongoing, yeah08:05
johnthetubaguyI think thats probably today-ish08:05
ttxwhat's in-flight already approved for it ?08:05
johnthetubaguyI think some stuff was mostly with −1 from something on it08:05
johnthetubaguybut loads has merged08:05
johnthetubaguyI will try catch dansmith when he comes online08:06
johnthetubaguy(and nikola)08:06
ttxyeah, ideally we would only pursue the ones that make it a bit more logicaly complete08:07
johnthetubaguyI approved a chuck of those yesterday08:07
johnthetubaguyttx: yeah, good point, but not sure its really that neat right now, will check08:07
ttxi.e. what REALLY needs to merge so that Juno looks like something vs. what could merge08:07
ttxIs it all contained in  ?ttps://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z08:08
ttxIs it all contained in https://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z ?08:08
johnthetubaguywell, probably nothing in here, it was more high priority because its blocking loads of the other vmware bits08:08
johnthetubaguyI think the answer is kinda of no, but it has the most important bits after the oslo patch, I think08:09
johnthetubaguyI think I probably block all the patches not on that list08:09
ttxbasically, starting tomorrow morning I think we should defer everything that is not already approved and in-flight08:10
johnthetubaguythats a good line to draw08:10
ttxthat leaves today for the last +2s08:10
johnthetubaguysounds fair08:10
johnthetubaguywell, agreed that still makes it very tight08:10
ttxand to trace a line in the sand for ongoing stuff like the objects work08:10
ttxSo for this morning I would defer/-2 everything that is just far from makign it08:11
johnthetubaguyyeah, stuff with −1s etc08:11
ttxonly keep the stuff that is 80% there at least, and which could possibly be approved today08:11
*** morganfainberg is now known as morganfainberg_Z08:12
johnthetubaguyright, the lows I have no idea on right now, but the mediums are mostly not done, from what I saw yesterday08:12
ttxjohnthetubaguy: want us to go through them ?08:12
ttx(the mediums)08:12
johnthetubaguymaybe pick some examples08:12
johnthetubaguyactually, not sure its worth it08:13
johnthetubaguysome have −2s with fix up this patch first, etc08:13
ttxhmm yeah08:13
johnthetubaguythey can go08:13
ttxwondering if https://blueprints.launchpad.net/nova/+spec/per-aggregate-disk-allocation-ratio is not completed08:14
johnthetubaguysome just have, sorry on holiday will fix this next week notices on them, but the boat has kinda sailed now08:14
johnthetubaguyoops, yeah, I merged that, so if its through the gate now, we should be good08:14
johnthetubaguyyep, done, thanks08:14
johnthetubaguythere some API ones that most people seem to have avoided reviewing, but will see how they are looking this morning08:16
ttxyeah, no other obvious candidate08:16
johnthetubaguyanyways, I think I know what we have to do I guess, just been putting off the mass −2 stuff08:16
ttxso yeah, we should probably communicate that anything that's not in-flight by tomorrow morning will be deferred08:17
ttxmaybe I should just send that overall08:17
johnthetubaguyoh, that would be cool08:17
ttxLike, it's Juno feature day08:17
johnthetubaguy+ stuff looking blocked at this point, will probably get deferred today, I guess08:17
johnthetubaguyat least it will feel consistently painful, if that makes sense08:18
ttxOK, I think we'll use the meeting today to go through the list again08:18
ttxso I won't ask for topics08:18
johnthetubaguyah, thats a good plan08:18
johnthetubaguyabout summit stuff, when is that due to open up?08:19
ttxjohnthetubaguy: anything else?08:19
ttxWe still need to decide how we want to handle that part08:19
johnthetubaguyjust saying, because we are thinking of requiring specs for feature like submitions08:19
ttxI feel like it's a bit unproductive to open a general CFP08:19
ttxI think teams working on etherpads can do a better job at it08:20
johnthetubaguyyeah, I guess we need to make that feel as open, and give people feedback somehow08:20
ttxbut first I need to check if the space allows for the setup I proposed08:20
johnthetubaguybut maybe thats just a meeting08:20
ttxI should know about that today08:20
johnthetubaguyah, cool08:20
johnthetubaguyanyways, I am sure you have that all in hand, just checking timescales really08:21
ttxwell, the original plan was to open yesterday08:21
ttxbut since we're talking about format changes08:21
ttxok, will send that email now08:21
ttxtalk to you later?08:22
*** mestery has quit IRC08:22
johnthetubaguylater is fine08:22
johnthetubaguyyeah, I will trawl through the list, and see what I can do to tidy things up a bit08:22
johnthetubaguythanks for the help, as always :)08:23
*** mestery has joined #openstack-relmgr-office08:23
*** flaper87 is now known as flaper87|afk08:37
*** flaper87|afk is now known as flaper8708:50
*** mestery has quit IRC08:52
*** mestery has joined #openstack-relmgr-office08:52
*** mestery has quit IRC10:15
*** mestery has joined #openstack-relmgr-office10:15
*** mestery has quit IRC10:21
*** mestery has joined #openstack-relmgr-office10:22
*** eglynn_ has joined #openstack-relmgr-office11:16
eglynn_ttx: knock, knock ... back to our usual 1:1 slot?11:45
*** mestery has quit IRC11:46
ttx#topic Ceilometer11:46
eglynn_BTW hat-tip to gordc for keeping on top of things while I was on vacation11:46
ttx#link https://launchpad.net/ceilometer/+milestone/juno-311:46
ttxyes, he did a very good job!11:46
eglynn_LP doesn't quite capture the full status11:46
eglynn_4 of 11 BPs merged, but another 3 are approved and wending their way thru' the gate as we speak11:46
ttxwhich ones?11:46
eglynn_which leaves 4 outsanding (1 high, 2 medium, 1 low)11:46
eglynn_which ones are gating?11:47
ttxSo like I said in a recent email to -dev, ideally startig tomorrow morning we would only keep the ones that are in-flight11:47
ttxyes, which ones are gating11:47
eglynn_central-agent-partitioning, hash-based-alarm-partitioning, xenapi-support11:47
ttxbecause i expect it will take 1+ day to get approved stuff through, with the obvious retries11:47
eglynn_the high priority BP bigger-data-sql is a bit of a concern at this stage, as the review has stalled out on differing performance test results being seen11:48
eglynn_(different mysql versions etc)11:48
eglynn_I'll speak to gordc about that when he comes online (out for Labor Day yesterday)11:48
eglynn_but, fair warning, I *may* be coming cap-in-hand looking for a FFE on bigger-data-sql to allow time to get more clarity on the performance improvement11:48
eglynn_on the medium BPs ...11:49
ttxyeah, and that one isn't exactly the kind you would like to grant a Feature Freeze exception for11:49
ttxbecause it's potentially disruptive11:49
eglynn_yeah, I'll have a better view later on today on whether that might be required11:49
ttxand affects existing functionality11:49
eglynn_yeap, fair point11:49
ttxI mean, if it's just a couple extra days away, why not, but I suspect there is more11:50
eglynn_fair enough, I'll bear that in mind11:50
eglynn_on the mediums ...11:50
eglynn_grenade-resource-survivability is still waiting on review attention from jogo & sdague11:50
eglynn_(again, Labor Day yesterday not ideal)11:50
eglynn_paas-event-format-for-ceilometer is documentation-only, but review has stalled so I'm prepared to bump it off the juno slate if necessary11:50
ttxeglynn_: but I think we said that one can merge post-j311:51
ttx(grenade one)11:51
ttxmaybe we can push it to rc1 already11:51
eglynn_yeah, that's fair11:51
ttxit's only extra tests, right ?11:51
eglynn_exactly, tests only11:51
eglynn_on paas-event-format-for-ceilometer, I've mailed Phil though to given him fair warning and an opportunity to close it out11:51
ttxok, moving to RC111:51
eglynn_on the low priority BP still outstanding ...11:52
eglynn_ipmi-support has patches up, but not yet in a landeable state11:52
eglynn_... I'm not massively concerned about it missing tho, as it's just an alternative way of generating the same IPMI sensor data that Ironic already notifies us about11:52
ttxok, shall be deferred tomorrow if it doesn't get approved today?11:53
eglynn_yeah if not in flight by EoD, definitely a candidate for bumping11:53
eglynn_on the j3 targetted bugs, I've bumped the higher priority bugs to RC1 that didn't look like they were going to make it11:53
eglynn_cdent just did a trawl thru all the outstanding reviews for the lower-priority j3-targetted bugs11:54
ttxok, we'll just bump to RC1 anything not fixcommitted by tag11:54
eglynn_cool, that's reasonable11:54
ttxOK, you seem in good shape11:56
eglynn_so what time on Thurs are you aiming to pull the trigger on the juno-3 tag?11:56
ttx6 left, 3 in flight, 2 which might get bumped, 1 that you could ask FFE for11:56
ttxWhen all the features in the pipe land11:56
eglynn_yep, that sums it up11:56
eglynn_cool enough11:56
ttxideally sometimes during the day :)11:57
ttxbut highly dependent on gate load11:57
eglynn_BTW cdent tells me he just got a +2 from Sean on the grenade patch11:57
ttxshall we bump to rc1 the doc-only one ?11:57
eglynn_so we may be able to re-instate that to juno-3, as I think jogo is pretty much on board with the approach11:57
eglynn_yeap, let's do that re. the paas-event-format11:58
ttxif it makes it we'll retroactively readd it to j311:58
ttxbut in the meantime we should bump all the non-featury stuff11:58
eglynn_cool paas-event-format-for-ceilometer bumped to rc111:58
ttx#info In flight: central-agent-partitioning, hash-based-alarm-partitioning, xenapi-support11:59
ttx#info Shall get bumped if not approved today: ipmi-support11:59
ttx#info Might get FFE-d if not approved today: bigger-data-sql12:00
ttxWe'll update that picture at the meeting tonight12:00
ttxeglynn_: thx!:12:00
ttxSergeyLukjanov: around?12:01
eglynn_#info may be reinstated if approved today: grenade-resource-survivability12:01
SergeyLukjanovttx, yup12:01
ttx#topic Sahara12:01
SergeyLukjanov#link https://launchpad.net/sahara/+milestone/juno-312:01
ttxSergeyLukjanov: is that current ? Not a lot of progress since last week12:02
SergeyLukjanovhm, looks like it's a bit outdated12:02
ttxSergeyLukjanov: could you update it now? We can discuss it afterwards12:02
SergeyLukjanovwe're moving two huge blueprints to K and adding one very small, already implemented12:03
SergeyLukjanovit's required for backward compat support between older versions12:03
SergeyLukjanovI'll update the lp page right now12:03
ttxSergeyLukjanov: let me know when you're done12:05
*** mestery has joined #openstack-relmgr-office12:06
SergeyLukjanovttx, good news - we've implemented integration w/ ceilometer (sending notifications), all user faced strings are now wrapped for translation using i18n and all sahara objects could be created using heat resources (it's in the gate now)12:07
SergeyLukjanovttx, am I right that it's ok to work on docs, tests and critical bug fixes after the j3?12:09
ttxYou can actually push back doc-only and test-only blueprints to RC1 already12:09
ttxthat would add clarity12:09
SergeyLukjanovttx, ok12:11
*** mestery_ has joined #openstack-relmgr-office12:12
ttxSergeyLukjanov: are you done with the J3 status update?12:13
*** mestery has quit IRC12:13
SergeyLukjanovttx, mostly yes12:14
ttxSergeyLukjanov: which, if any of those, is currently gating?12:15
SergeyLukjanovthere are two bps - https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust-authentication that is re-invented way for working with swwift data sources, it fix critical security issue re storing credentials12:15
ttxthat one is gating ?  ^12:16
SergeyLukjanovand https://blueprints.launchpad.net/sahara/+spec/cluster-persist-sahara-configuration that is needed for backward compat, both could be moved to rc1 due to their "bugfix" nature12:16
SergeyLukjanovoh, sorry, it's not about gating12:16
ttxoh ok12:16
SergeyLukjanovno changes in gate right now12:17
ttxSergeyLukjanov: we would probably have to grant a FFE for the first one, but i wouldn't consider it a bugfix12:17
SergeyLukjanovwe have a small rebase bomb exploaded12:17
ttxsince you need new feature code to plug the hole12:17
ttxand probably for the second one too12:17
ttxbut those would still be exceptions12:18
SergeyLukjanovttx, yup, I meen that I'd like to ask for the FFE for this two bps because of their importance and "bugfix" *nature*12:18
ttx#info edp-swift-trust-authentication & cluster-persist-sahara-configuration still in progress, will probably require FFEs12:18
SergeyLukjanovfor the second one code is ready and not approved only because of labor day in US :)12:18
SergeyLukjanovand spec isn't approved officially too (it was discussed on the last IRC meeting and we've agreed that we need it)12:19
ttxcluster-persist-sahara-configuration is not j312:19
ttxshould it be added there ?12:19
SergeyLukjanovttx, yup, but spec isn't approved12:19
ttxadd it with "Blocked" status12:20
SergeyLukjanovttx, ok, thx12:20
SergeyLukjanovttx, done12:20
ttxif we know we'll require it, I prefer it tracked/Blocked12:20
ttxOf the 4 "needs code review", should they all just get deferred if they are not approved today?12:21
SergeyLukjanovttx, I think so12:21
ttx#info cluster-secgroups, swift-url-proto-cleanup-deprecations, ceilometer-integration, anti-affinity-via-server-groups to be edferred if they don't get required approvals today12:22
ttxSergeyLukjanov: OK, I think that's all12:23
SergeyLukjanovok, thx12:23
ttxSergeyLukjanov: thx!12:23
ttxdhellmann: around?12:23
dhellmannttx: here12:23
ttx#topic Oslo12:23
dhellmannthe new project group looks good; we probably should have done this a while back12:24
ttxdhellmann: so the only unintended sideeffect of the oslo projectgroup transition so far seems to be the BP link hack in gerrit12:24
dhellmannyeah, is that something we can fix in gerrit, or should we link to our blueprints differently?12:24
ttxit's a bit tricky12:24
ttxthe BP name is unique in a LP project namespace, not unique in general12:25
ttxso when you say "blueprint foo-bar", gerrit rseolves that to a search for blueprints names foo-bar in the openstack projectgroup namespace12:25
ttxLike https://blueprints.launchpad.net/openstack/?searchtext=ceilometer-integration12:26
ttxwhich was a suboptimal hack already12:26
dhellmannI would be ok if we had to say "blueprint oslo/foo-bar" and gerrit found that oslo prefix12:26
ttxwe could fix that by making the link smarter12:27
ttxlike if no project is specified, search in the smae project as the basename of the repo12:27
ttxso if a review for openstack/nova contains "blueprint foo-bar" you would look for nova/foo-bar12:28
dhellmannthat would still make it possible for us to link to blueprints across projects, which is something we do when we submit changes to infra and the requirements project to add a new lib12:28
ttxand if a review for openstack-infra/config contains blueprint oslo.rootwrap/moo then you would look for oslo.rootwrap/moo12:28
dhellmannthat seems like a good solution to me12:29
ttxI fear that the linkification code is pretty basic though12:29
ttxmight be a basic pattern subst IIRC12:29
ttxso not sure you can feed it the repo name12:29
dhellmannprobably, but we should be able to specify 2 patterns, I would think12:30
dhellmannif the bp name includes / do one thing, otherwise do what we're doing now12:30
dhellmannah, true12:30
ttxoh, default to openstack namespace search12:30
ttxthat would work, I guess12:30
dhellmannthat way all of the old links work the same way12:30
ttxi should build an oslo library release script to handle Lp duties automatically12:31
dhellmannthat would be great to have12:31
ttxone question: in every oslo lib, would you track only released versions ? or alphas as milestones as well?12:31
ttxi.e. for olso.rootwrap, would we have a1, a2 milestones ?12:32
ttxI think it would make sense for intra-cycle planning12:32
ttxBUt then I need to think twice about the meaning of fixReleased12:32
ttxWe could track alphas, and then do consolidation like we do for the openstack integrated release12:32
dhellmannI created juno-3 and juno-rc1 milestones for all of them so far, but now that you mention it I think we agreed to just use "next" and rename them with a version number when we do the release12:32
ttxso.. finals only ? No way of knowing that a fix/feature is available in an alpha?12:33
dhellmannoh, no, I mean I would run something like "release_oslo_lib.sh oslo.rootwrap" and it would rename "next" to that version number12:33
dhellmannand fix up all of the commited bugs, etc.12:34
ttxah I see12:34
ttxwould you consolidate all alphas into a single final release page ?12:34
dhellmannwe don't necessarily know in advance if the next release is an alpha or the final, since we might only cut one alpha during a cycle for example12:35
ttxi.e. when you do the final "release" you would move all alphas bugs and features to the final12:35
*** mestery has joined #openstack-relmgr-office12:35
dhellmannoh, hmm12:35
*** mestery_ has quit IRC12:35
dhellmannI don't know if we would want that or not12:35
ttxthe way it's done in the integrated release is..12:35
ttxyou have -rcX12:35
ttxthen you add a 2014.2 milestone12:35
ttxmove over all juno-X and juno-rcX bugs/features to it12:36
ttxand mark that released12:36
dhellmannok, I guess that makes sense then12:36
ttxthat way during dev you know when something is available12:36
ttxbut after dev you shall forget the alphas12:36
dhellmannwe still have release notes to see when a fix actually went in, but if consolidating at the end of the cycle is the pattern used for the apps that's good12:36
ttxyes, git history still tracks what landed when if you really need to know12:37
ttxOK, so I might need to do two scripts, one for the "next" and one for the "final"12:37
ttxis the final aligned on the last alpha ? i.e. the same commit ends up tagged twice ?12:38
ttxrelease-candidate style ?12:38
dhellmannI would expect that to be the case, yes12:38
ttxok, so one alpha-release script and one "promote-alpha" one12:38
dhellmannwe do have some libs with versions < 1.0 that aren't alphas per-se, and I guess we would treat those the same way12:38
dhellmannwe didn't use alpha tags for some technical reason having to do with the mirror syncing12:39
ttxyeah, it wouldn't be sensitive to the actual version number used anyway12:39
ttxOK, sounds like a plan12:39
ttx#link https://launchpad.net/oslo/+milestone/juno-312:39
dhellmannnow, if that script could send email to the -dev list, that would save me an extra step, too :-)12:39
ttxwe can work on that :)12:40
ttxNow I suspect a few of those should now move to their specific projects12:40
ttxhttps://blueprints.launchpad.net/oslo-incubator/+spec/rootwrap-daemon-mode -> oslo.rootwrap12:40
ttxwill do that asap12:40
dhellmannyeah, I asked the library owners to clean up the bugs already via the ML12:41
dhellmannI don't remember if I asked for the bps too12:41
ttxfirst time I see this cross-project-sharing-same-milestone view. It's not bad12:41
ttxalmost makes me want the libs to use the common milestones :)12:41
dhellmannhmm, the shared view is going to be harder if we use "next" instead of "juno-3"12:41
ttx#link https://launchpad.net/oslo-incubator/+milestone/juno-312:42
ttxLet's look at that one instead  ^12:42
ttxSemantic version support for pbr -> pbr probably12:42
ttxMy question is... what on this list is still oslo-incubator work taht would be subject to FF12:43
dhellmannI put it in the incubator because of the specs2bp script, I think12:43
ttxthe "graduate" stuff we already know is not affected12:43
ttxshall we move all the "graduate" ones to rc1 ?12:43
dhellmannyes, that's fair at this point12:44
ttx(if it makes it this week you can retroactively target it here)12:44
ttxok, I'm on it12:44
dhellmannI think the concurrency and serialization ones are almost done, but we might as well move all of them12:44
* dhellmann thinks about ff12:44
* ttx craetes "next" milestones for rootwrap and pbr so that we can move stuff there12:45
dhellmannall of this work is actually happening in a library outside of the incubator12:45
ttxactually calling the milestone next-juno12:47
dhellmannnot juno-next like the numbered ones?12:47
dhellmannI guess it doesn't matter12:48
ttxno, there already is a next-juno for.. swift iirc12:48
ttxOK, reload https://launchpad.net/oslo-incubator/+milestone/juno-312:48
ttxIs that all oslo-incubator work ?12:48
dhellmannthe mysql one goes in oslo.db12:48
ttxAdoption of pylock file could move to RC1 too12:48
dhellmannthe 2 owned by josh harlow go in taskflow12:49
dhellmannyes, we can move the adoption one to rc112:49
dhellmannthe policy configuration directories is an incubator change12:49
ttxnot sure I can update the taskflow stuff12:49
ttxalso weird series there12:49
ttxoh, I can12:50
dhellmannyeah, josh has been using semver numbering. I need to get him to give me access there so I can update it12:50
ttxLooks liek we get power from the projectgroup12:50
dhellmannah, ok12:50
ttxOK: https://launchpad.net/oslo-incubator/+milestone/juno-312:51
ttxand https://launchpad.net/oslo/+milestone/next-juno12:52
*** eglynn_ has quit IRC12:52
ttxoh, the mysql one12:52
dhellmannsec, brb12:53
dhellmannsorry, hungry cats don't understand "you need to wait a minute"12:54
ttxThat leaves policy-configuration-directories12:54
dhellmannthe policy stuff is in the incubator, so that's the right place for that one12:54
dhellmannshould we move any of the closed items, or is that just going to end up being confusing?12:55
ttxShall it get bumped to kilo if it fails to get reviewed/apprved today ?12:55
* dhellmann looks at that changeset12:55
ttxWe should move the closed items yes12:55
ttxuse-events-for-error-wrapping should be in oslo.db?12:55
ttxok, moving12:56
ttxNow, that's simpler12:56
dhellmannI moved the config bug12:57
dhellmannand the db bug12:58
ttxok, good cleanup12:58
ttxone question this creates is...12:58
ttxshouldn't the libs also be feature frozen and get their final alphas soon ?12:58
dhellmannyes, probably so12:59
dhellmannanything that's already been released once this cycle, at least12:59
ttxMaybe we can address that next week12:59
dhellmannI have a couple of releases to do, I was going to put those off to monday to avoid issues this week12:59
ttxbut you should issue a fair warning to lib people12:59
dhellmannyeah, I'll do that this morning13:00
ttxwe cna have feature-"final" alphas13:00
ttxwe shall have*13:00
ttxeven if we can still work on bugfixes in the coming week(s)13:00
ttxwe shoudl also probably target a date for final releases13:00
ttxideally before RC1s13:01
dhellmannI was thinking sept 1813:01
ttxso that we can have the requirements all set13:01
ttxSept 18 would work13:01
ttxoslo.rootwrap is all set13:02
ttx(final feature alpha already out)13:02
ttxdhellmann: ok, I think that's all I wanted to discuss13:02
ttxmore later!13:02
dhellmannok, tty this afternoon13:03
*** flaper87 is now known as flaper87|afk13:06
dhellmannttx, still around?13:15
ttxdhellmann: yes13:16
dhellmannttx: I forgot to ask about cutting stable/juno for the incubator early13:16
ttxwhen do you want to cut it ?13:16
dhellmannwell, I had wanted to do it today but bnemec's comments on the ML thread made me reconsider -- did you see his reply?13:17
ttxI figured this could wait for a bit mre discussion13:18
dhellmannttx: I'm having second thoughts about consolidating the alpha milestones at the end of a cycle. If someone wants to see what was released in a version, can't they just look at the page for the whole series?13:24
ttxdhellmann: It's tricky. there is no single page for bugs in series for example13:28
ttxI mean bugs fixed in series13:28
ttxOnly milsetone pages show the list of bugfixes and implemented features13:28
*** eglynn_ has joined #openstack-relmgr-office13:29
ttxjgriffith: i'm available if you are14:02
dolphmttx: i also wouldn't mind going early; need to be on the road soonish14:02
ttxdolphm: ddeal14:04
ttx#topic Keystone14:04
ttx#link https://launchpad.net/keystone/+milestone/juno-314:04
ttx2 left14:04
dolphmthat's going to be our next 48 hours ^14:05
dolphmoverview of pending changes: https://gist.github.com/dolph/651c6a1748f69637abd014:05
dolphmwe landed the biggest patch for k2k last night, which was blocking the rest... and the rest are much simpler14:06
ttxdolphm: ok. The trick is you need to allow time for gate processing14:06
dolphmyeah :(14:06
ttxso ideally that would be all approved today :)14:06
dolphmthat is my goal!14:06
dolphmand i think it's achievable14:06
dolphmthe last patch for v3 api validation is basically a nice to have add-on. the rest of that bp is done14:06
ttxi suspect we would ask for FFE on the k2k stuff if it misses14:07
ttxWhat about the other ?14:07
dolphmfor k2k, i would14:07
dolphmfor v3 api validation, i'd just mark it as Implemented and file a wishlist bug for the remaining patch and move it to Kilo14:07
ttx#info keystone-to-keystone-federation still pending some reviews, would require FFE if it misses14:08
ttx#info api-validation still pending some reviews, would defer to kilo the remaining items if it misses14:08
ttxI'll just defer all bugs that don't make it to RC1, too14:09
ttxI don't see any milestone-critical stuff there14:09
dolphmi also haven't triaged bugs in a week, so there might be some surprises in there. i'll review the new stuff as soon as we're gating the last change for k2k14:10
ttxOK, I think that is all. You can run!14:10
dolphmthank you :)14:10
ttxmestery: you can go early if you want14:21
mesteryttx: o/14:21
ttx#tpoic Neutron14:21
mesteryYou caught me just after I got back from walking kids to school (first day here today)14:22
ttx#topic Neutron14:22
*** david-lyle has joined #openstack-relmgr-office14:22
ttxfirst day today too14:22
mesteryHey, congrats on the new role ttx! Well deserved. :)14:22
ttxmestery: thanks!14:22
ttx#link https://launchpad.net/neutron/+milestone/juno-314:22
ttx19 implemented, +9 since last week14:23
mesteryYes, we should land a few more today yet, some are close14:23
ttxSo the trick is, we need to allow for gate time14:23
mesteryAnd the 3 big ones we're tracking (L3 HA, ipset, and security group refactor) are fairly close as well, looking like ipset may need an FFE, but the other 2 look good14:23
mesteryack on gate time14:24
ttxso ideally we'd get them approved today and wait until they navigate the gate tomorrow, in time for tagging Thursday14:24
ttxA bit concerned with all those "High" still up14:24
ttxsince it sounds like a recipe for a lot of exceptions14:24
mesteryThe majority of those are all going to the incubator14:24
mesterySo I've left them in Juno-3 for now but we will move them once the incubator is up14:25
ttxah, hm.14:25
mesteryGroup Policy and LBaaS stuff14:25
ttxhow could we... get them off the list somehow14:25
mesteryCreate a new milestone for the incubator perhjaps?14:25
ttxcreating a launchpad project is a bit early14:25
mesteryWould thatm ake sense?14:25
ttxyeah, i was thinking that would work14:25
ttxI can create a "incubator" target14:25
mesteryOnce you do, I'll move stuff out of J314:26
ttxand then we can move all the work that will escape FF there14:26
ttxok, let's do that now14:26
* mestery waits for it so he can migrate stuff in real time14:26
mesteryOK, I'll move things after we're done talking so I can focus here ;)14:27
ttxhmm, actually it's hard to discuss unless I see what's left after the cleanup14:27
mesteryOK doing it now ;)14:27
ttxawesome :)14:27
*** mestery_ has joined #openstack-relmgr-office14:31
mestery_Sorry, connectivity issue there for a moment, but I am back now.14:32
mestery_So, the list should be clean now of LBaaS and GBP BPs14:32
mestery_The two testing BPs (https://blueprints.launchpad.net/neutron/+spec/retargetable-functional-testing and https://blueprints.launchpad.net/neutron/+spec/remove-unit-test-autodeletion) won't make Thursday and will need FFEs if we want them14:32
mestery_The owners already pinged me on those, I'll move htem out for now as well.14:32
*** mestery has quit IRC14:33
mestery_ttx: How does it look now?14:34
ttxare they testing-only ?14:34
ttxi.e. they only touch tests/ code ?14:34
mestery_Yes, but the owner didn't want to use scarce infra resources this week, so an FFE would make al ot of sense14:35
ttxin which case they don't need FFE14:35
mestery_Ah, ok, cool! Thanks!14:35
ttxIt's fine to merge extra tests or doc14:35
ttxuntil RC114:35
*** mestery_ is now known as mestery14:35
ttxso you can move them to RC1 already14:35
mesteryOK, thanks!14:35
ttxyou should move them to RC1 actually14:35
ttxthat will make the list more limited14:35
mesteryIt looks better now, I can likely clear a few more ones out today after talking to owners14:36
ttxIs there anything all-approved and in-flight already ? Or are those all waiting on extra reviews ?14:36
mesteryMost of these have multiple patches, some approved and some in flight, and some waiting on approval14:36
mesterySo, all over the board I guess :(14:37
ttxwhat about neutron-dvr-fwaas and ml2-hierarchical-port-binding ?14:37
ttxThe other two "High" you said were in good shape14:38
mesterydvr-fwaas is ready for review, we'll need an FFE for it to make FWaaS work with DVR14:38
mesteryml2-hiearchichal-port-binding is also out, but I don't think that one qualifies for an FFE if it won't make it14:38
mesteryml2-hiearchical can likely wait for kilo if it won't make it, I'll talk to rkukura to verify that14:39
ttxShould ml2-hiearchichal-port-binding be meidum and security-group-rules-for-devices-rpc-call-refactor be high ?14:39
ttxTry to keep the ones you would ask FFE for as "High"14:39
mesteryI think so, yes.14:39
* mestery updates that now14:39
ttxso.. ideally if it's not fully approved and in-flight tomorrow morning, we shoudl defer it14:40
ttxat least for the medium/low ones14:41
ttxOK, we'll talk again at the meeting and tomorrow morning14:41
ttx#info 33 blueprints still under review14:42
ttx#info Only the 4 Highs are likely to trigger FFEs14:42
ttx#info planning to defer what is not fully approved and in-flight tomorrow morning14:42
ttxmestery: thx!14:42
mesteryttx: Thank you too! Talk to you tomorrow.14:42
ttxdavid-lyle: ready when you are14:42
david-lylettx: ready14:43
ttx#topic Horizon14:43
ttx#info 20 implemented, +11 since last week14:43
ttx#info 18 blueprints left open14:43
ttxdavid-lyle: so the general idea would be to defer what is unlikely to be fully approved today14:44
ttxdavid-lyle: and tomorrow we defer anythign that is not fully approved and in-fliught in the gate14:44
ttxso that we have time for retries at the gate before the tag on Thursday14:44
david-lylettx: sounds good, we have a couple of potential FFEs that may not make Thurs14:45
ttxSo that means working on final approvals today14:45
ttxdavid-lyle: which ones for potential FFEs ?14:45
david-lylethe FFEs are mostly delayed due to other service dependencies14:45
david-lyleIPv6 support14:45
ttxthat's a good reason for them14:45
ttxmaybe we can mark them "High" priority to show that we'll likely FFE them14:46
david-lyleand there are a few around the new glance meta-data functionality14:46
ttx#info Likely FFEs for IPv6 support and a few around the new glance meta-data functionality14:47
david-lyleI'll bump them then14:47
ttxAre you OK in general for deferring stuff that won't be fully-approved and in gate hell tomorrow ?14:47
david-lyleyeah, I'll have a better idea after the Horizon meeting in an hour14:48
david-lylethen I'll start deferring bps14:48
ttxOK, we'll be in touch again at the meeting, and tomorrow14:48
david-lyleI think 3-4 should still land without FFE14:48
david-lylesound good14:49
ttxdavid-lyle: ok, thx!14:49
david-lylettx: thanks14:50
ttxjgriffith: you can fit in 10 minutes now if you hurry up14:50
*** markmcclain has joined #openstack-relmgr-office15:15
*** markmcclain has quit IRC15:16
*** markmcclain has joined #openstack-relmgr-office15:18
ttxstevebaker: ready when you are15:42
*** SlickNik has joined #openstack-relmgr-office15:49
ttxSlickNik: ready when you are16:04
SlickNikttx: here now16:04
ttx#topic Trove16:04
ttx#link https://launchpad.net/trove/+milestone/juno-316:04
ttxStill 4 to go16:04
ttxAre any of those already approved and in-flight ?16:05
SlickNik2 of them have 1 +2, and are looking for another.16:05
SlickNikANother one is really close to done, and I think I'm going to have to defer one of them.16:05
ttxSo, tomorrow we'll just defer anything that is not in-flight16:06
ttxthat leaves today for the last push16:06
SlickNikttx: sounds good — I've already communicated that to the rest of the team.16:07
SlickNikI'll make sure to keep the status updated as thing are on the move.16:07
ttxAnything you'd request FFE for if it can't get the requires approvals in time ?16:07
SlickNikWe have one FFE that will probably come in after.16:08
SlickNikMove to oslo.messaging.16:08
ttxhmm, ok. we'll discuss that then :)16:08
ttxthat's all I had. Will be talking to you again tomorrow16:08
SlickNikOkay sounds good. Will keep working on getting the BPs reviewed and closed out.16:09
*** morganfainberg_Z is now known as morganfainberg16:11
*** mestery_ has joined #openstack-relmgr-office16:16
ttxOK, will be back at 18:30 UTC16:19
ttxstevebaker: maybe we cna talk then16:19
*** mestery has quit IRC16:19
*** mestery has joined #openstack-relmgr-office16:26
*** mestery_ has quit IRC16:30
*** eglynn_ has quit IRC17:29
*** markwash__ has joined #openstack-relmgr-office17:49
*** mikal_ is now known as mikal17:50
markwash__ttx: ping17:52
*** johnthetubaguy is now known as zz_johnthetubagu18:26
ttxmarkwash__: pong?18:36
markwash__pong, indeed18:36
ttxmarkwash__: ready for a glance status update?18:36
markwash__ttx as ready as I'll ever be :-)18:36
ttx#topic Glance18:36
ttx#link https://launchpad.net/glance/+milestone/juno-318:37
ttxIs that current?18:37
markwash__ttx I think there was some movement this past weekend I'm not certain about18:38
markwash__I know the metadata definitions catalog has moved along nicely18:38
markwash__it is probably "Implemented" at this point18:38
markwash__async processing and "restrict users" are accurate tmk18:38
ttxmarkwash__: https://review.openstack.org/#/c/111483/ may still be needed for metadata def catalog18:39
markwash__ah yes18:40
markwash__but the prereqs have merged18:40
ttxmarkwash__: today is like the last day to approve features, starting tomorrow we'll cut what's not in flight and it will require FFE if you want it in Juno18:40
ttxso it migth be worth a few extra reviews to get them past the last hurdle18:41
ttxAnything you're likely to ask a FFE for ?18:41
markwash__Actually, depending on the status, I will ask for an FFE for all of those save GPFS18:41
ttxOK, i'll bump restrict to Medium then18:42
markwash__yeah that issue was in good shape except we hit some snags pulling in changes from oslo-incubator policy18:42
markwash__had to cherry-pick oslo-incubator (effectively) to bring things to a workable state for juno18:43
ttxWe'll do another status update tomorrow, and defer what won't land in time then18:43
markwash__ttx: what time do you want?18:43
ttxand we'll discuss FFEs after J3 on Friday18:43
ttxmarkwash__: same as today?18:43
markwash__should work18:43
ttxI'll try to be around18:43
ttx#info FFEs likely for everything but GPFS18:44
ttxmarkwash__: thanks for coming!18:44
markwash__ttx: sorry I was late. . I got confused by the long weekend18:44
ttxthat happens :)18:46
*** flaper87|afk is now known as flaper8718:49
ttxstevebaker: around?19:18
ttxbah, I guess we'll sync during the release meeting then19:19
openstackMeeting ended Tue Sep  2 19:20:00 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:20
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-09-02-08.00.html19:20
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-09-02-08.00.txt19:20
openstackLog:            http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-09-02-08.00.log.html19:20
*** markwash__ has quit IRC19:22
*** markwash__ has joined #openstack-relmgr-office19:27
*** morganfainberg is now known as needs19:57
*** needs is now known as needscoffee19:57
stevebakerttx: \o19:59
ttxstevebaker: starting TC meeting, talk to you during release meeting in one hour ?19:59
stevebakerttx: ok19:59
*** dhellman_ has joined #openstack-relmgr-office20:39
*** mestery has quit IRC20:53
*** mestery has joined #openstack-relmgr-office20:55
*** needscoffee is now known as morganfainberg20:56
*** flaper87 is now known as flaper87|afk21:09
*** morganfainberg is now known as steve_notmorgan21:32
*** steve_notmorgan is now known as morganfainberg21:32
*** dhellman_ has quit IRC21:54
*** markwash__ has quit IRC22:33
*** markwash__ has joined #openstack-relmgr-office22:35
*** david-lyle has quit IRC23:02
*** markwash__ has quit IRC23:08
*** markwash__ has joined #openstack-relmgr-office23:10
*** markmcclain has quit IRC23:37

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!