| *** AzherKhan has joined #openstack-relmgr-office | 00:19 | |
| *** AzherKhan has quit IRC | 00:21 | |
| *** AzherKhan has joined #openstack-relmgr-office | 00:31 | |
| *** AzherKhan has quit IRC | 01:00 | |
| *** AzherKhan has joined #openstack-relmgr-office | 01:00 | |
| *** Khaazher has joined #openstack-relmgr-office | 01:01 | |
| *** AzherKhan has quit IRC | 01:01 | |
| *** Khaazher has quit IRC | 01:16 | |
| *** thingee has quit IRC | 01:35 | |
| *** thingee has joined #openstack-relmgr-office | 01:41 | |
| *** AzherKhan has joined #openstack-relmgr-office | 02:31 | |
| *** AK has joined #openstack-relmgr-office | 02:31 | |
| *** dims___ has quit IRC | 02:48 | |
| *** dims_ has joined #openstack-relmgr-office | 03:48 | |
| *** dims_ has quit IRC | 03:53 | |
| *** david-lyle has quit IRC | 04:24 | |
| *** david-lyle has joined #openstack-relmgr-office | 04:25 | |
| *** dims_ has joined #openstack-relmgr-office | 06:37 | |
| *** dims_ has quit IRC | 06:42 | |
| ttx | ohai, starting office hours on this channel | 08: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 | |
| ttx | Grabbing coffee, brb | 08:07 |
| ttx | back | 08:13 |
| *** dims_ has joined #openstack-relmgr-office | 09:26 | |
| *** dims_ has quit IRC | 09:31 | |
| *** dims_ has joined #openstack-relmgr-office | 10:55 | |
| *** AK has quit IRC | 11:07 | |
| *** AzherKhan has quit IRC | 11:07 | |
| *** Kiall_ is now known as Kiall | 11:37 | |
| ttx | dhellmann: 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 pain | 12:53 |
| Kiall | ttx: 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/34d14b06d91b3d2e90d6531972bc25b8a8de53ab | 13:15 |
| Kiall | So.. 1) If we release this off the master branch, what version should we pick? | 13:15 |
| Kiall | 2) Can we backport to stable/kilo, and what version should we pick? | 13:15 |
| Kiall | I 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 IRC | 13:51 | |
| *** dims_ has joined #openstack-relmgr-office | 13:51 | |
| ttx | Kiall: ohai | 13:53 |
| Kiall | Heya | 13:54 |
| ttx | Still trying to wrap my head around an API change necessary to work with a Keystone session.... Didn't that work before ? | 13:54 |
| Kiall | Kinda.. 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 |
| ttx | If the API change is purely additive (not breaking) bumping the Y in X.Y.Z on master sounds like the right call | 13:55 |
| ttx | I'd say that this is inappropriate for a stable backport, but could use dhellmann's view on it | 13:56 |
| Kiall | It's breaking as is, it could be made backwards compat I guess though | 13:56 |
| Kiall | Let'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 |
| ttx | I don't think that would be appropriate for a stable/kilo .Z bump, since it changes the API | 13:59 |
| ttx | basically on master you can make semver X, Y or Z bumps | 13:59 |
| ttx | on stable/kilo it should only be .Z bumps | 14:00 |
| Kiall | Well, 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 |
| ttx | let'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 case | 14:01 |
| * dhellmann perks up his ears | 14:01 | |
| ttx | Kiall: users are supposed to use the master version anyway | 14:02 |
| dhellmann | ttx: sure, I can run the meeting today. Do you have an agenda put together? | 14:02 |
| ttx | Yes, Let me finalize it with your name on it | 14:02 |
| ttx | and I can send the agenda email | 14:02 |
| dhellmann | Kiall: is that work necessary to talk to a kilo cloud? | 14:03 |
| dhellmann | or, rather, is it necessary for the services within a kilo cloud to talk to each other? | 14:03 |
| ttx | dhellmann: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- first meeting with space for the horizontal / vertical teams announcements | 14:04 |
| ttx | I'll send an email to list about it | 14:05 |
| Kiall | dhellmann: 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 designateclient | 14:05 |
| Kiall | The fact that it got in like that at all was a eh.. mess up... | 14:05 |
| dhellmann | ttx: do you already have a list of folks who need a courtesy ping for that meeting, or should I put one together? | 14:07 |
| dhellmann | Kiall: so the kilo version of designateclient doesn't work with the kilo version of horizon? | 14:08 |
| *** KA has joined #openstack-relmgr-office | 14:08 | |
| *** AK has joined #openstack-relmgr-office | 14:08 | |
| ttx | dhellmann: I have one, but it's incomplete | 14:09 |
| ttx | I can courtesy-ping myself at the end of the TC meeting, and you can copypaste it | 14:09 |
| Kiall | Yea, now it's a tag murkey there in that our panels aren't baked into Horizon, but the panels tagged kilo don't | 14:09 |
| dhellmann | ttx: or you could throw it into my script at https://etherpad.openstack.org/p/cross-project-agenda | 14:09 |
| Kiall | tad* | 14:09 |
| dhellmann | ttx: either way | 14:09 |
| ttx | ok, throwing it in | 14:10 |
| dhellmann | Kiall: ok, it seems like this should probably be backported, then. | 14:11 |
| ttx | dhellmann: and still use a .Z bump under the "oops we really messed up kilo" exception rule ? | 14:12 |
| Kiall | Yea, 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 |
| ttx | Kiall: 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 process | 14:13 |
| ttx | and apply process paste onto it liberally | 14:13 |
| Kiall | ttx: Sure, I'm happy to hand that over once you / stable-maint and happy to handle it! | 14:14 |
| Kiall | s/and/are/ | 14:14 |
| dhellmann | Kiall: is the change going to be backwards compatible with existing client users? | 14:14 |
| Kiall | dhellmann: it will be in a few mins! | 14:14 |
| dhellmann | Kiall: ok, if it's API compatible with the existing kilo release a z bump is ok | 14:14 |
| dhellmann | ttx: in the agenda, by "vertical teams" you mean project teams like nova, right? | 14:17 |
| ttx | yep, I explained that much on the announcement email I just sent to dev | 14:17 |
| Kiall | dhellmann: 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 client | 14:18 | |
| ttx | dhellmann: it's basically a clearer "open discussion" | 14:18 |
| dhellmann | Kiall: they do need to be tagged separately, but the timing is up to you | 14:18 |
| dhellmann | Kiall: if you send me shas for each branch, I can tag them for you | 14:18 |
| Kiall | Sure.. I'm mostly wondering if the version #'s I suggested are correct? :) | 14:18 |
| ttx | dhellmann: feel free to reorganize it, it's your meeting | 14:18 |
| Kiall | dhellmann: sure, that works, I'll line things up and let you know ;) | 14:19 |
| Kiall | thansk! | 14:19 |
| Kiall | thanks* | 14:19 |
| dhellmann | Kiall: np, thanks for coordinating with us :-) | 14:19 |
| dhellmann | ttx: this looks fine, I just wanted to make sure I understood the intent | 14:19 |
| ttx | Kiall: stable/kilo would be 1.1.2, master would be 1.3.0 | 14:20 |
| ttx | I still think master should have a proper Y bump | 14:20 |
| ttx | (current stable/kilo for designateclient is 1.1.1) | 14:21 |
| dhellmann | ttx: who should I look to for the API WG discussion? etoews? | 14:21 |
| ttx | yes, he did add that item | 14:22 |
| dhellmann | ttx; ok | 14:22 |
| dhellmann | Kiall: ttx is right on the version numbers, 1.1.2 and 1.3.0 | 14:23 |
| Kiall | dhellmann: perfect :) | 14:25 |
| Kiall | I see where I messed up on that! | 14:25 |
| *** KA has quit IRC | 14:38 | |
| *** AK has quit IRC | 14:38 | |
| morganfainberg | dhellmann: 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 |
| dhellmann | morganfainberg: o_O | 16:24 |
| dhellmann | morganfainberg: wait, we did talk about that, ok | 16:26 |
| morganfainberg | We did. | 16:26 |
| *** j^2 has joined #openstack-relmgr-office | 21:05 | |
| *** j^2 has quit IRC | 22:13 | |
| *** dims__ has joined #openstack-relmgr-office | 22:31 | |
| *** dims_ has quit IRC | 22:34 | |
| *** j^2 has joined #openstack-relmgr-office | 22:56 | |
| *** j^2 has quit IRC | 23:09 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!