Tuesday, 2018-07-10

*** ricolin has joined #openstack-tc01:00
*** spotz_ has joined #openstack-tc02:14
*** ricolin_ has joined #openstack-tc02:15
*** corvus_ has joined #openstack-tc02:17
*** ff has joined #openstack-tc02:18
*** corvus has quit IRC02:19
*** flaper87 has quit IRC02:19
*** ricolin has quit IRC02:19
*** spotz has quit IRC02:19
*** mriedem has quit IRC02:54
*** rosmaita has quit IRC03:14
*** ricolin_ has quit IRC03:17
*** ricolin has joined #openstack-tc03:17
*** corvus_ is now known as corvus03:36
*** corvus is now known as Guest7845703:37
*** Guest78457 is now known as jeblair03:38
*** jeblair is now known as corvus03:43
*** ianychoi_ has quit IRC03:54
*** ianychoi has joined #openstack-tc04:08
*** gagehugo has quit IRC05:33
*** jpich has joined #openstack-tc07:01
*** tosky has joined #openstack-tc07:39
*** e0ne has joined #openstack-tc08:49
*** cdent has joined #openstack-tc08:56
cdenttc-members it's office hours time, anyone around with tc discussion?09:01
cdentmornin' cmurphy09:02
cmurphymornin' cdent09:02
* cdent brings this meeting of the c-nicks to order09:02
cdentI move that we only accept adjutant if they change their name to cadjutant09:03
cmurphythat sounds completely reasonable09:04
cmurphyi second09:04
* cdent finally votes on adjutant09:10
cdentI'm +1 but not in a way that I'm perfectly happy with09:10
cdentThis office hour has lost some of its flair. I wonder if we can put that on the ttx?09:23
cmurphyI think he's at a foundation retreat09:25
cmurphyso we can blame him for anything we want09:26
cmurphyit did seem to be more active not too long ago09:27
*** gagehugo has joined #openstack-tc09:38
* cdent arranges ptg flights09:53
*** rosmaita has joined #openstack-tc10:49
*** ff is now known as flaper8711:20
*** flaper87 is now known as Guest2168711:20
*** Guest21687 has quit IRC11:21
jrollcdent: I think you mean catjutant11:21
*** ff has joined #openstack-tc11:22
*** edmondsw has joined #openstack-tc11:25
TheJuliaGood morning11:37
* cdent waves11:39
cdentTheJulia: I had a question/thought you might have thoughts on. Came up in conversation with my son about trying to make inroads with the community in China:11:45
TheJuliacdent: I'm all ears... well ears lacking a coffee refill, but you know :)11:45
cdentHow do you think individuals (for example you) and organizations (the TC, the foundation, companies like red hat) should balance their desire for inclusion of individuals from china against what might be considered regressive attitudes towards openness held by companies or governments there? How much of an issue is that?11:46
cdent(of course this isn't an issue limited to china, but that was the context it came up in)11:47
cdentmy son speculated that it might be necessary to "make closed-ness hurt"11:49
cdenthe wasn't asserting that was necessary, more that it was an option11:49
TheJuliaI think it is a two part answer11:49
*** ricolin has quit IRC11:50
TheJuliaI think we all need to learn to decouple the associations we make that drive perceptions. We need to explicitly state what we know works and how we can interaction, meanwhile be open to operating a little differently. I'm not saying throw out patterns, but if someone emails a diff, perhaps that is viable. Ultimately be more understanding and realize the people on the other end are just like us, the just speak a11:52
TheJuliadifferent language day to day. The governments differ, but the fundamentals of governments and companies all kind of boil down to the same on both sides.  In essence, we need to build a bridge and see if they build towards that bridge as well.11:52
TheJuliaUltimately I think people and the companies are just like they are here, they are trying to solve their problem in the most effective low cost way. So in a sense, your son is right in that making closed behaviors hurt might bring people to the table, but they would have to know the table exists, and know that the other parties are not out to take them for everything.11:53
TheJuliaUltimately, it comes down to having mutually common goals.11:54
* TheJulia hopes that makes sense11:54
cdentit does, yeah11:57
TheJuliaI do believe there are perception differences, but upfront context into the ways can help soften those issues.12:07
cdentYeah, I think you've pretty much nailed it with the notion that we need to be foregrounding(?) context more and more often.12:13
fungicmurphy: if you call several day-long meetings deep in the heart of texas in the middle of summer a "retreat" then sure ;)12:17
cmurphyfungi: maybe s/foundation retreat/foundation hostage situation/12:18
fungieverything's bigger in texas, including the sun12:18
* cdent sings12:21
fungion the inclusivity front, i'm in favor of going out of my way to accommodate/facilitate less-efficient modes of contributor interaction, so long as i don't have to compromise my principles in doing so. e-mailed patch diffs are a fine example, as it's basically how our vmt operates on embargoed vulnerability reports12:22
fungiit may not be convenient, but it gets the job done12:22
*** mriedem has joined #openstack-tc12:59
scasback in yesterdecade, freebsd patches were almost exclusively emailed diffs. it wouldn't be unheard of, just old school13:26
*** hongbin has joined #openstack-tc13:40
*** ff is now known as flaper8713:47
*** flaper87 has quit IRC13:47
*** flaper87 has joined #openstack-tc13:47
*** diablo_rojo has joined #openstack-tc13:53
*** diablo_rojo has quit IRC13:54
*** annabelleB has joined #openstack-tc13:55
*** dklyle has quit IRC14:01
*** dklyle has joined #openstack-tc14:01
*** ricolin has joined #openstack-tc14:02
* TheJulia is finally done writing books in replies to emails while she was on PTO... at least downstream emails.14:03
TheJuliaShould we consider "outreach contacts", people who are willing to engage in discussions about various topic areas, and indicate various ways they can be reached?14:05
cdentthat seems like a good idea, but how would be publish such a thing? it often seems like if people know how to find that list, it's not much further to knowing what the list is providing14:06
TheJuliaThat is a super good point14:06
TheJuliaI suspect if we publish something, and then using some existing bridges of communication to circulate that information14:07
TheJuliaI wonder what Lauren might think about ^^^...14:07
cdentI find that I'm far more able and willing to respond to questions than I am to spontaneously creating info14:08
TheJuliaThere is definitely a cost to both, and the costs do differ14:18
*** annabelleB has quit IRC14:19
toskyapologize if it's not the proper place to ask, and in case please redirect me to the proper place:14:24
toskywe have few pending changes in python-saharaclient which would lead to a major version bump, breaking compatibility with old users of python-saharaclient14:24
toskydo all the compatibility deprecation/retention rules apply only to the API exposed by services, or also to the Python clients?14:25
*** spotz_ is now known as spotz14:31
dhellmannTheJulia , cdent : regarding "outreach contacts", that's part of what the First Contact SIG is trying to put together14:32
dhellmanntosky : good question14:33
dhellmanntosky : for most of the libraries we rely on some sort of integration testing to ensure that when we do release a breaking change it doesn't break us. So a library such as oslo.messaging has to roll a new API in before it can remove the deprecated API.14:34
dhellmannthat said, the governance rules we have are focused mostly on the REST APIs14:34
*** annabelleB has joined #openstack-tc14:35
dhellmannmy recommendation, as a consumer of libraries that break their APIs, is please try to support the deprecated API for as long as possible before removing it14:35
TheJuliaSo if there is a way to make it a minor version bump, and have the actual deprecated interface removed later, then it will be a much easier transition for the API consumers14:36
dhellmannbecause forcing a hard upgrade from one API to the next is not always as simple as we think it is14:36
toskynow I need to convince the others14:36
dhellmanntosky : if you need some help with making the API change in a backwards-compatible way, the oslo team has plenty of experience with that sort of thing and may be able to give some advice14:37
dhellmannsometimes it's obvious, and sometimes it's tricky14:37
*** jeremyfreudberg has joined #openstack-tc14:39
TheJuliatosky: Also, if you need assistance in regards to convincing others not to make a hard breaking api change, I'm sure a number of us have enough experience in the pain that can create.14:39
*** tellesnobrega has joined #openstack-tc14:39
toskywould it be possible to have official guidelines for Python clients too? Maybe (unrelated to the current change) something that also deals with a (future?) change to openstacksdk14:39
dhellmannwhat do you have in mind?14:40
jeremyfreudbergsorry - don't have the scrollback - can someone summarize what has been said on the tc side so far about the saharaclient issue?14:41
dhellmannjeremyfreudberg : sure, just a sec14:42
dhellmannfirst, today's logs will be at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-10.log.html14:42
dhellmannit looks like the bot hasn't caught up with us, yet14:42
dhellmannso in the mean time:14:42
dhellmanntosky asked about what the rules are for clients and API changes14:42
*** EmilienM is now known as EvilienM14:42
dhellmannformally the rules apply to REST APIs14:42
dhellmannhowever, we do encourage teams to consider that consumers of their libraries will not be happy with API breaks there14:43
dhellmannwe run into problems with our upstream dependencies pretty regularly and it causes all sorts of extra work for us14:43
dhellmannin many cases we have integration test jobs that ensure that libraries do not remove old APIs while they are still in use14:43
dhellmannI don't know the situation for the saharaclient library w.r.t. integration tests like that14:43
dhellmannit's possible, if sometimes tricky, to make API changes in a way that is still backwards compatible, and I suggested that the Oslo team may have some good advice about how to do that if you are having trouble with the change in question14:44
dhellmannI don't know the details of the change, yet, or how much you've already discussed various options, so that's just a suggestion of a source of advice if it could be useful14:45
dhellmannTheJulia : does that cover it? ^^14:45
*** AlanClark has joined #openstack-tc14:45
* jroll is not julia but agrees that covers it14:45
dhellmannthanks, jroll14:45
jeremyfreudbergdhellmann: besides the other sahara deliverables, and cloud users, some other consumers of saharaclient that i know of would be rally and heat14:45
jrollI'd love to see the change14:46
jeremyfreudbergputting aside all that though -- does that mean we can never make a breaking change?14:46
dhellmannjeremyfreudberg : no, not never. it just needs to be done with care.14:46
jeremyfreudbergand semver is not enough care?14:46
dhellmannthe approach we have found to work best is to produce a version of the library that works using both API versions, and to support both for some period of time, and then finally drop the old API14:46
dhellmannsemver helps signal when the break comes, but it does not make it easier to consume14:47
jrollI'm assuming we're discussing https://review.openstack.org/#/c/580693 , which did seem to properly deprecate things (though I'm not sure how long it was marked deprecated)14:47
dhellmannconsider the way we test our own software14:47
TheJuliadhellmann: Covers it very well14:47
dhellmannheat and rally would not be co-installable if they required different versions of sahara client to work14:47
toskyjroll: more thishttps://review.openstack.org/#/c/579680/14:47
toskythis: https://review.openstack.org/#/c/579680/14:47
jeremyfreudbergjroll: the one you linked is far less controversial14:48
toskyjeremyfreudberg: right, because it does not break the API - old code will continue to work (if session is provided)14:49
jrollmakes sense14:49
jrolldoes seem like a hard break14:49
dhellmannreordering the arguments in https://review.openstack.org/#/c/579680/2/saharaclient/api/data_sources.py to allow description to be optional and changing the credentials handling look like the main issues there14:50
dhellmannone way to handle that would be to make a new method with the desired new API and deprecate the old one14:50
dhellmannit looks like the old one could potentially even be implemented in terms of the new one14:51
dhellmannso you still only have 1 real implementation14:51
dhellmannby having a second method, you can keep both APIs around for a while to give folks time to adopt the new API14:51
dhellmannif we ignore downstream consumers and look just at our own CI, having a breaking change like that is technically impossible to adopt14:52
dhellmannany code calling that create() method would need to be modified, but the application containing that code couldn't have a new version of the dependency allowed by the constraints system until the unit tests would pass14:52
dhellmannand devstack job, if it's included there14:53
dhellmannthose changes are in separate repositories, so you can't land a single change that fixes everything at once14:53
dhellmannand so you either have to force one change through and live with something broken for a while, or you need to stage the API change to give some deprecation time14:53
dhellmannmake sense?14:54
*** annabelleB has quit IRC14:56
toskyto be honest, jeremyfreudberg put out a change to cover the compatibility change inside our test repository (https://review.openstack.org/#/c/581372/ )14:57
toskystill, I would avoid a total sudden breakage14:57
jeremyfreudbergi've been mostly convinced on making the saharaclient change less drastic14:59
jeremyfreudbergdoing so with good ux might be another story15:00
*** annabelleB has joined #openstack-tc15:06
toskyabout my previous question: I don't have anything specific in mind, apart from having some official guidelines for clients too, in addition to APIs, so that there is no need to ask again15:09
toskythe point about openstacksdk was a partially related question about the only visible big disruptive change that could happen for python clients in the future15:11
TheJuliaI feel that is a reasonable ask in terms of guidelines, I guess we will need to ponder that.15:15
*** annabelleB has quit IRC15:21
dhellmannthat seems like a good outcome15:39
*** zaneb has quit IRC15:54
*** zaneb has joined #openstack-tc15:57
*** jeremyfreudberg has quit IRC16:35
*** annabelleB has joined #openstack-tc16:39
*** e0ne has quit IRC16:51
*** jpich has quit IRC17:04
openstackgerritMerged openstack/governance master: Remove team diversity tags  https://review.openstack.org/57987017:05
openstackgerritDoug Hellmann proposed openstack/governance master: add check_review_status.py  https://review.openstack.org/57995317:11
openstackgerritJill Rouleau proposed openstack/governance master: Import ansible-role-tripleo-cookiecutter  https://review.openstack.org/58142817:13
*** annabelleB has quit IRC17:20
*** annabelleB has joined #openstack-tc17:20
*** AlanClark has quit IRC17:43
*** annabelleB has quit IRC17:43
*** annabelleB has joined #openstack-tc17:45
*** annabelleB has quit IRC17:48
*** mriedem has quit IRC17:53
*** mriedem1 has joined #openstack-tc17:57
*** mriedem1 is now known as mriedem18:00
*** annabelleB has joined #openstack-tc18:15
*** e0ne has joined #openstack-tc18:31
*** e0ne has quit IRC18:47
*** annabelleB has quit IRC18:51
*** annabelleB has joined #openstack-tc19:05
*** e0ne has joined #openstack-tc20:04
*** annabelleB has quit IRC20:14
openstackgerritZane Bitter proposed openstack/governance master: Clarify new project requirements for community engagement  https://review.openstack.org/56794420:19
*** ricolin has quit IRC20:19
*** annabelleB has joined #openstack-tc20:21
*** e0ne has quit IRC20:53
*** e0ne has joined #openstack-tc20:53
*** cdent has quit IRC21:10
*** e0ne has quit IRC21:22
*** rosmaita has quit IRC21:34
*** edmondsw has quit IRC22:01
*** annabelleB has quit IRC22:08
*** annabelleB has joined #openstack-tc22:13
*** annabelleB has quit IRC22:47
*** zaneb has quit IRC23:03
*** hongbin has quit IRC23:06
*** tosky has quit IRC23:08
*** edmondsw has joined #openstack-tc23:16
*** edmondsw has quit IRC23:21

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