Tuesday, 2017-11-21

*** hongbin has quit IRC00:14
*** gcb has joined #openstack-tc01:29
*** liujiong has joined #openstack-tc01:39
*** harlowja has quit IRC03:22
*** gcb has quit IRC03:42
*** harlowja has joined #openstack-tc04:01
*** gcb has joined #openstack-tc04:46
*** lbragstad has quit IRC04:58
*** kumarmn has quit IRC05:34
*** harlowja has quit IRC05:52
openstackgerritMasahito Muroi proposed openstack/governance master: Update Blazar's document references  https://review.openstack.org/52171906:08
*** dtantsur|afk is now known as dtantsur07:01
*** gcb has quit IRC08:12
*** gcb has joined #openstack-tc08:13
*** gcb has quit IRC08:19
*** gcb has joined #openstack-tc08:19
flaper87tc-members: office hour ?09:03
* flaper87 wonders who's around09:03
* cmurphy back in the right timezone09:03
flaper87I know ttx is at OSDays France09:03
flaper87cmurphy: yahooooo!09:03
* cmurphy also at osd france09:04
cmurphyso still in the wrong country09:04
flaper87cmurphy: nice, how is that going?09:04
cmurphyflaper87: they are speaking in french so i have no idea :P09:05
flaper87I was planning to go but I figured that I could use some time at home09:05
flaper87cmurphy: lol09:05
cmurphyttx was nice enough to give his keynote in english09:06
*** jpich has joined #openstack-tc09:07
*** tdasilva has quit IRC09:09
*** tdasilva has joined #openstack-tc09:15
*** dtantsur_ has joined #openstack-tc09:21
*** dtantsur has quit IRC09:22
*** dtantsur_ is now known as dtantsur09:22
* johnthetubaguy wonders in a bit late to see who is around09:22
* cmurphy waves09:24
* johnthetubaguy waves back09:29
*** cdent has joined #openstack-tc09:30
* smcginnis waves10:06
*** liujiong has quit IRC10:10
* cdent waves at smcginnis 10:11
* cdent calendar checks10:11
*** kumarmn has joined #openstack-tc10:38
*** kumarmn has quit IRC10:43
ttxI'll be a bit late in updating the the tracker today11:10
*** kumarmn has joined #openstack-tc11:39
*** kumarmn has quit IRC11:44
*** sdague has joined #openstack-tc12:08
*** gcb has quit IRC12:18
*** kumarmn has joined #openstack-tc13:41
*** kumarmn has quit IRC13:45
openstackgerritMerged openstack/governance master: Add policy artifacts for Freezer  https://review.openstack.org/51873813:47
ttxtracker updated14:03
cdentI’m still wading through a massive backlog of $stuff, haven’t had much chance to think about any governance related stuff :(14:04
ttxyeah same for me tbh14:05
ttxtraveling again this week doesn't help14:06
*** mriedem_away is now known as mriedem14:20
*** lbragstad has joined #openstack-tc14:24
*** zaneb has joined #openstack-tc14:25
*** kumarmn has joined #openstack-tc14:37
*** kumarmn has quit IRC14:42
*** rosmaita has joined #openstack-tc14:43
openstackgerritPavlo Shchelokovskyy proposed openstack/governance master: Add networking-generic-switch under ironic  https://review.openstack.org/52189415:24
*** rosmaita has quit IRC15:29
*** kumarmn has joined #openstack-tc15:38
*** kumarmn has quit IRC15:42
*** marst has joined #openstack-tc16:00
cdentSigh. 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
cdentdoing something a particular way because that’s the way it was done before isn’t always right16:34
dhellmanncdent : which option do you prefer?16:37
cdentdhellmann: 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
cdentIf 3 can’t happen, then I’m not really sure.16:39
dhellmannanother 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
cdentI think many small repos is a better way to have dissolution of boundaries between things16:40
dhellmannI'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 jobs16:41
cdentwhy 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
dhellmannin 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
dhellmannbecause there was no real plan to gate projects on those tests16:43
dhellmannso we'd have the tests used to verify the product works and the tests used to verify trademarks and they would diverge16:43
cdentbased on my conversation with mark, creating and reviewing tests is not a huge issue, except when a new project joins the trademarks16:43
cdentinstead they select existing tests16:44
dhellmannI thought we had issues in the past where tests changed in a way that made existing deployments no longer pass the interop guidelines16:44
cdentThat (selecting) seems a bit awkward to me16:44
cdentyeah, that16:44
cdentit would be great to have explicit tests for explicit things16:44
dhellmannyeah, 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
cdentIt is perhaps effortful to make explicit stuff and it would mean some duplication, but getting meaningful stuff often requires that16:45
mugsiewhat 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
dhellmannmugsie : my understanding is that tests related to integration with other projects go into tempest and functional tests not related to that integration go elsewhere16:46
dhellmannso that's a technical distinction that at least makes sense16:46
mugsieAh, that would make sense16:46
dhellmannthe 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 projects16:47
mugsieAlthough there is at least one test being written right now that should go into tempest then.16:47
cdentthere has been some noise of making an ‘intergrated-core-tempest-plugin’ but that got the “that’s what tempest alraedy is” response16:47
* mugsie will look in to that16:47
dhellmanncdent : right16:47
mugsieMy 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'd16:49
dhellmannit 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 us16:49
dhellmannmugsie : are there good review guidelines for the interop tests somewhere?16:49
mugsienot too my knowledge16:50
mugsieI think it is relying on the QA being the core team to have good reviews16:50
dhellmannthat feels like a prerequisite to splitting anything out or allowing teams to manage the tests themselves16:50
* TheJulia reads discussion16:50
dhellmannbecause my impression is that the rule is the tests really can't change at all under any circumstances, although that's probably harsher than reality16:51
mugsieand, 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 breakages16:51
dhellmannunfortunately I don't remember exactly what the situation was where a change did break things. maybe mtreinish remembers.16:51
mugsieI 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 resloved16:52
dhellmannmugsie : good point. we'd need to describe all of that as part of reverting the existing test location policy16:52
mugsieor the additionalProperties change to nova broke the InterOp  tests for some people as well16:52
dhellmannI 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 calls16:52
mtreinishdhellmann: yeah it was not allowing additional properties in nova16:53
dhellmannmaybe I'm confusing this issue with the thing oracle had not being able to boot linux16:53
dhellmannmtreinish : was that rax that had that issue?16:53
mugsieoh, yeah that was not a breakage, but it blocked Oracle from getting trademark status afaik16:53
mtreinishyep, rax and one of huawei's products16:53
dhellmannyeah, ok, that's coming back now16:54
dhellmannthanks, mtreinish16:54
dhellmannhow was that resolved?16:54
mugsiewe still allow additionalProperties in InterOp tests :)16:55
*** dtantsur is now known as dtantsur|afk16:55
mtreinishdhellmann: interop gave them an additional 6 months to fix it (which of course they didn't)16:55
mugsieI think it is being removed this time though16:55
mtreinishand then forgot to remove the waiver16:55
mtreinishit's finally being removed for the 2018.1 guideline16:55
mtreinishdhellmann: https://review.openstack.org/#/c/512447/16:56
dhellmannand 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
mtreinishdhellmann: 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 issue16:57
dhellmannok, so it was pushback from downstream rather than some sort of miscommunication16:58
dhellmannI 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-tc17:00
*** ChanServ sets mode: +v openstackstatus17:00
mtreinishto 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
dhellmannso we're back to having to solve our review bandwidth/throughput problem in order to fix anything! :-)17:00
dhellmannso, 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
mtreinishtbh, I would assume in the same way. But, it would really depend on the project team I guess17:05
dhellmannyeah, I guess a lot would depend on that team's engagement with the trademark program and their understanding of the need for flexibility there17:17
*** purplerbot has quit IRC17:18
*** purplerbot has joined #openstack-tc17:18
*** rosmaita has joined #openstack-tc17:35
*** hongbin has joined #openstack-tc17:58
*** david-lyle has quit IRC18:09
*** david-lyle has joined #openstack-tc18:09
*** jpich has quit IRC18:23
*** stevemar has left #openstack-tc18:34
openstackgerritDoug Hellmann proposed openstack/governance master: add/update documentation links  https://review.openstack.org/52198719:15
*** marst has quit IRC19:20
SamYaplequestion 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 everything19:44
SamYaplewithout being so opinionated it would be hard to maintain all ofthat19:44
*** cdent has quit IRC20:00
smcginnisSamYaple: I find that interesting at least.20:21
dhellmannSamYaple : how do you see that as different from triplo, osa, puppet, chef, etc. in terms of "acceptability"?20:38
SamYapledhellmann: 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 kubernetes20:47
SamYapleso it would be yet another kubernetes deploy20:47
SamYaplebut with a very narrow scope. im just not sure on the exact feelings of duplicate projects20:48
dhellmannin the past deployment has been one of those places where we expected a lot of variation20:48
dhellmannmaybe at some point we'll find one that enough users like that they stop building their own and getting stuck unable to upgrade20:49
SamYapleive always seen the issue with that being the sheer number of configuration options that exist20:50
SamYaplethats 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
SamYaplemakes upgrades far easier20:50
dhellmannthe 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 benefit20:51
dhellmannthat was a very wordy way of saying "go for it" :-)20:52
SamYaplei 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
SamYapleheh ok. sounds good.20:53
SamYaplei always try to start projects with the idea that im the only one maintaining them so the scope doesntcreep too much20:53
dtroyerIn 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 i20:56
dtroyerSo 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
dtroyerSamYaple: with that said, go for it.  Someone someday will get it right, and I don't want to be the guy to discourage them20:58
SamYapleim hoping the "security-focus" can get rid of some of that line of questioning and draw some that want turn-key security20:58
SamYaplewell see thatsjust it, i dont see it being possible to have a one-size-fits-all deploy20:58
SamYaplei want a one-size-fits-most deploy though20:58
dtroyerright, it isn't.  even -fits-most is really hard given the size and complexity we have now20:59
dtroyerThink about the categories jbryce talked about in SYD and narrow things along those lines20:59
SamYapleyea fair enough20:59
dtroyerie, pick the category of users and build for their case, don't start with the projects and look for users21:00
SamYaplewell im the user in this case21:00
dtroyerthere you go, and as you said above, that's your target21:00
SamYapleits my idealdeploy (and matches the user survey mostly)21:00
SamYapleokthansk for the feedback all. it has been helpful and not discouraging at all!21:00
dtroyerif 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 focus21:01
dtroyerIm looking forward to see what you come up with21:01
SamYapledtroyer: 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 interesting21:05
pabelangerfor 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 roles21:06
pabelangerI'd likely approach it that way myself21:07
dtroyerWhat's the saying about the only thing an indirection layer can't solve is too many indirection layers? :)21:10
*** marst has joined #openstack-tc21:19
SamYaplelol dtroyer21:58
SamYapleyea 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 needed21:59
SamYapledifferent upgrade proceedures as well22:00
SamYapleim hoping to get a rolling release going with kubernetes, but well see22:00
*** mriedem has quit IRC22:05
*** marst has quit IRC22:30
fungione 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 regression23:05
fungiso there is a bit of a "latecomer advantage" with deployment automation in particular23:06
fungiespecially if the focus is something strict like infosec23:07
*** sdague has quit IRC23:29
*** kumarmn has joined #openstack-tc23:38
*** kumarmn has quit IRC23:43

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