Tuesday, 2018-06-26

*** kumarmn has joined #openstack-tc00:05
fungii love that it was so obviously not intended for review, yet not only did they -1 it they didn't even leave a comment explaining why00:05
zanebI'm like 90% sure it's a bot00:07
fungii'm, like, 90% bot anyway00:08
fungiso who am i to judge?00:08
fungianyway, yes, gives 99cloud contributors a bad reputation00:09
*** edmondsw has quit IRC00:37
*** kumarmn has quit IRC01:01
*** kumarmn has joined #openstack-tc01:31
*** kumarmn has quit IRC01:36
*** rosmaita has quit IRC01:40
TheJuliahas anyone attempted to engage the reviewer?01:46
*** harlowja has quit IRC01:46
*** mordred has quit IRC01:49
*** kumarmn has joined #openstack-tc02:02
*** kumarmn has quit IRC02:07
*** mordred has joined #openstack-tc02:08
*** kumarmn has joined #openstack-tc02:24
*** kumarmn has quit IRC02:30
*** kumarmn has joined #openstack-tc02:35
*** kumarmn has quit IRC02:40
*** ricolin has joined #openstack-tc02:42
*** kumarmn has joined #openstack-tc02:47
*** kumarmn has quit IRC02:51
*** kumarmn has joined #openstack-tc02:59
*** kumarmn has quit IRC03:04
openstackgerritMichael Johnson proposed openstack/governance master: Octavia asserts supports-upgrade  https://review.openstack.org/57796703:18
openstackgerritMichael Johnson proposed openstack/governance master: Octavia asserts supports-accessible-upgrade  https://review.openstack.org/57797003:26
*** dims has quit IRC04:30
*** guvnah has quit IRC04:30
*** dims has joined #openstack-tc04:35
*** diablo_rojo has quit IRC04:37
*** e0ne has joined #openstack-tc05:13
*** openstackgerrit has quit IRC06:04
*** e0ne has quit IRC06:08
*** tosky has joined #openstack-tc07:41
*** jpich has joined #openstack-tc08:05
*** e0ne has joined #openstack-tc08:05
*** jaosorior has quit IRC08:39
*** cdent has joined #openstack-tc08:57
cdenteveryone and tc-members09:00
cdent#startmeeting tc09:01
openstackMeeting started Tue Jun 26 09:01:57 2018 UTC and is due to finish in 60 minutes.  The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot.09:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:01
*** openstack changes topic to " (Meeting topic: tc)"09:02
openstackThe meeting name has been set to 'tc'09:02
cdenti guess we are still doing this09:02
cdent#chair ttx09:02
openstackCurrent chairs: cdent ttx09:02
ttxDid we come to a decision for a TC workshop meet ? Several conferences were floated as potential anchor points for a workshop09:03
* ttx may CFP to OpenSource Summit EU in Edinburgh09:04
ttx(deadline July 1st)09:04
cdentI don't think that conversation got much further. I suppose we either need to have it in email or at the thursday office hour09:05
ttxcdent: re Basic "OpenStack" design tenets chapter for the Project Team Guide, I think I'll just draft a base content and propose it as a review. Baby steps09:05
cdentseems a good plan09:06
ttxWill try to come up with something today09:06
ttxcdent: I'd like to point to API guidelines, what's the best doc pointer I shall use ?09:07
*** ricolin has quit IRC09:07
cdentprobably http://specs.openstack.org/openstack/api-wg/#guidelines09:07
ttxgreat, thanks09:07
* ttx reviews progress on the brainstorming at https://etherpad.openstack.org/p/tech-vision-201809:09
cdentI added a couple of notes there yesterday, but nothing huge09:11
cdentI suspect part of the challenge there is we are trying to define what we see at the same time as what we want to see09:12
ttxyeah, which is why I think agreeing on terms and history is a first step09:12
ttxbecause it feels like we are trying to frame it as two completely opposite views, using strong terms, and in the end it's not that different09:13
cdentI think there was an initial goal of trying to describe those two different views as a way of understanding the issues, but that may be misleading.09:14
ttxlike "collection of abstraction layers"... isn't every software some collection of abstraction layers ?09:14
cdentI think that could be translated as "more assembly required"09:15
cdent(rather than "some assembly required")09:15
ttxcould you expand on that ?09:15
ttxbecause I feel like I'm missing something09:16
cdentI may be wrong, but when people use the phrase "collection of abstraction layers" they are saying "there's not enough here for you to install it and run a cloud, you need to put some pieces together, below and above what's provided by openstack to have a 'real' cloud"09:17
*** dtantsur|afk is now known as dtantsur09:18
cdentthe more positive spin on that is: these people allow you to build a cloud that works for you in the way you want it to OR with these pieces you can create the basis for a marketplace of added value09:18
cdentall of those descriptions lack something that is important to the people who want OpenStack to be "a cloud"09:19
ttxCloud construction kit vs. Cloud product with options ?09:19
cdentthe missing piece is "this is the same software and interface from installation to installation and you can use them all the same way"09:19
cdentpretty much, yeah09:19
ttxOK, so historically we shied away from seeing it as a "product", giving the "construction kit" aspect more weight, but today, some (at least me) are taking the opportunity to have more of a product approach (like with the map), so we could have a more opinionated product with options09:21
ttxThat evolution creates some tension, plus additional discussions as the "product" could go multiple ways09:22
cdentyes, and there's also a sort of divergent or middle ground:09:23
cdentthat's the model of "just" infrastructure which doesn't have enough of the user interface and user experience layers to be "a cloud" but is tightly focused on what were traditionally the "core" projects within openstack. Some people like that model because it is narrow and think focus would be used.09:25
ttxMy analogy would be whether we want to do old-style Lego boxes where you'd just get a set of random bricks with an  example booklet of things you could build with it, or new-style lego box where you are supposed to build something, even if you can obviously hack it into something else.09:25
cdentI'm sometimes in that camp out of frustration and desire to reduce noise.09:25
cdentthat's a useful analogy09:25
ttxcdent: ok, taking that analogy one step too far, that would be wanting a box with only the most basic lego blocks in, because we could actually do a great job at producing that.09:28
cdentyes, it's like the highest quality basic lego blocks; on this foundation you may build castles in the sky09:28
cdentbut I think that understates the product-ness of a good infrastructure as a service service09:29
ttxThe real question being -- what do people want ? OpenStack was pretty successful in adoption with its "let's do all the shapes" approach -- consumers were mostly complaining that it's hard to communicate what it is, not that they don't get what they need09:29
cdentthings like "this is the best way for you to host cloud foundry or kubernetes"09:29
cdentrather than "this is the best way for you to have your own cloud"09:29
ttxcdent: I see09:30
cdentjust to be clear: I'm not stating my own opinion here (I've not fully formed mine), more trying to illuminate the options and ideas09:30
ttxTrick is, people out there are using it in all shapes and forms. Which I think is a good thing. We build technology that enables people09:31
cdentIn an ideal world with time and money what we would be doing is making the best public cloud to replace amazon, gc and azure. But I'm pretty sure we're not in that world, so I'm trying to keep my mind open :)09:31
ttxheh, yes. thanks, that was useful, i think I understand the discussion a bit better now09:32
cdentYes, people do use it in all shapes and sizes but if there are limited contribution resources we have to have some way to choose.09:32
cdentSo to some extent what we're trying to do with a techincal vision is figure out a way to make sure the right people are showing up and for those people who are already here to know what to work on.09:34
cdentright now we have a model which is driven in fairly bizarre ways that I struggle to track. The number of actual _users_ who want all the complexity added by NFV is presumably quite small. But companies want it.09:34
cdentthat's a complex calculus09:35
cdenteffort to audience ratio09:37
* ttx has fun researching lego box pictures09:45
*** openstackgerrit has joined #openstack-tc10:04
openstackgerritThierry Carrez proposed openstack/project-team-guide master: Meetings no longer have to be in meeting channels  https://review.openstack.org/57805510:04
ttxHmm, we should close the office hour10:04
*** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/"10:04
openstackMeeting ended Tue Jun 26 10:04:49 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:04
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.html10:04
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.txt10:04
openstackLog:            http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.log.html10:04
*** cdent has quit IRC10:09
*** jaosorior has joined #openstack-tc10:29
*** cdent has joined #openstack-tc10:31
cdentthis thread on tempest release model is interesting and seems like it could be problematic: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html10:42
cdentand the adjutant review feels stuck: https://review.openstack.org/#/c/553643/10:45
*** rosmaita has joined #openstack-tc11:09
openstackgerritThierry Carrez proposed openstack/project-team-guide master: Evolve project setup into a tech guidance chapter  https://review.openstack.org/57807011:31
*** rosmaita has quit IRC12:32
*** mriedem has joined #openstack-tc12:51
*** edmondsw has joined #openstack-tc12:58
*** ian_ott has joined #openstack-tc13:01
cdentthank you dhellmann13:03
cdentyour struggle with taking things seriously13:04
cdentjaypipes: I appreciate your responses to the tc reports. Even if I don't agree, have any kind of attempt at a discussion is the _entire_ point. So, yeah, good, and thanks.13:17
jaypipescdent: I responded to you ML post because you had said the TC was listening in the paragraph I quoted... in the absence of not quite knowing a more appropriate way of raising the topic publicly.13:18
cdentseems a reasonable approach13:19
cdentIn this case I at least partially agree with you13:20
*** dtantsur is now known as dtantsur|brb13:22
*** frickler has quit IRC13:26
*** frickler has joined #openstack-tc13:26
*** evrardjp has joined #openstack-tc13:28
*** evrardjp_ has quit IRC13:30
dhellmanncdent : can you join #openstack-oslo so we can chat about the config env var spec? (assuming you have some time)13:39
*** e0ne has quit IRC13:39
cdentyeah, sure, now is no worse than any other time :)13:39
*** hongbin has joined #openstack-tc13:42
smcginniszaneb, fungi: I'm pretty sure that account is a bot. They were tailing me for a bit yesterday. Within a minute of every +2 I did during a reviewing block they showed up with a +1.13:43
smcginniszaneb, fungi: And not in a way that could have just been coincidence.13:43
smcginniszaneb, fungi: I've tried emailing them and when that failed I tried leaving comments after they had voted on patches - never a response.13:43
zanebhmm, time to delete that account as spam?13:44
smcginniszaneb, fungi: I would actually like to have that account disabled. At least that would then force them to communicate to resolve things.13:44
*** e0ne has joined #openstack-tc13:44
smcginnisAt least with just disabling there is a chance to correct the behavior and educate them.13:44
fungisure, disabling is easy. providing them with any sort of detailed error message when their account ceases working isn't, so it'll presumably take them some time to figure out that they need to talk to someone (and who to talk to)13:46
smcginnisfungi: Yeah, my hope is having the account disabled will force them to come asking why things are no longer working for them.13:47
smcginnis"Why did my bot break?" :D13:47
smcginnisSince other means of communication have failed.13:47
smcginnisI've even had folks try to reach out on Wechat.13:48
fungiwould also be good to bring this situation to the attention of the first contact sig, since this was one of the primary drivers for their formation (contributors not knowing where to better focus their activity, employers tracking performance in ways which encourage such misbehavior)13:49
dhellmannfungi , smcginnis : which review is this?13:49
fungidhellmann: zaneb's example was https://review.openstack.org/57743213:49
dhellmannI see 99cloud in that email address. Maybe talk to gcb?13:50
dhellmannI'm not against disabling the account, fwiw13:50
smcginnisI had heard they actually were no longer with 99cloud, which was part of the difficulty contacting them.13:50
fungidiablo_rojo_phon: ^ one example worth discussing at the fcsig meeting13:51
smcginnisI assumed padding some stats while looking for a new job.13:51
dhellmannmakes sense13:53
*** jaosorior has quit IRC13:59
zanebthe account has only done 83 reviews, but 45 of them were yesterday14:06
*** scas has joined #openstack-tc14:09
zaneb42 of them within the space of 50 minutes. let's see if the same thing happens today14:14
smcginnisOh, maybe this is a new account. I wonder if we did end up disabling the last one and they just created a new one.14:15
dhellmannso maybe not a bot, but still not especially useful14:15
zanebI'll be particularly interested if all the -1s start showing up with a reply to the first inline comment of this form: https://review.openstack.org/#/c/577859/3/hooks/neutron_contexts.py@159 https://review.openstack.org/#/c/560317/15/nova/compute/provider_tree.py@56114:15
zanebsmcginnis: it has been around since at least august: https://review.openstack.org/#/c/491674/14:17
smcginnisI agree with this view.14:17
zanebbut not active again until april14:17
fungiyeah, noticed those yesterday too. some reviewer leaves a -1 with a nit or similarly innocuous first inline comment and then the reason for the -1 is in subsequent comments. this user follows up saying they agree with the nit comment and leaves a -114:18
zanebfungi: same account, or are other bots doing this too?14:18
zaneb(those are the only 2 examples from that account, but they also appear to be the only 2 -1s where a previous reviewer had left inline comments)14:19
fungizaneb: was when i was looking into other recent reviews from the account you pointed out yesterday14:20
scasrelated: i've seen similar stats-gaming behavior across a few of my repos from similar unidentified typing entities. a few five-char patches here and there14:21
scassame domain, which set my shifty eyes emoji off14:21
*** e0ne has quit IRC14:23
smcginnisscas: Any particular accounts consistently behaving that way?14:24
*** e0ne has joined #openstack-tc14:26
openstackgerritMerged openstack/project-team-guide master: Meetings no longer have to be in meeting channels  https://review.openstack.org/57805514:27
scassmcginnis: my most recent drive-by patch was apparently human-driven, or -- tin-foil hatting here -- some sort of cnn algorithm, but it's in a similar stats-gaming pattern: https://review.openstack.org/#/q/owner:wangqi+status:open14:31
smcginnisOh, actual patches. That's a little different than the bot-like reviews. At least there's maybe some value out of these.14:32
smcginnisNot a lot, but some. :)14:32
scasmy point being, they look like gaming behavior14:32
scasalmost like someone cares about stackalytics14:33
scasit could all be legitimate people that show up as maybe-bot-maybe-not, but it could be some tinfoil hat reason, too14:36
scasoccam's razor suggests the former14:37
scasa motivated, stimulated individual can appear bot-like through a certain lens14:38
*** dtantsur|brb is now known as dtantsur14:45
fungione of the places where occam's and hanlon's razors are at odds14:49
dhellmannI don't care if people are gaming stats as long as the activity they generate to do so doesn't interfere with regular work from the rest of the community.14:52
smcginnisYeah, I'm more interested in encouraging the bot-like reviews to turn into something useful.14:55
*** e0ne has quit IRC15:07
scasindeed. it's not much overhead for me, so long as it doesn't interfere with work i'm doing. one of those even prompted me to finish delivering a non-trivial overhaul, which led me to the eternal problem15:09
*** e0ne has joined #openstack-tc15:11
smcginnisThose little ones do still bother me. I know some teams have very limited core review time, so they can be an unwanted distraction. But on the other hand, teams in that situation can just choose to ignore them.15:17
fungii generally just ignore them, yes15:23
fungiwhen we get onto even newer gerrit with the "hashtags" feature, reviewers can tag them with something like "trivial" and then filter them from dashboards15:25
zanebjaypipes, cdent: can you summarise how you think e.g. Nova would look different if it contained just plumbing and no porcelain?15:30
cdentzaneb: the main things, as I understand it, are two:15:31
cdentthe management of neutron and cinder via nova would go away, that would go up a layer15:32
cdentand things like flavors would not be at the nova layer. nova would specify vm requirements in detailed statements of exact resources15:33
jaypipeszaneb: and all of the following: "shelve/unshelve", "instance groups", "boot from volume where nova creates the volume during boot", "create me a network on boot" (yes, I know I was a proponent of that at one point), "num_instances > 1 when launching"15:34
zanebfwiw I would personally love to see a lot of that complexity disappear. in my mind that stuff got added largely because we lacked the higher-level... stuff... that clouds like AWS have to let you compose services to build what you need15:39
jaypipeszaneb: while we're at it... all of the following would also go bye-bye: "evacuate", "host-evacuate-live", "resize where the user 'confirms' the operation", "force/ignore host", "security groups in the copmute API", "force delete server", "restore soft deleted server", "lock server", "create backup"15:41
zanebbut the folks who have always argued for the 'small stable core' or whatever, they say that we should have *less* higher layer services (which is the very problem, IMHO, that has driven _more_ complexity into Nova)15:41
*** ricolin has joined #openstack-tc15:42
zanebjaypipes: yes!15:42
jaypipeszaneb: yeah... nobody I know who argues for a small stable core (in Nova) has ever said there should be fewer higher layer services.15:42
jaypipeszaneb: I'm not entirely sure where you got that idea from.15:43
zanebjaypipes: I'm talking about people who said OpenStack should have a small stable core, and that therefore we should never have expanded beyond Nova/Cinder/Neutron, big tent was a terrible thing, &c. &c.15:43
jaypipeszaneb: I'm not going to get into the conversation about people misunderstanding what the big tent was and wasn't.15:44
zanebright, yeah, let's not :)15:44
jaypipeszaneb: but I think you may be confusing certain people saying that there should be *well-defined* interfaces between different layers of the infrastructure stack with some notion that higher layers were somehow not necessary.15:45
zanebjaypipes: this is a really interesting discussion, because I think we are thinking of different people15:46
jaypipeszaneb: folks like myself have long argued for a smaller interface and surface area for things like Nova. but nobody I know of that has argued for this has ever said that upper layers that do orchestration actions aren't useful or necessary.15:46
jaypipeszaneb: and if I'm being absolutely honest, there are certain vendors over the past 7+ years that have thought "well, we're not going to convince Nova (or Cinder, or whatever) to add our feature-du-jour into a core service, so let's either add our stuff to a higher-layer project and dump it on that community OR let's start our own project that we can have complete and total control over".15:49
jaypipeszaneb: and any discussion of the "layers of OpenStack" isn't going to be complete without acknowledging that reality.15:49
*** dklyle has quit IRC15:50
smcginnisI have seen what zaneb is saying where they want the API in nova to be able to boot from volume because they don't want another service that orchestrates that for them or to go to cinder and do stuff, then go to nova and do stuff.15:52
*** dklyle has joined #openstack-tc15:53
jaypipessmcginnis: I know this makes me sound like an asshole, but I really don't care.15:54
jaypipessmcginnis: it's our job to make an orchestration layer that hides those kinds of details from the types of users that don't want to do anything other than click a box in a GUI. and that's what Horizon is for.15:55
zanebooooh, was with you there right up to Horizon ;)15:55
jaypipessmcginnis: but my point is that it shouldn't be *Nova's* job to do everything for said user. Just like it's not Nova's job to provide a GUI for these users.15:55
jaypipeszaneb: well, I'm just pointing out that Horizon is one of those applications that needs to hide/massage certain plumbing details because their target users are accustomed to interacting with things in a certain way (i.e. using a GUI not a set of CLIs)15:56
smcginnisjaypipes: I agree, but I think zaneb's point earlier was that there was/is pressure from some people that wanted that.15:57
jaypipeszaneb: I'm not saying Horizon is *the* orchestration layer.15:57
jaypipeszaneb: nor am I saying anything negative about horizon at all15:57
zaneb(I was half-joking about the horizon comment)15:57
jaypipeszaneb: just pointing out that Horizon's users != Nova's users. and pretending that they are does both sets of users a disservice IMHO.15:57
jaypipessmcginnis: no doubt! and I was saying I don't see a problem in saying "hell no" to certain users and saying "you are looking for X. we are not X. we are Y. If you want/need X, then Z is the project you are looking for"15:59
zanebso here's the theory I've been working from: there exists (or at least, there used to exist) a group of people who want OpenStack to be a self-service VMWare replacement, and are vehemently opposed to it having any other services on the grounds that it will take resources away from pushing more features like "restore soft deleted server" into Nova (or something)16:01
zanebso my idea was to write an alternative, non-trolling mission statement for those people (as you can see I'm struggling with the non-trolling part)16:01
smcginnisPart of it too is we didn't have this higher level orchestration layer, so when folks wanted to add fancy-new-funcitonality, it was easier to accept the porcelain API into the project since there was no where else to direct their efforts to.16:02
zanebso that we could hopefully learn something from them (even though I completely disagree with what they're pushing for), instead of just ignoring them and letting them carp from the sidelines16:03
ttxsmcginnis: there still isn't16:04
zanebbut an interesting thing happened: jaypipes and cdent were I think collecting ideas for the 'alternative' mission statement, but those ideas actually turn out to be quite close in practice to the openstack-as-integrated-cloud mission statement as I see it16:04
ttxand now we have users that a refactoring would break16:05
jaypipes(sorry, on an allhands call atm...)16:05
smcginnisttx: Yep16:05
ttxI mean, I could totally support a split between nova-low and nova-high with a stable API in between16:06
zanebeither this is very good and we're much closer to consensus than we all thought, or there's still a group of 'free VMWare' people out there and we haven't correctly captured their perspective yet16:06
ttxbut seeing that getting to a hypervisor driver public API is hard enough, I don't think that's reasonable16:06
cdentI'm gonna go with "curating" rather than "collecting" because "collecting" sounds like I have some allegience to them, rather than just gathering them up for the sake comparison. I continue to be unsure about what I feel (which is why I'm into this exercise)16:07
cdentzaneb: I assume you saw the chat between ttx and me this morning?16:07
cdentI think thinking of it in terms of two views is insufficient16:08
cdentthere's free vware, there's free aws, there's free plumbing for openshift/k8s/cloud foundry/whatever, there's free $something_else16:08
*** e0ne has quit IRC16:09
*** harlowja has joined #openstack-tc16:12
fungii feel like a lot of the "less separate orchestration, drive more complexity into existing lower-level services instead" pressure came because we were getting end-user feedback filtered through deployers and operators (since in our ecosystem these are often separate folks). the users wanted more complex orchestration, the deployers/operators wanted to just be able to upgrade to newer nova or whatever16:12
fungiwhich added magic api support for those things without needing them to work out how to add yet another service and expose that to the users16:12
*** e0ne has joined #openstack-tc16:13
ttxbeen slicing org diversity under a new dimension: calculating organizational bus factor / individual bus factor for a given series. I wonder if that would not serve us better than the current metric16:13
ttxmnaser ^16:13
ttx(caveat: my script might be broken, and relies on stackalytics questionable data anyway)16:14
jrollfungi: that's an interesting take16:14
zanebfungi: yeah, I agree. in the early days it was very hard to add a new service and almost impossible to get anyone to deploy it, so there was pressure to push all of those features into the core APIs16:14
ttxbenefit in "individual bus factor" is that it exposes smaller projects too16:14
fungiwhen we added separate services for these additional pieces which users wanted, the users pressured providers to start adding them to their deployments. but the feedback we got on use cases was never "we want a separate service to do this"16:14
fungialso, relying on developer contributions from companies deploying and operating openstack often meant that the preferred solution they would attempt to develop was one which added complexity to existing services, to make things easier on themselves at the expense of leaving the software harder to maintain over the long term16:17
cdentI've long thought that we were predisposed to listen too much to deployers versus "end users"16:17
cdentnot that we shouldn't listen to deployers/ops but rather that it needs to be more balanced16:17
fungiwell, and we have a lot more direct lines of communications to people running openstack services in the field, but not so many to people using those services _except_ through said deploying/operating organizations16:19
zanebfungi: and also, the core APIs did not (and in many cases still do not) expose enough information to allow external services to build on top. hence why projects from Ceilometer through to the instance HA thing that I forget the name of have had to hack stuff into the compute nodes16:19
fungitotally agree there16:19
zanebFreezer too16:19
fungithat goes as much to the argument that it's hard to work within existing projects, to the point where even getting the api to expose those details is more work than just kluging around it16:20
scasttx: that's a metric i'm not happy to be near the top of, but it's definitely illuminating16:21
zanebthe thing I really want to achieve with the mission is to say to those projects: here's what we're trying to build around you, and why it would benefit you to e.g. expose events to the user so that other services can consume them16:22
zanebs/mission/technical vision/16:22
zanebso that they don't see the feature requests as hostile, but as an opportunity to simplify while making the whole project more powerful16:23
zanebhopefully I haven't demoralised any Nova cores by saying that :)16:24
*** jpich has quit IRC16:28
zaneb(Masakari was the thing I couldn't remember the name of)16:29
scasttx: my bus factor number might be higher if i didn't occasionally browbeat the other chef cores to broker review time. if i self-approved changes, i'd likely come in at a higher rate16:29
scasn.b. browbeat is heavily laden with sarcasm16:31
*** ricolin has quit IRC16:33
cdentn.b. browbeat is the name of my attorney16:35
*** e0ne has quit IRC16:35
fungieven more amusing if true16:39
smcginnisNathaniel Bryant Browbeat III, Attorney at Law16:44
* cdent has had a long day16:46
scasit's been a long week16:46
cdenttrue, already16:46
fungiis it only tuesday still?16:48
scasif i were to ratchet up my bus factor by a marginal factor, i'd probably have a release out the door and be able to close the loop on the release discussion i've had open regarding the chef cookbooks16:48
scasi've seen that as rather distasteful, but my thinking could be outmoded in that regard16:49
jaypipeszaneb: sorry, was on an allhands.. reading back now to respond to your ideas.16:53
*** harlowja has quit IRC17:10
jaypipesttx: interesting numbers on your rocky-2-bus-factor etherpad. Pretty much confirms my long-held opinion that deployment-related projects nearly always end up being vendor-heavy areas and should be treated more as products/derivatives than core projects...17:11
*** e0ne has joined #openstack-tc17:11
jrollit would be interesting to also add how many people from the org make up the number17:12
clarkbre porcelain and the example of get me a network. regardless of implementation I think whatever "boot me a compute instance" API the uesr talks to should rsult in simple functional networking for that instance17:12
jrolle.g. I suspect glance is 1 person, but ironic is many more17:12
jaypipesclarkb: no disagreement. I just don't think the Nova API should be that thing.17:13
clarkbthe user doesn't care how it is implemented as long as they don't need to go make a router, make a network, make a subnet, tie them all together in a manner that results in them working prior to making an instance17:13
jaypipesclarkb: that's pretty much exactly what Horizon is... fwiw17:13
clarkbjaypipes: this should also be doable without clicking buttons17:13
clarkbclicking buttons is highly inaccurate17:13
jaypipesclarkb: indeed.17:15
*** dtantsur is now known as dtantsur|afk17:15
clarkbpart of the problem in that specific case was that the details often end up being so site specific too17:15
clarkband our apis didn't expose to anyone willing to build it from scratch what was necesary to do so17:15
jaypipesclarkb: ftr, what you are describing is what https://github.com/jaypipes/enamel was originally the idea behind..17:16
jaypipesclarkb: just never followed up on it.17:16
clarkbsubnetpools made this slightly better but have largely only been implemented for ipv617:16
clarkb(basically the api is now, cloud give me something that will work and I will plumb it up rather than needing to determine that outside the apis somehow)17:17
scasfwiw, from the chef perspective, i'm not a vendor providing an openstack product. it's an itch that needed to be scratched that turned into a disorder17:18
*** e0ne has quit IRC17:18
clarkbjaypipes: I think nova net being there first also set expectations differently than neutron and from a development perspective this wasn't accomodated when we deprecated nova net17:20
jaypipesscas: ack. and OpenStack Ansible isn't a vendor either, even though a large portion of the contributor base for the project comes from Rackspace. My point was really that nobody can ever seem to agree on **anything** ever in deployment and packaging land, and as far as I am concerned, I'm happy to let (mostly distributions) battle things out on their own and reinvent things endlessly.17:21
jaypipesclarkb: no doubt17:21
dhellmannI wonder what OpenStack would look like if we only had 1 REST API service that talked to the other "services" via some other channel.17:21
jaypipesclarkb: same with nova-volume etc17:21
jaypipesdhellmann: it would look like kube-api.17:21
dhellmannI meant more how would these sorts of discussions be different and how would the interactions between teams be different.17:23
fungiis that what oaktree wants to be when it grows up?17:23
scasjaypipes: indeed. and it sometimes comes down to someone in my situation overriding packaging decisions than going back upstream to change it properly17:23
jaypipesscas: ack17:23
dhellmannfungi : I guess partly?17:24
dhellmannttx: I'm interested in understanding how the corporate bus factor is different from what we've been doing17:26
dhellmannttx: you may want to try the "who-helped" command set in the goal-tools repo17:26
dhellmannit likely needs to be extended and it definitely needs to be documented17:26
mnaserttx: interesting doc.  surprised but not surprised about swift17:29
mnaseralso.. designate = blizzard?17:30
mugsieyeah. eanderson is pretty active these days17:32
mnaseryay, that's cool17:34
notmynamettx: what/what are the cutoffs used for bold or not?17:40
scasover the past several months, chef openstack has been mostly me. stackalytics tells most of the truth only because i wait and pester people for time17:41
scasmy biggest takeaway is that i probably should have been self-approving changes to keep throughput at a higher rate, but that's the tech worker in me looking at it and not with the maintainer lens17:53
*** jaosorior has joined #openstack-tc18:13
*** gouthamr has quit IRC18:32
*** e0ne has joined #openstack-tc19:52
*** e0ne has quit IRC20:15
eanderssonwe are also active in autoscaling (senlin) and k8s (magnum)!20:15
*** cdent has quit IRC20:28
*** gouthamr_ has joined #openstack-tc20:29
*** gouthamr_ is now known as gouthamr20:29
dhellmannscas : having lots of self-approved patches would likely have triggered a different red flag20:31
scasdhellmann: as i figured, which is why i almost never do it20:32
* dhellmann nods20:32
scasit's tempting when my throughput is hindred by available eyes, but i tend to view what i do for openstack through the maintainer lens20:33
fungii also find that if i need to scratch my own itch, i can carry a local "fork" with my gerrit changes checked out or cherry-picked20:56
fungiwhile i wait (maybe months) for reviews20:56
fungias long as i'm willing to scrap or rework my fork while my proposed change evolves21:01
scasmy itch to scratch is making sure there's an upstream to follow :D21:14
*** zaneb has quit IRC21:17
*** cmurphy_vacation is now known as cmurphy21:22
dmsimarddhellmann: I have to self approve patches for ara but it's mostly because I'm the only core contributor. I keep myself honest by actually reviewing my things and having good test coverage. Given the choice, I would very much prefer another human reviewing my things :p21:23
*** gouthamr has quit IRC21:25
*** gouthamr has joined #openstack-tc21:26
*** zaneb has joined #openstack-tc21:29
eanderssonYea - reviewing is so important. It isn't always just to help catch mistakes, it's also to make code better in general, and to help personal growth.21:49
eanderssonNothing better than constructive feedback,.21:49
*** ian_ott has quit IRC21:51
*** mriedem has quit IRC21:52
*** mriedem has joined #openstack-tc21:56
scasindeed. my issues as a developer amplify a bit because of the scope of the work. sometimes changes have to be coordinated across 14-15 repos at a time, which takes even more time to review -- even if my integration labs are all happy and making success noises22:03
*** edmondsw has quit IRC22:04
*** edmondsw has joined #openstack-tc22:07
scasfrom time to time discussions of the platform come up, as one did this morning. my perspective has usually been from a stance of the sunk cost fallacy. for as much as i appreciate what github has done and brought, it's still a hard sell, at least for me personally, to bootstrap a new offshoot on another public platform in the spotlight for suboptimal reasons22:08
*** edmondsw has quit IRC22:11
scaswasn't my intention to go all confessional, but it did come up in the channel and does have some reflection on the bus factor and org diversity in my little corner22:19
*** mriedem has quit IRC22:21
*** hongbin has quit IRC22:36
*** tosky has quit IRC23:08

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