| *** hongbin has quit IRC | 00:14 | |
| *** gcb has joined #openstack-tc | 01:29 | |
| *** liujiong has joined #openstack-tc | 01:39 | |
| *** harlowja has quit IRC | 03:22 | |
| *** gcb has quit IRC | 03:42 | |
| *** harlowja has joined #openstack-tc | 04:01 | |
| *** gcb has joined #openstack-tc | 04:46 | |
| *** lbragstad has quit IRC | 04:58 | |
| *** kumarmn has quit IRC | 05:34 | |
| *** harlowja has quit IRC | 05:52 | |
| openstackgerrit | Masahito Muroi proposed openstack/governance master: Update Blazar's document references https://review.openstack.org/521719 | 06:08 |
|---|---|---|
| *** dtantsur|afk is now known as dtantsur | 07:01 | |
| *** gcb has quit IRC | 08:12 | |
| *** gcb has joined #openstack-tc | 08:13 | |
| *** gcb has quit IRC | 08:19 | |
| *** gcb has joined #openstack-tc | 08:19 | |
| flaper87 | o/ | 09:02 |
| flaper87 | tc-members: office hour ? | 09:03 |
| * flaper87 wonders who's around | 09:03 | |
| cmurphy | o/ | 09:03 |
| * cmurphy back in the right timezone | 09:03 | |
| flaper87 | I know ttx is at OSDays France | 09:03 |
| flaper87 | cmurphy: yahooooo! | 09:03 |
| * cmurphy also at osd france | 09:04 | |
| cmurphy | so still in the wrong country | 09:04 |
| flaper87 | cmurphy: nice, how is that going? | 09:04 |
| cmurphy | flaper87: they are speaking in french so i have no idea :P | 09:05 |
| flaper87 | I was planning to go but I figured that I could use some time at home | 09:05 |
| flaper87 | cmurphy: lol | 09:05 |
| cmurphy | ttx was nice enough to give his keynote in english | 09:06 |
| *** jpich has joined #openstack-tc | 09:07 | |
| *** tdasilva has quit IRC | 09:09 | |
| *** tdasilva has joined #openstack-tc | 09:15 | |
| *** dtantsur_ has joined #openstack-tc | 09:21 | |
| *** dtantsur has quit IRC | 09:22 | |
| *** dtantsur_ is now known as dtantsur | 09:22 | |
| * johnthetubaguy wonders in a bit late to see who is around | 09:22 | |
| * cmurphy waves | 09:24 | |
| * johnthetubaguy waves back | 09:29 | |
| *** cdent has joined #openstack-tc | 09:30 | |
| * smcginnis waves | 10:06 | |
| *** liujiong has quit IRC | 10:10 | |
| * cdent waves at smcginnis | 10:11 | |
| * cdent calendar checks | 10:11 | |
| cdent | mleh | 10:12 |
| *** kumarmn has joined #openstack-tc | 10:38 | |
| *** kumarmn has quit IRC | 10:43 | |
| ttx | bleh | 11:01 |
| ttx | I'll be a bit late in updating the the tracker today | 11:10 |
| *** kumarmn has joined #openstack-tc | 11:39 | |
| *** kumarmn has quit IRC | 11:44 | |
| *** sdague has joined #openstack-tc | 12:08 | |
| *** gcb has quit IRC | 12:18 | |
| *** kumarmn has joined #openstack-tc | 13:41 | |
| *** kumarmn has quit IRC | 13:45 | |
| openstackgerrit | Merged openstack/governance master: Add policy artifacts for Freezer https://review.openstack.org/518738 | 13:47 |
| ttx | tracker updated | 14:03 |
| cdent | ttx++ | 14:03 |
| cdent | I’m still wading through a massive backlog of $stuff, haven’t had much chance to think about any governance related stuff :( | 14:04 |
| ttx | yeah same for me tbh | 14:05 |
| ttx | traveling again this week doesn't help | 14:06 |
| *** mriedem_away is now known as mriedem | 14:20 | |
| *** lbragstad has joined #openstack-tc | 14:24 | |
| *** zaneb has joined #openstack-tc | 14:25 | |
| *** kumarmn has joined #openstack-tc | 14:37 | |
| *** kumarmn has quit IRC | 14:42 | |
| *** rosmaita has joined #openstack-tc | 14:43 | |
| openstackgerrit | Pavlo Shchelokovskyy proposed openstack/governance master: Add networking-generic-switch under ironic https://review.openstack.org/521894 | 15:24 |
| *** rosmaita has quit IRC | 15:29 | |
| *** kumarmn has joined #openstack-tc | 15:38 | |
| *** kumarmn has quit IRC | 15:42 | |
| *** marst has joined #openstack-tc | 16:00 | |
| cdent | Sigh. I feel like we have a real opportunity to change attitudes towards reviews, QA, and openstack in general by _not_ maintaining the status quo with regard to https://review.openstack.org/#/c/521602/ | 16:34 |
| cdent | doing something a particular way because that’s the way it was done before isn’t always right | 16:34 |
| dhellmann | cdent : which option do you prefer? | 16:37 |
| cdent | dhellmann: ideally 3, but it would mean pretty much everyone having to change how they work to some extent, which makes it feel least likely. But in part that changing is a big factor in why I like it: nobody gets left to not change, everyone has to, and in the process everyone is engaged in improvement/adjustment. | 16:39 |
| cdent | If 3 can’t happen, then I’m not really sure. | 16:39 |
| dhellmann | another option proposed in the past was for the interop group to maintain their own set of tests. The reasons given for doing that were that they didn't like some of the specific tests being used or some changes that were made or something -- basically someone got angry at the QA team. | 16:40 |
| cdent | I think many small repos is a better way to have dissolution of boundaries between things | 16:40 |
| dhellmann | I'm a bit worried 3 would turn into that, since project teams already have to deal with the tempest repo for the integrated gate test jobs | 16:41 |
| cdent | why is it bad for interop group to maintain their own tests? (not saying it’s not just wonder what the reasons given in the past) | 16:42 |
| dhellmann | in my mind it's a question of where the reviewers for these things come from. If we're going to train the entire community to be effective reviewers for trademark-tagged tests, then spreading them out makes sense. If we think there is more likely to be a small team interested in the issues around those special tests, having one repo makes more sense. | 16:42 |
| dhellmann | because there was no real plan to gate projects on those tests | 16:43 |
| dhellmann | so we'd have the tests used to verify the product works and the tests used to verify trademarks and they would diverge | 16:43 |
| cdent | based on my conversation with mark, creating and reviewing tests is not a huge issue, except when a new project joins the trademarks | 16:43 |
| cdent | instead they select existing tests | 16:44 |
| dhellmann | I thought we had issues in the past where tests changed in a way that made existing deployments no longer pass the interop guidelines | 16:44 |
| cdent | That (selecting) seems a bit awkward to me | 16:44 |
| cdent | yeah, that | 16:44 |
| cdent | it would be great to have explicit tests for explicit things | 16:44 |
| dhellmann | yeah, the process for that feels painful. I'm not worried about new tests. I'm worried about not breaking things once they enter this use case. | 16:44 |
| cdent | It is perhaps effortful to make explicit stuff and it would mean some duplication, but getting meaningful stuff often requires that | 16:45 |
| mugsie | what is the boundary for projects that have tests in tempest and in a plugin (like neutron)? how do they decide what goes in core tempest, and what is in the plugin? | 16:45 |
| cdent | indeed | 16:46 |
| dhellmann | mugsie : my understanding is that tests related to integration with other projects go into tempest and functional tests not related to that integration go elsewhere | 16:46 |
| dhellmann | so that's a technical distinction that at least makes sense | 16:46 |
| mugsie | Ah, that would make sense | 16:46 |
| dhellmann | the stuff in tempest is supposed to be about testing the integrated gate, and we took advantage of the fact that all of the interop tests up to this point where related to those projects | 16:47 |
| mugsie | Although there is at least one test being written right now that should go into tempest then. | 16:47 |
| cdent | there has been some noise of making an ‘intergrated-core-tempest-plugin’ but that got the “that’s what tempest alraedy is” response | 16:47 |
| * mugsie will look in to that | 16:47 | |
| dhellmann | cdent : right | 16:47 |
| mugsie | My preference is 3 > 1 > 2 - but I didn't want to do all the work to add designate to tempest (for option 1) to have it -2'd | 16:49 |
| dhellmann | it makes sense to review the decision of where to put these things, but I don't want to see us make a decision that somehow introduces a lot more work for us | 16:49 |
| dhellmann | mugsie : are there good review guidelines for the interop tests somewhere? | 16:49 |
| mugsie | not too my knowledge | 16:50 |
| mugsie | to* | 16:50 |
| mugsie | I think it is relying on the QA being the core team to have good reviews | 16:50 |
| dhellmann | that feels like a prerequisite to splitting anything out or allowing teams to manage the tests themselves | 16:50 |
| * TheJulia reads discussion | 16:50 | |
| dhellmann | because my impression is that the rule is the tests really can't change at all under any circumstances, although that's probably harsher than reality | 16:51 |
| mugsie | and, I think if we do move the tests to plugins, or have only optional tests as plugins we need to make sure we set up gating on tempest to avoid breakages | 16:51 |
| dhellmann | unfortunately I don't remember exactly what the situation was where a change did break things. maybe mtreinish remembers. | 16:51 |
| mugsie | I do - the stable API was broken while we were in Denver, and it took us the best part of a week to get get it resloved | 16:52 |
| dhellmann | mugsie : good point. we'd need to describe all of that as part of reverting the existing test location policy | 16:52 |
| mugsie | or the additionalProperties change to nova broke the InterOp tests for some people as well | 16:52 |
| dhellmann | I think this was farther back than that. I thought it had something to do with underlying behavior of the test, rather than the actual API calls | 16:52 |
| mtreinish | dhellmann: yeah it was not allowing additional properties in nova | 16:53 |
| dhellmann | maybe I'm confusing this issue with the thing oracle had not being able to boot linux | 16:53 |
| dhellmann | mtreinish : was that rax that had that issue? | 16:53 |
| mugsie | oh, yeah that was not a breakage, but it blocked Oracle from getting trademark status afaik | 16:53 |
| mtreinish | yep, rax and one of huawei's products | 16:53 |
| dhellmann | yeah, ok, that's coming back now | 16:54 |
| dhellmann | thanks, mtreinish | 16:54 |
| dhellmann | how was that resolved? | 16:54 |
| mugsie | we still allow additionalProperties in InterOp tests :) | 16:55 |
| *** dtantsur is now known as dtantsur|afk | 16:55 | |
| mtreinish | dhellmann: interop gave them an additional 6 months to fix it (which of course they didn't) | 16:55 |
| mugsie | I think it is being removed this time though | 16:55 |
| mtreinish | and then forgot to remove the waiver | 16:55 |
| mtreinish | it's finally being removed for the 2018.1 guideline | 16:55 |
| dhellmann | ok | 16:55 |
| mtreinish | dhellmann: https://review.openstack.org/#/c/512447/ | 16:56 |
| dhellmann | and what would have been the ideal way to avoid that turning into an issue? change the interop guidelines somehow first? Or with more coordination? | 16:56 |
| mtreinish | dhellmann: it was a case of companies not wanting to do anything to adjust. (which is why they still fail) There was a ton of coordination and communication and this was a known thing coming for > 1yr before it became an issue | 16:57 |
| dhellmann | ok, so it was pushback from downstream rather than some sort of miscommunication | 16:58 |
| dhellmann | I guess the ideal thing would have been to have that flag set the way we wanted it before the interop guidelines went into effect :-) | 16:59 |
| *** openstackstatus has joined #openstack-tc | 17:00 | |
| *** ChanServ sets mode: +v openstackstatus | 17:00 | |
| mtreinish | to be fair, the change flipping the jsonschema flag was proposed before the interop program was started, it just took 6 months for the patch to land :) | 17:00 |
| dhellmann | heh | 17:00 |
| dhellmann | so we're back to having to solve our review bandwidth/throughput problem in order to fix anything! :-) | 17:00 |
| dhellmann | so, how would we have resolved the problem if the test had been in a plugin under a single project team's purview instead of in tempest? | 17:01 |
| mtreinish | tbh, I would assume in the same way. But, it would really depend on the project team I guess | 17:05 |
| dhellmann | yeah, I guess a lot would depend on that team's engagement with the trademark program and their understanding of the need for flexibility there | 17:17 |
| *** purplerbot has quit IRC | 17:18 | |
| *** purplerbot has joined #openstack-tc | 17:18 | |
| *** rosmaita has joined #openstack-tc | 17:35 | |
| *** hongbin has joined #openstack-tc | 17:58 | |
| *** david-lyle has quit IRC | 18:09 | |
| *** david-lyle has joined #openstack-tc | 18:09 | |
| *** jpich has quit IRC | 18:23 | |
| *** stevemar has left #openstack-tc | 18:34 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: add/update documentation links https://review.openstack.org/521987 | 19:15 |
| *** marst has quit IRC | 19:20 | |
| SamYaple | question for the TC about deployment projects. ive been on-and-off playing with a super-opinionated super-secure openstack deployment for a while. is there room for that in openstack offical? im talking one backend (ceph), one distro (ubuntu), rewritten apparmor profiles, written rootwrap-filters, tls everything | 19:44 |
| SamYaple | without being so opinionated it would be hard to maintain all ofthat | 19:44 |
| *** cdent has quit IRC | 20:00 | |
| smcginnis | SamYaple: I find that interesting at least. | 20:21 |
| dhellmann | SamYaple : how do you see that as different from triplo, osa, puppet, chef, etc. in terms of "acceptability"? | 20:38 |
| SamYaple | dhellmann: i guess i should have added "duplicate" in some form. to do the security the way i would need to there needs to be a degree of automation, and i dont plan on writing that myself but rather hooking into kubernetes | 20:47 |
| SamYaple | so it would be yet another kubernetes deploy | 20:47 |
| SamYaple | but with a very narrow scope. im just not sure on the exact feelings of duplicate projects | 20:48 |
| dhellmann | in the past deployment has been one of those places where we expected a lot of variation | 20:48 |
| dhellmann | maybe at some point we'll find one that enough users like that they stop building their own and getting stuck unable to upgrade | 20:49 |
| SamYaple | heh. | 20:49 |
| SamYaple | ive always seen the issue with that being the sheer number of configuration options that exist | 20:50 |
| SamYaple | thats why i want thismore opinionated deploy that has a very narrow field. the security focus is just icing onthe cake (security is also one ofthe bits im always passionate about) | 20:50 |
| SamYaple | makes upgrades far easier | 20:50 |
| dhellmann | the obvious question is how hard would it be to do some of what you're talking about inside an existing project, but I don't think an answer of "harder than i want to deal with" is a reason to stop you from going ahead or to say the project is redundant, assuming the results provide some different benefit | 20:51 |
| dhellmann | that was a very wordy way of saying "go for it" :-) | 20:52 |
| SamYaple | i suppose it wouldnt be impossible, but i would call it nigh unmaintainable to do it that way, without *everyones* support (and commitment long term) | 20:53 |
| SamYaple | heh ok. sounds good. | 20:53 |
| SamYaple | i always try to start projects with the idea that im the only one maintaining them so the scope doesntcreep too much | 20:53 |
| dtroyer | In theory I'm all for an opinionated install, as long as they are the right opinions. :) And I think that's one reason you see the state we have in deployment projects, there are too many choices to make (even just the big ones) to get a good critical mass behind one set that is close enough. It is why I think deployment projects really are not what we (OpenStack-wide 'we') should be focusing on, someone should though. I spent a few years working i | 20:56 |
| dtroyer | So many potential customers said "that's great, except for X, could we do Y instead" for different values of X and Y for nearly every customer. | 20:56 |
| dtroyer | SamYaple: with that said, go for it. Someone someday will get it right, and I don't want to be the guy to discourage them | 20:58 |
| SamYaple | im hoping the "security-focus" can get rid of some of that line of questioning and draw some that want turn-key security | 20:58 |
| SamYaple | well see thatsjust it, i dont see it being possible to have a one-size-fits-all deploy | 20:58 |
| SamYaple | i want a one-size-fits-most deploy though | 20:58 |
| dtroyer | right, it isn't. even -fits-most is really hard given the size and complexity we have now | 20:59 |
| dtroyer | Think about the categories jbryce talked about in SYD and narrow things along those lines | 20:59 |
| SamYaple | yea fair enough | 20:59 |
| dtroyer | ie, pick the category of users and build for their case, don't start with the projects and look for users | 21:00 |
| SamYaple | well im the user in this case | 21:00 |
| dtroyer | there you go, and as you said above, that's your target | 21:00 |
| SamYaple | its my idealdeploy (and matches the user survey mostly) | 21:00 |
| SamYaple | okthansk for the feedback all. it has been helpful and not discouraging at all! | 21:00 |
| dtroyer | if it grows though, those criteria can help you decide among those who show up to help that you should and should not listen to… ie, maintain focus | 21:01 |
| dtroyer | Im looking forward to see what you come up with | 21:01 |
| SamYaple | dtroyer: well my lab has vault running with k8s right now. and vault can generate single-use rabbitmq and mariadb creds. then with the TLS stuff automated and authed through kubernetes, i can do x509 tokenless auth with keystone... so thats all pretty interesting | 21:05 |
| pabelanger | for me, deployment projects are hard to do, like you mentioned, there is 100 and 1 ways to support something. But, if (in the case of ansible) the roles were generic enough, it shouldn't matter how they are consumed. As long as they are independant of each other, with minimal dependencies, I think we could have a bunch more deployment projects, but built a top of same roles | 21:06 |
| pabelanger | I'd likely approach it that way myself | 21:07 |
| dtroyer | What's the saying about the only thing an indirection layer can't solve is too many indirection layers? :) | 21:10 |
| *** marst has joined #openstack-tc | 21:19 | |
| SamYaple | lol dtroyer | 21:58 |
| SamYaple | yea pabelanger that is what i would love idealy, reusable work. the issue ive found is when you start saying "well i want to deploy in containers" then you basically have a completely different role needed | 21:59 |
| SamYaple | different upgrade proceedures as well | 22:00 |
| SamYaple | im hoping to get a rolling release going with kubernetes, but well see | 22:00 |
| *** mriedem has quit IRC | 22:05 | |
| *** marst has quit IRC | 22:30 | |
| fungi | one of the main contributing hurdles to duplication, i think, is deployed userbase. if you already have users, it's hard to lock things down and take away options. new deployment schemes with no users can ratchet it down as tight as they like with no risk of regression | 23:05 |
| fungi | so there is a bit of a "latecomer advantage" with deployment automation in particular | 23:06 |
| fungi | especially if the focus is something strict like infosec | 23:07 |
| *** sdague has quit IRC | 23:29 | |
| *** kumarmn has joined #openstack-tc | 23:38 | |
| *** kumarmn has quit IRC | 23:43 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!