Tuesday, 2015-06-02

*** AzherKhan has joined #openstack-relmgr-office00:19
*** AzherKhan has quit IRC00:21
*** AzherKhan has joined #openstack-relmgr-office00:31
*** AzherKhan has quit IRC01:00
*** AzherKhan has joined #openstack-relmgr-office01:00
*** Khaazher has joined #openstack-relmgr-office01:01
*** AzherKhan has quit IRC01:01
*** Khaazher has quit IRC01:16
*** thingee has quit IRC01:35
*** thingee has joined #openstack-relmgr-office01:41
*** AzherKhan has joined #openstack-relmgr-office02:31
*** AK has joined #openstack-relmgr-office02:31
*** dims___ has quit IRC02:48
*** dims_ has joined #openstack-relmgr-office03:48
*** dims_ has quit IRC03:53
*** david-lyle has quit IRC04:24
*** david-lyle has joined #openstack-relmgr-office04:25
*** dims_ has joined #openstack-relmgr-office06:37
*** dims_ has quit IRC06:42
ttxohai, starting office hours on this channel08:00
*** ChanServ changes topic to "OpenStack Release Managers office - Office hours on Tuesdays, 0800-1000 UTC and 1800-2000 UTC - Logged at http://eavesdrop.openstack.org/irclogs/%23openstack-relmgr-office/"08:02
ttxGrabbing coffee, brb08:07
ttxback08:13
*** dims_ has joined #openstack-relmgr-office09:26
*** dims_ has quit IRC09:31
*** dims_ has joined #openstack-relmgr-office10:55
*** AK has quit IRC11:07
*** AzherKhan has quit IRC11:07
*** Kiall_ is now known as Kiall11:37
ttxdhellmann: hi! Would you mind driving the cross-project meeting today ? I'll ask for another volunteer to drive it next week. Would like to create a rotation so that all TC members can experience the pain12:53
Kiallttx: about? I had a Q re client releases now that we have a stable branch.. We have what is effectivly a API change, but one that's actually necessary to use the client properly with an existing Keystone session (e.g. from Horizon, Neutron).. https://github.com/openstack/python-designateclient/commit/34d14b06d91b3d2e90d6531972bc25b8a8de53ab13:15
KiallSo.. 1) If we release this off the master branch, what version should we pick?13:15
Kiall2) Can we backport to stable/kilo, and what version should we pick?13:15
KiallI suppose there's a #3 too.. Should we be following the "server" launchpad conventions (e.g. target to Kilo series) for a backport like that?13:16
*** dims_ has quit IRC13:51
*** dims_ has joined #openstack-relmgr-office13:51
ttxKiall: ohai13:53
KiallHeya13:54
ttxStill trying to wrap my head around an API change necessary to work with a Keystone session.... Didn't that work before ?13:54
KiallKinda.. It was a total mess up tho that "added" extra attributes to the keystone session object.. Which, funny enough, Horizon etc don't do!13:55
ttxIf the API change is purely additive (not breaking) bumping the Y in X.Y.Z on master sounds like the right call13:55
ttxI'd say that this is inappropriate for a stable backport, but could use dhellmann's view on it13:56
KiallIt's breaking as is, it could be made backwards compat I guess though13:56
KiallLet's assume we make it backwards compat, cherry-pick to stable and do 2 releases 1 off each branch? I guess I'm mainly trying to figure out what the release process for clients is now!13:57
ttxI don't think that would be appropriate for a stable/kilo .Z bump, since it changes the API13:59
ttxbasically on master you can make semver X, Y or Z bumps13:59
ttxon stable/kilo it should only be .Z bumps14:00
KiallWell, if we make it 100% additive so it's non-breaking, but fixes the bug a Z bump makes sense as it really is a bug that prevents useage of a Keystone session created outside of our create KS session helper..14:00
ttxlet's wait and pick dhellmann's brains -- in theory backward-compatible API changes are not allowed in a .Z but it may be a corner case14:01
* dhellmann perks up his ears14:01
ttxKiall: users are supposed to use the master version anyway14:02
dhellmannttx: sure, I can run the meeting today. Do you have an agenda put together?14:02
ttxYes, Let me finalize it with your name on it14:02
ttxand I can send the agenda email14:02
dhellmannKiall: is that work necessary to talk to a kilo cloud?14:03
dhellmannor, rather, is it necessary for the services within a kilo cloud to talk to each other?14:03
ttxdhellmann: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- first meeting with space for the horizontal / vertical teams announcements14:04
ttxI'll send an email to list about it14:05
Kialldhellmann: yea, the bug is essentiually that our "Kilo" client expects a monkeypatched Keystone Session object to add some Designate specific properties, which is clearly not what we intended/wanted.. And breaks this like the Horizon panels from passing a pre-created/shared KS session into designateclient14:05
KiallThe fact that it got in like that at all was a eh.. mess up...14:05
dhellmannttx: do you already have a list of folks who need a courtesy ping for that meeting, or should I put one together?14:07
dhellmannKiall: so the kilo version of designateclient doesn't work with the kilo version of horizon?14:08
*** KA has joined #openstack-relmgr-office14:08
*** AK has joined #openstack-relmgr-office14:08
ttxdhellmann: I have one, but it's incomplete14:09
ttxI can courtesy-ping myself at the end of the TC meeting, and you can copypaste it14:09
KiallYea, now it's a tag murkey there in that our panels aren't baked into Horizon, but the panels tagged kilo don't14:09
dhellmannttx: or you could throw it into my script at https://etherpad.openstack.org/p/cross-project-agenda14:09
Kialltad*14:09
dhellmannttx: either way14:09
ttxok, throwing it in14:10
dhellmannKiall: ok, it seems like this should probably be backported, then.14:11
ttxdhellmann: and still use a .Z bump under the "oops we really messed up kilo" exception rule ?14:12
KiallYea, I'm going to add 1 more change that keeps backwards compatibility first though.. Once done, what branch actually get's tagged? Do tags ever go on the client stable/* branches?14:12
ttxKiall: yes, we do tags on stable branches. Note that we'll likely get back tagging control on libraries in the near future so that we can oversee that process14:13
ttxand apply process paste onto it liberally14:13
Kiallttx: Sure, I'm happy to hand that over once you / stable-maint and happy to handle it!14:14
Kialls/and/are/14:14
dhellmannKiall: is the change going to be backwards compatible with existing client users?14:14
Kialldhellmann: it will be in a few mins!14:14
dhellmannKiall: ok, if it's API compatible with the existing kilo release a z bump is ok14:14
dhellmannttx: in the agenda, by "vertical teams" you mean project teams like nova, right?14:17
ttxyep, I explained that much on the announcement email I just sent to dev14:17
Kialldhellmann: K.. I'll get the changes lined up.. Last question - should both master and stable/kilo get tagged once everything is merged? kilo is 1.2.x, should stable/kilo get 1.2.1 and master get 1.3.0?14:18
* dhellmann goes to his email client14:18
ttxdhellmann: it's basically a clearer "open discussion"14:18
dhellmannKiall: they do need to be tagged separately, but the timing is up to you14:18
dhellmannKiall: if you send me shas for each branch, I can tag them for you14:18
KiallSure.. I'm mostly wondering if the version #'s I suggested are correct? :)14:18
ttxdhellmann: feel free to reorganize it, it's your meeting14:18
Kialldhellmann: sure, that works, I'll line things up and let you know ;)14:19
Kiallthansk!14:19
Kiallthanks*14:19
dhellmannKiall: np, thanks for coordinating with us :-)14:19
dhellmannttx: this looks fine, I just wanted to make sure I understood the intent14:19
ttxKiall: stable/kilo would be 1.1.2, master would be 1.3.014:20
ttxI still think master should have a proper Y bump14:20
ttx(current stable/kilo for designateclient is 1.1.1)14:21
dhellmannttx: who should I look to for the API WG discussion? etoews?14:21
ttxyes, he did add that item14:22
dhellmannttx; ok14:22
dhellmannKiall: ttx is right on the version numbers, 1.1.2 and 1.3.014:23
Kialldhellmann: perfect :)14:25
KiallI see where I messed up on that!14:25
*** KA has quit IRC14:38
*** AK has quit IRC14:38
morganfainbergdhellmann: goin to need a branch of KSA soon will ping you with the SHA - this is to support the idea you can install multiple versions side-by-side (we're moving to keystoneauth1 and keystoneauth will be a virtual package that installs all the ksas) future proofing.15:43
dhellmannmorganfainberg: o_O16:24
dhellmannmorganfainberg: wait, we did talk about that, ok16:26
morganfainbergWe did.16:26
*** j^2 has joined #openstack-relmgr-office21:05
*** j^2 has quit IRC22:13
*** dims__ has joined #openstack-relmgr-office22:31
*** dims_ has quit IRC22:34
*** j^2 has joined #openstack-relmgr-office22:56
*** j^2 has quit IRC23:09

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