| *** emagana has quit IRC | 00:36 | |
| *** emagana has joined #openstack-tc | 00:37 | |
| *** emagana has quit IRC | 00:41 | |
| *** mtreinish has quit IRC | 02:17 | |
| *** mtreinish has joined #openstack-tc | 02:22 | |
| *** david-lyle has quit IRC | 03:16 | |
| *** david-lyle has joined #openstack-tc | 03:23 | |
| ttx | Wow, 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 |
|---|---|---|
| ttx | I 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 water | 07:32 |
| ttx | But 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 |
| ttx | For 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 |
| ttx | aaaaand, it's office hours time. Feel free to ask TC questions! | 09:02 |
| * smcginnis passes by | 09:05 | |
| ttx | smcginnis: shouldn't you be sleeping ? | 09:06 |
| smcginnis | ttx: Unfortunately I have a flight to catch. | 09:06 |
| ttx | those things happen | 09:06 |
| smcginnis | The things I'll do to make sure I can take my preferred airline. ;) | 09:06 |
| ttx | mordred: would be great if you could comment on https://review.openstack.org/#/c/491413/2 | 09:57 |
| ttx | Otherwise 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 review | 10:03 |
| *** dtantsur|afk is now known as dtantsur | 10:09 | |
| *** cdent has joined #openstack-tc | 10:47 | |
| ttx | Early warning, sounds like the Board+TC+UC meeting on the Sunday in Sydney will start at 11am instead of the usual 2pm. | 10:50 |
| ttx | Working to get confirmation | 10:51 |
| openstackgerrit | Dmitry Tantsur proposed openstack/governance master: Refresh Pike goals status for Ironic https://review.openstack.org/491754 | 10:56 |
| *** sdague has joined #openstack-tc | 10:59 | |
| cdent | on “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 |
| ttx | cdent: we could -- though I think we won't have much ready before Sydney | 11:51 |
| cdent | ttx I wasn’t really thinking about the doing, more simply just the talking | 11:52 |
| cdent | I don’t want to have some kind of polished presentation for the board | 11:52 |
| cdent | I think we need to show up and say, casually, “hey, we think we’e got a problem we’d like to discuss" | 11:52 |
| ttx | cdent: we /could retrofit it in the "closing the feedback loop" workstream since all those streams will be discussed | 11:53 |
| cdent | What I’m hoping for is a friendly discussion amongst peers that there’s some stuff to do | 11:56 |
| mordred | ttx: on it | 12:53 |
| mordred | ttx: I'm confused by that patch | 12:55 |
| ttx | mordred: it's wrong on a number of levels, yes | 12:59 |
| ttx | johnthetubaguy: is the VM&BM working group still a thing ? | 13:01 |
| cdent | ttx: 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 |
| cdent | in fact I’d say it is the ideal case | 13:03 |
| ttx | cdent: 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 thing | 13:06 |
| mordred | ttx: 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 |
| ttx | cdent: rather than a group that would assemble devs/ops/users and everything in between related to the VM&BM use case | 13:08 |
| ttx | But then I could be totally wrong about what they were up to | 13:08 |
| cdent | in boston, the idea of the group was to maximize the interaction between users/ops/devs who are concerned about those five projects | 13:10 |
| ttx | cdent: then it sounds like a good fit, yes | 13:11 |
| cdent | as I recall john was very concerned with breaking down the somewhat artificial boundaries, especially with regard to feedback loops | 13:12 |
| *** hongbin has joined #openstack-tc | 13:47 | |
| *** marst has joined #openstack-tc | 14:05 | |
| *** emagana has joined #openstack-tc | 14:42 | |
| *** dtantsur is now known as dtantsur|brb | 14:44 | |
| *** emagana has quit IRC | 14:52 | |
| *** emagana has joined #openstack-tc | 14:56 | |
| *** emagana has quit IRC | 15:01 | |
| *** marst_ has joined #openstack-tc | 15:26 | |
| *** marst has quit IRC | 15:27 | |
| *** dtantsur|brb is now known as dtantsur | 15:30 | |
| *** emagana has joined #openstack-tc | 15:46 | |
| ttx | confirmed the Sydney Board+TC+UC thing will start at 11am: | 16:15 |
| ttx | https://wiki.openstack.org/wiki/Governance/Foundation/5Nov2017BoardMeeting | 16:16 |
| dims | ack thanks ttx | 16:18 |
| *** emagana has quit IRC | 16:21 | |
| *** emagana_ has joined #openstack-tc | 16:21 | |
| *** dtantsur is now known as dtantsur|afk | 17:17 | |
| *** emagana_ has quit IRC | 18:25 | |
| * mordred apologizes for missing the scrollback and conversation so far on CD ... I am quite opposed to dropping support for CD | 19:32 | |
| mordred | the 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 consumers | 19:34 |
| mordred | openstack 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 consumers | 19:36 |
| mordred | but I clearly have a ton of discussion I've missed in scrollback, so I'll try to catch up - sorry again for missing it | 19:37 |
| cdent | mordred: I think you’ve sussed out the main crux bits. | 19:47 |
| cdent | people are thinking about things in terms of interoperating clouds that have apis, have a very identifiable perspective | 19:48 |
| cdent | s/are/who are/ | 19:48 |
| mordred | ok. cool. | 19:53 |
| cdent | well, maybe not cool, because not everyone has that perspective | 19:57 |
| *** emagana has joined #openstack-tc | 20:07 | |
| *** emagana_ has joined #openstack-tc | 20:26 | |
| *** emagana has quit IRC | 20:26 | |
| fungi | ttx: if we borrow rfa and o from debian, we should borrow mia as well ;) | 20:27 |
| fungi | mordred: 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 that | 20:31 |
| fungi | might still need adjusting before release time | 20:31 |
| fungi | so 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 on | 20:32 |
| mordred | cdent: I mean "cool" in that at least there was a sussed out main crux bit - not cool as in we've solved it | 20:34 |
| cdent | ✔ | 20:35 |
| sdague | fungi: 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 |
| mordred | fungi: 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 perspective | 20:36 |
| mordred | sdague: jinx | 20:36 |
| * mtreinish stops typing the same exact thing | 20:36 | |
| mtreinish | I'm too slow | 20:36 |
| fungi | should we "burn" microversions for poorly-thought-out behaviors that didn't make it to release, i guess? | 20:36 |
| sdague | and, 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't | 20:36 |
| mordred | fungi: doesn'tmatter - they're aversion of a particular call - burning them isn't a big deal | 20:37 |
| sdague | fungi: we've been doing it for 3 years, it hasn't been an issue | 20:37 |
| mordred | where 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 this | 20:37 |
| fungi | i'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 |
| sdague | and 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 CDing | 20:38 |
| fungi | we could, i guess, take it completely the other direction and say no more partial/in-flux implementations should be approved | 20:38 |
| sdague | fungi: yeh, I can see that, do you have particular instances to post mortem? | 20:38 |
| mtreinish | fungi: that seems like the real answer | 20:38 |
| mordred | well - no, I disagree | 20:38 |
| mordred | I think it's still cart before horse | 20:38 |
| mordred | we have developed a fine-grained signalling mechanism - we need to use it - THEN we can sort out issues with it | 20:39 |
| mordred | since microversions are opt-in on a per-request basis | 20:39 |
| fungi | sdague: hrm... glance allows users to specify arbitrary (and multiple) urls to images, reports "checksums" but never actually verifies that they're correct | 20:39 |
| mordred | a 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 behavior | 20:40 |
| mordred | fungi: 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 them | 20:41 |
| sdague | fungi: yeh, we could do a lot of post mortem on challenges in the glance api | 20:41 |
| cdent | mordred: I agree: we need to use the mechanism | 20:41 |
| mordred | if 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 header | 20:41 |
| fungi | in 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 step | 20:42 |
| sdague | fungi: you need to get in ahead of me on naming more often :) | 20:42 |
| fungi | that's more a hindsight thing on my part as well | 20:42 |
| fungi | plus, my personal policy on bikeshed-avoidance would get in the way | 20:43 |
| sdague | you also get to blame me for big tent, so I'm resigned to not naming anything anymore | 20:43 |
| mtreinish | sdague: I'm not much better. Like I named 2 test runner projects ostestr (and the python package is os-testr) and stestr | 20:44 |
| *** marst_ has quit IRC | 20:44 | |
| * mordred waves jeepyb in the air | 20:44 | |
| mtreinish | oh and take a look at the subunit2sql data schema everything is test, tests, runs, and test_runs | 20:45 |
| fungi | mtreinish: at least it wasn't testrsterone | 20:45 |
| mordred | btw - 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 request | 20:45 |
| mordred | so 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 |
| mtreinish | fungi: haha, yeah I guess it could be worse | 20:46 |
| *** marst has joined #openstack-tc | 20:55 | |
| *** cdent has quit IRC | 21:01 | |
| *** rockyg has joined #openstack-tc | 21:27 | |
| *** emagana_ has quit IRC | 22:06 | |
| *** emagana has joined #openstack-tc | 22:07 | |
| *** emagana has quit IRC | 22:11 | |
| *** emagana has joined #openstack-tc | 22:23 | |
| *** rockyg has quit IRC | 22:24 | |
| *** emagana has quit IRC | 22:28 | |
| *** emagana has joined #openstack-tc | 22:42 | |
| *** marst has quit IRC | 23:06 | |
| *** sdague has quit IRC | 23:22 | |
| *** hongbin has quit IRC | 23:31 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!