Tuesday, 2017-08-08

*** emagana has quit IRC00:36
*** emagana has joined #openstack-tc00:37
*** emagana has quit IRC00:41
*** mtreinish has quit IRC02:17
*** mtreinish has joined #openstack-tc02:22
*** david-lyle has quit IRC03:16
*** david-lyle has joined #openstack-tc03:23
ttxWow, nice wall of text. I'll just say that yes, there was a tradition of supporting two deployment cases: CD and release hopping.07:31
ttxI agree with sdague that supporting the CD case helped us having sane, non-user-breaking development policies, and I'd hate to throw that baby with any bath water07:32
ttxBut I also agree with smcginnis/dhellmann that the set of expectations / assurances you get from one model doesn't necessarily have to match the other.07:33
ttxFor example, for security issues, the people doing release hopping get security advisories warning them of that specific patch being present in stable branches. People doing CD are assumed to be doing CD all the time and getting always the latest fixes;07:58
ttxaaaaand, it's office hours time. Feel free to ask TC questions!09:02
* smcginnis passes by09:05
ttxsmcginnis: shouldn't you be sleeping ?09:06
smcginnisttx: Unfortunately I have a flight to catch.09:06
ttxthose things happen09:06
smcginnisThe things I'll do to make sure I can take my preferred airline. ;)09:06
ttxmordred: would be great if you could comment on https://review.openstack.org/#/c/491413/209:57
ttxOtherwise we're still missing a couple of votes on https://review.openstack.org/#/c/440601/ ... If you have objections to it please leave a comment on the review10:03
*** dtantsur|afk is now known as dtantsur10:09
*** cdent has joined #openstack-tc10:47
ttxEarly warning, sounds like the Board+TC+UC meeting on the Sunday in Sydney will start at 11am instead of the usual 2pm.10:50
ttxWorking to get confirmation10:51
openstackgerritDmitry Tantsur proposed openstack/governance master: Refresh Pike goals status for Ironic  https://review.openstack.org/49175410:56
*** sdague has joined #openstack-tc10:59
cdenton “Call for agenda items for the September 10” do we need to put something formally about the “open source education / corporate member engagement / ensuring the right stuff gets worked on” issues we’ve discussed a few different times in this channel? how can we encapsulate that?11:14
ttxcdent: we could -- though I think we won't have much ready before Sydney11:51
cdentttx I wasn’t really thinking about the doing, more simply just the talking11:52
cdentI don’t want to have some kind of polished presentation for the board11:52
cdentI think we need to show up and say, casually, “hey, we think we’e got a problem we’d like to discuss"11:52
ttxcdent: we /could retrofit it in the "closing the feedback loop" workstream since all those streams will be discussed11:53
cdentWhat I’m hoping for is a friendly discussion amongst peers that there’s some stuff to do11:56
mordredttx: on it12:53
mordredttx: I'm confused by that patch12:55
ttxmordred: it's wrong on a number of levels, yes12:59
ttxjohnthetubaguy: is the VM&BM working group still a thing ?13:01
cdentttx: in case johnthetubaguy is not actively around (i don’t think he’s started the new job yet?), I know that he’s talked about wanting it to continue and I agree that it should. If you’re thinking in terms of making it a SIG, makes sense to me.13:02
cdentin fact I’d say it is the ideal case13:03
ttxcdent: that's a question I had actually. My understanding is that the group would coordinate activities across Cinder/Ironic/Nova/Neutron/Glance, which sound very much like a developer coordination thing13:06
mordredttx: reading through the johnthetubaguy text makes me want us to stop using the word "deprecated" and instead borrow RFA and O from debian ...13:07
ttxcdent: rather than a group that would assemble devs/ops/users and everything in between related to the VM&BM use case13:08
ttxBut then I could be totally wrong about what they were up to13:08
cdentin boston, the idea of the group was to maximize the interaction between users/ops/devs who are concerned about those five projects13:10
ttxcdent: then it sounds like a good fit, yes13:11
cdentas I recall john was very concerned with breaking down the somewhat artificial boundaries, especially with regard to feedback loops13:12
*** hongbin has joined #openstack-tc13:47
*** marst has joined #openstack-tc14:05
*** emagana has joined #openstack-tc14:42
*** dtantsur is now known as dtantsur|brb14:44
*** emagana has quit IRC14:52
*** emagana has joined #openstack-tc14:56
*** emagana has quit IRC15:01
*** marst_ has joined #openstack-tc15:26
*** marst has quit IRC15:27
*** dtantsur|brb is now known as dtantsur15:30
*** emagana has joined #openstack-tc15:46
ttxconfirmed the Sydney Board+TC+UC thing will start at 11am:16:15
dimsack thanks ttx16:18
*** emagana has quit IRC16:21
*** emagana_ has joined #openstack-tc16:21
*** dtantsur is now known as dtantsur|afk17:17
*** emagana_ has quit IRC18:25
* mordred apologizes for missing the scrollback and conversation so far on CD ... I am quite opposed to dropping support for CD19:32
mordredthe biggest reason is that OpenStack itself asusming people are going to deploy releases and only releases means that we're going to get lax with dealing with intra-release REST API shifts - which means that deployers who need to cherry-pick something, or who do run something in-between releases will potentially present a hardship to API consumers19:34
mordredopenstack releases are both opaque and meaningless from an API consumption perspective, the only thing that matters is api version information as reported by the API - and anyhting that opens the door to that information becoming less granular even accidentally will make life harder for consumers19:36
mordredbut I clearly have a ton of discussion I've missed in scrollback, so I'll try to catch up - sorry again for missing it19:37
cdentmordred: I think you’ve sussed out the main crux bits.19:47
cdentpeople are thinking about things in terms of interoperating clouds that have apis, have a very identifiable perspective19:48
cdents/are/who are/19:48
mordredok. cool.19:53
cdentwell, maybe not cool, because not everyone has that perspective19:57
*** emagana has joined #openstack-tc20:07
*** emagana_ has joined #openstack-tc20:26
*** emagana has quit IRC20:26
fungittx: if we borrow rfa and o from debian, we should borrow mia as well ;)20:27
fungimordred: for me the key point was that if deployers are going to run code from arbitrary points in master branches "between" major releases, we should have some way of disabling or marking as experimental those api versions which were not present in the prior release and will first "appear" in the next one (from a release perspective) so that they don't unwittingly expose half-baked api features that20:31
fungimight still need adjusting before release time20:31
fungiso that if they want to run an experimental deployment for testing purposes they can totally try out those new features, knowing that there is no stability guarantee, while still having some assurance that established api features will remain identifiable as such and safe to rely on20:32
mordredcdent: I mean "cool" in that at least there was a sussed out main crux bit - not cool as in we've solved it20:34
sdaguefungi: so the issue I have with that statement, is that it actually assumes that lots of projects aren't functioning that way. There is a reason that we put microversion on every API change, not just at release. So your statement actively changes the status quo.20:35
mordredfungi: I hear that - for me the way nova has been doing this works great - a new API feature or behavior change is always behind a microversion, and it's behind one as soon as it lands. if it changes again - it gets a new microversion - it works well from a consume perspective20:36
mordredsdague: jinx20:36
* mtreinish stops typing the same exact thing20:36
mtreinishI'm too slow20:36
fungishould we "burn" microversions for poorly-thought-out behaviors that didn't make it to release, i guess?20:36
sdagueand, I realize that not every project does operate that way, but we should start with describing the constraints of operating in a CD safe way, and see which projects are on board and which aren't20:36
mordredfungi: doesn'tmatter - they're  aversion of a particular call - burning them isn't a big deal20:37
sdaguefungi: we've been doing it for 3 years, it hasn't been an issue20:37
mordredwhere this is still painful is mainly the places where microversions haven't gotten rolled out yet - so I'd rather see us get microversions out more pervassively and make use of the thing that was developed to solve this20:37
fungii'm thinking more in terms of some (not nova) teams that have implemented things even across release boundaries which were never actually complete implementations (and then the vmt gets left holding the bag when someone reports that this feature has being secure as a "todo")20:37
sdagueand not make a statement about all of openstack doing one thing or another, and get a more accurate survey of the world, before we push on something like deprecating CDing20:38
fungiwe could, i guess, take it completely the other direction and say no more partial/in-flux implementations should be approved20:38
sdaguefungi: yeh, I can see that, do you have particular instances to post mortem?20:38
mtreinishfungi: that seems like the real answer20:38
mordredwell - no, I disagree20:38
mordredI think it's still cart before horse20:38
mordredwe have developed a fine-grained signalling mechanism - we need to use it - THEN we can sort out issues with it20:39
mordredsince microversions are opt-in on a per-request basis20:39
fungisdague: hrm... glance allows users to specify arbitrary (and multiple) urls to images, reports "checksums" but never actually verifies that they're correct20:39
mordreda particular microversion for an API call can be marked as experimental in the docs - and a user would have to opt-in to that microversion to get that experimental behavior20:40
mordredfungi: glance also doens't support microversions at all and instead lists multiple api versions for a given major versoin in the version dict but gives no way for the user to select between them20:41
sdaguefungi: yeh, we could do a lot of post mortem on challenges in the glance api20:41
cdentmordred: I agree: we need to use the mechanism20:41
mordredif we could get microversions rolled out to glance, then the new upload api that's now marked 3.7 EXPERIMENTAL could instead be put behind a 3.7 microversion and wouldn't show up for folks who didn't opt-in to it wih a microversion header20:41
fungiin no way do i object to getting a consistent "microversion" (as misleading as that word turned out to be) scheme across api servicves. seems like a great next step20:42
sdaguefungi: you need to get in ahead of me on naming more often :)20:42
fungithat's more a hindsight thing on my part as well20:42
fungiplus, my personal policy on bikeshed-avoidance would get in the way20:43
sdagueyou also get to blame me for big tent, so I'm resigned to not naming anything anymore20:43
mtreinishsdague: I'm not much better. Like I named 2 test runner projects ostestr (and the python package is os-testr) and stestr20:44
*** marst_ has quit IRC20:44
* mordred waves jeepyb in the air20:44
mtreinishoh and take a look at the subunit2sql data schema everything is test, tests, runs, and test_runs20:45
fungimtreinish: at least it wasn't testrsterone20:45
mordredbtw - if I didn't bother you all with this - keystoneauth now supports sending microversion headers - so we now have consistent support in our base rest layer for sending the headers on request20:45
mordredso as we continue to roll out server-side support, the client side piece is there and will send them (and discover which are available and provide that info back)20:46
mtreinishfungi: haha, yeah I guess it could be worse20:46
*** marst has joined #openstack-tc20:55
*** cdent has quit IRC21:01
*** rockyg has joined #openstack-tc21:27
*** emagana_ has quit IRC22:06
*** emagana has joined #openstack-tc22:07
*** emagana has quit IRC22:11
*** emagana has joined #openstack-tc22:23
*** rockyg has quit IRC22:24
*** emagana has quit IRC22:28
*** emagana has joined #openstack-tc22:42
*** marst has quit IRC23:06
*** sdague has quit IRC23:22
*** hongbin has quit IRC23:31

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