07:56:46 <ttx> #startmeeting ptl_sync
07:56:47 <openstack> Meeting started Tue Apr 28 07:56:46 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:56:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:56:50 <openstack> The meeting name has been set to 'ptl_sync'
07:56:51 <ttx> #topic Heat
07:56:54 <ttx> asalkeld: o/
07:56:59 <asalkeld> yo
07:57:31 <asalkeld> are we looking at bugs that might cause another rc?
07:57:37 <ttx> asalkeld: so at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
07:57:52 <ttx> https://bugs.launchpad.net/heat/+bugs?field.tag=kilo-rc-potential
07:57:53 <asalkeld> I don't see any like that
07:58:00 <ttx> Do you have anythign that meets that description there ?
07:58:19 <asalkeld> not yet
07:58:24 <ttx> https://bugs.launchpad.net/heat/+bug/1446252 sounds like a typical bug
07:58:24 <openstack> Launchpad bug 1446252 in heat "Can't rollback update with nested stack in progress" [High,Fix committed] - Assigned to Zane Bitter (zaneb)
07:58:43 <ttx> can land in stable/kilo post-release alright
07:58:55 <asalkeld> yes
07:59:05 <ttx> Quick look at proposed stable/kilo things
07:59:12 <asalkeld> ok
07:59:15 <ttx> https://review.openstack.org/#/q/is:open+project:openstack/heat+branch:stable/kilo,n,z
07:59:39 <ttx> https://review.openstack.org/#/c/177602/ is interesting
08:00:07 <asalkeld> looking
08:00:14 <ttx> is it something we can change at any time ?
08:00:48 <asalkeld> ttx: it is not a security issue
08:01:03 <ttx> Right, this SHA1 is not actually brute-forceable enough
08:01:07 <asalkeld> so yeah, can be done any time
08:01:31 <ttx> ok, looks like you're good (which is good news, since some others are not in such good shape)
08:01:33 <asalkeld> it's just to make a dynamic version number
08:01:47 <ttx> You should work on release notes on the remaining time
08:01:57 <ttx> https://wiki.openstack.org/wiki/ReleaseNotes/Kilo
08:02:07 <asalkeld> ok will do
08:02:09 <ttx> #info At RC2, no need for a RC3 at this stage
08:02:31 <ttx> We need release notes completed by Thursday when we unleash the thing to the world
08:02:33 <asalkeld> agree
08:02:47 <ttx> We usually have more time to work on them but we were late this cycle
08:03:07 <ttx> so the sooner the better (as you get closer you'll get edit conflicts)
08:03:15 <asalkeld> ok
08:03:23 <ttx> asalkeld: questions?
08:03:34 <asalkeld> ttx: no all good
08:03:39 <ttx> asalkeld: unless I hear from you I'll retag the RC2 as final on release day and play LP tricks
08:03:55 <asalkeld> sounds good
08:04:04 <ttx> awesome, thanks !
08:04:15 <asalkeld> i'll let you know if there is something critical
08:04:22 <asalkeld> but i haven't seen any
08:04:45 <ttx> asalkeld: right
08:04:58 <ttx> the point is, we'll find significant bugs next week too
08:05:07 <ttx> so the question at this stage is... can this wait
08:05:39 <asalkeld> ok
08:06:00 <asalkeld> ... yes we can
08:06:04 <asalkeld> (wait)
09:18:26 <ttx> johnthetubaguy: o/ talk to you in a minute
09:20:13 <johnthetubaguy> ttx: ack
09:20:20 <ttx> #topic Nova
09:20:42 <ttx> So we have a RC3 window opened, and it's not that easy to close with a busy gate
09:21:03 <ttx> We opened it for https://bugs.launchpad.net/nova/+bug/1448075
09:21:03 <openstack> Launchpad bug 1448075 in OpenStack Compute (nova) kilo "Recent compute RPC API version bump missed out on security group parts of the api" [Critical,In progress]
09:21:13 <ttx> which didn't merge in master yet
09:21:55 <ttx> and is failing tests again on the retry
09:22:18 <ttx> so I'm a bit worried we won't be able to close this one today
09:22:34 <ttx> One of the reasons I don't want to consider anything not merged in master for RC
09:23:13 <johnthetubaguy> oh dear, agreed with must be merged in master
09:23:20 <johnthetubaguy> taking a look
09:23:44 <ttx> At this point on current load, that patch won't merge in the next 14 hours
09:24:07 <ttx> which places the RC3 closing, at best, at 26 hours
09:24:18 <ttx> not sure we can afford that
09:24:35 <johnthetubaguy> ah, sounds like gate has gone unstable :(
09:25:07 <johnthetubaguy> aweful timing, as ever with these things
09:25:20 <ttx> well, I don't agree. We shouldn't depend on last week for anything
09:25:34 <johnthetubaguy> very true
09:25:37 <ttx> RCs from last week should have been ok
09:25:53 <ttx> So I blame lack of test coverage for things that are considered RC
09:26:13 <johnthetubaguy> thats totally fair
09:26:18 <ttx> anyway, two things trying to slip in the same RC window
09:26:26 <johnthetubaguy> I have schedued a session for this
09:26:27 <ttx> https://bugs.launchpad.net/nova/+bug/1447132
09:26:27 <openstack> Launchpad bug 1447132 in OpenStack Compute (nova) kilo "nova-manage db migrate_flavor_data doesn't do instances not in instance_extra" [High,New]
09:26:41 <ttx> and bug 1444745
09:26:41 <openstack> bug 1444745 in OpenStack Compute (nova) "Updates RPC version alias for kilo" [High,Fix committed] https://launchpad.net/bugs/1444745 - Assigned to Alex Xu (xuhj)
09:26:57 <ttx> That last one is concerning, sounds like something that should be done prerelease
09:27:05 <ttx> (but hasn't been)
09:27:16 <johnthetubaguy> yeah, thats the one I am worried about
09:27:36 <ttx> Both are actually closer to merging than 1448075
09:27:39 <ttx> since they are in master already
09:27:46 <johnthetubaguy> basically, it causes us some upgrade issues for liberty, but I think we could work around it
09:27:46 <ttx> so two options
09:28:03 <ttx> 1/ cancel RC3 while nothing has merged in it yet
09:28:24 <ttx> 2/ Do RC3 (in which case we could add both bugs in)
09:29:07 <ttx> I'm leaning toward doing it with at least 1448075 and 1444745 in
09:29:15 <ttx> Not totally sure about 1447132
09:29:33 <ttx> That probably means closing RC3 tomorrow
09:29:41 <ttx> which means it won't see any testing
09:29:49 <ttx> so this fixes must be 100% safe
09:30:09 <johnthetubaguy> right
09:30:16 <ttx> and I have a hard time understanding what those RPC things actually change
09:30:27 <ttx> what's your take on the options ?
09:30:42 <johnthetubaguy> so my take is, its all about this one: https://bugs.launchpad.net/nova/+bug/1448075
09:30:42 <openstack> Launchpad bug 1448075 in OpenStack Compute (nova) kilo "Recent compute RPC API version bump missed out on security group parts of the api" [Critical,In progress]
09:31:06 <johnthetubaguy> thats the only real trigger for RC3
09:31:21 <ttx> ...and we just added another hour to the lead in, thanks to a patch that was top of line and -2ed
09:31:51 <ttx> Now at 12:42
09:31:54 <johnthetubaguy> if that doesn't make it, then RC3 doesn't matter, I think
09:31:57 <ttx> 12 hours and 42 minutes
09:32:06 <johnthetubaguy> right
09:32:12 <johnthetubaguy> thats kinda crazy
09:32:30 <johnthetubaguy> so lets just revisit the other ones a second
09:32:34 <ttx> and that's European morning, so as low as it will be
09:32:49 <johnthetubaguy> bug 1444745
09:32:49 <openstack> bug 1444745 in OpenStack Compute (nova) "Updates RPC version alias for kilo" [High,Fix committed] https://launchpad.net/bugs/1444745 - Assigned to Alex Xu (xuhj)
09:32:55 <johnthetubaguy> that one can be backported
09:33:13 <johnthetubaguy> we usually forget to do that, it only really gets used by those using liberty anyway
09:33:22 <johnthetubaguy> not too major
09:33:30 <ttx> ok
09:33:39 <johnthetubaguy> bug 1447132
09:33:40 <openstack> bug 1447132 in OpenStack Compute (nova) kilo "nova-manage db migrate_flavor_data doesn't do instances not in instance_extra" [High,New] https://launchpad.net/bugs/1447132
09:34:01 <johnthetubaguy> this is a utility that helps force the database to upgrade the data
09:34:32 <johnthetubaguy> now we plan to force people to run that before some point in liberty, so we can drop the compat code
09:34:57 <johnthetubaguy> that could be first step during a liberty upgrade, if it really has to be, so we could backport that OK, possibly
09:35:12 <johnthetubaguy> its fairly risk free, as its changing a util not core code
09:35:30 <johnthetubaguy> I would like to jam that in, if we had time, but we don't, so I am OK without that I think
09:35:45 <ttx> So... how about we cancel the RC3 until we know if we have a chance to make one
09:36:10 <ttx> We get that other fix in master, and once it's in, we see what the lead time is for the stable/kilo patch
09:36:17 <johnthetubaguy> ttx: OK, so we reopen RC3 if/when bug 1448075 lands
09:36:17 <openstack> bug 1448075 in OpenStack Compute (nova) kilo "Recent compute RPC API version bump missed out on security group parts of the api" [Critical,In progress] https://launchpad.net/bugs/1448075
09:36:22 <ttx> yes
09:36:43 <ttx> if it lands and the lead time on the gate still lets us do RC3 before Thursday
09:36:47 <johnthetubaguy> worst case, we give are selves some more compat code to keep during liberty, I think we can keep just those methods, but I need to check
09:37:03 <johnthetubaguy> ttx: yes true
09:38:55 <ttx> so let's keep an eye on that patch (https://review.openstack.org/#/c/177186/) and gate queue status today
09:39:03 <ttx> johnthetubaguy: we can talk at the end of the day
09:39:11 <johnthetubaguy> ttx: so I think the mistake we made was to be way too late trying to raise the compute RPCAPI, its a long time since we did that, and turns out we didn't really remember everything that was needed
09:39:11 <ttx> In the mean time I'll kill the RC3 window
09:39:18 <johnthetubaguy> ttx: OK, thanks
09:39:31 <johnthetubaguy> ttx: so we have a first draft of Nova summit sessions in an etherpad now
09:40:00 <johnthetubaguy> ttx: waiting for cross project ones, and finding session leaders before we upload all of those to sched
09:41:22 <ttx> ok
09:42:24 <johnthetubaguy> ttx: thanks sorry for the delay, stupid trains
09:42:28 <ttx> johnthetubaguy: oh, we have option 3 too. Merge stuff in kilo that are not in master yet
09:42:43 <ttx> Not sure that's a good idea though
09:42:47 <johnthetubaguy> ttx: yeah, I am not sure I like that idea
09:43:06 <ttx> ok, RC3 deleted for now
09:43:51 <johnthetubaguy> ttx: tahnks
09:43:54 <johnthetubaguy> doh
09:43:55 <johnthetubaguy> thanks
09:45:21 <ttx> johnthetubaguy: I'll let you explain the situation to the nova crowd
09:45:46 <johnthetubaguy> ttx: will do
09:46:02 <ttx> We could ask peopel to stop approving things, but I know it's useless
09:46:55 <ttx> johnthetubaguy: oh, and while you wait on gate... https://wiki.openstack.org/wiki/ReleaseNotes/Kilo
09:47:01 <ttx> We need those done by tomorrow
09:47:15 <ttx> the earlier, the better to avoid edit conflicts
09:48:18 <johnthetubaguy> ah, by tomorrow, oops, yes
09:48:44 <johnthetubaguy> its on the agenda for the meeting on thursday, which is no good
09:48:49 <johnthetubaguy> will push on that
09:49:00 <ttx> yeah, at that point release will be out already
09:49:08 <johnthetubaguy> right
11:38:44 <ttx> gate lead-in down to 4h55min
12:00:45 <eglynn> ttx: knock, knock ... ready when you are
12:01:27 <eglynn> ttx: re. the ceilometerclient stable/kilo release, I need to discuss that a bit with gordc
12:01:54 <eglynn> ttx: (on the agenda for our call at 13:30UTC today)
12:02:07 <ttx> eglynn: ohai
12:02:19 <ttx> eglynn: it's been published yesterday
12:02:25 <ttx> #topic Ceilometer
12:02:59 <eglynn> a-ha, I see https://pypi.python.org/pypi/python-ceilometerclient/1.0.14
12:03:01 <eglynn> cool
12:03:01 <ttx> eglynn: so at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
12:03:10 <ttx> especially with the gate being on fire
12:03:15 <eglynn> yep, got it
12:03:33 <ttx> looking at ceilometer, you seem to be on the good side
12:03:58 <eglynn> yep, nothing major on the horizon
12:04:04 <ttx> Even https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Telemetry_.28Ceilometer.29 seems to be in good shape
12:04:20 * ttx gives out the "Good Citizen" badge to Ceilometer team
12:04:43 <eglynn> ttx: LOL :) ... finally!
12:05:03 <ttx> eglynn: that doesn't mean you get the "webscale" badge :P
12:05:20 <eglynn> ttx: touche!
12:05:41 <ttx> But yeah, I appreciate you guys not being late :)
12:06:21 <ttx> so, no remark on my side. Will retag RC2 to final on release day, unless you scream before then
12:06:32 <eglynn> cool, sounds good!
12:06:39 <ttx> Have a nice day!
12:07:03 <eglynn> you too, thanks for your time!
12:08:09 <ttx> SergeyLukjanov: ready when you are
12:08:22 <ttx> #info No RC3 on the horizon
12:08:57 <ttx> #topic Sahara
12:25:21 <ttx> well, no Sergey
12:25:24 <ttx> #undo
12:25:25 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x8cc3350>
12:25:28 <ttx> dhellmann: you there ?
12:25:38 <SergeyLukjanov> ttx, hey
12:25:45 <SergeyLukjanov> ttx, sorry for the delay
12:25:45 <ttx> bah
12:25:51 <ttx> #topic Sahara
12:25:53 <dhellmann> ttx: here, but take SergeyLukjanov first I'm in the middle of a release for oslo.messaging
12:26:16 <ttx> SergeyLukjanov: as I told eglynn, so at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
12:26:26 <ttx> especially with gate not behaving
12:26:30 <SergeyLukjanov> so, no new issues in Sahara, we're ready for release
12:26:43 <ttx> right, can't spot any such issues in shara backlog
12:26:55 <ttx> so we are goot to go, will retag on Thursday as final
12:26:58 <SergeyLukjanov> and I think we already fully finished testing and switched to L dev
12:27:21 <ttx> SergeyLukjanov: nice. Will you be around to push the "other" shara pieces around release time ?
12:27:30 <SergeyLukjanov> ttx, yup
12:27:48 <ttx> SergeyLukjanov: I can do Sahara in the EU morning, so ping me then
12:27:55 <SergeyLukjanov> ttx, okay
12:28:08 <ttx> SergeyLukjanov: you need to work on https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Data_Processing_service_.28Sahara.29
12:28:22 <ttx> needs ot be finalized before EOD tomorrow
12:28:32 <ttx> well, not "finalized"
12:28:37 <ttx> but at least be made presentable
12:28:48 <ttx> so people reading them don't feel it's WIP
12:28:50 <SergeyLukjanov> ttx, ack, we have a draft already, will finalize it tomorrow EU morning
12:28:53 <ttx> ok
12:28:57 <ttx> that is all
12:29:04 <ttx> SergeyLukjanov: have a great day!
12:29:15 <ttx> #topic Oslo
12:29:22 <SergeyLukjanov> what's about client release from stable/kilo?
12:29:39 <SergeyLukjanov> with fresh requirements
12:29:58 <dhellmann> SergeyLukjanov: we can't change the requirements of stable branch clients
12:30:00 <ttx> #undo
12:30:01 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x8cac710>
12:30:23 <SergeyLukjanov> I mean https://github.com/openstack/python-saharaclient/compare/0.8.0...stable/kilo
12:30:24 <ttx> SergeyLukjanov: is there any critical bug that would warrant a kilo point release ? Or could you just make a liberty release ?
12:30:41 <SergeyLukjanov> we have requirements synced to stable/kilo branch of python-saharaclient
12:30:47 <SergeyLukjanov> (Kilo release reqs)
12:30:59 <SergeyLukjanov> do we need to have a release in this branch that includes them?
12:31:01 <ttx> SergeyLukjanov: yeah, I don't think that is needed
12:31:08 <SergeyLukjanov> no bugs
12:31:22 <dhellmann> SergeyLukjanov: releasing an update of the library with requirements changes would require changing the minor version of the library, which would put it outside of the stable branch release series
12:31:26 <dhellmann> you should probably revert that commit
12:31:40 <dhellmann> that way when you have a bug fix later, you can release safely
12:31:57 <SergeyLukjanov> dhellmann, in master we have 0.9.0 and in stable/kilo the latest one is 0.8.0
12:32:02 <ttx> SergeyLukjanov: also I wouldn't backport random fixes to the lib branch, that sounds overkill
12:32:15 <dhellmann> the old minimums without caps are compatible with the stable branch
12:32:29 <SergeyLukjanov> okay, so, no need to release client from stable branch
12:32:38 <ttx> SergeyLukjanov: confirmed
12:32:43 <SergeyLukjanov> thx
12:32:56 <ttx> #topic Oslo
12:33:05 <ttx> dhellmann: so oslo.messaging release was my only topic
12:33:23 <dhellmann> I just tagged it, and I'm looking for my sandbox with the script for generating the release note mail
12:33:47 <ttx> ok, so I think we are good. Maybe we can tag stable/kilo oslo-incubator
12:34:07 <ttx> and release too
12:34:08 <dhellmann> yes, let's go ahead and do that
12:34:26 <ttx> i.e. I ca push a 2015.1.0 tag and cut stable/kilo from same commit
12:34:30 <dhellmann> you mean branch, not tag, right?
12:34:36 <dhellmann> yeah, ok, both
12:34:38 <ttx> historically there was a tag too
12:34:49 <ttx> not that it changes anything, but consistency ftw
12:34:52 <dhellmann> right, I was a little behind and meant for the stable/kilo name
12:35:08 <dhellmann> it should be safe to do that from master, let me check
12:35:15 <ttx> yep
12:36:08 <dhellmann> I have master as 0db1430757e1a33de7d3a20f4dd7048b4374d024 and that should be OK
12:36:36 <ttx> ack that is what I have
12:38:00 <ttx> all set
12:38:23 <ttx> I think we are kilo-done as far as Oslo is concerned
12:38:38 <ttx> dhellmann: anything on your mind ?
12:39:21 <dhellmann> we may want to talk about centralizing library releases, since the semver thing continues to be a source of confusion
12:39:36 <ttx> yes, I have a working session oin RelMgt track for that
12:39:39 <dhellmann> excellent
12:39:56 <dhellmann> did you see lifeless' post on requirements management?
12:39:58 <ttx> I'd like to take a page off oslo book and see how wer can reorg the "release team" to do that
12:40:13 <ttx> dhellmann: still on my todo
12:40:14 <dhellmann> #link https://rbtcollins.wordpress.com/2015/04/28/dealing-with-deps-in-openstack/
12:40:36 <dhellmann> yes, "central" would need to include several people
12:41:03 <ttx> I fear that's the only way to enforce some amount of process
12:41:22 <ttx> The trick is to do it without getting in the way
12:41:38 <dhellmann> at least until we have enough community knowledge, which I fear we won't be able to build until we stop tweaking the process :-)
12:41:49 <ttx> but the current process inconsistency is not really looking good anyway
12:42:10 <dhellmann> I'm thinking of ways to automate the process, but it keeps coming back to having the signed git tags
12:42:15 <ttx> and as we rely more and more on lib stuff... starts to become a clear issue
12:42:37 <ttx> dhellmann: if it all boils down to having a way to review tags.... we could push for that support in Gerrit
12:43:11 <ttx> I like mordred's announcements.
12:43:37 <dhellmann> yeah, I have no idea what would be involved in making it possible for gerrit to review tags. My thought was to have a file that lists the tags, and review that, and then have a bot apply the tag after the review
12:43:40 <ttx> anyway, meat for that discussion
12:43:59 <dhellmann> but we would have to trust the bot's gpg signature, which I suppose isn't a huge issue
12:44:01 <ttx> dhellmann: https://groups.google.com/forum/#!topic/repo-discuss/VV_xj6ftvoY
12:44:22 <dhellmann> I need to learn more about gpg's interaction with git
12:44:28 <dhellmann> oh, interesting, I'll put that on my reading list
12:44:43 <ttx> well, it's just other people complaining about that feature gap
12:44:50 <ttx> not really interesting reading
12:45:01 <dhellmann> ah
12:45:17 <ttx> just proving it's not completely an openstack thing
12:45:32 <mordred> dhellmann: I would like very  much to get someone to add tag submission to gerrit directly
12:45:50 <mordred> it really just takes someone being willing to write java
12:46:04 <ttx> mordred: I'll write Haskell before I'm back to Java code
12:46:04 <mordred> maybe we can convince mirantis to let SergeyLukjanov do it - he likes java
12:46:29 * SergeyLukjanov reading
12:46:43 <ttx> Although writing it is less painful than trying to package it, trust me.
12:47:31 <ttx> dhellmann: so all that is left of https://etherpad.openstack.org/p/the-big-thaw is the external dep pinning on stable/kilo
12:47:40 <ttx> dhellmann: I think we can postpone that until YVR
12:48:04 <ttx> no point in doing that if we rebuild a new house of cards
12:48:07 <dhellmann> yes, I would like to put that off as long as we can
12:48:11 <dhellmann> right
12:48:31 <SergeyLukjanov> mordred, I like JVM, not Java, I've been writing on pure Java about 3 or 4 years ago last time ;)
12:48:44 <mordred> SergeyLukjanov: :)
12:48:53 <mordred> SergeyLukjanov: but you can do ANYTHING! ;)
12:48:54 <ttx> SergeyLukjanov: no no you like writing Java code and even more having on Gerrit code.
12:49:02 <ttx> hacking*
12:49:05 <dhellmann> SergeyLukjanov: I'll bet it's like riding a bike. You'll pick it up again in no time
12:49:22 <ttx> dhellmann: it's more like riding a bike without a saddle
12:49:31 <dhellmann> heh
12:49:42 <SergeyLukjanov> heh
12:49:48 <ttx> dhellmann: you can do it, but only if that's the only way to travel
12:50:07 <SergeyLukjanov> gerrit in build using GWT and that's the main reason IMO to avoid looking in its code
12:50:24 * ttx throws up in a remote corner of the office
12:50:28 <SergeyLukjanov> but from our PoV gerrit with tags support is very usefull
12:51:34 <ttx> SergeyLukjanov: right!
13:43:57 <ttx> mestery: ready when you are
13:44:02 <mestery> ttx: Here
13:44:08 <ttx> #topic Neutron
13:44:23 <ttx> mestery: struggling a lot to close that RC3 window
13:44:31 <mestery> YEs, I see that https://review.openstack.org/177789 is having issues in the check queue
13:44:34 <ttx> but at least the change is in master
13:45:07 <ttx> so I still hope we'll get it through
13:45:13 <mestery> ++
13:45:14 <ttx> but shows the danger of late respins
13:45:21 <ttx> you're at the mercy of gate weather
13:45:30 <mestery> Totally agree, but on the other hand, I'm glad testing found these issues, so :)
13:45:53 <ttx> well, I would even more glad if automated testing found those issues 2 months ago
13:46:02 <mestery> Completely agree
13:46:21 <ttx> anyway, I think we should get it in by EOD
13:46:43 <ttx> and we have patches merged for RC3 already so backpedaling is not really a good option
13:46:56 <ttx> so... full speed ahead!
13:47:00 <mestery> Agreed
13:47:01 <mestery> ++
13:47:33 <ttx> https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Network_Service_.28Neutron.29  looks in good shape
13:47:47 <mestery> I've had people working on it, I'll go through it again and update as needed
13:48:30 <ttx> mestery: if by EOD we don't have that last patch in we have two choices
13:48:58 <ttx> we can delay RC3 until tomorrow (leaving little time to catch weird errors like corrupted tarballs)
13:49:06 <ttx> and we can cut without that fix in
13:49:25 <mestery> Well, lets just see if we can get that in
13:49:30 <mestery> And not have to look at those options
13:49:41 <mestery> Though I agree, those are the options should we not succeed
13:49:43 <ttx> full speed ahead!
13:49:47 <mestery> :)
13:50:15 <ttx> suffice to say only really odd stuff will trigger a RC addition at this point
13:50:19 <mestery> ttx: Just curious, how many other RC3s are in the works? Are we the only one?
13:50:36 <ttx> There was a Nova one but the fix isn't in master yet so I cancelled it
13:50:37 <mestery> \++ to that
13:50:43 <mestery> OK
13:50:57 <ttx> we may revive it if the fix finally makes it, since it's a pretty critical thing
13:51:11 <ttx> but in the mean time we wait
13:51:17 <mestery> OK
13:51:21 <ttx> there may be a swift one
13:51:42 <ttx> only news so far
13:51:54 <mestery> Ack
13:52:10 * mestery puts on his zuul monitoring glasses for the day
13:52:15 <ttx> the gate os completely desintegrating before my eyes
13:52:18 <ttx> is*
13:52:24 <mestery> I know :(
13:52:34 <mestery> Lots of red on there
13:52:42 <ttx> let's hope they figure it out
13:52:52 <mestery> ++
13:52:58 <ttx> at least we cut on the lead time. We seem to fail faster now
13:53:07 <mestery> :)
13:53:12 <mestery> Positive spin I guess
13:53:16 <ttx> this morning the lead time was 15 hours
13:53:21 <mestery> Yikes
13:53:28 <ttx> so it took 15 hours to fail
13:53:42 <mestery> If it was like that now, we'd just as well spin RC3 without that last one.
13:54:07 <ttx> OK, I'll be talking to you later
13:54:20 <mestery> Yes, talk to you later
14:20:53 <ttx> nikhil_k_: o/
14:21:00 <nikhil_k_> ttx: hi
14:21:05 <ttx> #topic Glance
14:21:31 <ttx> so at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
14:21:38 <ttx> especially with the gate on fire
14:21:56 <ttx> nikhil_k_: do you have anything that fits that description
14:21:56 <nikhil_k_> makes sense
14:22:32 <ttx> I don't see anything in the kilo-rc-potential list or the proposed backports
14:27:01 <ttx> nikhil_k_: in the remaining time (before tomorrow EOD) you should fill out https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Image_Service_.28Glance.29
14:27:14 <ttx> so that it's ready for release day
14:27:39 <nikhil_k_> ttx: all three?
14:27:51 <nikhil_k_> Key New Features, Known Issues and Upgrade Notes ?
14:28:05 <nikhil_k_> just trying to make sure if ground is covered
14:28:09 <ttx> Yes. If you don't have anything to say in the latter sections, just remove them
14:28:53 <ttx> If you have significant issues that won't get fixed in release, good idea to mention them in "Known Issues"
14:28:54 <nikhil_k_> ttx: ok. I don't have anything else for now in Kilo.
14:28:59 <nikhil_k_> ok
14:29:14 <ttx> all good
14:29:20 <nikhil_k_> ttx: so about the upgrade notes
14:29:36 <nikhil_k_> ttx: we have tried to apply as many UpgradeImpact flags as possible.
14:29:43 <nikhil_k_> Where do those flags go?
14:30:03 <nikhil_k_> or you get some notification to include them if misses?
14:30:05 <nikhil_k_> missed*
14:30:13 <ttx> They don't automatically go anywhere. But you should be able to grep them in the git log and mention the most significant glitches
14:30:30 <nikhil_k_> ok
14:30:41 <nikhil_k_> I hoped some digest is already created
14:30:46 <ttx> They are supposed to help in redacting that section
14:30:50 <ttx> not that I know of
14:30:51 <nikhil_k_> anyways, grepping is always fun
14:31:39 <ttx> nikhil_k_: OK, so unless we talk again, I'll be releasing RC2 as final on Thursday. You get those release notes filled before then.
14:33:30 <ttx> nikhil_k_: talk to you later!
14:33:34 <ttx> thingee: around?
14:33:43 <thingee> ttx: hi
14:33:45 <ttx> #topic Cinder
14:34:08 <thingee> bug came up with config generator. Unfortunately nova also has it
14:34:27 <thingee> https://bugs.launchpad.net/cinder/+bug/1447380
14:34:27 <openstack> Launchpad bug 1447380 in OpenStack Compute (nova) "wrong cinder.conf.sample generation: missing directives for keystone_authtoken (at least)" [Critical,In progress] - Assigned to John Griffith (john-griffith)
14:34:35 <ttx> thingee: that was fixed in RC2 for Cinder right
14:34:50 <ttx> thingee: Nova dismissed it as being broken for a long time
14:35:03 <thingee> ok sorry missed that on there side.
14:35:15 <nikhil_k_> (sorry, got disconnected from IRC. talk to you later)
14:35:24 <ttx> as I told nikhil; at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
14:35:35 <ttx> I don't see any such things in the pipe for Cinder
14:35:49 <ttx> Also the gate is on fire so we can't really respin anything at the moment
14:35:52 <thingee> I've been watching the incoming bugs pretty closely and caught up. nothing important came in
14:36:07 * thingee throws a cup of water at it
14:36:14 <ttx> So I'll retag RC2 as final on Thursday, unless we speak again (or you send me an email)
14:36:39 <ttx> in the mean time, you should apply final polish to https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Block_Storage_.28Cinder.29
14:36:44 <thingee> ttx: btw, documentation with release note items. oh my :)
14:37:01 <thingee> so happy about this
14:37:14 <ttx> nice
14:37:49 <ttx> thingee: anything else ?
14:38:02 <thingee> git log --grep=UpgradeImpact --since=6.month ... I think that does it?
14:38:04 <thingee> nikhil_k_: ^
14:38:20 <nikhil_k_> nice, thanks
14:38:40 <thingee> that's it for me. gearing up for sessions and liberty specs :)
14:38:48 <thingee> ttx: thanks
14:38:48 <ttx> awesome, ttyl
14:38:50 <ttx> david-lyle: hi!
14:46:00 <david-lyle> ttx: o/
14:46:23 <ttx> #topic Horizon
14:46:37 <ttx> As I tell everyone today... at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
14:46:45 <ttx> especially since the gate decided to burn all day
14:46:57 <ttx> Looking at Horizon I see one thing that could have qualified
14:47:06 <ttx> https://bugs.launchpad.net/horizon/+bug/1447288
14:47:06 <openstack> Launchpad bug 1447288 in OpenStack Dashboard (Horizon) "create volume from snapshot using horizon error" [Critical,In progress] - Assigned to Masco Kaliyamoorthy (masco)
14:47:28 <ttx> But since it's not even fixed in master yet, I  think that will have to live as a known release bug and get fixed post-release
14:47:34 <david-lyle> I don't think that's worth a new spin
14:47:57 <ttx> david-lyle: at least not a very late spin.
14:48:30 <ttx> david-lyle: ok, so RC2 is still good to go at this point
14:48:31 <david-lyle> we can backport for the next stable kilo release
14:48:34 <david-lyle> yes
14:48:50 <ttx> Time to focus on https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Dashboard_.28Horizon.29
14:49:02 <david-lyle> indeed
14:49:08 <ttx> That should be completed before EOD tomorrow, since the release will happen before you get up on Thursday
14:49:15 <david-lyle> ok
14:49:17 <david-lyle> will do
14:49:50 <ttx> Unless we talk again, will retag RC2 as final on release day. Thanks for your help!
14:49:56 <david-lyle> thank you
14:50:29 <ttx> ttyl
14:50:36 <david-lyle> later
15:48:40 <ttx> morganfainberg: around?
15:48:48 <morganfainberg> Ttx sure am
15:48:50 <ttx> #topic Keystone
15:48:57 <ttx> As I tell everyone today... at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
15:49:16 <morganfainberg> Nothing I've seen qualifies for that in keystone.
15:49:24 <ttx> right me neither
15:49:36 <ttx> So I'll retag RC2 as final on thursday, unless we speak again
15:49:43 <morganfainberg> Sounds good.
15:49:50 <morganfainberg> Release notes are under way
15:50:03 <ttx> Yep you should complete those by EOD tomorrow
15:50:12 <ttx> since the release will be out by the time you get up on thursday
15:50:20 <ttx> so you can wake up to campagne
15:50:23 <ttx> err
15:50:24 <ttx> champagne
15:50:25 <morganfainberg> I will work on them today. But I am unavailable all tomorrow.
15:50:39 <ttx> morganfainberg: ok, so TODAY. Or delegate
15:50:40 <morganfainberg> Will be traveling. I shall delegate as well to another core.
15:50:50 <morganfainberg> To finalize at our meeting.
15:50:55 <ttx> Alright
15:50:59 <morganfainberg> :)
15:51:12 <ttx> Thanks for everything !
15:51:17 <morganfainberg> Yay Kilo release!
15:51:17 <ttx> I'll be seeing you soon.
15:51:25 <morganfainberg> Yep!
15:51:35 <ttx> notmyname: around now if you are
15:51:41 <morganfainberg> Thanks!
15:51:45 <notmyname> ttx: I'm here
15:51:51 <ttx> #topic Swift
15:52:12 <ttx> notmyname: did you come to a conclusion on what we discussed yesterday ?
15:52:22 <notmyname> looking at it right now
15:58:36 <ttx> so for the record, we may consider a RC3, but we'll know more later today
15:58:56 <notmyname> yes
15:59:07 <notmyname> also, I've started working on the release notes wiki page
15:59:24 <notmyname> and hope to get to summit scheduling later this week
16:00:10 <ttx> ok, as far as release notes go, try to get them completed by EOD tomorrow
16:00:17 <ttx> Release will happen before you get up on Thursday
16:00:20 <notmyname> ok
16:00:28 <notmyname> what is the release time?
16:00:33 <notmyname> 0000UTC?
16:00:51 <notmyname> or is there a set time?
16:00:52 <ttx> I starttagging stuff at 0800 UTC and usually finish around 13:00 utc
16:00:57 <notmyname> ok
16:01:05 <ttx> PR goes off at 14:00 utc I think
16:01:12 <ttx> but I just send email when I'm done
16:01:18 <ttx> Alright, I'll be talking to you later today on that RC3
16:01:22 <notmyname> thanks
16:01:55 <ttx> devananda: raedy when you are
16:04:06 <ttx> hmm, actually I'll be back in 10min
16:05:05 <devananda> ttx: mmkay
16:05:07 <devananda> i'll be here
16:16:56 <ttx> #topic Ironic
16:17:00 <ttx> devananda: o/
16:17:16 <ttx> devananda: As I tell everyone today... at this point we only respin in case of a major regression, blatant security hole or stuff that can't be fixed post-release
16:17:28 <ttx> I see no such thing in Ironic kilo-rc-potential or proposed backports
16:17:58 <devananda> ttx: nor do I
16:18:06 <ttx> Alright!
16:18:12 <devananda> one of those seems to be a bug that affects a lot of projects
16:18:17 <devananda> some of htem have done backports?
16:18:21 <devananda> so I'm unclear about it
16:18:28 <ttx> which one ?
16:18:40 <devananda> https://bugs.launchpad.net/ironic/+bug/1384379
16:18:40 <openstack> Launchpad bug 1384379 in OpenStack Compute (nova) "versions resource uses host_url which may be incorrect" [High,In progress] - Assigned to shihanzhang (shihanzhang)
16:18:55 <ttx> No they don't
16:19:00 <devananda> ah. or they fixed it earlier in the cycle
16:19:01 <devananda> gotcha
16:19:05 <ttx> That leaves https://wiki.openstack.org/wiki/ReleaseNotes/Kilo
16:19:11 <ttx> you should add a Ironic section to that
16:19:18 <devananda> https://wiki.openstack.org/wiki/Ironic/ReleaseNotes/Kilo
16:19:19 <ttx> and fill it before EOD tomorrow
16:19:28 <devananda> how's that look?
16:19:46 <ttx> Looks good
16:20:06 <ttx> maybe just copy/paste
16:20:12 <devananda> cool, will do now
16:20:33 <devananda> i think that's it :)
16:20:35 <ttx> a few TODOs still in there
16:20:40 <devananda> ooh. right.
16:20:43 <devananda> will do once those are done :)
16:21:01 <ttx> Also might want to map to the other format, but I don't mind people being original there :)
16:21:49 <ttx> OK, so unless we speak again I'll retag RC2 as final on release day and make things happen in LP and tarballs and stuff
16:22:05 <ttx> devananda: ttyl !
16:22:13 <devananda> ttx: cheers!
16:22:23 <ttx> We seem to be out of SlickNiks
16:22:29 <ttx> let's wait a few
16:22:34 <ttx> #topic Trove
16:23:11 <ttx> For the record, nothing critical seems to have crept up there
16:23:56 <ttx> So that leaves us with a RC3 for Neutron, and potential ones for Swift and Nova.
16:26:11 <ttx> mestery: that damn change is really not playing ball, failing again in check
16:26:22 <ttx> that said the gate is now empty so retries might be an option
16:26:31 <mestery> ttx: Lets give it anotehr spin, I noticed the same.
16:26:47 <mestery> ttx: But it is being difficult, this time failing in some random way in the functional job unrelated to the change.
16:27:41 <ttx> zz_johnthetubagu: given that gate seems to be more amenable now, I'm willing to consider the Nova RC3 if https://review.openstack.org/#/c/177186/ makes it to master over the next hours
16:28:50 <sdague> mestery: what's the pass rate of the neutron functional job? I've seen that failing a lot in the gate
16:29:37 <mestery> sdague: One second, in another thread I'm unwiding
16:30:12 <ttx> OK, I'll be abck in a couple of hours to take the temperature on those RC3s again
16:30:17 <ttx> #endmeeting