08:02:36 <ttx> #startmeeting ptl_sync
08:02:37 <openstack> Meeting started Tue Apr 21 08:02:36 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:39 <ttx> #topic Heat
08:02:40 <openstack> The meeting name has been set to 'ptl_sync'
08:02:44 <ttx> asalkeld: hi!
08:02:48 <asalkeld> hi
08:03:15 <ttx> so... RC2
08:03:17 <asalkeld> so we have a heap of https://bugs.launchpad.net/heat/+bugs?field.tag=kilo-rc-potential
08:03:23 <asalkeld> in fix commited
08:03:38 <ttx> and a few proposed for backport already
08:04:01 <asalkeld> yeah
08:04:03 <ttx> Let's open a RC2 and see which bugs should be added to it
08:04:09 <asalkeld> ok
08:04:32 <ttx> At this stage we'll only accept bugs that are already fixed in master
08:04:42 <asalkeld> makes sense
08:04:51 <asalkeld> what is the timeline?
08:04:55 <ttx> https://launchpad.net/heat/+milestone/kilo-rc2
08:05:08 <ttx> The idea would be to close it Thursday at the latest
08:05:26 <ttx> depending on how the library requirements mess untangles
08:05:32 <asalkeld> ok, so we need to proprose these quickly
08:05:34 <ttx> So let's see your list
08:05:55 <ttx> https://bugs.launchpad.net/heat/+bugs?field.tag=kilo-rc-potential&orderby=-status&start=0
08:06:20 <asalkeld> there are 11
08:06:33 <ttx> (I see 9)
08:06:44 <asalkeld> yeah, 2 in incomplete
08:06:58 <ttx> https://bugs.launchpad.net/heat/+bug/1437158
08:06:58 <openstack> Launchpad bug 1437158 in heat "Module novaclient.v1_1 is deprecated" [Medium,Fix committed] - Assigned to Michal Rostecki (mrostecki)
08:07:42 <ttx> wondering if that's the best moment to change that
08:08:09 <asalkeld> so the patch tries v2 else falls back to v1
08:08:21 <asalkeld> the client copied v1 to v2
08:08:31 <asalkeld> (from what i saw)
08:08:37 <ttx> hmm
08:09:05 <ttx> asalkeld: if you think it's totally safe, I guess we can get it in. It's just not really a bug, more of a leftover feature
08:09:13 <asalkeld> https://github.com/openstack/python-novaclient/commit/0a60aae852d2688861d0b4ba097a1a00529f0611
08:09:16 <ttx> and RC2 is a very late stage to add that
08:09:27 <asalkeld> Rename v1_1 to v2
08:09:45 <asalkeld> and add deprecation messages all over the place
08:09:52 <ttx> ok
08:10:00 <ttx> sounds like a useful prerelease cleanup
08:10:03 <asalkeld> i think it's ok
08:10:16 <ttx> adding
08:10:22 <ttx> https://bugs.launchpad.net/heat/+bug/1438978
08:10:22 <openstack> Launchpad bug 1438978 in heat "The internal create_stack interface misses 'parent' parameter" [High,Fix committed] - Assigned to Angus Salkeld (asalkeld)
08:10:56 <asalkeld> yip, that's important
08:11:39 <asalkeld> so ttx do i set the milestone to rc2 ?
08:11:45 <asalkeld> as it's in master already
08:11:52 <ttx> I'm doing it (you have to create the kilo task so it's a bit weird
08:12:05 <ttx> That one sounds like a large patch too
08:12:17 <ttx> safe?
08:12:24 <asalkeld> yeah, better in than out
08:12:32 <ttx> ok
08:12:55 <asalkeld> regression from a blueprint we did
08:13:05 <ttx> https://bugs.launchpad.net/heat/+bug/1439497
08:13:05 <openstack> Launchpad bug 1439497 in heat "No Ip assigned to server after update" [High,Fix committed] - Assigned to huangtianhua (huangtianhua)
08:13:26 <ttx> looks safe
08:14:51 <asalkeld> yip
08:14:53 <ttx> https://bugs.launchpad.net/heat/+bug/1439708
08:14:53 <asalkeld> wow git.openstack.org is slow
08:14:53 <openstack> Launchpad bug 1439708 in heat "stack update fail when server has a port" [High,Fix committed] - Assigned to Ethan Lynn (ethanlynn)
08:15:13 <ttx> Also better fixed pre-release
08:15:24 <asalkeld> yeah that's good
08:15:42 <ttx> https://bugs.launchpad.net/heat/+bug/1439959
08:15:42 <openstack> Launchpad bug 1439959 in heat "heat db field nullable is True by default" [Wishlist,Fix committed] - Assigned to Kanagaraj Manickam (kanagaraj-manickam)
08:16:14 <asalkeld> that's a cleanup
08:16:28 <ttx> That one sounds like it could bear some risk
08:16:35 <asalkeld> shouldn't actually effect anything
08:16:42 <ttx> oh, that's the default ?
08:16:45 <ttx> ok then
08:17:04 <ttx> https://bugs.launchpad.net/heat/+bug/1443252
08:17:04 <openstack> Launchpad bug 1443252 in heat "sql migration failed on db2" [Medium,Fix committed] - Assigned to Ethan Lynn (ethanlynn)
08:17:28 <asalkeld> that's is fine, only effects db2
08:17:29 <ttx> that one is safe since it's DB2-cased
08:17:52 <ttx> https://bugs.launchpad.net/heat/+bug/1444087
08:17:52 <openstack> Launchpad bug 1444087 in heat "SoftwareDeployments don't work for non-CREATE actions" [High,Fix committed] - Assigned to Steven Hardy (shardy)
08:18:24 <ttx> sounds useful
08:18:39 <asalkeld> yeah
08:18:50 <asalkeld> only effects on resource
08:18:53 <ttx> https://bugs.launchpad.net/heat/+bug/1445170
08:18:53 <openstack> Launchpad bug 1445170 in heat "get_file doesn't notice changes during update" [High,Fix committed] - Assigned to Zane Bitter (zaneb)
08:19:33 <ttx> looks good to go too
08:19:47 <asalkeld> yeah, fine
08:19:53 <ttx> https://bugs.launchpad.net/heat/+bug/1415887
08:19:53 <openstack> Launchpad bug 1415887 in heat "ValueError: AES key must be either 16, 24, or 32 bytes long" [Medium,Fix committed] - Assigned to rajiv (rajiv-kumar)
08:20:44 <ttx> arh, string update there
08:20:45 <asalkeld> that's just a startup error on wrong config
08:21:37 <ttx> I'd rather leave that one out
08:21:39 <asalkeld> do you want to hold it?
08:21:40 <asalkeld> ok
08:21:44 <asalkeld> not a big deal
08:22:14 <ttx> You said you had two incomplete ones that you would like to investigate and potentially include ?
08:22:45 <asalkeld> ttx: they don't look bad
08:22:51 <asalkeld> we can backport later if needed
08:22:59 <ttx> OK, let's revisit them just before we cut the RC2, in case they are fixed then
08:23:16 <ttx> Otherwise let's go with the list @ https://launchpad.net/heat/+milestone/kilo-rc2
08:23:37 <asalkeld> ok, looks good
08:24:08 <ttx> Two of them are already proposed (I set them to InProgress)
08:24:09 <asalkeld> i'll work on backporting
08:24:15 <ttx> That leaves 6 to backport
08:24:18 <asalkeld> ok
08:24:20 <ttx> I'll validate them once they are in
08:24:27 <asalkeld> thanks!
08:24:35 <ttx> Thanks!
08:25:32 <ttx> johnthetubaguy: o/
08:25:51 <johnthetubaguy> ttx: hi
08:25:55 <ttx> #topic Nova
08:26:04 <ttx> OK, so let's open RC2 and see what we can put in
08:26:36 <johnthetubaguy> cool
08:26:50 <johnthetubaguy> do we just target to the milestone at this point?
08:27:18 <ttx> hmm, we also need to cvreate the kilo task I think
08:27:42 <ttx> https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=kilo-rc-potential&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&fiel
08:27:42 <ttx> d.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
08:27:45 <ttx> err
08:28:18 <ttx> https://bugs.launchpad.net/nova/+bugs?orderby=-importance&field.status%3Alist=FIXCOMMITTED&field.tag=kilo-rc-potential
08:28:30 <ttx> Let's go down that one ^
08:28:42 <johnthetubaguy> yep
08:28:44 <ttx> I suspec tthe 3 critical ones are really critical ?
08:29:19 <johnthetubaguy> yeah, I mean they could be high, but they are all bad
08:29:35 <johnthetubaguy> the API one is critical
08:29:39 <ttx> ok, targeting them all
08:30:09 <ttx> https://bugs.launchpad.net/nova/+bug/984996
08:30:09 <openstack> Launchpad bug 984996 in OpenStack Compute (nova) "Instance directory does not exist: Unable to pre-create chardev file console.log" [High,Fix committed] - Assigned to Matt Riedemann (mriedem)
08:30:19 <ttx> an oldie
08:30:29 <ttx> it's rare that those get fix in a RC
08:30:52 <ttx> simple patch, +1 for me
08:31:19 <johnthetubaguy> yeah, +1
08:31:24 <johnthetubaguy> https://review.openstack.org/#/c/173099/
08:31:43 <ttx> https://bugs.launchpad.net/nova/+bug/1433609
08:31:43 <openstack> Launchpad bug 1433609 in OpenStack Compute (nova) "Not adding a image block device mapping causes some valid boot requests to fail" [High,Fix committed] - Assigned to jichenjc (jichenjc)
08:32:18 <ttx> sounds like a regression
08:32:40 <johnthetubaguy> +1
08:33:09 <ttx> says "then we can revert the nova client exception"... does that mean there is a companion patch ?
08:33:39 <ttx> bah novaclient
08:33:51 <johnthetubaguy> yeah, we can ignore that bit I think
08:33:58 <johnthetubaguy> looks like it adds something back into novaclient
08:34:10 <ttx> https://bugs.launchpad.net/nova/+bug/1440968
08:34:10 <openstack> Launchpad bug 1440968 in OpenStack Compute (nova) "AttributeError: 'module' object has no attribute 'DatastorePath'" [High,Fix committed] - Assigned to Sabari Murugesan (smurugesan)
08:34:31 <ttx> pretty straightforward
08:34:41 <johnthetubaguy> +1
08:35:01 <ttx> https://bugs.launchpad.net/nova/+bug/1442602
08:35:01 <openstack> Launchpad bug 1442602 in OpenStack Compute (nova) "live migration fails during destination host check" [High,Fix committed] - Assigned to Dan Smith (danms)
08:35:36 <johnthetubaguy> +1 for that one too really
08:35:39 <johnthetubaguy> small fix
08:35:41 <ttx> legit
08:36:04 <ttx> https://bugs.launchpad.net/nova/+bug/1444021
08:36:04 <openstack> Launchpad bug 1444021 in OpenStack Compute (nova) "HostState.consume_from_instance fails when instance has numa topology" [High,Fix committed] - Assigned to Przemyslaw Czesnowicz (pczesno)
08:37:02 <ttx> Feels a bit more specialized, but probably isolated enough
08:37:37 <johnthetubaguy> yeah, its a possible
08:37:46 <ttx> let's add it
08:38:08 <ttx> https://bugs.launchpad.net/nova/+bug/1444300
08:38:08 <openstack> Launchpad bug 1444300 in OpenStack Compute (nova) "nova-compute service doesn't restart if resize operation fails" [High,Fix committed] - Assigned to Rajesh Tailor (rajesh-tailor)
08:38:43 <johnthetubaguy> +1 for that, its a simple fix really
08:38:50 <ttx> ack
08:39:14 <ttx> https://bugs.launchpad.net/nova/+bug/1444728
08:39:14 <openstack> Launchpad bug 1444728 in OpenStack Compute (nova) "KeyError: 'uuid' trace in n-cpu logs when logging with instance=instance kwarg" [High,Fix committed] - Assigned to Matt Riedemann (mriedem)
08:39:53 <ttx> +1 fropm me
08:40:00 <johnthetubaguy> +1
08:40:41 <ttx> https://bugs.launchpad.net/nova/+bug/1445040
08:40:41 <openstack> Launchpad bug 1445040 in OpenStack Compute (nova) "InstancePCIRequests.obj_from_db fails to get requests from db" [High,Fix committed] - Assigned to Przemyslaw Czesnowicz (pczesno)
08:41:23 <ttx> sounds simple enough
08:41:46 <ttx> added
08:42:00 <ttx> https://bugs.launchpad.net/nova/+bug/1438238
08:42:00 <openstack> Launchpad bug 1438238 in OpenStack Compute (nova) "Several concurent scheduling requests for CPU pinning may fail due to racy host_state handling" [Medium,Fix committed] - Assigned to Nikola Đipanov (ndipanov)
08:42:39 <ttx> since we accepted the other part...
08:42:45 <johnthetubaguy> yeah
08:43:02 <johnthetubaguy> it seems sound
08:43:11 <ttx> ok
08:43:33 <ttx> https://bugs.launchpad.net/nova/+bug/1441169
08:43:33 <openstack> Launchpad bug 1441169 in OpenStack Compute (nova) "can't schedule vm with numa topology and pci device" [Medium,Fix committed] - Assigned to Przemyslaw Czesnowicz (pczesno)
08:44:02 <ttx> hrm
08:44:35 <johnthetubaguy> yeah, bumps a version number for an object
08:44:41 <ttx> right
08:44:53 <ttx> "one of the BPs completed in Kilo is completely broken without the patch"
08:45:08 <ttx> not sure about the impact of bumping a microversion so late
08:45:08 <johnthetubaguy> its a now or never, so I guess we should add it?
08:45:13 <ttx> yeah
08:45:28 <ttx> I feel like it's disruptive, but otherwise won't be in kilo at all
08:45:34 <johnthetubaguy> yeah
08:45:38 <ttx> +1
08:45:47 <ttx> Let's cut it soon enough to detect breakage though
08:46:05 <ttx> https://bugs.launchpad.net/nova/+bug/1340068
08:46:05 <openstack> Launchpad bug 1340068 in OpenStack Compute (nova) "Useless option mute_weight_value" [Low,Fix committed] - Assigned to Davanum Srinivas (DIMS) (dims-v)
08:46:31 <johnthetubaguy> ttx: thats a good point
08:46:43 <ttx> hmm, string change here
08:47:18 <ttx> also a change in defaults
08:47:39 <johnthetubaguy> yeah, I think this has missed the boat, only really got merged as liberty was open
08:47:46 <johnthetubaguy> I need to go back an update the message, sadly
08:48:05 <ttx> yeah
08:48:16 <ttx> deprecated in 2015.2
08:48:21 <ttx> I'd leave that one out at this point
08:48:32 <johnthetubaguy> +1 for leaving that, mostly due to the string
08:48:42 <johnthetubaguy> its not worth all the hoops we need for that
08:48:42 <ttx> ok removing tag
08:49:19 <ttx> ok, that gives: https://launchpad.net/nova/+milestone/kilo-rc2
08:49:29 <ttx> checking the match with the currently-proposed backports
08:51:27 <ttx> johnthetubaguy: we have a backport for https://bugs.launchpad.net/nova/+bug/1444630 proposed too
08:51:27 <openstack> Launchpad bug 1444630 in OpenStack Compute (nova) "nova-compute should stop handling virt lifecycle events when it's shutting down" [Medium,Fix committed] - Assigned to Matt Riedemann (mriedem)
08:51:48 <ttx> and for https://bugs.launchpad.net/nova/+bug/1429093
08:51:49 <openstack> Launchpad bug 1429093 in OpenStack Compute (nova) "nova allows to boot images with virtual size > root_gb specified in flavor " [Medium,Fix committed] - Assigned to Roman Podoliaka (rpodolyaka)
08:52:04 <johnthetubaguy> ah, its marked as a backport potential
08:53:25 <ttx> what is your call on it ?
08:53:30 <ttx> (1444630)
08:54:28 <johnthetubaguy> so I looked at this in the wrong order
08:54:42 <johnthetubaguy> 1429093 is almost a security thing
08:55:34 <ttx> yeah, that one sounds like a worthy thing
08:55:49 <ttx> adding
08:56:24 <ttx> what about https://bugs.launchpad.net/nova/+bug/1444630
08:56:24 <openstack> Launchpad bug 1444630 in OpenStack Compute (nova) "nova-compute should stop handling virt lifecycle events when it's shutting down" [Medium,Fix committed] - Assigned to Matt Riedemann (mriedem)
08:56:34 <ttx> sounds also pretty safe
08:56:59 <johnthetubaguy> yeah, I think thats a nice small fix
08:57:19 <ttx> added
08:57:25 <ttx> last one
08:57:31 <ttx> https://review.openstack.org/#/c/174066/
08:57:36 <ttx> no bug reference
08:58:10 <ttx> https://bugs.launchpad.net/nova/+bug/1445675
08:58:10 <openstack> Launchpad bug 1445675 in OpenStack Compute (nova) "missing index on virtual_interfaces can cause long queries that can cause timeouts in launching instances" [Undecided,In progress] - Assigned to Mike Bayer (zzzeek)
08:58:13 <ttx> that would be this one
08:58:32 <ttx> not in master yet
08:58:44 <ttx> I'll -2 it as not being in master yet
08:58:53 <johnthetubaguy> yep
08:59:28 <ttx> OK, final list at https://launchpad.net/nova/+milestone/kilo-rc2
08:59:33 <ttx> We'll need 4 extra backports
08:59:41 <ttx> I'll approve soon
09:00:01 <ttx> johnthetubaguy: I think that is all -- ttyl
09:00:29 <johnthetubaguy> ttx: OK, thanks, do we want to look at the ones that are not yet committed that might block releasing RC2?
09:00:51 <johnthetubaguy> actually, I am not sure there are any now
09:00:54 <ttx> johnthetubaguy: do you have any ?
09:01:03 <ttx> Let's reconsider when we are close to cutting RC2
09:01:04 <johnthetubaguy> there was one, but I just downgraded it
09:01:11 <ttx> i.e. tomorrow/Thursday
09:01:18 <johnthetubaguy> ttx: I was just going to ask, cool
09:01:25 <johnthetubaguy> ttx: need those backports first I guess
09:01:57 <johnthetubaguy> ttx: thanks, thats everything now I think
09:02:35 <ttx> arh, looks like I shouldn't have created those kilo tasks and just reuse the release thing
09:02:39 <ttx> willfix
09:02:56 <ttx> damn Lp
09:04:38 <johnthetubaguy> ttx: ah, why is that?
09:04:51 <ttx> long story
09:04:57 <johnthetubaguy> no worries
09:05:08 <johnthetubaguy> so we are just doing targeting to milestones for this?
09:05:21 <ttx> in previous releases we'd rely on FixCommitted = fixed in master / FixReleased = fixed in milestone
09:05:32 <johnthetubaguy> ah, that rings a bell
09:05:32 <ttx> rather than use series tasks
09:05:43 <johnthetubaguy> avoids the slow LP query bugs I guess
09:05:57 <ttx> but that was relying on the Gerrit/LP updater specialcasing proposed/*
09:06:10 <ttx> (and turning bugs there to FixReleased on merge)
09:06:20 <ttx> Now that we use stable/kilo things are borken
09:06:28 <ttx> I need to fix that
09:06:54 <ttx> two options: use kilo tasks (and have them closed at RC delivery time)
09:07:07 <ttx> or...
09:07:24 <ttx> somehow make the Gerrit/LP updated understand what it needs to do
09:07:33 <ttx> without the help of the branch name
09:07:38 <johnthetubaguy> ah, gotcha
09:07:50 <johnthetubaguy> nasty
09:07:51 <ttx> might actually be simpler to use kilo tasks
09:08:08 <johnthetubaguy> it seems clear at least
09:08:40 <ttx> hmm, will think a bit more about it
09:09:39 <ttx> in the meantime lets us spot which backports are missing, which is a plus
09:15:28 <johnthetubaguy> +1
10:03:48 <johnthetubaguy> ttx: we have backports ready for those other bugs now: https://launchpad.net/nova/+milestone/kilo-rc2
10:09:44 <ttx> ack, will approve soon
10:10:08 <ttx> no hurry, we'll need requirements bumps in and those are not solved yet
10:10:22 <ttx> just approved the backlog so that we don't build a huge one
10:52:42 <sdague> ttx: so... hmm... I think I just found another cross cutting critical openstack bug related to oslo :(
10:52:59 <sdague> stable/kilo services can not reliably shutdown
10:53:26 <sdague> the oslo.service code seems to be losing children
10:54:01 <sdague> this is incubator code, so if this is really the bug, we're going to need to respin everyone
11:08:25 <ttx> sdague: well, better now than next week
11:08:53 <ttx> but we'll need a solution soon so that we can include it in the RC2s we are opening right now
11:09:18 <sdague> yeh, well we'll need oslo folks to go active around this, I just brought it up in channel
11:10:07 <sdague> the exposure is we can't add stable/kilo -> liberty testing in our infrastructure, because the grenade jobs fail too often trying to shutdown processes - https://review.openstack.org/#/c/175391/
11:10:19 <sdague> so the d-g change keeps getting blocked
11:10:33 <sdague> how do you want to track something like this?
11:11:22 <ttx> hmm, ideally a bug with a task in every consuming servcie
11:11:29 <ttx> praying that LP will behave
11:12:11 <ttx> For the time being, you can create a bug that would at least include keystone, heat and nova, since that is the current RC2 windows we have
11:12:18 <ttx> I suspect swift is not affected ?
11:13:02 <sdague> so, I've seen keystone and cinder choke on it
11:24:08 <ttx> SergeyLukjanov: we can talk now so that we get more time to discuss RC2
11:27:48 <sdague> ttx: https://bugs.launchpad.net/oslo-incubator/+bug/1446583
11:27:48 <openstack> Launchpad bug 1446583 in oslo-incubator "services no long reliably stop in stable/kilo" [Critical,New]
11:28:23 <ttx> thx. As soon as it's confirmed and we have some clue into how to fix it, I'll create RC2 tasks for it
11:33:11 <sdague> dims was the approver on a lot of that code, so I'm hoping he'll have ideas
11:33:20 <sdague> but, he's not around atm?
11:42:50 <sdague> ok, I added keystone and cinder to the bug
11:42:59 <sdague> and put in everything I could about what I'm seeing
11:51:00 <SergeyLukjanov> ttx, hi, sorry, I've been on a lunch
11:51:11 <SergeyLukjanov> ttx, I'm ready if you are
11:51:22 <ttx> ok, let's do this
11:51:27 <ttx> #topic Sahara
11:51:56 <SergeyLukjanov> we have no critical issues found for rc2
11:52:03 <ttx> I see nothing fixcommitted in kilo-rc-potezntial
11:52:32 <ttx> Someone proposed https://review.openstack.org/#/c/175026/
11:52:41 <SergeyLukjanov> the only potential thing - fix a few links in docs (will be useful for users, but it's mostly nice to have)
11:53:28 <ttx> SergeyLukjanov: we'll certainly do a RC2 to catch up requirements / translations
11:53:29 <SergeyLukjanov> ttx, yup, I think we can do it after release - it's a bunch of testing scenario files
11:53:46 <ttx> so we could include "nice to have" clearly safe stuff
11:54:09 <SergeyLukjanov> okay, that's great, I'll make a patch soon
11:54:16 <ttx> but if nothing urgent and RC1 still lookg good for testing, we should keep it around for a few days
11:54:32 <ttx> Let's plan to do a RC2 at the end of the week
11:54:40 <ttx> to catch up the last stuff
11:55:01 <SergeyLukjanov> okay
11:55:13 <ttx> https://review.openstack.org/#/c/175026/
11:55:17 <ttx> About this one ^
11:55:28 <ttx> If we do a RC2 anyway, would you include it ?
11:55:35 <SergeyLukjanov> so, I think then we'll have in addition to requirements - https://review.openstack.org/#/c/175026/ , small change in docs
11:55:39 <ttx> If yes, could you have a bug for it and tag it kilo-rc-potential ?
11:55:46 <SergeyLukjanov> yup, it'll enable useful
11:55:48 <SergeyLukjanov> will do
11:55:49 <ttx> same for the change in docs
11:55:52 <SergeyLukjanov> sure
11:55:54 <ttx> so that it's on the RC2 radar
11:56:12 <ttx> OK, and let's plan to talk again, say, Thursday
11:56:22 <SergeyLukjanov> ttx, ack, thx
11:56:35 <ttx> About the Design Summit layout for Sahara, did you have time to look into it ?
11:56:36 <SergeyLukjanov> ttx, I think that we'll be ready to tag rc2 at Thu
11:56:56 <ttx> just toi check it's not completely crazy
11:57:27 <ttx> https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing
11:58:32 <ttx> A few work sessions on Wed, then most sessions Thursday afternoon
11:58:35 <SergeyLukjanov> ttx, yup, we discussed the number of slots (2-5-2) with team on irc meeting and we think that it's okay
11:58:44 <SergeyLukjanov> ttx, re layout it seems ok I think
11:58:53 <ttx> ok. It's too hard to change anyway :)
11:59:08 <SergeyLukjanov> heat and infra at the same time looks a bit sad for me, but I understand
11:59:43 <ttx> Yeah, tried to reduce that conflict, at least fishbowls don't collide
12:00:21 <SergeyLukjanov> ttx, yeah
12:00:30 <SergeyLukjanov> ttx, so, IMO it looks very nice
12:01:05 <SergeyLukjanov> ttx, I like this fragmentation, I think it'll increase a chance for cross project communication
12:01:13 <ttx> well, we'll see
12:01:17 <ttx> SergeyLukjanov: ttyl!
12:01:22 <ttx> eglynn: o/
12:01:25 <eglynn> hey
12:01:27 <ttx> #topic Ceilometer
12:01:30 <SergeyLukjanov> ttx, thx
12:02:04 <eglynn> still nada in https://bugs.launchpad.net/ceilometer/+bugs?field.tag=kilo-rc-potential
12:02:10 <ttx> eglynn: I see no bug in the kilo-rc-potential list
12:02:16 <eglynn> so I think we're looking realtively good
12:02:27 <eglynn> IIRC 5 fixes have landed on liberty so far
12:02:28 <ttx> there was a proposed backport though
12:02:34 <eglynn> none higher than medium
12:02:36 <ttx> actually two
12:02:43 <ttx> https://review.openstack.org/#/c/174049/
12:02:56 <ttx> bug 1446201
12:02:56 <openstack> bug 1446201 in Ceilometer "gnocchi alarm: url endpoint for validating query is wrong" [Medium,In progress] https://launchpad.net/bugs/1446201 - Assigned to Mehdi Abaakouk (sileht)
12:03:00 <ttx> and...
12:03:04 <ttx> https://review.openstack.org/#/c/175807/
12:03:11 <ttx> bug 1445227
12:03:11 <openstack> bug 1445227 in Ceilometer "hbase should not use message_signature as unique id" [Medium,Fix committed] https://launchpad.net/bugs/1445227 - Assigned to ZhiQiang Fan (aji-zqfan)
12:03:41 <eglynn> both medium bugs
12:03:51 <ttx> eglynn: we'll certainly do a RC2 anyway to catch requirements/translations
12:04:04 <ttx> At this point we can still keep RC1 around a couple more days
12:04:14 <eglynn> generally rc2 would only be for critical issues, amiright?
12:04:29 <ttx> well, we trigger a respin only for critical issues
12:04:44 <ttx> but once the respin is decided, we can look for obviously-safe backports
12:05:03 <eglynn> a-ha, so you're saying that we could pull in those two medium bugs since we're doing an RC2 anyway for other reasons
12:05:05 <eglynn> got it
12:05:15 <ttx> since we'll respin to include the synced requirements anyway, we can look into things that would make sense to backport in the same run, low-risk
12:05:35 <eglynn> so in that case, both relatively sane ... I'll review in detail and get them landed
12:05:40 <ttx> that said, your RC1 looks good enough to be testable for a few more days
12:05:48 <ttx> so no hurry there
12:05:54 <eglynn> cool
12:06:04 <ttx> I propose we discuss again on Thursday and see what to include in the respin
12:06:21 <eglynn> sounds good
12:06:29 <eglynn> (I'm on PTO tmrw BTW)
12:06:42 <ttx> eglynn: ack
12:06:54 <ttx> The other topic I wanted to discuss is python-ceilometerclient
12:07:13 <ttx> I noted you may want to do a stable/kilo re-release
12:07:31 <ttx> is that needed to fix a specific bug ?
12:07:43 <ttx> If not, maybe a liberty featureful release is the best way forward
12:08:08 <ttx> oh, that was done already (1.1.0)
12:08:19 <ttx> so the question is more, do we need a 1.0.14
12:08:42 <eglynn> gordc has been working on a bunch of backports, I need to check with him when he comes online which of those he wanted to include (i.e. are all landed yet)
12:09:02 <ttx> I understand that means "yes" ?
12:09:17 <eglynn> yes to 1.0.14, not sure on the exact timing
12:09:20 <ttx> but no need to bump the min version there
12:09:38 <ttx> we can't do any release just now anyway
12:09:46 <ttx> we need to fix stuff[tm] first
12:09:55 <eglynn> sure
12:10:13 <eglynn> min version == z-version in SEMVER terminology?
12:10:19 <ttx> eglynn: could you check if there would be an
12:10:23 <ttx> arh
12:10:42 <ttx> any reason to bump the min version in stable/kilo requirements (to >=1.0.14 <1.1.0)
12:11:08 <eglynn> a-ha, that min version, the lower version bound
12:11:19 <ttx> yep
12:11:34 <ttx> the best answer would be "no"
12:11:34 <eglynn> ok, will do, I've a call with gordc in ~90 mins, can discuss then
12:11:46 <ttx> since otherwiuse that triggers requirements updatexws
12:11:54 <ttx> updates*
12:11:56 <eglynn> yeap, got it
12:11:58 <ttx> to other projects
12:12:22 <ttx> I think that is all...
12:12:37 <eglynn> cool, thanks for your time
12:12:40 <ttx> Asl gordc to look into the DS ceilometer track layout
12:12:46 <ttx> Ask*
12:12:59 <eglynn> cool, will do ... where is that published?
12:13:11 <ttx> https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing
12:13:15 <eglynn> cool
12:13:21 <ttx> (sent an email to list about it last wek)
12:13:23 <ttx> +e
12:14:01 <ttx> would be good to know if you still want that extra fishbowl slot, because it conflicts with one of your workroom slot
12:14:15 <ttx> so I'll need to shuffle schedule if you want it
12:14:23 <eglynn> slightly fragmented track
12:14:41 <eglynn> but I guess non-contiguous is probably the norm now
12:14:45 <ttx> They are all fragmented, yes
12:14:51 <eglynn> i.e. with all the additional projects in the mix
12:14:54 <eglynn> yeap
12:14:55 <ttx> Ceilo is actually not that fragmented
12:15:11 <eglynn> yeap, I've seen worse in past summits :)
12:15:19 <ttx> The goal is also to avoid block overlaps
12:15:32 <ttx> like "all cinder sessions collide with all ceilometer sessions, no way to be together"
12:15:43 <eglynn> yeap, makes sense
12:15:56 <ttx> for a fragmented track, look at keystone :)
12:16:25 <ttx> ok, will talk to you again on Thursday
12:16:26 <eglynn> yeah, true that
12:16:33 <eglynn> ... and as always Nova just conflicts with everything else :)
12:16:39 <eglynn> coolness, talk to you then
12:17:46 <ttx> dhellmann: ready when you are
12:17:50 <dhellmann> ttx: o/
12:17:55 <ttx> dhellmann: you are back!
12:18:01 <ttx> Lots of stuff to discuss.
12:18:19 <dhellmann> yes! sorry for the ill-timed disappearance
12:18:21 <ttx> #topic Oslo
12:18:34 <ttx> No problem, I think we made great progress over the weekend and on Monday
12:18:42 <ttx> enough to open RC2 windows now
12:18:54 <ttx> The idea being stable/kilo is in pretty good shape right now
12:19:02 <dhellmann> cool - I started scanning the-big-thaw but might need a walk-through of the current status
12:19:12 <ttx> the fuckup is more around mastre requirements and libraries
12:19:16 <ttx> so..
12:19:22 <ttx> let me walk through it
12:19:50 <ttx> We got all the .gitreview pushed to libs, except ezaqarclient which is borken on all branches
12:20:16 <ttx> We got all the uncap-requirements in master merged
12:20:29 <dhellmann> I saw flavio's note about zaqar, so maybe we're not worried about fixing that for now?
12:20:34 <ttx> except swiftclient (which doesn't sync anyway) and zaqarclient (borken as mentioned above)
12:20:48 <ttx> right, I propose we ignore zaqarclient, not imported anywhere anyway
12:20:53 <dhellmann> ++
12:20:57 <flaper87> ++
12:21:01 <flaper87> I'm working on that, though.
12:21:09 <ttx> So we are at the "release libraries with updated requirements (no caps)"
12:21:12 <flaper87> I need to figure out the right way to enable pooling in the gate
12:21:28 <ttx> basically we need to make liberty releases for all libs with uncapped reqs
12:21:35 <dhellmann> flaper87: ok, we can address the problem when the status of the project is decided, but make it low priority for now
12:21:41 <ttx> before we reenable the tests and syncs
12:21:49 <dhellmann> ttx: ok, I can work on that today, assuming I have the required powers
12:22:00 <ttx> On the stable/kilo side, I fixed all branches and got the .gitreview merged in all projects
12:22:17 <ttx> so we opened RC2 windows for some projects alreadyt
12:22:23 <dhellmann> nice! there were a few jobs to disable, did that happen, too?
12:22:26 <ttx> We still block on stable/kilo library point release
12:22:31 <ttx> dhellmann: yes
12:22:41 <dhellmann> what's blocking the library point releases? process or gate jobs?
12:22:50 <ttx> so we can't really "close" the windows we opened until we can mertge the final requirements bumps
12:23:08 <ttx> we need the "release libraries with updated requirements" step to be completed first
12:23:13 <ttx> otherwise we bvreak the world
12:23:27 <ttx> basically master MUST find the liberty uncapped lib
12:23:40 <ttx> not our stable/kilo point release woth capped reqs
12:23:45 <dhellmann> ah, got it
12:24:03 <ttx> so yeah, relkeasing those liberty libs is pretty time-sensitive, and I'd welcome your help in solving that
12:24:08 <ttx> You can do oslo first
12:24:19 <dhellmann> yeah, I can do that this morning right after breakfast
12:24:30 * dhellmann needs at least one cup of tea before cutting releases
12:24:40 <dhellmann> I can go ahead and do all of them, if you'd like
12:24:45 <ttx> So that is one thing. The other exciting topics are issues in oslo libs /incub
12:25:11 <ttx> we have oslo.messaging needing a stable/kilo point release for https://bugs.launchpad.net/oslo.messaging/+bug/1436769
12:25:11 <openstack> Launchpad bug 1436769 in oslo.messaging "ConnectionError: Too many heartbeats missed" [Critical,Confirmed] - Assigned to Mehdi Abaakouk (sileht)
12:25:43 <ttx> We have sdague's recent oslo.service issue at https://bugs.launchpad.net/oslo-incubator/+bug/1446583
12:25:43 <openstack> Launchpad bug 1446583 in oslo-incubator "services no long reliably stop in stable/kilo" [Critical,New]
12:26:09 <ttx> the latter needing urgent attention since we'll have to copypaste the code back to every project in RC2
12:26:14 <ttx> (if genuine)
12:26:49 <ttx> Last topic would be.. when/where to cut stable/kilo for the incubator
12:27:01 <ttx> we decided last time to do it when every RC1 is cut
12:27:18 <ttx> but we may want to do that once we solve 1446583
12:27:27 <dhellmann> yes, that would be more convenient
12:27:42 <ttx> dhellmann: I think that is all.
12:27:46 <ttx> :)
12:27:57 <dhellmann> so the oslo.messaging release will be taken care of once we have the requirements issues in master resolved and all of those libraries are released
12:28:07 <ttx> Most of those items are somewhere in the etherpad, fwiw
12:28:12 <dhellmann> I need to find someone to look at that bug, though
12:28:28 <dhellmann> ok, good, I'll re-read now that I have the context for highlights
12:28:42 <ttx> yeah, oslo.messaging doesn't need work, it's just blocked on the master requirements unwind at this point
12:28:50 <ttx> like everything else
12:28:51 <dhellmann> right
12:29:13 <ttx> I'll be busy with RC2 tracking today, so I'd rather have you own the liberty lib release thing entirely
12:29:24 <dhellmann> ok, I'll do all of the releases
12:29:40 <ttx> My underatsngin is that we need to release everything (even those which already have liberty releases) to catch the uncapped reqss
12:29:53 <dhellmann> ttx: is the list of libs starting on line 148 of the etherpad complete?
12:29:56 <dhellmann> yes, that's what I would expect
12:30:14 <ttx> dhellmann: It correspon,ds to the uncap-requirements merges
12:30:30 <ttx> I noticed it excludes glnce_store
12:30:36 <dhellmann> for each I need to verify that the requirements.txt in the lib is currently not showing caps and then cut a new minor release
12:30:48 <ttx> but then that one seems to not have caught the caps in the first place
12:30:48 <dhellmann> ok, I'll add that to the bottom
12:30:58 <ttx> same for ceilometermiddleware
12:31:28 <dhellmann> noted
12:31:56 <dhellmann> if they don't have caps in their current release, I think we can skip releasing new copies
12:32:48 <ttx> Ideally we would go through most of step 9 (from the etherpad) today, so that we can do stable/kilo lib releases starting tomorrow
12:33:01 <ttx> and so that we could announce depfreeze end on master too
12:33:09 <dhellmann> agreed
12:33:34 <dhellmann> I do have some other spec work I had hoped to do today, but I can put that off until tomorrow
12:33:42 <ttx> I'll be around if you need sanity checking for anything
12:34:04 <dhellmann> ok. I'll start by making a complete list of the planned releases and their version #s
12:35:33 <ttx> yep, and find someone to look into that oslo.service thing
12:35:36 <dhellmann> ttx: I probably don't have rights to create milestones in LP for a lot of these projects, so I'll just skip that step
12:35:39 <dhellmann> yep
12:35:58 <ttx> I think I created most of the milestones there
12:36:51 <ttx> I can go through them once you have numbers
13:04:39 <mestery> ttx: I am here anytime between now and the top of the hour if you're here, have to run the Neutron meeting at 1400UTC and that will consume me for an hour.
13:05:20 <ttx> mestery: I'd rather talk to you now, since RC2 discussion usually goes beyond the allocated 10min
13:05:37 <ttx> #topic Neutron
13:05:38 <mestery> That was my thinking as well
13:05:42 <mestery> Thanks for being flexible!
13:06:03 <ttx> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=kilo-rc-potential
13:06:13 <ttx> There seems to be enough matter in there to justify a RC2 window now
13:06:22 <mestery> ++
13:06:31 <ttx> Also I hapopen to have merged somethign in neutron-fwaas to unblock that branch already
13:06:39 <mestery> :)
13:06:46 <ttx> so let me open the milestone and we'll target stuff to it
13:06:53 <mestery> Ack
13:08:13 <ttx> We don't really have a bug for https://review.openstack.org/#/c/175137/
13:08:24 <ttx> (the one I merged to unblock fwaas)
13:08:38 * mestery looks
13:08:39 <mestery> Ah
13:08:40 <mestery> OK
13:08:42 <mestery> Shall I file one?
13:09:01 <ttx> would be good to have one so that people who want to know the bug diff between RC1 and RC2 can see it
13:09:11 <mestery> Ack opening one now
13:09:12 <ttx> We'll mark it fixed directly
13:09:31 <ttx> In the mean time I'll add the 3 criticals to RC2
13:10:12 <mestery> ack
13:10:53 <mestery> ttx: Bug for the review noted above: https://bugs.launchpad.net/neutron/+bug/1446642
13:10:53 <openstack> Launchpad bug 1446642 in neutron "Updated Protocol named constants" [Low,Fix committed] - Assigned to Romil Gupta (romilg)
13:11:26 <mestery> ttx: Handy gerrit query for our potential backports: https://review.openstack.org/#/q/branch:stable/kilo+status:open+(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas),n,z
13:12:03 <ttx> let's look at the kilo-rc-potential list first, we'll match it with backports after
13:12:09 <mestery> Ack
13:12:20 <ttx> https://bugs.launchpad.net/neutron/+bug/1438040
13:12:20 <openstack> Launchpad bug 1438040 in neutron "fdb entries can't be removed when a VM is migrated" [High,Fix committed] - Assigned to Kyle Mestery (mestery)
13:12:44 <ttx> This one links to a fix that closes 3 bugs
13:12:54 <mestery> Yes, it's an efficient fix :)
13:13:35 <ttx> looks simple enough and worthy
13:13:40 <mestery> Yes
13:13:48 <ttx> I'll target the corresponding three bugs
13:13:56 <mestery> Thank you!
13:14:54 <ttx> https://bugs.launchpad.net/neutron/+bug/1442043
13:14:54 <openstack> Launchpad bug 1442043 in neutron "Brocade Vyatta Firewall feature impacted by L3 agent refactor" [High,Fix committed] - Assigned to vishwanath jayaraman (vishwanathj)
13:15:32 <mestery> This one fixes the Brocade Vyatta driver for FWaaS
13:15:39 <mestery> It's low risk and should be in RC2
13:15:44 <ttx> ack
13:16:23 <ttx> https://bugs.launchpad.net/neutron/+bug/1443798
13:16:23 <openstack> Launchpad bug 1443798 in neutron "Restrict netmask of CIDR to avoid DHCP resync" [High,In progress] - Assigned to watanabe.isao (watanabe.isao)
13:16:36 <mestery> I'm actually sad this one didn't merge yet
13:16:50 <mestery> But it hasn't passed Jenkins and still has a -1 on it.
13:17:10 <ttx> ok, let's keep it on list and see where it is when we close the window
13:17:25 <mestery> Yes! The issue with that one is if we don't fix it, we may need to issue a security alert
13:17:31 <mestery> I'll highlight this one in the neutron meeting
13:17:34 <ttx> last 3 fixcommitted would be:
13:17:41 <ttx> https://bugs.launchpad.net/neutron/+bug/1439857
13:17:42 <openstack> Launchpad bug 1439857 in neutron kilo "live-migration failure leave the port to BUILD state" [Medium,New]
13:17:54 <ttx> already targeted
13:18:10 <ttx> https://bugs.launchpad.net/neutron/+bug/1442494
13:18:10 <openstack> Launchpad bug 1442494 in neutron "test_add_list_remove_router_on_l3_agent race-y for dvr" [Medium,Fix committed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
13:18:38 <mestery> 1439857 needs to go in for sure
13:18:46 <mestery> Same with 1442494
13:18:50 <ttx> ack
13:19:20 <ttx> https://bugs.launchpad.net/neutron/+bug/1442615
13:19:20 <openstack> Launchpad bug 1442615 in neutron "don't ship ml2_conf_odl.ini" [Medium,Fix committed] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
13:19:35 <ttx> good pre-release fix as well
13:19:35 <mestery> 1442615 is pretty simple and will make packager's lives easier
13:19:38 <mestery> Yes
13:20:07 <ttx> ok, now let's match those with stuff already proposed
13:20:34 <ttx> running through your query
13:20:38 <ttx> top to bottom
13:21:05 <ttx> err
13:21:24 <ttx> Not a big fan of open issues like https://bugs.launchpad.net/neutron/+bug/1445412
13:21:24 <openstack> Launchpad bug 1445412 in neutron "performance of plugin_rpc.get_routers is bad" [High,In progress] - Assigned to Kevin Benton (kevinbenton)
13:21:38 <ttx> those tend to never be completed
13:21:40 <mestery> I'm not sure why that one is cherry-picked back
13:21:45 <mestery> And I agree
13:21:46 <ttx> which odes not work well with the release process
13:22:28 <ttx> It's one side-effect of naming the branch stable/kilo. People thinnk stable rules apply.
13:22:32 <mestery> Shall we -2 that for now until we open stable/kilo?
13:22:33 <mestery> Yes
13:22:34 <mestery> :)
13:22:35 <ttx> fungi: ^ see
13:22:38 <ttx> yes
13:23:04 <ttx> https://review.openstack.org/#/c/175588/
13:23:10 <ttx> looks same
13:23:17 <mestery> -2
13:23:29 <mestery> The next two are global requirements
13:23:38 <ttx> skipping those for the moment
13:23:39 <fungi> ttx: what am i looking at? the stable backports to kilo discussion or something else?
13:23:58 <ttx> fungi: me complaining about the predicted side effects of naming stuff stable/kilo
13:24:14 <mestery> Ack
13:24:14 * ttx ranting told you so
13:24:34 <mestery> ttx: This one can go in
13:24:39 <mestery> https://review.openstack.org/#/c/175385/
13:25:07 <ttx> yep
13:25:19 <ttx> skipping translations
13:25:29 <ttx> https://review.openstack.org/#/c/174608/
13:25:32 <fungi> ttx: speaking of, did bswartz get up with you about approving changes for stable/kilo in manila?
13:25:32 <mestery> ttx: I added a +2, are you just going to merge this post our meeting?
13:25:33 <ttx> No bug there
13:25:39 <ttx> fungi: not yet
13:25:51 <ttx> mestery: I'll approve a bunch yes
13:25:56 <mestery> For 174608, I'll file a bug now
13:25:58 <fungi> he was confused that release management was taking over manila's release project since it's not part of the integrated release
13:26:15 <fungi> er, taking over manila's release
13:26:32 <ttx> fungi: right, also unclear if stable branch team will take it as well
13:26:53 <fungi> i didn't know why you had me add it to the list of projects to do branch restrictions on, so told him to check with you
13:27:06 <mestery> ttx: https://bugs.launchpad.net/neutron/+bug/1446657
13:27:06 <openstack> Launchpad bug 1446657 in neutron "Add Kilo release milestone" [Medium,In progress] - Assigned to Henry Gessau (gessau)
13:27:30 <ttx> mestery: so I guess this is necessary as well
13:27:37 <mestery> ttx: ack, we do this for each release
13:27:51 <ttx> we'll have to add the other -aas
13:28:08 <ttx> is it somethign that needs to land in master as well ?
13:28:09 <mestery> ttx: I think so too, I'll poke HenryG on that in the Neutron meeting
13:28:50 <mestery> No, it's only in the stable branches
13:29:02 <ttx> hmm, looks like it did though https://review.openstack.org/#/c/174483/
13:29:20 * mestery looks
13:29:44 <mestery> I stand corrected
13:29:57 <ttx> ok, will un-2
13:30:42 <ttx> https://review.openstack.org/#/c/175029/ is fine
13:30:48 <mestery> ack
13:30:58 <ttx> https://review.openstack.org/#/c/174699/
13:31:06 <ttx> fine too
13:31:17 <mestery> Yes
13:31:49 <ttx> The other two add Kilo milestone are ok too. Could you add a comment to ref the bug number
13:31:49 <mestery> The next two are the milestone commits for vpnaas and lbaas
13:31:54 <mestery> Yes
13:32:29 <ttx> https://review.openstack.org/#/c/174071/
13:32:50 <ttx> Sounds like a good thing to have too
13:32:54 <mestery> Bleah, no bug again
13:33:03 <mestery> Shall I quickly file one and reference it again?
13:33:13 <ttx> well we could approve that one as a stable/kilo branch setup thing
13:33:19 <mestery> :)
13:33:20 <ttx> I'll approve that one first
13:33:21 <mestery> excellent
13:33:29 <ttx> if you remove your -2
13:33:32 <mestery> done
13:33:38 <ttx> same for the other two
13:34:11 <mestery> Done for all 3
13:34:46 <ttx> https://review.openstack.org/#/c/174641/
13:34:53 <ttx> targeted, so ok
13:35:14 <mestery> yup
13:35:19 <ttx> https://review.openstack.org/#/c/174373/
13:35:37 <ttx> so that one closes 3 bugs only one of which is targeted
13:36:14 <mestery> Yes, I see that. Shall I target the other two? This is something we want in RC2.
13:36:14 <ttx> I fear we might miss part of the bugfixes there, since there are related merges as well
13:36:53 <mestery> I was going on what HenryG told me on this one, in that getting this particular commit in would be great to have
13:36:56 <mestery> I can talk to him again and verify
13:37:05 <ttx> wow, this is a mess, there is a revert in there
13:37:06 <mestery> Actually
13:37:09 <mestery> Yes
13:37:35 <mestery> I think we need this one, this fixed a bunch of issues on subnet allocation which caused us gate issues recenttly
13:37:51 <mestery> https://bugs.launchpad.net/neutron/+bug/1440183
13:37:51 <openstack> Launchpad bug 1440183 in neutron kilo "DBDeadlock on subnet allocation" [Critical,New]
13:37:54 <mestery> That was the nasty gate bug
13:38:04 <ttx> we targeted this one already
13:38:09 <mestery> Yes
13:38:47 <ttx> so I'm a bit confused
13:39:10 <ttx> want to make sure we don't lose partn of the commit history that made thi spatch necessary
13:39:44 <mestery> I agree
13:40:14 <ttx> hmm, so there was one fix, which was reverted, then a new one
13:40:19 <ttx> only the new one was proposed to stable
13:40:33 <ttx> just need to make sure we don't need the first part at all
13:40:51 <mestery> The revert is in stable/kilo: 0107bdd5f03e3d0fef6be88b8b586f735f610522
13:40:54 <mestery> That's the commit hash
13:41:09 <ttx> hmm, ok, probably safe if it applies anyway
13:41:16 <mestery> Yes, it shoudl be ok
13:41:22 <mestery> I just verified the revert is in stable/kilo
13:41:28 <ttx> so this one really closes those 3 bugs for us ? I'll target them as well
13:41:41 <mestery> Yes, it does.
13:41:45 <mestery> And thanks for targeting them
13:42:29 <ttx> https://review.openstack.org/#/c/174610/
13:42:39 <ttx> same, add a comment on that bug for reference
13:43:10 <ttx> https://review.openstack.org/#/c/174057/ is targeted alright
13:43:27 <mestery> done and yes
13:43:44 <ttx> same for last one
13:44:03 <mestery> yes
13:44:38 <ttx> OK, I'll map to the ones which have fix proposed now
13:44:46 <mestery> Thanks!
13:44:47 <ttx> so we know if anything is missing
13:47:18 <ttx> mestery: we need that one in asap : https://review.openstack.org/#/c/174498/
13:47:26 <ttx> not in master so can't land in stable/kilo
13:47:46 <mestery> Good catch! Just put it in the merge queue
13:48:15 <mestery> The queue is small, hopefully it lands in it's estimated 54 minutes
13:49:35 <ttx> OK, looks like all the backports were proposed: https://launchpad.net/neutron/+milestone/kilo-rc2
13:49:46 <mestery> Yay! :0
13:50:02 <ttx> I'll push the W+1 button for them later
13:50:20 <ttx> in the mean time we can send rechecks where needed
13:50:31 <mestery> Yes
13:50:38 <mestery> I put +2s on most of those in preparation for you
13:50:46 <mestery> Is the branch still limited with who can approve there?
13:51:17 <ttx> it's limited to neutron-milestone and release managers I think
13:51:30 <ttx> until release where it will go under control of the stable maint team
13:51:32 <mestery> Excellent
13:51:34 <mestery> Yes
13:51:41 <ttx> OK, I think we are good
13:51:49 <mestery> OK, thanks for all the help here! I'm glad I pinged you early today :)
13:51:52 <ttx> Hopefully we'll be able to close eth RC2 window tomorrow or Thursday
13:51:54 <mestery> yes
13:52:02 * mestery goes off to prep for neutron meeting
13:52:03 <ttx> once we straighten out the requirements situation
13:52:06 <mestery> ++
13:52:09 <mestery> Oh one more thing
13:52:21 <mestery> I need to talk to you or dhellmann about the branchign strategy for python-neutronclient
13:52:26 <mestery> But that can wait until the RC2 stuff is done
13:52:29 <ttx> ack
13:52:32 <mestery> Just putting it on yoru radar for now
13:52:33 <mestery> cool
13:52:36 <mestery> OK, have a great day ttx!
13:52:41 <ttx> cheers
14:21:21 <ttx> nikhil_k: ohai
14:21:29 <nikhil_k> hehey
14:21:35 <ttx> #topic Glance
14:21:58 <ttx> https://bugs.launchpad.net/glance/+bugs?field.tag=kilo-rc-potential
14:22:09 <ttx> Not that many fixcommitted things in there
14:22:22 <ttx> https://bugs.launchpad.net/glance/+bug/1434578
14:22:22 <openstack> Launchpad bug 1434578 in Glance "Inefficient db call while doing a image_get with image_id." [Low,Fix committed] - Assigned to Kamil Rykowski (kamil-rykowski)
14:22:43 <nikhil_k> ttx: yes, let's not look at that
14:22:55 <nikhil_k> ttx: here's what I've for RC2 blockers https://trello.com/c/CoZ9g13d/45-kilo-rc2
14:23:15 <ttx> ok looking
14:23:31 <ttx> https://bugs.launchpad.net/glance/+bug/1445026
14:23:31 <openstack> Launchpad bug 1445026 in Glance "glance-manage db load_metadefs does not load tags correctly" [Critical,In progress] - Assigned to Pawel Koniszewski (pawel-koniszewski)
14:23:41 <ttx> that one is not fixed in master yet
14:24:14 <ttx> so you should get it merged asap if you want it under consideration for a RC2
14:24:22 <nikhil_k> yes
14:24:33 <ttx> https://review.openstack.org/#/c/173646/
14:25:02 <ttx> If we want that one, we'll need a bug for it + get it merged to master asap
14:25:17 <ttx> https://review.openstack.org/#/c/169813/
14:25:23 <ttx> needs to merge in master too
14:25:33 <nikhil_k> ok
14:25:51 <ttx> same for https://bugs.launchpad.net/glance/+bug/1436877
14:25:51 <openstack> Launchpad bug 1436877 in Glance "metadef JSON files need updating for the Kilo release" [Medium,In progress] - Assigned to Wayne (wayne-okuma)
14:26:08 <ttx> so basically, you'll need those merged in master by tomorrow so we can open a RC2 window with them in
14:26:24 <ttx> no need to backport right now, priority on getting them in master branch
14:26:26 <nikhil_k> ttx: can we sync on thursday instead?
14:26:42 <ttx> #info Glance RC2 potentials stored at https://trello.com/c/CoZ9g13d/45-kilo-rc2
14:26:44 <nikhil_k> tomorrow might be tricky because of timezone issues
14:26:47 <ttx> nikhil_k: sounds good
14:26:52 <nikhil_k> thanks
14:27:03 <ttx> note we have one already proposed
14:27:17 <nikhil_k> ttx: I have a meeting conflicting at this time on thursday so, may be an hours later then
14:27:40 <nikhil_k> ttx: proposed? what exactly?
14:27:43 <ttx> https://review.openstack.org/#/c/175442/ (partial backport for https://bugs.launchpad.net/glance/+bug/1445827)
14:27:43 <openstack> Launchpad bug 1445827 in Glance "unit test failures: Glance insist on ordereddict" [High,In progress] - Assigned to Stuart McLaren (stuart-mclaren)
14:27:47 <nikhil_k> ah ok
14:27:56 <ttx> I'll blkock it until Thursday
14:28:10 <nikhil_k> cool
14:28:45 <ttx> the other topic is the glanceclient 0.17.1 update. We should be able to push it tomorrow or thursday
14:28:50 <ttx> once the lib requirement mess is solved
14:28:57 <nikhil_k> cool
14:29:13 <ttx> we'll need that one out asap so we can bump the requirements to >=0.17.1
14:29:36 <nikhil_k> ttx: hmm, sure. Thursday again then?
14:29:43 <ttx> otherwise it won't make it to ceilometer cinder heat horizon ironic nova RC2s
14:29:53 <ttx> nikhil_k: soudns good
14:29:55 <nikhil_k> I will try to get reviews on it today/tomorrow
14:29:58 <nikhil_k> thanks
14:30:15 <ttx> will talk to you then. In the mean time, get those fixes in master
14:30:21 <nikhil_k> yup
14:30:33 <ttx> cheers!
14:31:02 <nikhil_k> Santé (hope I used that correctly)
14:31:29 <ttx> thingee: around?
14:31:39 <thingee> ttx: hi!
14:31:45 <ttx> #topic Cinder
14:31:49 <ttx> https://bugs.launchpad.net/cinder/+bugs?field.tag=kilo-rc-potential
14:32:31 <ttx> thingee: looks like we ahve enough material to do a RC2 now
14:32:50 <thingee> yeah 1446583 is new to me. I just woke up :)
14:32:57 <thingee> that critical one
14:32:58 <ttx> Let's start with reviewing kilo-rc-potential bugs, then we'll look at the proposed backports
14:33:12 <ttx> some solo-incubator code you fall victim of
14:33:25 <ttx> let's leave that one out of the equation for now
14:33:34 <ttx> https://bugs.launchpad.net/cinder/+bug/1439371
14:33:34 <openstack> Launchpad bug 1439371 in Cinder "Volume creation from image fails for UEC and Glance API version 2" [High,Fix committed] - Assigned to Jon Bernard (jbernard)
14:34:03 <ttx> sounds like a good one
14:34:11 <thingee> yeah
14:34:35 <ttx> ok, targeting
14:34:45 <thingee> I left a +1
14:35:12 <ttx> https://bugs.launchpad.net/cinder/+bug/1443331
14:35:12 <openstack> Launchpad bug 1443331 in Cinder "Fix a wrong argument of create method in QoSSpecsController Class" [High,Fix committed] - Assigned to Daisuke Fujita (fuzita-daisuke)
14:35:34 <thingee> I'll need to propose one
14:35:36 <ttx> sounds pretty straightforward
14:35:40 <thingee> pretty good catch
14:36:19 <ttx> https://bugs.launchpad.net/cinder/+bug/1406703
14:36:19 <openstack> Launchpad bug 1406703 in Cinder "Deleting VM with an attached volume during copy-volume-to-image causes the volume remains in-use state" [Medium,Fix committed] - Assigned to Abhijeet Malawade (abhijeet-malawade)
14:37:10 <ttx> add new db api? Is that safe ?
14:37:36 <thingee> https://review.openstack.org/175898
14:37:38 <ttx> like, doesn't it have to be used by drivers or anything ?
14:38:21 <thingee> nah it's only touched by the manager
14:38:31 <thingee> the manager is the only layer that can make state changes for drivers.
14:38:45 <ttx> you want it in RC2 ?
14:39:10 <thingee> yes
14:39:15 <ttx> ok adding
14:39:47 <ttx> https://bugs.launchpad.net/cinder/+bug/1437290
14:39:47 <openstack> Launchpad bug 1437290 in Cinder "Windows SMBFS: volume extend fails" [Undecided,Fix committed] - Assigned to Petrut Lucian (petrutlucian94)
14:40:16 <thingee> limited to a driver. I'm not worried
14:40:19 <ttx> pretty simple
14:40:24 <ttx> adding
14:41:00 <ttx> ok...
14:41:13 <ttx> Let's map that to proposed fixes @ https://review.openstack.org/#/q/project:openstack/cinder+branch:stable/kilo,n,z
14:41:14 <thingee> https://review.openstack.org/175900
14:41:53 <ttx> https://review.openstack.org/#/c/174050/ is for https://bugs.launchpad.net/cinder/+bug/1439371 which we targeted
14:41:54 <openstack> Launchpad bug 1439371 in Cinder kilo "Volume creation from image fails for UEC and Glance API version 2" [High,In progress]
14:42:24 <ttx> https://review.openstack.org/#/c/175723/
14:42:43 <ttx> maps to https://bugs.launchpad.net/cinder/+bug/1444855 (not targeted)
14:42:43 <openstack> Launchpad bug 1444855 in Cinder "RBD driver doesn't support customized ceph cluster name" [Low,Fix committed] - Assigned to Huang Zhiteng (zhiteng-huang)
14:42:52 <ttx> what should we do with that one
14:43:22 <ttx> adding a config option, beh
14:43:38 <thingee> yeah not good
14:43:41 <ttx> I .. think we are a bit late for that
14:43:46 <thingee> agreed
14:43:53 <ttx> I'll let you -2 it
14:44:25 <ttx> https://review.openstack.org/#/c/175740/
14:44:34 <ttx> maps to targeted bug
14:44:56 <ttx> https://review.openstack.org/#/c/174482/
14:45:22 <ttx> arh
14:45:39 <ttx> damn fix was pushed to stable/juno
14:46:05 <thingee> which?
14:46:15 <ttx> https://review.openstack.org/#/c/174700/
14:46:42 <thingee> we can revert
14:46:59 <ttx> yes, sounds like a good idea
14:48:26 <ttx> https://review.openstack.org/#/c/175261/ -> https://bugs.launchpad.net/cinder/+bug/1445561
14:48:26 <openstack> Launchpad bug 1445561 in Cinder "cinder scheduler fails to handle CONF.scheduler_max_attempts = 1 " [Medium,Fix committed] - Assigned to Huang Zhiteng (zhiteng-huang)
14:49:07 <ttx> hmm, new log message... not sure the bug is worth it
14:49:24 <ttx> also seems to have regression potential
14:50:08 <thingee> https://review.openstack.org/175909
14:51:11 <thingee> I agree
14:51:35 <thingee> I'll give it a -2
14:52:29 <thingee> -1 rather. Don't have -2 abilitieis
14:52:46 <ttx> https://review.openstack.org/#/c/175202/ -> https://bugs.launchpad.net/cinder/+bug/1410107
14:52:46 <openstack> Launchpad bug 1410107 in Cinder "NetApp lun misaligned on hyper-v" [Undecided,Fix committed] - Assigned to Bob Callaway (bob-callaway)
14:52:48 <ttx> we should fix that
14:52:50 * ttx looks
14:53:39 <ttx> thingee: you appear not to be in https://review.openstack.org/#/admin/groups/82,members
14:54:04 <ttx> but I have powerz to add you! cool
14:54:06 <thingee> ha even jesse has abilities :)
14:54:16 <ttx> will clean up
14:54:21 <ttx> ok done
14:54:33 <ttx> so what about this LUN thing
14:55:02 <thingee> done
14:55:18 <ttx> feels like a rather large patch, but limited in scope
14:55:49 <ttx> I'm fine with it if you want it...
14:56:05 <ttx> but it's definietly larger than what we ususally accept at this stage
14:56:48 * thingee reads things closer
14:57:19 <thingee> this is an optimization for other hypervisiors
14:57:27 <thingee> not concerned this needs to go in right now
14:57:46 <thingee> "NetApp luns need to be aligned properly while attaching it to different operating systems. Currently its optimized for linux but will eventually need to cater to openstack environments with multiple hypervisors and guest os's."
14:57:54 <thingee> according to the bug description anyways
14:58:25 <ttx> ok, let's keep it out
14:58:38 <ttx> https://review.openstack.org/#/c/174051/ -> https://bugs.launchpad.net/cinder/+bug/1444224
14:58:38 <openstack> Launchpad bug 1444224 in Cinder "Race in PureISCSIDriver when creating hosts" [Undecided,Fix committed] - Assigned to Patrick East (patrick-east)
14:58:42 <ttx> not targeted yet
14:59:17 <ttx> sounds safe and simple
14:59:24 <thingee> agreed I'm fine with it
14:59:30 <ttx> oka dding
14:59:53 <ttx> https://review.openstack.org/#/c/174052/
15:00:01 <ttx> -> https://bugs.launchpad.net/cinder/+bug/1432972
15:00:01 <openstack> Launchpad bug 1432972 in Cinder "update quota failed with multi-value in one request" [High,Fix committed] - Assigned to Ankit Agrawal (ankitagrawal)
15:00:31 <ttx> your call, I'm fine with it
15:01:06 <thingee> yeah I'm fine with this
15:01:08 <thingee> tested it myself
15:01:24 <ttx> ok targeting
15:01:53 <ttx> https://launchpad.net/cinder/+milestone/kilo-rc2
15:01:56 <ttx> result ^
15:02:16 <thingee> thank you
15:02:36 <ttx> We'll get that in and prepare to close on Wed/Thu
15:02:41 <ttx> need to run
15:02:43 <thingee> I'll go through my -1's and switch them to -2's when I get back. Gotta head out.
15:02:46 <thingee> ok, thanks!
15:02:49 <ttx> david-lyle: Having a call now, will ping you later
15:28:55 <ttx> david-lyle: available now if you are around
15:46:13 <devananda> ttx: i'm here if you're free now
15:46:59 <ttx> devananda: well, hmm... about to talk to morgan and his window of availability is short
15:47:11 <ttx> so would rather talk to you in a few :)
15:47:27 <devananda> k k
15:47:42 <morganfainberg> o/
15:47:47 <ttx> morganfainberg: ohai
15:47:51 <ttx> #topic Keystone
15:47:52 <morganfainberg> :)
15:47:54 <devananda> I'll be afk for ~15. see you at our normal time
15:47:55 <ttx> We have a RC2 window opened
15:47:59 <morganfainberg> yes we do
15:48:13 <ttx> https://launchpad.net/keystone/+milestone/kilo-rc2
15:48:22 <ttx> anything new to push onto it ?
15:48:23 <morganfainberg> and all outstanding fixes besides what was discussed in #openstack-oslo this morning look to be committed
15:48:29 <ttx> right
15:48:51 <morganfainberg> let me look at the rc potentials... but i don't think anything else warrants being added
15:49:11 <ttx> I'll remove from potentialks the ones already atrgeted for sanity
15:49:46 <morganfainberg> yep
15:49:59 <morganfainberg> looks like we don't have any more i see needing to be targeted to rc
15:50:06 <morganfainberg> except the in-progress one from this morning
15:50:12 <morganfainberg> whihc i see was added
15:50:25 <ttx> right, so let's talk about libraries
15:50:43 <ttx> We'll ned a keystoneclient and a keystonemiddleware stable/kilo .Z bump
15:50:49 <ttx> to include that security fix
15:51:14 <ttx> I.. am not sure we want a bump the minimum version in requirements though
15:51:27 <ttx> as that would cascade-affect to everyone and that is nasty
15:51:34 <morganfainberg> didn't we fix the .Z requirement?
15:51:43 <morganfainberg> since we couldn't land anything in keystoneclient
15:51:56 <ttx> that is a different issue
15:52:06 <morganfainberg> oh minimum
15:52:11 <ttx> the question is, after you release keystoneclient 1.3.1 and keystonemiddleware 1.5.1
15:52:22 <morganfainberg> oh uh, we have an OSSN out right?
15:52:22 <ttx> should we set >=1.3.1 and >=1.5.1 in global-reqs
15:52:29 <ttx> yes we do
15:52:51 <morganfainberg> i think i'm ok with leaving it as is.
15:52:59 <morganfainberg> for sanity sake
15:53:08 <ttx> sounds good
15:53:41 <ttx> so we can't release until dhellmann is finished with releasing an uncapped liberty library for everything
15:53:48 <morganfainberg> right
15:53:49 <ttx> otherwise it breaks the world
15:54:04 <ttx> so hopefully that will be completed later today
15:54:14 <ttx> and we'll able to do those point updates stable/kilo libs tomorrow
15:54:19 <morganfainberg> sounds good
15:54:34 <ttx> and then merge the last bumps and close the RC2 for keystone
15:54:44 <ttx> I'd say Thursday at the latest, maybe tomorrow.
15:54:52 <morganfainberg> wfm
15:55:02 <ttx> all depends on that oslo-incub thing too
15:55:15 <ttx> so I'll ping you again tomorrow.
15:55:26 <morganfainberg> right. lets hope that solves it. but this is another reason i am happy eventlet is going away
15:55:29 <morganfainberg> for keystone
15:55:33 <morganfainberg> i wish i could remove it in liberty
15:55:37 <morganfainberg> instead of M
15:55:50 <ttx> damn users
15:55:55 <morganfainberg> right!? ;)
15:56:18 <ttx> Anyway, that is all I had
15:56:31 <morganfainberg> oh, keystoneauth
15:56:35 <ttx> You can see the design summit layout, which is pretty fragmented for keystone (by design)
15:56:50 <morganfainberg> added the goverance change and chasing down infra changes.
15:56:51 <ttx> so that you don't blatantly overlap with anyone in particular
15:57:07 <ttx> keystoneauth?
15:57:19 <morganfainberg> lib that isolates session/auth plugins, etc
15:57:27 <ttx> liberty stuf right
15:57:31 <morganfainberg> so to auth with keystone you don't need to forklift in all of keystoneclient
15:57:32 <morganfainberg> yeah
15:57:43 <morganfainberg> just a heads up the changes are pending.
15:57:45 <ttx> ok, so I'll gladly ignore that for now
15:57:49 <morganfainberg> hah
15:58:02 <morganfainberg> ok i'll look at the design summit layout for keystone
15:58:12 * ttx 's brain already divided in 15 projects RCs right now
15:58:24 <morganfainberg> only 15?!
15:58:26 <morganfainberg> phsaw,
15:58:42 <ttx> 16 actually.
15:58:49 <ttx> I can't count anymore
15:58:56 <morganfainberg> oh now thats the staw that breaks the camel's back.
15:59:03 <morganfainberg> 15 easy, 16... too much :P
15:59:08 <morganfainberg> anyway, all sounds good.
15:59:16 <ttx> yep, always the 16th that creates the most problems
15:59:29 <ttx> morganfainberg: ok, ttyl
15:59:35 <ttx> notmyname: ready when you are
15:59:41 <notmyname> hello
15:59:43 <ttx> #topic Swift
15:59:59 <ttx> https://launchpad.net/swift/+milestone/2.3.0-rc2
16:00:06 <ttx> I added a bug to track that PyEClib thing
16:00:20 <notmyname> ah ok
16:00:27 <notmyname> I'll be adding the rest today
16:00:28 <ttx> that way I know what I'm blocking on
16:00:37 <ttx> anything else to expect ?
16:00:43 <ttx> https://review.openstack.org/#/q/project:openstack/swift+branch:stable/kilo,n,z
16:00:49 <notmyname> we've got a list of the stuff that needs to be in rc2, and I'm shooting for a commit SHA by EoD for it
16:00:51 <ttx> has https://review.openstack.org/#/c/174552/
16:01:06 <ttx> I assumed https://review.openstack.org/#/c/175741/ is part of that ECLib bump ?
16:01:17 <notmyname> https://wiki.openstack.org/wiki/Swift/PriorityReviews
16:01:23 <ttx> If I assumed too much, I can divide that bug I created into two
16:02:01 <notmyname> hmm...I'm just now catching up from what happened while I was asleep
16:02:18 <notmyname> looks like patches have landed and there are stable/kilo patches
16:02:23 <notmyname> I was hoping to do that myself
16:02:23 <ttx> that wiki matches what is up on https://review.openstack.org/#/q/project:openstack/swift+branch:stable/kilo,n,z
16:02:41 <ttx> I'll let you do that then
16:02:51 <notmyname> anyway, today, I'll be making sure they have RC2 bugs, reproposing, and landing them on stable/kilo
16:03:05 <notmyname> but it looks like we've got all the patches needed on master
16:03:19 <ttx> ok. Just make double-sure anything you merge in stable/kilo is already landed in master
16:03:30 <notmyname> of course :-)
16:04:16 <ttx> OK, planning to cut RC2 for you tomorrow morning
16:04:27 <notmyname> I'll send an email with the commit sha as soon as I have it
16:04:27 <ttx> anything else to mention?
16:04:47 <notmyname> no, I think I'm good. later this week I'll be refocusing on summit planning. if I have questions, I'll ping you then
16:04:57 <notmyname> thanks for the help with global requirements
16:05:18 <david-lyle> ttx: here if you have time
16:05:44 <ttx> notmyname: alright then
16:05:51 <ttx> david-lyle: let's do it real quick
16:05:57 <ttx> #topic Horizon
16:06:08 <ttx> https://bugs.launchpad.net/horizon/+bugs?field.tag=kilo-rc-potential
16:06:18 <ttx> 2 candidates there
16:06:46 <ttx> I think we can open the RC2 now and merge what you have proposed... or would you rather wait a bit more ?
16:06:47 <david-lyle> yes and two others that are in progress may land
16:07:12 <david-lyle> we are waiting on the final translations I believe
16:07:20 <david-lyle> April 23 is the expected date
16:07:32 <ttx> hmm, so how about we open the RC2 tomorrow ?
16:07:39 <david-lyle> that sounds good
16:07:42 <ttx> so that we don't keep the thing untestable for too long
16:07:53 <ttx> sounds good, lets me catch my breath
16:08:05 <david-lyle> I'll try to bump the other two in progress bugs along
16:08:25 <ttx> right, and anything else that is fixed on master could be included if safe
16:08:37 <ttx> so maybe time to give the last ones a bump
16:08:53 <ttx> I'll talk to you tomorrow then
16:08:58 <david-lyle> sounds good
16:09:01 <david-lyle> thanks
16:09:08 <ttx> np! thanks
16:09:13 <ttx> devananda: you're on
16:09:23 <devananda> ttx: o/
16:09:26 <ttx> #topic Ironic
16:09:39 <ttx> https://bugs.launchpad.net/ironic/+bugs?field.tag=kilo-rc-potential
16:09:47 <ttx> is pretty empty but I suspect you have your own list
16:09:48 <devananda> 3 candidates
16:10:22 <devananda> one has landed on master already, the other two should be landable soon
16:10:36 <ttx> hmm, so I'd say we should wait at least one more day to open the RC2 window
16:10:44 <ttx> especially if you want those fixes in
16:10:55 <devananda> could you explain / point me t oa reference for this process? it seems different from last cycle, and I haven't figured it out yet
16:11:02 <ttx> I'd rather only consider for backport stuff that is already fixed in amster
16:11:10 <devananda> like, when we can land backports
16:11:20 <ttx> devananda: I think last cycles you were not integrated yet
16:11:31 <ttx> so you were pretty much deciding
16:11:38 <ttx> here the idea is to encourage testing
16:11:43 <devananda> indeed. but we were trying to track the release process as closely as possible
16:11:50 <ttx> people are dumb, they only test when they believe it will be the final thing
16:12:00 <devananda> heh
16:12:06 <ttx> so whenever you say something like "we'll do a RC2 two days before release" they wait
16:12:10 <ttx> human nat ure I guess
16:12:15 <ttx> so you don't say that
16:12:26 <ttx> You say "this RC1 will be final ! test it!"
16:12:33 <devananda> gotcha. so "open rc2" really means "tag rc2"
16:12:47 <ttx> then when you finally decide to do a RC2, you want the window to be as short as possible
16:12:52 <ttx> and get them back to testing
16:12:59 <devananda> and we stage the fixes as proposed to kilo/stable but with a -2 until then
16:13:04 <devananda> ?
16:13:09 <ttx> Also reduces risk that you would keep a RC window opened over release time
16:13:18 <ttx> i.e. you don't open something you don't know how to close
16:13:40 <ttx> hence, ideally,  the targeting of only-already-fixed-in-master things
16:13:43 <devananda> right. quite a different process from the other milestones, and I hadn't read anything about this previously
16:14:08 <devananda> relatedly, what about fixes for the stable branch of the client?
16:14:08 <ttx> https://wiki.openstack.org/wiki/ReleaseCycle#Pre-release_.28Release_Candidates_dance.29
16:14:33 <ttx> so that is slightly different
16:14:40 <devananda> yea, that ^ does not describe what we're doing
16:14:46 <ttx> And again, using the same branch name is confusing
16:14:54 <devananda> "A new milestone will be open (RC2), with bugs targeted to it. " << not what we're doing
16:15:18 <ttx> what we'll be doing
16:15:20 <devananda> I think that is where my confusion stemmed from. thanks for clarifying
16:15:35 <ttx> so stable/kilo for openstack/ironic is a pre-release branch at the moment
16:15:46 <ttx> but for the lib, it's a real stable branch
16:15:58 <devananda> hmm. k.
16:16:04 <ttx> They have different meanings, which is why I resisted them being called the same thing
16:16:11 <ttx> But then sdague won
16:16:18 <devananda> he does that some times
16:16:39 <ttx> so the real stable branch is something you push backport of fixes too
16:16:57 <ttx> no need for RC windows. No deliverable to test, no release candidates
16:17:01 <devananda> cool
16:17:05 <ttx> no coordinated release either
16:17:05 <devananda> i'll do the usual things there, then
16:17:26 <ttx> that said... stable branches for libs are there for testing purposes
16:17:37 <ttx> so only very critical fixes should be backported to them
16:17:55 <ttx> you are still supposed to give users the HEAD version and be backward compatible
16:17:59 <devananda> fwiw, people are already beginning to ask about stable branches of libs & clients and asking why we're not just calling it the kilo release of python-ironicclient
16:18:35 <ttx> It's more "the version the rest of Kilo was tested with"
16:18:39 <devananda> I understand the reasons that we want them for testing purposes, but it's going to confuse users
16:19:06 <ttx> You can point them to http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
16:19:15 <devananda> will do
16:19:23 <ttx> but yeah, i agree this is confusing
16:19:28 <ttx> anyway
16:19:45 <ttx> back to topic
16:19:53 <devananda> :)
16:19:56 <ttx> So I propose we discuss the opening of the RC2 window tomorrow
16:20:22 <ttx> hopefuly those fixes will have landed and we'll have a peaceful conversation
16:20:25 <devananda> :)
16:20:41 * ttx doesn't like unfixed bugs in his RC lists
16:20:43 <devananda> sounds good. same bat time, same bat channel?
16:21:03 <ttx> yes, just ping me when you can talk
16:21:08 <ttx> could be before
16:21:21 <ttx> #topic Trove
16:21:46 <ttx> No SlickNik today, looking into opening a RC2 window there on Thursday to catch late requirements/translations
16:21:49 <ttx> #endmeeting