15:00:31 #startmeeting tc 15:00:32 Meeting started Thu Jun 28 15:00:31 2018 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:35 The meeting name has been set to 'tc' 15:00:38 #topic Office Hour 15:00:41 bonjour o/ 15:01:01 #chair mnaser dhellmann ttx smcginnis cdent TheJulia zaneb 15:01:01 o/ 15:01:01 Current chairs: TheJulia cdent dhellmann fungi mnaser smcginnis ttx zaneb 15:01:05 o/ 15:01:06 o/ 15:01:12 #chair pabelanger 15:01:13 Current chairs: TheJulia cdent dhellmann fungi mnaser pabelanger smcginnis ttx zaneb 15:01:16 o/ 15:01:20 #chair mugsie 15:01:20 Current chairs: TheJulia cdent dhellmann fungi mnaser mugsie pabelanger smcginnis ttx zaneb 15:01:26 o/ 15:01:38 for those just joining, we were discussing the pre-PTG meeting plans 15:01:56 late on the food topic, but before things get busy, just wanna point out denver seems to have thousands of microbreweries :) 15:01:58 I am waiting to hear if we have a conference room, but have been reassured that we could likely use the lounge if we have to. 15:02:04 dhellmann: where do we stand on an "additional workshop around an established conference" ? 15:02:15 Was that abandoned ? 15:02:20 the general trend seemed to be for an afternoon-only meeting, so plan your travel accordingly 15:02:24 ttx: good question 15:02:40 CFP for Open Source Summit in Edimburgh closes Sunday iirc 15:02:41 I had thought maybe this pre-PTG thing would make that unnecessary, but that wasn't really clear. 15:03:00 Maybe we can postpone 15:03:03 My impression was that while a lot of us would like to have a workshop, there didn't sound like there was a good time or place for everyone to meet. 15:03:18 ok 15:03:30 Alan Clark did ask to join us on Sunday in Denver, and I thought it might be a good opportunity. Does anyone have any objections to including him? 15:03:39 Not saying I don't think we should try for it, but there were some challenges to work through yet if we do. 15:03:41 In September we'll have a better idea of teh early-2019 conference landscape and could pick one 15:03:43 i'd welcome his presence 15:03:49 dhellmann: That would be great! 15:03:53 likewise 15:03:53 or anyone from the community really 15:03:54 alan showing up would be great 15:03:55 yeah, that seems like a good idea 15:04:04 smcginnis : yeah, I think we might have a better chance scheduling something off-peak conference season 15:04:15 ok, I will relay the current vague plans 15:04:17 fwiw, I plan to be there… (Sunday PTG) 15:04:23 Q1 2019 might give us enough time and be a good time of year to try to do something. 15:04:36 we could consider doing some virtual video conferencing if people were up for it, but that night be a pain 15:04:43 Leaving MN in February to go to Cancun or Hawaii works for me. 15:04:48 which are, we'll meet some time after lunch, so as not to try to make anyone take really early flights to get there first thing 15:04:49 ok, noted. i might still go to Edinburgh :P 15:05:08 there may be an opportunity for me to be attend the ptg on behalf of chef openstack. i suspect it'll be more for me to whip my deceased equine than talk about chef itself 15:05:10 * jroll <3 edinburgh 15:05:12 ttx I'm still thinking about it as well, but I'm struggling with seeing the future well 15:05:14 s/words/words/ 15:05:19 ttx : I will be there for EuroPython so opted not to make 2 trips to the same place so close together. 15:05:40 I'll apply for CFP -- usually mentioning OpenStack in the abstract is a good way to get rejected 15:05:53 le sigh 15:05:58 Hah, that does seem to be the case these days. 15:06:15 yeah, i avoid mentioning openstack in any cfp submission due to openstack fatigue 15:06:49 I also wanted to discuss diversity tracking, if nobody else has anything more urgent 15:07:13 i liked the "bus factor" recharacterization 15:07:18 It feels like we have several options on the table 15:07:18 I was going to ask where things stood with the work on "job descriptions" but I didn't see dims sign in 15:07:26 helps focus on the actual concern rather than the abstract measurement 15:07:37 1- try to adjust the metrics and continue to do tags 15:07:58 2- try to adjust the metrics but use them to feed questions to teh health Tracker for deeper dive into data 15:08:05 3- drop tracking altogether 15:08:19 Jeremy Stanley proposed openstack/project-team-guide master: There are no core developers, only core reviewers https://review.openstack.org/578819 15:08:22 4- Produce a comprehensive report every cycle 15:08:36 I' not convinced 4 is worth the effort 15:08:54 I'm convinced (1) is more destructive than useful 15:08:54 Agree re: 4 15:09:12 so I'm somewhere between 2 and 3 at this point 15:09:17 2 seems like a reasonable compromise 15:09:17 I think we should stop publishing the data, but produce it regularly to use it to inform human interactions 15:09:24 cdent: ++ 15:09:25 I was just going to say the same - somewhere between 2 and 3. 15:09:28 that's where I am 15:09:47 Have teh data, but don't make it more significant than it actually is 15:10:07 because the more i look into it, the more brittle I see it is 15:10:08 measuring the thing but not having it published is where i'd go, too. better to measure and not need 15:10:22 2 seems reasonable and the lesser lift work wise to implement. 15:11:11 it does give a rough idea as to where things stand, but it's not something i'd want to plaster on the wall 15:11:30 And as I mentioned in a recent remark on this channel, 67% corporate bus factor on swift due to commit % is less critical than 67% for Masakari. 15:11:44 As one is more featurecomplete than the other 15:12:03 yeah, and i agree fully that badgifying it via governance tags just turns it into something teams will complain is unfairly casting them in a poor light 15:12:24 If Swiftstack abandoned Swift I feel like Swift would survive ok. If NTT abandoned Maskari, it would be a walking dead 15:12:38 it brought me out of my foxhole since chef is pretty relevant there 15:12:44 due to lack of an ecosystem of users 15:13:20 The only drawback of 2/3 is that you don't communicate that information on project health to consumers anymore 15:13:52 do we know if consumers were actually using that information? 15:13:54 except if they find the not-so-secret wiki url 15:13:56 we should care most about openstack health, not individual projects? 15:13:58 dhellmann: ++ 15:14:01 if ntt abandoned masakari it would be a zombie at least until some other interested party picked it back up (a la blazar) 15:14:21 of course, they can't use it if we don't publish it 15:14:22 Trove is actually my favorite example :) 15:15:34 dhellmann: yeah, I'm not sure how much corporate diversity actually plays a role in deployment decisions 15:16:03 sorry, I gotta run, will catch up 15:16:24 But I feel like it's a more positive message to post "you can use Barbican now, the TC says it's solid" rather than "don't use TripleO, only Red Hat contributes to it" 15:16:34 ttx: I would suggest it doent at all 15:16:47 'does it blend without cutting me to shreds' is the general sentiment that i've seen from various interactions with my downstreams in the deploy space 15:17:08 scas: but it's a more complex statement than a diversity tag, right 15:17:10 ttx: but we don't make judgements on the code - we can't say Barbican is solid, just that more than one company works on it 15:17:14 ttx: very much so 15:17:24 mugsie: well maybe that needs to change 15:17:32 ttx: for core openstack, swift the big exception, you could say that chef is fairly stable 15:17:41 quite possibly 15:18:23 * mugsie is just imagining the wall of flames from the first TC code review 15:18:56 mugsie: right... I'm just suggesting we somehow communicate that it's time for people to rely more on Designate for example 15:19:07 fireproof pants mode *on* 15:19:09 so long as 'someone' is keeping up with build failures and extra-community developments, diversity is a third or fourth degree factor. the user survey metrics for chef are fairly stable because the main use case is 'fairly stable', to overuse the phrase. but that's a complex thing to measure 15:19:14 well, bolding us in the project map would help :P 15:19:18 not saying that the others are less ready :) 15:19:33 Bold is the new core 15:20:23 anyway, that's a bit of a tangent 15:21:02 OK! so: I will refine my busfactor scripts and post them to governance repo 15:21:22 ++ 15:21:28 I will highlight the most disturbign stats in the HealthCheck page so taht those can be raised in future health checks 15:21:47 that sounds good, too 15:21:59 and I will propose a removal of the existing diversity tags 15:22:35 mnaser: if you want to take some of those work items, feel free :) 15:22:55 it would be nice, in a bikesheddy sort of way i suppose, to come up with a less morbid term than "bus factor" to describe this concept 15:22:56 but I'm probably in a better position to push those 15:23:08 So what if a team actually doesn't care about the diversity tag? 15:23:10 hah 15:23:34 TheJulia : if it's going away, that doesn't really matter, right? do you mean affiliation diversity in general? 15:23:44 fungi: "diversity brittleness" ? 15:23:53 TheJulia: most of us don't really care, apart from the kiss of death from the single-vendor one 15:23:54 well, I think my mind is going towards tags in general 15:23:57 The problem is that diversity has more dimensions 15:24:11 ttx: "diversity" has so many meanings, I think we always need to include "affiliation" when we talk about it in this way 15:24:14 to be clear 15:24:15 yeah 15:24:25 fungi: I'll take any suggestion that works both for corporate busfactor and individual busfactor 15:24:27 mugsie: that was kind of what I was expecting the answer to be, and that is my perception as well. 15:24:41 though also affiliation may be irrelevant in the single-contributor case 15:24:54 although I'll regret my busfactor.py 15:25:10 perhaps 'key person risk', to dredge from the old school 15:25:20 to be clear, i don't object to it but some people may find the imagery of contributors getting hit by a bus unsettling 15:25:24 ttx: it can always be renamed ;) 15:25:38 * ttx cries in a corner 15:25:51 :( 15:25:56 anybody want to talk Adjutant? 15:26:15 * dhellmann would like to hear some other opinions on adjutant 15:26:17 fungi: less unsettling than being forked, right 15:26:24 * ttx shuts up 15:26:25 heh 15:26:43 Adjutant++ 15:27:08 I was leaning towards +1ing it but didn't want to influence anyone 15:27:28 I'm still a bit on the fence and am looking for someone to tip me one direction or the other. 15:27:41 ttx: fungi: I like "lottery factor", winning the lottery is a much happier scenario where people might just stop working on things :) 15:27:52 jroll: or retirement ;) 15:28:02 retirement usually isn't so sudden :P 15:28:05 oops i'm late 15:28:11 dhellmann: I'm pretty relaxed about voting for it, so I'd like to hear more about your concern that its flexible architecture could prove to be a Bad Thing if it results in people writing lots of non-interoperable plugins 15:28:32 For Adjutant, I'm fine adding it, because it's easy to remove it afterwards if it ends up being destructive after all 15:28:33 yeah, retirement seems to be more of a trickledown from what I've seen so far 15:28:46 "tableflip factor"? 15:28:46 jroll: fair. also working on free software already feels like retirement to me at least ;) 15:28:46 I think we expressed our concerns 15:28:58 rage quit factor 15:29:07 ttx: Is it "easy" to remove? When was the last time we removed a project? 15:29:35 I wouldn't consider it "easy", but maybe in relation to the work getting it added it would be. :) 15:29:40 That would be Fuel and the App catalog.. 2017? 15:29:42 we removed fuel, app catalog, akanda 15:29:45 cue? 15:29:48 yup 15:30:03 zaneb : We've done so much work on interoperability with other projects, and place so much value and emphasis on it now, that I'm having trouble just letting go of that. 15:30:07 dhellmann: specifically, in what ways could making it an official project make the downstream plugin problem worse? 15:30:08 It's easier than most due to where it would end up in the map 15:30:41 zaneb : it wouldn't be any different, at a technical level. It would be different because we would be saying "yeah, we don't care about the lack of interop with this one project" 15:30:45 dhellmann: I would definitely not accept it if it ended up in the "main" bucket 15:30:47 the app catalog removal is probably the most similar, since it was "we're retiring this active effort because it is not the direction we want to take openstack" 15:30:50 and I guess I prefer not to make exceptions 15:30:54 I think that needs clear APIs 15:31:33 at the same time, I've wished we had the user onboarding features for *ages* (the thing we built at Dreamhost wasn't reusable in any way) 15:32:03 and to be clear, I will support the decision of the group, whichever way it goes 15:32:12 *this group 15:32:19 yeah. and the info I would take for onboarding into my cloud is completely different to the info collected by vexxhost for example 15:32:54 I'm talking post-signup onboarding 15:33:10 stuff like "welcome! next we're going to create some default networks for you" 15:33:36 some of what we had to do was driven by our choice of networking architecture and backend 15:33:43 dhellmann: re: Adjutant if we add them now they won't be in Rocky anyway, forit release would be Stein 15:33:48 first* 15:33:58 I forget where I read it recently, bit there was some wording around the desire for interop with OpenStack not meaning it's something you can easily switch between providers with absolutely no changes, but rather having a base level of expected compatibility. 15:34:31 I see adjutant as being outside of that base level and something more on the provider level where it's perfectly fine if vendor a works slightly differently than vendor b. 15:34:31 it's not like we don't have non-interoperable ways of doing it now, it seems like Adjutant is at least a step in the right direction 15:34:50 But at least both vendors can use a tool supported by the community and not some home grown widely divergent thing. 15:35:03 ttx: i can take on some of these tasks if you want to assign any 15:35:12 i'm still trying to grasp most of the diversity stuff but i'll take any action items 15:35:38 mnaser: I'll see if I end up needing help, You have plenty on your plate 15:35:55 smcginnis: and tbh I am less concerned with interop when the interface is Horizon (which anybody can relearn pretty quick) vs. a bunch of scripts that have to be rewritten 15:36:02 ttx: thanks, i've had some unexpected surprises of extra work on my way.. 15:36:08 not unconcerned, but definitely less concerned 15:36:16 zaneb: Same here. 15:36:25 there is an API, right? 15:36:46 zaneb: depending on how much prevalent those sorts of APIs already are, one could even consider that Adjutant is helping standardize overall 15:36:47 * mnaser doesn't like the fact some providers build their own control panels and not use horizon instead 15:36:55 dhellmann: AIUI yes, but mostly for the purposes of exposing it through horizon 15:37:10 ah, ok 15:37:24 Even if it's scripted for some reason, I don't see a problem with that. 15:37:36 mnaser: ++ 15:37:42 I guess that's a good question -- how many of the OpenStack public clouds already use some sort of proprietary API to integrate with their business logic on $stuff 15:37:50 As a user, if I've scripted something for working with Vexxhost, I would assume I need to redo some things if I then go to some other provider. 15:37:54 If all of tehm do, then Adjutant is a win 15:38:09 If none of them do, then Adjutant is likely to increase divergence 15:38:10 I would assume at least 90+% of them do. 15:38:16 in previous discussions, adjutant developers were quite clear the api is and is meant to be user-facign and not merely for web integration 15:39:29 smcginnis: i like to think that what you run against our cloud should be the same as any other cloud 15:39:40 the only thing i'd expect to change are things like.. image id.. flavor.. 15:39:42 network id.. 15:39:53 that's how i think it should be anyways 15:41:05 my view is that: each company can do it's own thing in a way, but at some point, you will end up with a set of openstack credentials and the experience from that point onwards should always be consistent 15:41:05 i expect it was more like for self-service sign-up the information you collect from new customers is likely to be at least somewhat different from the information some other provider might collect 15:41:49 fungi: in a lot of cases they piggyback on an existing system 15:41:50 mnaser: technically some of what adjutant handles is the part before you get the openstack credentials 15:42:27 ttx: agreed. especially if cloud services are not the only product/service so they already have a crm and billing system 15:42:38 this might be a bit ignorant of me to ask, but do you *have* to be interop-able to be an official project? 15:43:11 nope 15:43:23 the deployment tools are an example of projects with no interoperability guarantees because that wouldn't make sense 15:43:24 depends what you mean by operop-able 15:43:26 it is a goal of our though 15:43:34 https://governance.openstack.org/tc/reference/new-projects-requirements.html 15:43:52 so the way i imagine adjutant is just a collaboration across different providers who would like to stop duplicating their logic and work together to implement their common business logic 15:43:54 has some things to say about "basic interoperability with the rest of OpenStack: User-facing API services should support Keystone for discovery and authentication" 15:44:16 and extend it with their own business logic on top, rather than each provider having their own set of onboarding stuff 15:45:03 as long as that is limited to logic that isn't user facing imho 15:45:18 user facing and touching other openstack api services 15:45:36 but anyways, i might be late to this whole convo. i'll follow the review and comment 15:45:51 mnaser: yeah, in adjutant's case rather than wanting to have interchangeable backend drivers with a consistent api, they want the backends to change the api conditionally 15:46:11 mnaser: that would be the ideal scenario yes 15:47:01 yeah that's a no bueno imho. work with other providers and come up with the set of common shared api calls you want to work on: ex.. reset password, etc 15:47:03 for me what it boils down to is that we've had examples of dynamic apis in openstack, and our experience to date is that you can't really build redistributable tools around those 15:47:36 i do feel like at that point it's a bit odd 15:47:37 so instead you end up with provider-specific clients and sdks 15:47:49 which we've also had a proliferation of in the past 15:47:57 like it has it's own queueing and task management tooling 15:48:15 we have tools that do that in openstack which it would be nice to depend on and help the overall ecosystem 15:49:14 one thing we haven't discussed: is there actually interest from other vendors? I only see one email on openstack-dev to that effect 15:49:30 No - we covered that a long time ago, there is no relation between Mistral and Adjutant 15:49:51 yeah, adjutant "tasks" are not at all like mistral's 15:50:00 zaneb: that's a good question yes. If there is no hope of open collaboration aroudn Adjutant, the overall value add is limited 15:50:07 mnaser: every project has it own internal queuing and task managment system 15:50:08 (perhaps more like glance's "tasks"?) 15:50:24 yeah, that's pretty close fungi 15:50:37 zaneb: i dont want to speak on their behalf but i think citycloud might be using parts of it 15:50:41 or designate's workers / tasks 15:50:43 tobberydberg: ^ ? 15:51:32 I guess I should check the operators list 15:52:01 if we can go back to the PTG meeting for a second, Alan asked if it would be appropriate to invite the rest of the board members who may be in town to join us. I don't have a problem with that, except that I don't know how much space we have yet. Is there any other reason not to include them? 15:52:15 zaneb: i want to say there was some discussion of it on the operators list last year, but i'll need to find my old notes from the last time i researched it 15:52:34 http://lists.openstack.org/pipermail/openstack-operators/2018-April/015106.html 15:52:42 dhellmann: yeah, maybe wait until we know if we have a room... The bar won't be enough if the board comes 15:52:53 dhellmann: I dont think there is an issue, apart from space 15:52:53 dhellmann: assuming space is not an issue, i'm cool inviting anyone from the community, even board members 15:52:57 dhellmann: only if we want to talk about them behind their backs. I reckon we want to talk about them to their faces 15:52:59 ttx: yeah, that's what I was thinking. I only asked for space for 13 to start 15:53:24 I will ping Kendall again today to see where things stand 15:53:31 cdent: i certainly prefer to talk about people to their faces ;) 15:54:40 Maybe we can get the lunch area? It would be great to have the board there if possible. 15:55:02 * mnaser is totally in support of that idea 15:55:22 Maybe instead of bemoaning not getting invited to board meetings, we just need to invite the board to our meetings. 15:55:27 ++ 15:55:35 there's some other big event going on over that weekend, so space is going to be tight 15:56:00 i think the only thing is as long as it stays a 'tc meeting', but i'm sure we won't have a problem with that 15:56:16 that was my other question: what do we actually want to talk about? 15:56:17 Maybe we can all get train tickets and just take over a car and ride around the city all day. 15:56:43 dhellmann: https://wiki.openstack.org/wiki/Technical_Committee_Tracker i think is a good start 15:56:46 cue train ascii art 15:56:49 dhellmann: isn't september too far away to be agenda building? 15:56:59 we can get a lot of that hashed out imho 15:57:03 I reckon it depends on how far we've got on some things 15:57:10 With the board, I would like more discussion about FOundation direction for expanding to other areas and what projects we're bringing on board. 15:57:23 smcginnis: ++ 15:57:31 but if we haven't finished it yet, I reckon two things: tech vision and board interaction 15:57:43 smcginnis: AIUI wherever the board has quorum it becomes a Board Meeting and then it's a whole Thing 15:57:55 True 15:58:23 this would be "other board members who will be at the PTG" so not necessarily enough people to trigger quorum 15:58:41 yeah, i don't anticipate a majority of the board will travel to the ptg 15:58:56 most of the elected individual directors likely will 15:59:15 dhellmann: yeah, I think this is fine, just thinking about why 'just invite the board to our meetings' might not be a solution in general 15:59:28 and a few of the appointed directors are also active contributors in the trenches as well 15:59:42 I've suggested we wait to invite anyone else until we have more details about space, and I've pinged Kendall to see what the status on that is. I'll let you all know when I have more info. 16:00:00 and I need to drop offline for a while, unfortunately, but please do carry on without me 16:00:25 I think we are done :) 16:01:01 thanks everyone! 16:01:05 #endmeeting