Thursday, 2015-05-28

*** asalkeld has left #openstack-relmgr-office00:32
*** dims_ has quit IRC01:35
*** dims_ has joined #openstack-relmgr-office08:02
*** dims_ has quit IRC08:08
*** dims_ has joined #openstack-relmgr-office09:57
*** dims_ has quit IRC11:16
*** dims_ has joined #openstack-relmgr-office11:17
*** dims_ has quit IRC11:28
*** dims_ has joined #openstack-relmgr-office11:28
*** dims_ has quit IRC11:33
*** dims_ has joined #openstack-relmgr-office11:39
*** dims_ has quit IRC13:37
*** dims_ has joined #openstack-relmgr-office13:38
*** david-lyle_ has joined #openstack-relmgr-office14:56
ttxdhellmann: around?15:17
ttxso... crossproject meeting15:42
ttxI could see a point in keeping it if we also used it as a minimal communication point to replace weekly 1:1 syncs15:43
ttxfor us to say things like "remeber liberty-1 is next week"15:44
ttxin addition to discussing random cross-project specs15:44
ttxI know some projects like the idea of having a soapbox to describe achivements15:44
ttxalthough they could use the current meeting to do that and they don't15:45
dhellmannthe oslo team was looking for another outlet, and we thought about setting up a blog. annegentle and reed are going to set things up so we can post to blog.openstack.org, so maybe if more teams use that it can become an official notice channel?15:45
ttxideally all PTLs would be present at least at the beginning of the meeting15:46
ttx(or their delegate)15:46
ttxand stay if the remaining topics are of interest to them15:46
ttxso we could use the start of the meeting for general comms15:46
dhellmannthat makes sense15:47
ttxus and other horizontal teams15:47
ttxI don't thin kthe concept of discussing cross-project specs there is flawed15:47
ttxit's more the concept of cross-project specs that need a bit of rework I think15:47
dhellmannwe need more participation in those discussions, one way or another15:48
ttxright, but removing the last meeting where we all meet doesn't seem to be the best step we can take15:50
ttxI think having more people run that meeting will help finding the right tone/topic15:50
ttxwe should find other candidates to rotate with15:50
dhellmannyeah, I agree that having the meeting still makes sense15:54
dhellmannrotating the chair might help, too, and I'm definitely willing to take that on more this cycle now that I'm not running the Oslo meetings as well15:55
*** david-lyle_ has quit IRC16:16
morganfainbergttx, dhellmann since I see both of you....16:27
morganfainbergAnd I suck at remembering to email people.16:27
ttxdhellmann: if you review https://review.openstack.org/186390 , we could merge it and cut a new version for yaml2ical that would include your extra-settings and unblock that review16:27
morganfainbergMoving keystonemiddleware to the standard 6mo release cycle.16:27
morganfainbergWhen you have a moment.16:27
ttxmorganfainberg: I think dhellmann has run somewhere for an errand16:27
ttxmorganfainberg: I don't think that woud cause crazy issues on our side16:28
morganfainbergRight. I just want to start making it happen and figure out the plan.16:28
ttxmorganfainberg: but I think you should start a thread about that on the ML, because I feel like there might be some resistance to the concept16:28
ttxso better explain it in written form16:28
morganfainbergSince it is unreasonable to assume ksm from say grizzly can run on Juno.16:28
morganfainbergThere was a ML thread. The only comment was from lifeless asking about semver and requirements issues.16:29
ttxoh, ok16:29
morganfainbergWe did the leg work for general approval at the end of kilo.16:30
ttxmorganfainberg: to support intermediary releases we talked about denormalizing version numbers for stuff that is released on a 6-month cadence16:30
morganfainbergOk.16:30
ttxmorganfainberg: so it's not totally crazy to think that what you need to do is refrain from tagging final releases16:31
morganfainbergWe can keep using semver if we want. And just do the swift-ish releases per milestone, but just track per named release in stead of "whenever"16:31
ttxso you are at 1.6.1, you could do 1.7.0b1, 1.7.0b2.. 1.7.0rc1 and 1.7.016:32
morganfainbergSounds good.16:32
morganfainbergI'll also propose the governance chant to indicate it isn't independent releases?16:33
ttxI'll give it another thought tomorrow. I bet dhellmann will have a poke at the idea when he comes back, too16:33
ttxmorganfainberg: yes, that would go with it16:33
morganfainbergYeah. Let me know after mulling on it / chatting with dhellmann16:33
ttxwe migth need to do some setup.cfg version to make pbr use preversioning16:34
morganfainbergI'll also have a take away that we need to update he docs to say "this only works with its coinciding release" once we do that.16:34
ttxso that the versions built are more 1.7.0-alphas than 1.6.1.0.124416:34
morganfainbergTtx++. I also think there is a test change we will need to make. But I'll poke at that front as we get there.16:35
ttxmorganfainberg: the only drawback of this approach is that you lose the sync with keystone version number16:35
ttxmorganfainberg: is the middleware release tied to keystone release ? Or to the series in general ?16:36
ttxthat would be the only reason to jump to keystone version as the next (so jump to 2015.2.0b1 at liberty-1)16:36
morganfainbergSeries.16:36
morganfainbergNot to keystone b16:36
ttxI mean, both would work16:36
morganfainbergMiddleware runs in the process space of nova etc. keystone version is fairly independent.16:37
morganfainbergKsm mostly works with any keystone version. Since keystone has its own special middleware.16:37
morganfainbergCan't do a rest call to itself to lookup in the DB information.16:38
ttxok, then it might not make sense to jump to align to keystone version, especially with swift and ironic likely to diverge soon16:38
ttxI think it makes sense to switch to 1.7.0 preversions16:38
ttxand tag betas and all16:39
morganfainbergttx: I would try and diverge keystone itself but I think it would cause hell.16:39
ttxok, need to run16:39
morganfainbergOk will bug dhellmann about my other client release question later on. Thanks and cheers16:39
ttxcheers16:40
*** sileht has quit IRC16:47
*** david-lyle_ has joined #openstack-relmgr-office17:09
*** david-lyle_ has quit IRC17:18
*** sileht has joined #openstack-relmgr-office17:27
morganfainbergdhellmann: you around. Have a question about keystoneclient. I seem to have misplaced a release. And want to make sure I didn't miss something important.21:17
morganfainbergdhellmann: we have a 1.4.0 tagged already. Was that you when you setup Liberty (you/ttx that is)21:17
morganfainbergTrying to cut the next release but unsure where 1.4.0 came from. I guess I can poke at the signature on the tag as well.21:18
dhellmannmorganfainberg, ttx: we had a *lot* of resistance to using alphas, and it's quite likely that some of our release tools no longer work with them now. Is there any reason not to treat the middlware as we do other libraries, with intermediate releases and stable branches at the end of cycles?21:30
dhellmannmorganfainberg: yeah, I tagged 1.4.0 on 21 Apr21:30
morganfainbergdhellmann: great I'll close that milestone and 1.5.0 for the next release.21:31
dhellmannmorganfainberg: I think when I did those, I told the script to ignore the milestones in lp because many projects didn't have them21:31
morganfainbergFor the middleware I want to clearly make it not a "library" because it really is insane to expect a Juno middleware to run in Liberty.21:32
dhellmannI'll be updating that script to create new milestones, now that we're not doing predictive tracking for releases21:32
dhellmannmorganfainberg: you can control that with dependency specifications though, can't you?21:32
morganfainbergYeah. I will likely just do a per-milestone release with a specific release at the end of the cycle.21:32
morganfainbergIf the alphas are bad.21:32
morganfainbergIt was more of a "do it the best way to coordinate it" and make your lives easier.21:33
dhellmannyeah21:33
dhellmanndo you ever want a kilo middleware to run in a juno environment?21:33
morganfainbergAt this point. No.21:33
dhellmanncool21:33
morganfainbergThe keystone api should never move in a way that breaks people with that in mind.21:34
dhellmannso if you have the apps specify the version of the middleware for the current cycle, you can just treat it like we do an oslo lib and make intermediate releases with stable branches at the end of the cycle21:34
morganfainbergMidldeware is more closely lined with the services that use it rather than to keystone.21:34
morganfainberg++ works for me.21:34
dhellmannyay, consistency! :-)21:34
morganfainbergAlso we are going to 2.0.0 keystoneclient this cycle.21:35
morganfainbergI'll bug you as we get closer.21:35
morganfainbergBut we are doing that when we start depending on keystoneauth and will likely drop CLI at the same time.21:36
morganfainbergAnd the bit rotting middleware in the ksc package will also drop (i can't even tell you if it works now with modern servers)21:36
morganfainbergBut I'll coordinate with you prior to making that release so we can head off icky-ness as it pops up.21:37
*** dims_ has quit IRC23:17
*** dims_ has joined #openstack-relmgr-office23:20

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