Tuesday, 2017-10-10

*** kumarmn has joined #openstack-tc01:32
*** kumarmn has quit IRC01:43
*** kumarmn has joined #openstack-tc01:43
*** kumarmn has quit IRC01:46
*** kumarmn has joined #openstack-tc01:47
*** rosmaita has quit IRC01:55
*** kumarmn has quit IRC02:19
*** flwang1 has quit IRC02:34
*** flwang1 has joined #openstack-tc02:52
*** kumarmn has joined #openstack-tc03:20
*** lukebrowning_ has joined #openstack-tc03:23
*** kumarmn has quit IRC03:24
*** lukebrowning has quit IRC03:26
*** lukebrowning_ has quit IRC03:47
*** lukebrowning has joined #openstack-tc03:48
*** flwang1 has quit IRC04:08
*** kumarmn has joined #openstack-tc04:20
*** kumarmn has quit IRC04:25
*** lukebrowning_ has joined #openstack-tc04:27
*** lukebrowning has quit IRC04:29
*** lukebrowning_ has quit IRC04:41
*** lukebrowning has joined #openstack-tc04:42
*** lukebrowning_ has joined #openstack-tc04:45
*** lukebrowning has quit IRC04:47
*** kumarmn has joined #openstack-tc05:21
*** kumarmn has quit IRC05:25
openstackgerritChangBo Guo(gcb) proposed openstack/governance master: Retired pylockfile  https://review.openstack.org/51075205:41
*** kumarmn has joined #openstack-tc07:23
*** kumarmn has quit IRC07:27
*** jpich has joined #openstack-tc07:35
openstackgerritMerged openstack/governance master: Adjustments to Infra contributors top-5 entry  https://review.openstack.org/50763708:19
openstackgerritMerged openstack/governance master: Masakari - Instances High Availability Service  https://review.openstack.org/50011808:19
openstackgerritMerged openstack/governance master: typo in masakari mission statement  https://review.openstack.org/50574208:20
*** kumarmn has joined #openstack-tc08:23
openstackgerritMerged openstack/governance master: Change email address of Zun PTL  https://review.openstack.org/50952308:27
*** kumarmn has quit IRC08:29
ttxTracker updated @ https://wiki.openstack.org/wiki/Technical_Committee_Tracker08:48
*** cdent has joined #openstack-tc08:54
ttxohai *09:01
smcginnisOffice hour time.09:01
cdenttc-members assemble, etc09:02
ttxsmcginnis: are you on European time this week, or just early?09:02
smcginnisttx: Thanks for updating the tracker. That is immensely helpful.09:02
smcginnisttx: Just can't sleep for some reason.09:02
ttxI had two topics. First one is our set of candidates, which I think looks good at this point09:03
* smcginnis is glad to see a few more names09:03
ttxI expect a few others to throw their name by the end of the day09:03
ttxI like the geographic diversity09:03
ttxnot sure that's a consequence of getting rid of meetings, by having done that will certainly facilitate their job is elected09:04
ttxMy second topic was Glare and what to do with that governance change at this point09:05
cdentthere seems to be a bit of ships passing in the fog on that09:05
ttxWe have good rules to affirm yes or no, but not so good rules when neither option gets  majority09:05
ttxcdent: ships passing in the fog sounds very English09:05
persiaAs someone who became unexpectedly entwined with it at PTG, I think it should either be explicitly postponed for a definite time period with clear goals to be met within that time or approved.09:06
ttxpersia: yes, that's what I was after09:06
smcginnisI do feel for them that we are just dragging it out.09:06
cdentttx that probably makes it an even more appropriate statement then: I think some of the confusion in the feedback is in the nuances of language people are perceiving09:06
persiasmcginnis: Sadly, some of the behaviours that have led to some of the downvotes are a result of approval-seeking from the time period involved.09:07
smcginnispersia: Yeah, I agree.09:07
cdentpersia: yeah, I think if we can scrape that off, that would help09:07
smcginnisThe biggest hangup is them targeting Glance.09:07
cdentit sometimes seems that glare will be whatever people ask it to be09:07
* ttx reads the review again to see if the comments there by the non-supporters are clearer09:07
smcginnisThey seemed agreeable to that in the meeting, but their history doesn't give a lot of confidence there.09:08
persiaI spent a lot of time with both the Glare and Glance teams at PTG, and there is a common plan to have both, with complementary functionality at this point.09:08
ttxThe others have a pretty clear situation. Mogan can be deferred until after Sydney, it's a young proposal anyway09:08
cdentI think the concerns about glare/glance are not all that relevant since we have several people from glance who are +109:08
ttxStackube is frozen while we figure out if including it in "openstack" is really the best move09:09
persiaBut, yes, Glare will be anything anyone indicates it needs to be to be approved, which complicates things.09:09
smcginnisThe thing I do like about it is it (at least claims) to address an NFV use case, and I feel that's an important and growing segment of our users.09:09
ttxBut Glare needs an answer09:09
ttxBeen on the docket since June, which is a bit embarassing09:09
smcginnisOK, let's say we do approve it and they end up coming back in a couple months with an agressive plan to shoulder out glance. What are our options if that happens?09:10
ttxI asked for clear requirements before it can be reconsidered, with limited success, then tried to sum it up more clearly09:10
smcginnisJust for arguments sake.09:10
persiasmcginnis: They will not do that.09:10
ttxsmcginnis: we can remove them09:10
smcginnispersia: Just hypothetically speaking, since that seems to be the concern some have with this.09:11
persiaThere are a large number of reasons, not least having to do with the personalities and affiliations of those involved.09:11
persiaIn that case, yes, the appropriate action is to remove the project.09:11
ttxThe "cost" is potentially a mascot design, if that's done between now and then09:11
ttxIt's arguably harder to say no later than say no now09:11
cdentI prefer to think of these things in terms of why we should say yes[1]. So far the only concrete thing I’ve heard is “it helps with the nfv use case”.09:13
cdent[1] I’d take this position with any application, I’m anti-growth.09:13
ttxAt this point I want to give them a clear answer. My personal choice would be to let them play and fix it if they don't follow the rules, but I'm OK with deferring, as long as we give a clear picture of when and how it will be reconsidered09:14
persiaIn effect, not providing an answer soon is to remove incentives for Glare to be cooperative.  I don't know the precise timeframe for this, but I had the impression that they needed to land in a sensible follow-up from PTG to continue to justify value in having Glare part of OpenStack.09:14
ttxcdent: under our current rules of approval (which we could change) we have to accept them if they "help with the openstack mission" and follow the 4 opensa nd basic principles09:15
cdentttx: right that was the other thing I was going to say: we seem to be struggling to follow our own rules; they’ve matched the criteria so we have no real basis on which to reject them.09:16
ttxcdent: would you say they don't help with the mission, due to providing no value and or causing unnecessary dilution?09:16
persiacdent: More interestingly, it covers backups, template files, etc.  That the generic object API can also be used for VNFs is a side-effect, rather than the main focus.09:16
cdentpersia: right and as I’ve said on the review if they are that generic why are they targetting openstack instead of the wide world?09:16
ttxcdent: "helping with the mission" gives us some flexibility to say no if we think openstack would be better off without it09:16
ttxcdent: that's fair09:17
cdentI think we’re really in a position where we stop dilly dallying and accept them because they’ve met the criteria, or change the rules.09:17
cdentIf we do choose to put them off, or reject then outright then we are obliged to update the rules.09:17
cdentotherwise we’re being jerks09:17
*** fanzhang has joined #openstack-tc09:18
ttxcdent: We have rejected/delayed projects in the past where we concluded that Openstack would be hurt but the addition09:18
ttxby the addition I mean09:18
cdentif the rules are a) follow the opens, b) cause no harm then I think the way forward is take them on good faith09:19
ttxSo if the objection is, we can't afford to make Glance position more fragile, we could reject it under the mission scope match09:19
cdentbut would like us to change the rules for the future09:20
ttxcdent: no, the rules are "is this helping with the mission"09:20
ttx(+ the 4opens/principles match)09:20
cdentI think the glance thing is a total red herring based on miscommunication: Mike was prompted by others to say that it could replace glane09:20
cdentand from there we went on a goose chase09:20
smcginniscdent: I'm not sure Brian would agree with that completely.09:21
smcginnisBut that did get maybe more focus than it should have.09:21
cdentokay, but brian did come back with a +109:21
ttxI'm not saying OpenStack is better off without Glare -- I wish there was more complementarity rather than scope overlap, but even that I don't think is a reason to consider OpenStack would be better off without it09:21
smcginnisYeah, the glance team seems a little hesitant, but behind coexistence.09:22
ttxOur rules say competition is OK, gratuitous competition is not. Artifact stuff started in Glance and was deemed out of scope, so the competition is not gratuitous09:23
ttxNow you could say two things09:23
ttx1/ thet Glance would be hurt so much by Glare that it will damage OpenStack as a whoe eas a result09:23
persiaMy understanding is that after the Glare vs. Glance session at the PTG, the Glance team is entirely behind coexistence.  The main issue being that they would like to support some of the glare features, but that this cannot easily happen because of the pain of changing the image API.09:24
ttx2/ that artifact storing is not really a IaaS thing and this should really be an outside project that we glue in09:24
ttxsame way as "we should not be in the business of building a time-series db09:24
ttxor a message queue09:25
ttxI don't believe in (1)09:25
ttxI could agree to (2)09:26
cdent(2) is where my concerns lie, but I don’t know that we have a strong enough statement about what “we” do for it to matter.09:26
ttxideally glance would retrieve artifacts on Glare, in an ideal world09:27
smcginnisI think (2) could be used as an argument against a lot of our projects.09:28
ttxSo we could totally say that the Glare design doesn't fit well with the way openstack is componentized now, so we'd rather not create a mess by having it "in" the official picture09:28
ttxsmcginnis: I remember that discussion from when we considered zaqar09:29
ttxthat one took a very long time too09:29
*** david-lyle has quit IRC09:29
ttxin the end it's zaneb who pleaded the need for internal message queueing that won the day09:30
ttx(for cloud apps to use)09:31
smcginnisMaybe we need to define what OpenStack "is".09:31
* smcginnis ducks09:31
ttxBut this is arguably a storage engine with versioning, so it sits auite close to what the various galnce-stores provide09:32
* cdent gives smcginnis a hard hat09:32
* ttx gets the paintball gun09:33
* smcginnis puts on eye protection09:33
persiasmcginnis: That isn't a safe discussion.  I've been in it before a couple times (and with cloud software not yet called "OpenStack"), without useful result.  The best solution I've seen to the discussion is "The stuff that *we* want to store in repos", where "*we*" is typically defined in terms of current and expected future community participants.09:33
ttxI mean, there is certainly a need for artifact storing in the open source world09:34
ttxbeyond what openstack could make of it09:34
persiattx: Glare cannot provide some of the guarantees that Glance provides, upon which Nova depends, without significant extra development in Glare (which is no longer planned).  Glance cannot support artifacts with metadata outside that required for disk images.  If we could go back in time, there would only be one, but that cannot happen today (or likely at any point in the next several years).09:34
ttxArtifactory claims to be "the first, and only, universal Artifact Repository Manager on the market"09:35
ttxand it's open core09:35
ttxcdent: so I think for (2) we are missing use cases that make it "cloud"09:37
ttxi think there are some (NFV is one)09:37
ttxso I'm still fine with it being in09:37
cdentunfortunately we haven’t got the people who are most opposed in the room right now09:38
cdentdoug and sean seemed pretty keen to wait09:38
ttxBut I can see that some still object for the (1) reason, and why some find it not enough cloud-specific and still object for teh (2) reason09:38
ttxYes, we are missing key people09:39
cdentI’m currently at a sort of +0 state.09:39
persiaAs I understood it, NFV support by Glare was proposed to ETSI at PTG, and depends on ETSI's current choice to have images be in zipfiles, rather than anything Glance compatible.  The ETSI folk were happy to discuss alternate models with the Neutron folk, and may be adjustable.  Glare should be accepted (or not) because of the project activity and nature, rather than because it matches the "NFV" keyword.09:39
ttxWe should try to cover that at the Thu 1500 office hour09:39
cdentjohnthetubaguy seems to still be concerned about the image api, despite assurances from several parties09:39
ttxpersia: that's part of fungi's objection aiui. Glare is not a solution for a cloud problem we have, it's a solution actively looking at cloud problems to solve09:40
ttxheck, I could use it to replace tarballs.o.o09:41
ttxwe do produce artifacts around here09:41
persiaAs I understand it, Glare is used in production by an OpenStack deployer for storing Heat Templates and Database backups.  I believe all the other solutions that Glare has targeted have been the result of confusion about how to be approved as a project.09:41
ttxpersia: yes, that's fair. We asked for use cases so they looked for them09:42
persiaI certainly don't believe using Glare to replace Glance or to support special custom NFV images are sensible targets.09:42
ttxAnyway, i agree this discussion between people who actually support the Glare addition is a bit useless09:42
ttxLet's punt to the Thu 1500utc office hour and try to have sdague dhellmann fungi johnthetubaguy around then09:42
johnthetubaguysorry, I am half around right now, if that is useful09:43
ttxAlso would be great to see where the others fall. cdent is +009:43
ttxflaper87 seems to be +0.509:43
persiaI don't have a vote, but if I did., it would be +0.  I just have lots of PTG context.09:44
ttx(i.e not expressed, but his comment lean toward +1)09:44
ttxIt could also be fair to reboot the discussion once we have the new members, since it's a tight discussion09:45
johnthetubaguypersia: were does heat normally store templates? I don't think its 'normally' glare as such?09:45
ttxAlthough I REALLY feel like we owe them an answer by now09:45
johnthetubaguyttx: I thought the answer is no, given the current state of the world? There are various things that could make that a yes in the future.09:46
johnthetubaguyor does no need more no votes?09:47
persiajohnthetubaguy: As I understand it, on the user's filesystem.09:47
ttxjohnthetubaguy: that's where the balance is right now, since I'm the only one on +1 and there are a few on -1. No majority yet though09:47
ttxyes it needs 3 more no votes to be properly killed.09:47
ttxotherwise we are in limbo delay09:48
ttxonly 5 votes expressed over a total of 13 though, so there is clearly space09:48
ttxerr, smcginnis just voted, so 609:48
smcginnisLeaning on the positive side, though I have to say not that strongly.09:49
ttxI'm not a strong +1 either. I just feel like we owe them a decision, and I'm leaning slightly toward +1 at this point09:50
johnthetubaguyttx: So turns out I haven't been through the process for a no before, makes total sense, just hadn't joined the dots there (doh!)09:50
ttxI'm fine if the NO wins, if we express the why clearly09:50
johnthetubaguyI am not sure we have a majority on the reason for the no, although I suspect most no people are +1 fungi's comments on scope.09:51
ttxWe have delayed things in the past withuot waiting for 7 No votes, when that's where the consensus lied09:51
persiaIt is my understanding that Glare will be fine with NO, if expressed clearly, although some of the individuals may be unhappy with the effort they have put in to date.09:51
johnthetubaguyits not no to the existence of the project, its no to it being OpenStack in its current state.09:52
johnthetubaguyif those are the same thing, there are other problems...09:52
persiaI do not believe those are the same thing, based on the information I have.09:52
ttxLet's continue that discussion on Thursday when most of the stakeholders will be around09:53
johnthetubaguyttx ++09:53
ttxbut I kinda want to take a final decision then09:53
*** dtantsur|afk is now known as dtantsur09:53
ttxanything else to discuss ?09:54
* ttx looks up the tracker09:54
ttxMogan will be an interesting one too, but I want to see where F2F discussion gets us in Sydney09:55
ttxcdent: any progress on the Neutron driver team situation ?09:55
cdentI sent mail to the main parties last week, but haven’t had a response yet. I need to ping miguel to make sure he got it.09:56
ttxsmcginnis: I flagged https://review.openstack.org/#/c/506263/ for abandonment, seems like Lee's patch makes it irrelevant09:56
smcginnisttx: Yep. Was just waiting a little to see how the nova and cinder discussion went.09:57
smcginnisttx: I can abandon that now if you want. Looks like there's actually interest in having it.09:57
johnthetubaguyttx: as a heads up I am quite anti-Mogan at this point, and I can't be in Sydney, largely because it feels like a bad direction for SDK users.09:57
cdentI hope the mogan discussion can be positive. I _really_ don’t want the nova heritage to anchor mogan.09:57
cdentanti-jinx! :)09:58
johnthetubaguycdent: yup09:58
ttxjohnthetubaguy: SDK users ?09:58
ttxI'll probably have to dive into the Mogan proposed API to understand what baremetal-native functions actually look like09:59
johnthetubaguyttx: for creating baremetal, there are lots of users of the Nova API, and an ecosystem around that, seems strange to bisect that with Mogan10:00
persiaAt PTG, The Ironic team seemed surprised that Mogan might be a thing: it is probably good to make sure they are represented in discussion in Sydney10:00
cdentIsn’t that kind of the point? We want to do baremetal without nova.10:00
johnthetubaguycdent: I am thinking purely the end user of the system here, not the operator10:01
cdentme too10:01
smcginnisYeah, I think it could actually improve the SDK experience since it's not trying to shoehorn bare metal in virtual machine API semantics.10:01
cdentIt’s possible there are new users who don’t want to use, care, know or be constrained by the nova api10:02
johnthetubaguycdent: that I agree with, it just sounded more like those nova folks are hard to work with, so we created this new thingy to add these three features nova is being very slow to add10:02
cdent(hell, it’s even possible that there are new vm users who would be incredibly pleased to see an alternate vm api, but that can of worms can wait)10:02
ttxIf https://wiki.openstack.org/w/images/thumb/3/39/Mogan-why.png/600px-Mogan-why.png is correct, it's not just a workaround Nova10:03
johnthetubaguyttx: so I am current adding the RAID and firware stuff10:03
ttxjohnthetubaguy: if Nova is planning to cover the Mogan-only part of that Venn diagram, yes it's a different story10:04
johnthetubaguyttx: we spoke about implimenting resize at the PTG (can't 100% remember the use case now, but it was fairly strong)10:04
johnthetubaguynow its doing it all in a Nova way, which might be different to what Mogan users want, which is a different thing10:04
ttxwe are also saying that Nova is too big and we should split off whatever we can whenever we can10:05
cdentttx: we say that, but does nova say that?10:05
ttxcdent: I think they do. it's just hard to?10:06
ttxThe work on placement certainly looks like a scheduler split10:06
* cdent raises an eyebrow10:06
cdentodds at this point of placement ever being extracted seem very low10:06
cdentthere will always be a reason for why not10:07
ttxAh, thought it was still on the roadmap :)10:07
* johnthetubaguy hopes cdent is wrong on the placement split10:07
cdentI hope I am too10:07
cdentbut we keep coming up with reasons otherwise10:07
ttxAlright. I need to ru, I'm on lunch duty10:07
cdentand part of the reason why I think mogan is a potentially good idea is because it is _already_ separate10:07
ttxrun even10:07
cdentand why I’ve been keen on cyborg, blazar, etc10:07
cdentstart outside10:07
ttxand masakari10:08
cdentif you want to be outside10:08
* cdent nods10:08
ildikovcdent: are those reasons or excuses?10:08
cdentildikov: for placement not extracting. a mix.10:08
smcginnisI hope placement gets split out. I know there is some sentiment that it's use shouldn't be expanded until it's its own thing.10:08
johnthetubaguy+1 on it being a mix10:08
cdenta lot of just comes down to resources10:08
ildikovyeah, the resources part is tough10:09
cdentbut also we’ve now worked ourselves into a corner where getting it out may be quite an undertaking, unless we break some rules (which I would be happy to break)10:09
ildikovrules, like?10:10
cdentone rule being that it needs to be a separate database10:10
cdentI think it would be fine for the placement project to continue talking to the nova api database10:10
cdentno migration required10:10
*** lukebrowning_ has quit IRC10:11
ildikovcan that be looked at as a TODO?10:11
cdentdepends on who you ask10:11
smcginniscdent: Is that the "right" place though given long term plans for placement?10:11
ildikovI mean moving to the split out direction with items to fix later10:11
johnthetubaguyits the landing all the migrations in Nova for a thing that isn't in Nova that seems odd10:11
cdentthe idea that we have lots of little database might also be odd10:12
*** sdague has joined #openstack-tc10:12
cdentsmcginnis: not the long term right place10:12
cdentbut I guess what I’m saying is that I think a lot of that stuff can be managed outside the confines of the project code; it’s just data10:13
johnthetubaguythe split would need staging, and this needs discussion, which loops back to resources really10:13
* cdent nods10:13
ildikovjohnthetubaguy: +110:14
ildikovbut overall it still points to splitting it out and the resources part is something that can be worked on10:15
cdentanother bit of unfortunate is that we’ve had some options for self-healing built into nova’s use of placement, but we are slowly moving those things10:15
cdentthat means a sort of greenfield switchover for deployments will not be possible (wherein a new placement service is in place and all clients report inventory and allocations at startup)10:16
cdentoverall, the limitations aren’t really technical, they are more process and many are self imposed10:17
cdentbut in all of those cases, yes, resources is a limiting factor10:17
ildikovcdent: as in most of the cases10:17
ildikovcdent: could this be a sort of cross-project effort to move this forward?10:18
ildikovcdent: there's also a SIG forming around 'self-healing'10:18
cdentI’m not sure. If we were to state such a thing now-ish there would be a lot of resistance from the people building stuff with placement right now along the lines of “please, can i just get this done before you make me think about yet more stuff”10:18
smcginnisDefinitely not looking favorable for spreading adoption. I don't think cinder will use it.10:18
smcginnis"Sure, you can run cinder standalone. Just install an entire OpenStack cloud to get all the depencies."10:19
cdentsmcginnis: yeah, it’s got a taint10:19
*** lukebrowning has joined #openstack-tc10:22
ildikovhmm, fair enough10:23
*** kumarmn has joined #openstack-tc10:26
*** lukebrowning has quit IRC10:27
*** kumarmn has quit IRC10:30
flaper87ttx: re Glare, I'm actually +1, I should vote10:40
*** dtantsur has quit IRC11:04
*** dtantsur has joined #openstack-tc11:08
*** dtantsur has quit IRC11:08
*** dtantsur has joined #openstack-tc11:09
*** dtantsur has quit IRC11:09
*** dtantsur has joined #openstack-tc11:13
*** lukebrowning has joined #openstack-tc11:23
*** rosmaita has joined #openstack-tc11:24
*** kumarmn has joined #openstack-tc11:27
*** kumarmn has quit IRC11:31
*** kumarmn has joined #openstack-tc12:27
*** kumarmn has quit IRC12:32
* mordred waves at all the nice people12:50
fungiwow, i missed a very active office hour!12:57
*** david-lyle has joined #openstack-tc13:06
*** kumarmn has joined #openstack-tc13:06
fungito be clear, my position on glare is not to postpone/defer if we're unsure but to reject, with clear feedback on our reasons for the rejection so they know what they should have addressed if they see any value to reapplying some time in the future. and i'm not worried that they're still setting their sights on replacing/obsoleting glance (or barbican, or...) but rather that such prior behavior is13:14
fungiindicative of a lack of any clear plan and scope for their project13:15
fungijumping at prospective use cases in hopes of making the project seem relevant, rather than working to improve the use cases they already had (i.e., a repository for heat templates, which might also be usable for other things once people have it in place)13:17
persiaI wonder if perhaps the "talk about project statuses" meetings should be postponed to later in the week next PTG.  That the Glare/TC meeting was prior to the Glare/Glance meeting was unfortunate, and while those who attended the Glare/Glance meeting are voting both for and against approval, it seems that those who didn't attend are uncertain, perhaps because of uncertainties expressed by the Glare team in the Glare/TC meeting (as the Glance input13:17
persiawas not yet available).13:17
persiafungi: To be fair, they were asked to "demonstrate use cases".  I won't go too far as an apologist, but I will claim that there was some apparent agreement in focus on Glare's core goals as a result of the Glare/Glance discussion.13:18
fungiyeah, maybe i'll accept that there could have been unclear communication by the tc and/or language barrier causing them to interpret that as "come up with more ways people could start to use this" when what we wanted was "how is this being used?"13:25
*** lbragstad has joined #openstack-tc13:28
persiaAnd, to be fair, it's all hearsay, so that might also not be the case (or be a post-facto explanation)13:29
fungii'd probably be +1 if they had a small, focused, achievable scope of the things it's already mostly being used for and then they could expand their scope in reasonable ways (with patches to their mission statement in governance) as those new facets look viable13:30
cdentfungi: that’s pretty much how I feel too13:30
fungia shared repository for heat templates seems like it could further the openstack mission13:32
persiaMy impression was that this was thought to have been achieved a couple cycles back, and considered insufficient (in part, perhaps, from lack of clear support and guidance: the Glance team, being the natural shepherds, were distracted with other concerns), leading to confusion.  Maybe I'm wrong about dhellmann's suggested addition to the top0-513:33
*** zaneb has quit IRC13:33
*** kumarmn has quit IRC13:35
*** kumarmn has joined #openstack-tc13:35
*** kumarmn has quit IRC13:35
*** kumarmn has joined #openstack-tc13:36
*** kumarmn has quit IRC13:38
*** kumarmn has joined #openstack-tc13:38
smcginnispersia: Good point. That may be better to do that part later in the week.13:41
*** zaneb has joined #openstack-tc13:45
*** zaneb has quit IRC13:50
*** hongbin has joined #openstack-tc13:54
dhellmannon glare, I attended the glance/glare meeting but not the tc discussion earlier in the week. It's clear to me that the glare team is asserting that they're going to stop trying to push glare as a replacement. I'd like to observe that before I +1 adding the project.14:05
dhellmannpersia : it's not clear to me why you're objecting to recruiting people to manage goals and to recognize people who do other sorts of cross-project work.14:06
dhellmannor maybe I misunderstand your comment there entirely14:07
persiadhellmann: I'm obecting to making a top-5 claim that we don't have those folk.  I believe recruiting is important, but think that this should be done throughout all the other documentation, so that people appreciate that supporting others is a critical step towards gaining stature and recognition.14:11
persiaIt's mostly that I don't believe recruiting stewards and shepherds is an achieveable task, in that it cannot be "done".14:11
persiaThat said, the specific situation where the team with the most knowledge and capability to steward Glare was so overwhelmed so as not to be able to do so is a good example of why we perhaps need a lot more immediately (or at least to help expose the ones that exist, so folk know who to contact), after which effort it can go back to a high-priority background activity.14:13
persiaIf that is an accurate statement of the current state of affairs, then perhaps I should be less unhappy with the idea of a top-5 goal in this area.14:14
dhellmannpersia : the top 5 list is a place to point out need. the fact that we have a few people today does not mean we have anyone for the future.14:17
dhellmannand putting that need on the list is a way to then say to companies, "here is an area you may not know we need your help with"14:17
persiaIn terms of companies, I think we need less of that, and more clear documentation on how companies can nakedly pursue their objectives successfully.  A roadmap for horse-trading and (transparent and open) collusion.14:18
persiaBut I have yet to step up to write the "company contribution guide", as hasn't anyone else, so perhaps such a statement is a useful interim means of requesting time of folk who can do that.14:19
dhellmannwell, I think the communities we're trying to build are very different then14:19
persiaFor clarity, the behaviours that bother me are 1) contributing organisations refusing to share their agenda, and then complaining when they are unable to achieve their agenda, perhaps including statements about how OpenStack is not a functional community, etc.14:21
persia2) contributing organisations that instruct staff to "go work upstream", and then choose to fund or defund staff based on whether they happen to be working on marterials of corporate interest14:21
persia3) Contributing organisations that seek to hire the most expensive and popular of the community as a means to "buy influence", rather than hiring more junior folk, so we can all get more done.14:22
persiaI believe all of these behaviours would be reduced by transparent collusion, wherein the contributing orgs specified what they wanted to achieve, and the level of commitment (perhaps expressed in FTEs) they would be willing to make to achieve that.14:23
persiaI don't believe that sort of collusion would undermine the general openness and transparency of the community at large.14:23
* cdent is intrigued14:23
persiaDo you still believe we seek different end states?14:23
mugsiepersia: for 3) there is also organisations that get a lot of more junior devs, and then tell them to "go work upstream" with no guidence, which is equally as bad14:23
*** zaneb has joined #openstack-tc14:24
dhellmannthat was all part of what the product management working group was supposed to do, but never did14:24
persiamugsie: yes, but if the contributing orgs were enabled to pursue agenda, they could tell folk what to do :)14:24
mugsieexpressing committment by FTE would be a bad thing in my book14:24
dhellmannI would be happy for more transparency in agendas. I don't think that precludes us also saying that we need companies to give people time to do enough cross-project work to learn what they need to know to join the tc or have other leadership roles in the community.14:24
persiadhellmann: Yes.  I don't think we got the right people in the room in the Janaury 2015 meeting in California.  I still beleive that is the right model.14:25
dhellmannwell, I remember a room full of product managers in a room in Atlanta(?) where several of us told them to share their needs and resources and they said they would.14:26
persiadhellmann: I think you and I are saying the same thing differently.  I think contributing orgs should be incentivised to fund coordinators, facilitators, etc. as a means to more effectively accomplish their goals.  I hear you saying that you think contributing organisations should allocate more of their resources to champions, shepherds, and stewards, or the community will not be healthy enough to support their goals.14:27
dhellmannmaybe we are then. I see the top-5 list as a path to adding that incentive.14:28
persiaYes.  My issue with the folk who were sent to Atlanta is that few of them had budget authority to allocate resources.14:28
dhellmannthe idea is to go to sponsoring companies (gold and platinum) and ask them directly for help with that list.14:28
dhellmannincluding, especially, *prospective* gold and platinum members14:29
persiaI guess I'm just a little uncertain that the best way to get that sort of folk is to ask for them, rather than more aggressively hunt within the ranks for people already doing it, and help them get recognition for doing it more widely.14:30
persiaI really don't like the idea of asking Gold/Platinum members to contribute resources to X.  That reinforces the emerging idea that OpenStack is a play-to-play game.14:31
dhellmannI think we have fewer people doing that sort of work now than we used to, so looking to the same people to do more isn't going to help us grow the next generation of leadership.14:31
persiaRather, I think the call should be to all existing and potential contributing orgs.  No reason a firm needs to spend X in order to hire a couple people.14:31
dhellmannthere are already questions about committing resources in the sponsor application, this list just makes some areas the community needs more visible.14:32
persiaI'm not suggesting asking people to do more.  I'm suggesting asking the people who are doing the detail coordinatoin on some little issue or between teams within a project to step up, and asking other developers to help out on the little stuff.  A path to success.14:32
dhellmannit's not like I'm going to turn away help from someone who isn't a sponsor, that's just a place that we can focus to start14:33
dhellmannasking everyone to do something has never worked for us as well as asking a small group directly14:33
* persia thinks the sponsor application is largely irrelevant: only organisations that either 1) beleive they must be in openstack to stay operational, or 2) have had success achieving goals in openstack are even interested in being sponsors.14:33
dhellmannwe have to start somewhere14:33
fungion persia's desire #3 and mugsie's counter-concern, there is also an underside to that where companies who are divesting from community involvement are laying off talented and embedded contributors and it would be nice if other companies who wanted to hire experienced upstream contributors could pick those people up as opposed to a) hiring away already effective upstream contributors, or b) dumping14:33
fungipeople who have never heard of free software on us and hoping we'll find time to mentor them all to effectiveness14:34
persiaThen perhaps we are trying to build different communities (although I don't have as much time to help as I'd prefer)14:34
mugsiefungi: ++14:34
persiaTo be fair, I only ever find that someone does what I ask when I ask one person at a time (sometimes that person represents a group).  Asking fewer people is easier.  Asking everyone takes time, but as is the same with going to every door in a given town with a clipboard, it can be time well spent to achieve a wider goal.14:35
cdentthis is becoming a refrain: “asking everyone to do something has never worked for us as well as asking a small group directly” and it makes me nervous for reasons I’m unable to articulate14:36
cdentit feels a bit like a flip side of a coin that says “command and control is the only effective road to success”14:37
cdentI know that’s _not_ what it is saying14:37
persiacdent: +114:37
cdentbut it feels like it, somehow14:37
persiaI believe that is the effect of succumbing to that narrative.14:37
dhellmanncdent : I mean something similar to what persia said: Talking directly to people is more effective than blanket requests sent to large groups.14:37
dhellmann"Pat, will you help me" gets a better response rate than "Help!"14:38
cdentit also feels a bit like a surrendering the idea of “this is important so people will want to work on it” and fighting against a kind of decline14:38
fungipat is a remarkably helpful individual14:38
cdent(which might be legit)14:38
persiadhellmann: And I suppose where I perceive our intent to differ is that, if I had the time, I'd rather spend it asking *everyone*, starting mostly with the smaller sponsors of the local user group meetings (who often have 1-2 FTEs available to allocate), rathe than starting with the folk already contributing a lot.14:38
cdentdhellmann: yeah, totally hear that, which is why I’m trying to couch it in “this is not what people are saying, but part of what I’m hearing"14:39
persiaAnd I'm more interested in folk who aren't foundation sponsors, because the same money can be a fair number of FTEs, especially in lower cost-of-living locations.14:39
dhellmannpersia : looking at our existing crop of community leaders, how many fit that profile?14:39
persiaOn the Ops side, I'd say 80%.14:39
persiaFor UC, probably 60%14:39
dhellmanndoing upstream cross-project leadership work?14:40
persiaIn the developer community, maybe 20-30%, mostly because folk who don't have large backing *need* to operate cross-project to be effective.14:40
persiaNote that in UC and Ops, "upstream" is defined as the deliverables for those groups, rather than raw coding.14:40
dhellmannI'm more concerned with the contributor community.14:41
persiaAlthough within Ops, there's a fair amount of work done to maintain various patches collaboratively whilst they work their way into mainline.14:41
sdaguecdent: my experience with organizing any activity which is voluntary is that direct asks are pretty much the only way to get hard things done. You can have general asks of low commitment transactional stuff to grow the pool of people that you can direct ask, but except in *very* rare circumstances do you get leaders out of general asks.14:41
persiaI'm unconcerned with the contributor community.  The number of folk who do so from love is vanishingly small.  The remainder are told what to do.  If they are ineffective, that says something about what they are told.14:41
cdentsdague: you’re focusing in on the “ask” thing, and that’s not what I’m commenting on. I agree that asking people directly finds people and gets shit done.14:42
persiaAnd if we lose many of them, if there are orgs that want to pay to tell people what to develop, the same individuals can be hired (although I'd like more transparency there, as fungi suggested)14:42
dhellmannwell, that's the problem I'm trying to address here14:42
persiawhich one: that contributing orgs seem incapable of telling their folk what to do in a sensible way, or that there are an insufficient number of volunteers who work on openstack without payment?14:43
cdentsdague: on the other hand, I don’t consider openstack voluntary14:43
cdentpeople volunteer for thiings, sure14:43
cdentbut their engagment is not voluntary, it is employment14:43
cdentI “volunteered” for the tc because I think it makes me and openstack more effective14:44
persiacdent: Take care: there are at least 10s of volunteers (not much in the face of it all, but not absent, and some very active indeed)14:44
cdentpersia: that’s why I used the word “I” and “consider” when stating my opinion14:44
dhellmannI don't expect openstack to ever turn into a "for fun" project for a large number of people. I am concerned that orgs funding people do not understand the community needs, and I am trying to make it easier to highlight those needs so that we can say to them "if you want openstack to be healthy and include your thing, we need your help over here"14:44
cdentto try and make it clear it was mine, and other people may have different ones14:44
persiaApolgies: my comment was about "their engagement is not voluntary", and I should have waited to press <enter>14:44
cdentdhellmann: that’s nicely concrete14:45
cdentin that sense the top-5 list is a tool14:45
cdentand I hope it works14:45
persiadhellmann: Quite honestly, I think it would be much more advantageous to come up with a new name for the influencers, and request contributing org involvement (dropping the current organsation that seems to have gone off the rails).  Dumping a bunch of "stewards" into the environment with no direction isn't going to help that much, and telling random developers "spend more time cross-project" also doesn't help them figure out how to do that  (with14:46
persia results much like the spelling fixes)14:46
persiaBut perhaps I'm mistaken, and there is enough support to receive an injection of those folk that could accomplish great things.14:47
dhellmannso you think that item should be more specific?14:47
persiaI think so.  I think my problem with it might just be the wording, although I'll have to have some more thought to suggest any alternative.14:48
dhellmannwe need goal champions for rocky. we need people to champion some things that are *not* goals, or not *yet* goals. we need people to help finish the work on the existing goals that weren't completed.14:48
persiaAs I said in my comment, I fear the current language might put off people who are currently doing some of that work in an unacknowledged way.14:48
dhellmannwe need people to keep up with projects like the cinder/nova multi-attach thing that ildikov has been trying to drive for forever now14:48
persiaHaving explicit reference to goals to be achieved and specific names that go against them (or not) would remove all of my concerns, although I think that's a slightly different ask.14:49
dhellmannI'll think about how to add some more detail14:49
smcginnisdhellmann: ++14:49
ildikovdhellmann: we're almost there now :)14:49
dhellmannildikov : keep up the good work! ++14:50
ildikovdhellmann: thanks :)14:51
ildikovdhellmann: I need to read back to see the topic, but from my experience for activities that are less trivial and need more projects to accomplish it's good to have a driver14:51
dhellmannas far as recognition, I'd like to see us celebrate folks doing this sort of work in keynotes at the summits. mention a few people every summit, show a picture maybe, say "thank you" as a community.14:51
ildikovdhellmann: helps with cross team communications as well on the specific topic and sometimes maybe overall as well14:52
dhellmannildikov : we were discussing https://review.openstack.org/#/c/510656/114:52
cdentdhellmann: I think that’s potentially useful, but has a risk of disenfranchising people who have been grinding away in a project for N months.14:52
dhellmannwell, maybe we should ask PTLs to pick someone from their project to celebrate, too14:53
ildikovdhellmann: looks great, thanks for pushing this14:53
cdentemployee of the month!14:53
dhellmannno, it wouldn't come with a parking spot, just a "thank you"14:53
cdentfree pass to the front of the zuul queue14:54
persiaThese models don't scale.  As with PTLs, better to have some repo somewhere that highlights nicks, terms covering an issue, and "Thanks" when they complete (or hand off to a successor).14:54
ildikovI think a "thank you" is many times worth way more than a parking spot14:54
persiaSOmeone else can scrape it and turn it into marketing candy14:54
dhellmannoh, man, CI priority would be an awesome gift14:54
dhellmannpersia : you're focused on the implementation details. We don't say "thank you" as a whole community at all right now.14:55
ildikovmriedem sent out a 'Thank you' mail not long ago to the Dev ML and I think that was a great way to point out when people are doing outstanding work and a nice gesture as well14:55
dhellmannildikov : I missed that, do you remember when it was?14:55
ildikovdhellmann: one sec, I will dig it up14:55
persiadhellmann: Fair14:56
ildikovdhellmann: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120975.html14:57
dhellmannildikov : thanks, that's a great example14:58
ildikovdhellmann: +114:58
smcginnisI think there's a #thanks bot now too.15:00
cdentto go along with success?15:03
smcginnisYeah, something similar. I think thingee was working on it.15:04
cdent#thanks smcginnis for telling me about thanks15:06
* cdent listens15:06
smcginnisHah, maybe not in the channel? Can't find the eavesdrop link, but I'm pretty sure I saw something.15:07
smcginnisThanks cmurphy. See, I'm not crazy.15:08
smcginnisAh, -infra. I was looking in the -dev logs.15:08
cdentwe live in a big wide world15:08
*** kumarmn has quit IRC15:22
*** kumarmn has joined #openstack-tc15:23
*** kumarmn has quit IRC15:27
thingee#thanks cdent for showing me thanks bot is broken?15:47
cdentis it maybe just not here?15:47
thingeeI don't know how to fix that15:48
smcginnisThankless bot.15:50
*** kumarmn has joined #openstack-tc15:51
*** kumarmn_ has joined #openstack-tc15:53
openstackgerritLance Bragstad proposed openstack/governance master: Add policy artifacts for magnum  https://review.openstack.org/51092015:53
*** kumarmn has quit IRC15:56
thingeeI have in draft a superuser post about the thankless bot. Someday they'll know.16:06
*** kumarmn has joined #openstack-tc16:24
*** kumarmn_ has quit IRC16:26
*** kumarmn has quit IRC16:35
*** kumarmn has joined #openstack-tc16:36
*** jpich has quit IRC16:39
*** kumarmn has quit IRC16:41
*** kumarmn has joined #openstack-tc16:41
*** kumarmn has quit IRC16:56
*** kumarmn has joined #openstack-tc16:56
*** kumarmn has quit IRC17:04
*** kumarmn has joined #openstack-tc17:21
*** lukebrowning has quit IRC17:24
*** lukebrowning has joined #openstack-tc17:24
*** kumarmn has quit IRC17:25
fungicdent: we need openstackstatus to /join17:27
fungithingee: ^17:28
fungii'll push a patch17:28
*** persia has quit IRC17:30
*** SamYaple has joined #openstack-tc17:31
*** flwang1 has joined #openstack-tc17:32
cdentfungi: thanks, I couldn’t remember which repo that stuff’s in17:37
fungitook me a second too17:37
*** dtantsur is now known as dtantsur|afk17:38
cdentmy mind was doing a “somewhere there’s a yaml file for this"17:39
dhellmannit's yaml files all the way down17:40
dimswhoa, i am really liking everyone throwing their hat in the ring for TC17:42
dhellmannyeah, I'm happy to see some new candidates17:42
fungiyes, i'm thrilled. this will be an exciting race!17:43
fungicounting the elections page, announcements to the ml and open reviews it looks like we could have at least 16 candidaets17:47
fungiand there's still time for more nominations. we could easily end up with 3x as many candidates as open seats17:48
fungiwhatever we've all been doing to encourage more people to run, it seems to be working17:49
*** kumarmn has joined #openstack-tc17:52
cdentand here I was worried there wouldn’t be people17:56
fungicould be there's a bit of a snowball effect too. people see others they know and with whom they relate stepping up to run, and realize that yes they absolutely can do the same thing17:59
*** persia has joined #openstack-tc18:07
*** kumarmn has quit IRC18:28
*** kumarmn has joined #openstack-tc18:28
*** kumarmn has quit IRC18:33
*** flwang1 has quit IRC18:34
*** flwang1 has joined #openstack-tc18:35
*** flwang1 has quit IRC18:35
*** flwang1 has joined #openstack-tc20:20
*** openstackgerrit has quit IRC20:33
cdentthese tc reports are getting increasingly difficult to write21:10
flwang1cdent: thank for sharing your thoughts. i'm reading it ;)21:11
cdentyou’re welcome21:11
cdentI think the reason it is getting hard is because I’ve got too many things on my mind21:12
flwang1true, maybe it's because you're touching more corners of the community21:13
cdentmay be21:15
flwang1cdent: but I just want to say it's a really good thing to see your report which give me a different angel to the work happening in TC21:17
cdentI’m glad, that’s part of the reason I do it, so that there’s multiple points of view.21:18
flwang1yep. I think you raised a great point in the #41 report,  how to use the power21:19
flwang1we (maybe just me) always think TC have power to manage/govern the community21:19
flwang1but TBH, we don't know what's the power, the scope, the strength21:20
cdentI used to think that way, and often still do, but it’s not really the case21:20
flwang1so sometimes, we're expecting more21:20
flwang1as you can see in my candidacy, personally, I think it's a tricky/hard time for openstack, so we may need some change in case we lost21:21
cdentI agree21:22
flwang1back to the power, if most of the contributors believe TC have the power, can't we get the power really?21:23
cdentI think the power is there to be exercised if people figure out the best ways to do so.21:24
cdentMany people want it to be.21:24
cdentBut there are other people who don’t, who feel that the role of the TC is correctly highly constrained21:25
cdentThat doesn’t necessarily have to change, it may just be that the TC can provide a forum for individuals to exercise their own power more effectively21:26
flwang1cdent: so do we have a central place documented the scope of the "power" of tc?21:26
cdentsort of, let me find you some links21:28
flwang1to be clear, I'm not asking TC to do something out of their responsibilities, I'm trying to figure out, can/how tc help the community to work together tighter?21:28
cdentthe four links at the top of https://wiki.openstack.org/wiki/Technical_Committee_Tracker are good starting points21:28
flwang1I'm quoting this "each project is fairly autonomous" from your report21:29
cdentI think a lot of that kind of thing comes down to a style of leadership that draws attention to alternative ways of doing things21:29
flwang1good words21:29
cdentand that was quoting dtroyer when he was talking to you, I think21:29
flwang1cdent: haha, thanks for correcting me21:30
flwang1but I'm not quite like it, TBH21:30
cdentmy mistake really, I don’t do a great job of referencing the blog posts21:30
flwang1that could work at the beginning of OpenStack21:30
flwang1but I don't think it works well for now21:30
cdentyeah, I’m not certain that “having a nice chat about opportunities” works that great when dealing with say a conflict between a big old project like nova and say a new project like cyborg21:31
flwang1so it's like using many autonomous projects to beat a well-designed, well-integrated product, like vsphere, aws, azure21:33
flwang1i hope you can get my point21:33
cdentOne of the things that’s exciting about the current batch of TC candidates is that many of them come from parts of the community that have been under-represented in the past. This could mean a change in style21:33
cdentI do21:33
cdentthat’s a long running topic of discussion in openstack21:33
cdenta lot of people don’t think it is openstack’s job to beat vpshere, aws, azure. the job, instead, is to provide the buidling blocks that would allow someone else to do so21:34
cdentI think that’s passing the buck21:34
flwang1true, somebody still think that in that way, but I think that's the thing TC need to clear21:35
flwang1things changed21:36
flwang1we can't always hold the belief which we believe 5 years ago21:36
flwang1in other words, even though taking openstack as  building blocks, we do need to make sure they can working well together21:37
flwang1flaper87 told me stop complaining, just do it, so i'm stand up to find the gaps and try to fill them :D21:39
cdentthat’s great21:40
cdentwe should all remember [t 1fAc] all the time21:41
purplerbot<flwang1> we can't always hold the belief which we believe 5 years ago [2017-10-10 21:36:41.239041] [n 1fAc]21:41
flwang1cdent: good to see a English native speaker like my words21:42
cdentit’s very well said21:42
flwang1cdent: let me give you more samples if you like21:43
flwang1zaqar got 3 reviews from incubation to integrated, all failed21:43
flwang1we got some real challenges like:21:44
flwang11.  why Zaqar, as a message service, want to supprt FIFO?21:44
flwang1then, AWS's SQS start to support FIFO about 1 or 2 years ago21:45
* cdent nods21:45
flwang12. Why zaqar use Falcon as the wsgi framework instead of pecan+wsme?21:45
flwang1do you remember the email sent by the pecan/wsme maintainer ask for help?21:46
flwang1those are good samples for "we can't always hold the belief which we believe 5 years ago"21:46
cdentI remember being drafted to be a core of wsme, because no one else would be21:46
flwang1we need to embrace the changes21:47
flwang1happy to making noisy21:49
cdentthat’s part of what I was trying to say with regard to mogan being an opportunity to break some of the trends21:49
cdentdoing things differently can sometimes be a good thing21:49
flwang1cdent: holding the old things with changes is always easy than making changes21:50
flwang1but if we want to grow instead of staying at the comfort zone, we need changes21:50
flwang1though some of them looks like killing ourselves21:51
* cdent nods21:51
flwang1we could fail, but that's the way we learn21:51
*** sdague has quit IRC22:39
*** cdent has quit IRC23:02
*** hongbin has quit IRC23:22
*** rosmaita has quit IRC23:34
*** harlowja has joined #openstack-tc23:59

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