| *** kumarmn has joined #openstack-tc | 00:05 | |
| fungi | i 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 why | 00:05 |
|---|---|---|
| zaneb | I'm like 90% sure it's a bot | 00:07 |
| fungi | i'm, like, 90% bot anyway | 00:08 |
| fungi | so who am i to judge? | 00:08 |
| fungi | anyway, yes, gives 99cloud contributors a bad reputation | 00:09 |
| *** edmondsw has quit IRC | 00:37 | |
| *** kumarmn has quit IRC | 01:01 | |
| *** kumarmn has joined #openstack-tc | 01:31 | |
| *** kumarmn has quit IRC | 01:36 | |
| *** rosmaita has quit IRC | 01:40 | |
| TheJulia | has anyone attempted to engage the reviewer? | 01:46 |
| *** harlowja has quit IRC | 01:46 | |
| *** mordred has quit IRC | 01:49 | |
| *** kumarmn has joined #openstack-tc | 02:02 | |
| *** kumarmn has quit IRC | 02:07 | |
| *** mordred has joined #openstack-tc | 02:08 | |
| *** kumarmn has joined #openstack-tc | 02:24 | |
| *** kumarmn has quit IRC | 02:30 | |
| *** kumarmn has joined #openstack-tc | 02:35 | |
| *** kumarmn has quit IRC | 02:40 | |
| *** ricolin has joined #openstack-tc | 02:42 | |
| *** kumarmn has joined #openstack-tc | 02:47 | |
| *** kumarmn has quit IRC | 02:51 | |
| *** kumarmn has joined #openstack-tc | 02:59 | |
| *** kumarmn has quit IRC | 03:04 | |
| openstackgerrit | Michael Johnson proposed openstack/governance master: Octavia asserts supports-upgrade https://review.openstack.org/577967 | 03:18 |
| openstackgerrit | Michael Johnson proposed openstack/governance master: Octavia asserts supports-accessible-upgrade https://review.openstack.org/577970 | 03:26 |
| *** dims has quit IRC | 04:30 | |
| *** guvnah has quit IRC | 04:30 | |
| *** dims has joined #openstack-tc | 04:35 | |
| *** diablo_rojo has quit IRC | 04:37 | |
| *** e0ne has joined #openstack-tc | 05:13 | |
| *** openstackgerrit has quit IRC | 06:04 | |
| *** e0ne has quit IRC | 06:08 | |
| *** tosky has joined #openstack-tc | 07:41 | |
| *** jpich has joined #openstack-tc | 08:05 | |
| *** e0ne has joined #openstack-tc | 08:05 | |
| *** jaosorior has quit IRC | 08:39 | |
| *** cdent has joined #openstack-tc | 08:57 | |
| cdent | everyone and tc-members | 09:00 |
| ttx | o/ | 09:01 |
| cdent | #startmeeting tc | 09:01 |
| openstack | Meeting 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:01 |
| *** openstack changes topic to " (Meeting topic: tc)" | 09:02 | |
| openstack | The meeting name has been set to 'tc' | 09:02 |
| cdent | i guess we are still doing this | 09:02 |
| cdent | #chair ttx | 09:02 |
| openstack | Current chairs: cdent ttx | 09:02 |
| ttx | Did we come to a decision for a TC workshop meet ? Several conferences were floated as potential anchor points for a workshop | 09:03 |
| * ttx may CFP to OpenSource Summit EU in Edinburgh | 09:04 | |
| ttx | (deadline July 1st) | 09:04 |
| cdent | I don't think that conversation got much further. I suppose we either need to have it in email or at the thursday office hour | 09:05 |
| ttx | cdent: 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 steps | 09:05 |
| cdent | seems a good plan | 09:06 |
| ttx | Will try to come up with something today | 09:06 |
| ttx | cdent: I'd like to point to API guidelines, what's the best doc pointer I shall use ? | 09:07 |
| *** ricolin has quit IRC | 09:07 | |
| cdent | probably http://specs.openstack.org/openstack/api-wg/#guidelines | 09:07 |
| ttx | great, thanks | 09:07 |
| * ttx reviews progress on the brainstorming at https://etherpad.openstack.org/p/tech-vision-2018 | 09:09 | |
| cdent | I added a couple of notes there yesterday, but nothing huge | 09:11 |
| cdent | I suspect part of the challenge there is we are trying to define what we see at the same time as what we want to see | 09:12 |
| ttx | yeah, which is why I think agreeing on terms and history is a first step | 09:12 |
| ttx | because 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 different | 09:13 |
| cdent | I 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 |
| ttx | like "collection of abstraction layers"... isn't every software some collection of abstraction layers ? | 09:14 |
| cdent | I think that could be translated as "more assembly required" | 09:15 |
| cdent | (rather than "some assembly required") | 09:15 |
| ttx | could you expand on that ? | 09:15 |
| ttx | because I feel like I'm missing something | 09:16 |
| cdent | I 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 dtantsur | 09:18 | |
| cdent | the 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 value | 09:18 |
| cdent | all of those descriptions lack something that is important to the people who want OpenStack to be "a cloud" | 09:19 |
| ttx | Cloud construction kit vs. Cloud product with options ? | 09:19 |
| cdent | the 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 |
| cdent | pretty much, yeah | 09:19 |
| ttx | OK, 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 options | 09:21 |
| ttx | That evolution creates some tension, plus additional discussions as the "product" could go multiple ways | 09:22 |
| cdent | yes, and there's also a sort of divergent or middle ground: | 09:23 |
| cdent | that'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 |
| cdent | s/used/useful/ | 09:25 |
| ttx | My 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 |
| cdent | I'm sometimes in that camp out of frustration and desire to reduce noise. | 09:25 |
| cdent | that's a useful analogy | 09:25 |
| ttx | cdent: 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 |
| cdent | yes, it's like the highest quality basic lego blocks; on this foundation you may build castles in the sky | 09:28 |
| cdent | but I think that understates the product-ness of a good infrastructure as a service service | 09:29 |
| ttx | The 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 need | 09:29 |
| cdent | things like "this is the best way for you to host cloud foundry or kubernetes" | 09:29 |
| cdent | rather than "this is the best way for you to have your own cloud" | 09:29 |
| ttx | cdent: I see | 09:30 |
| cdent | just to be clear: I'm not stating my own opinion here (I've not fully formed mine), more trying to illuminate the options and ideas | 09:30 |
| ttx | Trick is, people out there are using it in all shapes and forms. Which I think is a good thing. We build technology that enables people | 09:31 |
| cdent | In 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 |
| cdent | s/an/my/ | 09:32 |
| ttx | heh, yes. thanks, that was useful, i think I understand the discussion a bit better now | 09:32 |
| cdent | Yes, 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 |
| cdent | So 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 |
| cdent | right 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 |
| cdent | that's a complex calculus | 09:35 |
| cdent | effort to audience ratio | 09:37 |
| * ttx has fun researching lego box pictures | 09:45 | |
| *** openstackgerrit has joined #openstack-tc | 10:04 | |
| openstackgerrit | Thierry Carrez proposed openstack/project-team-guide master: Meetings no longer have to be in meeting channels https://review.openstack.org/578055 | 10:04 |
| ttx | Hmm, we should close the office hour | 10:04 |
| ttx | #endmeeting | 10: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 | |
| openstack | Meeting ended Tue Jun 26 10:04:49 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:04 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.html | 10:04 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.txt | 10:04 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-26-09.01.log.html | 10:04 |
| *** cdent has quit IRC | 10:09 | |
| *** jaosorior has joined #openstack-tc | 10:29 | |
| *** cdent has joined #openstack-tc | 10:31 | |
| cdent | this thread on tempest release model is interesting and seems like it could be problematic: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html | 10:42 |
| cdent | and the adjutant review feels stuck: https://review.openstack.org/#/c/553643/ | 10:45 |
| *** rosmaita has joined #openstack-tc | 11:09 | |
| openstackgerrit | Thierry Carrez proposed openstack/project-team-guide master: Evolve project setup into a tech guidance chapter https://review.openstack.org/578070 | 11:31 |
| *** rosmaita has quit IRC | 12:32 | |
| *** mriedem has joined #openstack-tc | 12:51 | |
| *** edmondsw has joined #openstack-tc | 12:58 | |
| *** ian_ott has joined #openstack-tc | 13:01 | |
| cdent | thank you dhellmann | 13:03 |
| dhellmann | ? | 13:04 |
| cdent | your struggle with taking things seriously | 13:04 |
| cdent | jaypipes: 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 |
| jaypipes | cdent: 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 |
| cdent | seems a reasonable approach | 13:19 |
| cdent | In this case I at least partially agree with you | 13:20 |
| *** dtantsur is now known as dtantsur|brb | 13:22 | |
| *** frickler has quit IRC | 13:26 | |
| *** frickler has joined #openstack-tc | 13:26 | |
| *** evrardjp has joined #openstack-tc | 13:28 | |
| *** evrardjp_ has quit IRC | 13:30 | |
| dhellmann | cdent : 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 IRC | 13:39 | |
| cdent | yeah, sure, now is no worse than any other time :) | 13:39 |
| *** hongbin has joined #openstack-tc | 13:42 | |
| smcginnis | zaneb, 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 |
| smcginnis | zaneb, fungi: And not in a way that could have just been coincidence. | 13:43 |
| smcginnis | zaneb, 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 |
| zaneb | hmm, time to delete that account as spam? | 13:44 |
| smcginnis | zaneb, 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-tc | 13:44 | |
| smcginnis | At least with just disabling there is a chance to correct the behavior and educate them. | 13:44 |
| fungi | sure, 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 |
| smcginnis | fungi: 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?" :D | 13:47 |
| smcginnis | Since other means of communication have failed. | 13:47 |
| fungi | sure | 13:47 |
| smcginnis | I've even had folks try to reach out on Wechat. | 13:48 |
| fungi | would 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 |
| dhellmann | fungi , smcginnis : which review is this? | 13:49 |
| fungi | dhellmann: zaneb's example was https://review.openstack.org/577432 | 13:49 |
| dhellmann | I see 99cloud in that email address. Maybe talk to gcb? | 13:50 |
| dhellmann | I'm not against disabling the account, fwiw | 13:50 |
| smcginnis | I had heard they actually were no longer with 99cloud, which was part of the difficulty contacting them. | 13:50 |
| dhellmann | aha | 13:51 |
| fungi | diablo_rojo_phon: ^ one example worth discussing at the fcsig meeting | 13:51 |
| smcginnis | I assumed padding some stats while looking for a new job. | 13:51 |
| dhellmann | makes sense | 13:53 |
| *** jaosorior has quit IRC | 13:59 | |
| zaneb | the account has only done 83 reviews, but 45 of them were yesterday | 14:06 |
| *** scas has joined #openstack-tc | 14:09 | |
| zaneb | 42 of them within the space of 50 minutes. let's see if the same thing happens today | 14:14 |
| smcginnis | Oh, 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 |
| dhellmann | so maybe not a bot, but still not especially useful | 14:15 |
| zaneb | I'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@561 | 14:15 |
| zaneb | smcginnis: it has been around since at least august: https://review.openstack.org/#/c/491674/ | 14:17 |
| smcginnis | I agree with this view. | 14:17 |
| zaneb | but not active again until april | 14:17 |
| zaneb | lol | 14:17 |
| fungi | yeah, 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 -1 | 14:18 |
| zaneb | fungi: 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 |
| fungi | zaneb: was when i was looking into other recent reviews from the account you pointed out yesterday | 14:20 |
| scas | related: 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 there | 14:21 |
| scas | same domain, which set my shifty eyes emoji off | 14:21 |
| *** e0ne has quit IRC | 14:23 | |
| smcginnis | scas: Any particular accounts consistently behaving that way? | 14:24 |
| *** e0ne has joined #openstack-tc | 14:26 | |
| openstackgerrit | Merged openstack/project-team-guide master: Meetings no longer have to be in meeting channels https://review.openstack.org/578055 | 14:27 |
| scas | smcginnis: 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:open | 14:31 |
| smcginnis | Oh, actual patches. That's a little different than the bot-like reviews. At least there's maybe some value out of these. | 14:32 |
| smcginnis | Not a lot, but some. :) | 14:32 |
| scas | my point being, they look like gaming behavior | 14:32 |
| scas | almost like someone cares about stackalytics | 14:33 |
| smcginnis | Definitely. | 14:33 |
| scas | it could all be legitimate people that show up as maybe-bot-maybe-not, but it could be some tinfoil hat reason, too | 14:36 |
| scas | occam's razor suggests the former | 14:37 |
| scas | a motivated, stimulated individual can appear bot-like through a certain lens | 14:38 |
| *** dtantsur|brb is now known as dtantsur | 14:45 | |
| fungi | one of the places where occam's and hanlon's razors are at odds | 14:49 |
| dhellmann | I 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 |
| smcginnis | Yeah, I'm more interested in encouraging the bot-like reviews to turn into something useful. | 14:55 |
| dhellmann | ++ | 14:55 |
| *** e0ne has quit IRC | 15:07 | |
| scas | indeed. 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 problem | 15:09 |
| *** e0ne has joined #openstack-tc | 15:11 | |
| smcginnis | Those 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 |
| fungi | i generally just ignore them, yes | 15:23 |
| fungi | when we get onto even newer gerrit with the "hashtags" feature, reviewers can tag them with something like "trivial" and then filter them from dashboards | 15:25 |
| zaneb | jaypipes, cdent: can you summarise how you think e.g. Nova would look different if it contained just plumbing and no porcelain? | 15:30 |
| cdent | zaneb: the main things, as I understand it, are two: | 15:31 |
| cdent | the management of neutron and cinder via nova would go away, that would go up a layer | 15:32 |
| zaneb | \o/ | 15:32 |
| cdent | and things like flavors would not be at the nova layer. nova would specify vm requirements in detailed statements of exact resources | 15:33 |
| jaypipes | zaneb: 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 |
| zaneb | fwiw 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 need | 15:39 |
| jaypipes | zaneb: 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 |
| zaneb | but 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-tc | 15:42 | |
| zaneb | jaypipes: yes! | 15:42 |
| jaypipes | zaneb: 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 |
| jaypipes | zaneb: I'm not entirely sure where you got that idea from. | 15:43 |
| zaneb | jaypipes: 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 |
| jaypipes | zaneb: I'm not going to get into the conversation about people misunderstanding what the big tent was and wasn't. | 15:44 |
| zaneb | right, yeah, let's not :) | 15:44 |
| jaypipes | zaneb: 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 |
| zaneb | jaypipes: this is a really interesting discussion, because I think we are thinking of different people | 15:46 |
| jaypipes | zaneb: 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 |
| zaneb | https://cloudpundit.com/2014/05/14/reflections-on-the-openstack-atlanta-summit/ | 15:49 |
| jaypipes | zaneb: 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 |
| jaypipes | zaneb: and any discussion of the "layers of OpenStack" isn't going to be complete without acknowledging that reality. | 15:49 |
| *** dklyle has quit IRC | 15:50 | |
| smcginnis | I 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-tc | 15:53 | |
| jaypipes | smcginnis: I know this makes me sound like an asshole, but I really don't care. | 15:54 |
| jaypipes | smcginnis: 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 |
| zaneb | ooooh, was with you there right up to Horizon ;) | 15:55 |
| jaypipes | smcginnis: 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 |
| jaypipes | zaneb: 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 |
| smcginnis | jaypipes: I agree, but I think zaneb's point earlier was that there was/is pressure from some people that wanted that. | 15:57 |
| jaypipes | zaneb: I'm not saying Horizon is *the* orchestration layer. | 15:57 |
| jaypipes | zaneb: nor am I saying anything negative about horizon at all | 15:57 |
| zaneb | (I was half-joking about the horizon comment) | 15:57 |
| jaypipes | zaneb: 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 |
| jaypipes | smcginnis: 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 |
| zaneb | so 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 |
| zaneb | so 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 |
| smcginnis | Part 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 |
| zaneb | so 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 sidelines | 16:03 |
| ttx | smcginnis: there still isn't | 16:04 |
| zaneb | but 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 it | 16:04 |
| ttx | and now we have users that a refactoring would break | 16:05 |
| jaypipes | (sorry, on an allhands call atm...) | 16:05 |
| smcginnis | ttx: Yep | 16:05 |
| ttx | I mean, I could totally support a split between nova-low and nova-high with a stable API in between | 16:06 |
| zaneb | either 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 yet | 16:06 |
| ttx | but seeing that getting to a hypervisor driver public API is hard enough, I don't think that's reasonable | 16:06 |
| cdent | I'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 |
| cdent | zaneb: I assume you saw the chat between ttx and me this morning? | 16:07 |
| zaneb | yes | 16:07 |
| cdent | I think thinking of it in terms of two views is insufficient | 16:08 |
| zaneb | fair | 16:08 |
| cdent | there's free vware, there's free aws, there's free plumbing for openshift/k8s/cloud foundry/whatever, there's free $something_else | 16:08 |
| *** e0ne has quit IRC | 16:09 | |
| *** harlowja has joined #openstack-tc | 16:12 | |
| fungi | i 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 whatever | 16:12 |
| fungi | which added magic api support for those things without needing them to work out how to add yet another service and expose that to the users | 16:12 |
| *** e0ne has joined #openstack-tc | 16:13 | |
| ttx | been 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 metric | 16:13 |
| ttx | https://etherpad.openstack.org/p/rocky-2-bus-factor | 16:13 |
| ttx | mnaser ^ | 16:13 |
| ttx | (caveat: my script might be broken, and relies on stackalytics questionable data anyway) | 16:14 |
| jroll | fungi: that's an interesting take | 16:14 |
| zaneb | fungi: 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 APIs | 16:14 |
| ttx | benefit in "individual bus factor" is that it exposes smaller projects too | 16:14 |
| fungi | when 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 |
| fungi | also, 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 term | 16:17 |
| cdent | I've long thought that we were predisposed to listen too much to deployers versus "end users" | 16:17 |
| cdent | not that we shouldn't listen to deployers/ops but rather that it needs to be more balanced | 16:17 |
| fungi | well, 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 organizations | 16:19 |
| zaneb | fungi: 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 nodes | 16:19 |
| fungi | totally agree there | 16:19 |
| zaneb | Freezer too | 16:19 |
| fungi | that 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 it | 16:20 |
| scas | ttx: that's a metric i'm not happy to be near the top of, but it's definitely illuminating | 16:21 |
| zaneb | the 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 them | 16:22 |
| zaneb | s/mission/technical vision/ | 16:22 |
| zaneb | so that they don't see the feature requests as hostile, but as an opportunity to simplify while making the whole project more powerful | 16:23 |
| zaneb | hopefully I haven't demoralised any Nova cores by saying that :) | 16:24 |
| *** jpich has quit IRC | 16:28 | |
| zaneb | (Masakari was the thing I couldn't remember the name of) | 16:29 |
| scas | ttx: 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 rate | 16:29 |
| scas | n.b. browbeat is heavily laden with sarcasm | 16:31 |
| *** ricolin has quit IRC | 16:33 | |
| cdent | n.b. browbeat is the name of my attorney | 16:35 |
| *** e0ne has quit IRC | 16:35 | |
| smcginnis | heh | 16:36 |
| fungi | even more amusing if true | 16:39 |
| smcginnis | Nathaniel Bryant Browbeat III, Attorney at Law | 16:44 |
| cdent | https://www.youtube.com/watch?v=KcycHTp-zDg | 16:45 |
| * cdent has had a long day | 16:46 | |
| scas | it's been a long week | 16:46 |
| cdent | true, already | 16:46 |
| fungi | is it only tuesday still? | 16:48 |
| scas | if 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 cookbooks | 16:48 |
| scas | i've seen that as rather distasteful, but my thinking could be outmoded in that regard | 16:49 |
| jaypipes | zaneb: sorry, was on an allhands.. reading back now to respond to your ideas. | 16:53 |
| *** harlowja has quit IRC | 17:10 | |
| jaypipes | ttx: 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-tc | 17:11 | |
| jroll | it would be interesting to also add how many people from the org make up the number | 17:12 |
| clarkb | re 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 instance | 17:12 |
| jroll | e.g. I suspect glance is 1 person, but ironic is many more | 17:12 |
| jaypipes | clarkb: no disagreement. I just don't think the Nova API should be that thing. | 17:13 |
| clarkb | the 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 instance | 17:13 |
| jaypipes | clarkb: that's pretty much exactly what Horizon is... fwiw | 17:13 |
| clarkb | jaypipes: this should also be doable without clicking buttons | 17:13 |
| clarkb | clicking buttons is highly inaccurate | 17:13 |
| jaypipes | clarkb: indeed. | 17:15 |
| *** dtantsur is now known as dtantsur|afk | 17:15 | |
| clarkb | part of the problem in that specific case was that the details often end up being so site specific too | 17:15 |
| clarkb | and our apis didn't expose to anyone willing to build it from scratch what was necesary to do so | 17:15 |
| jaypipes | clarkb: ftr, what you are describing is what https://github.com/jaypipes/enamel was originally the idea behind.. | 17:16 |
| jaypipes | clarkb: just never followed up on it. | 17:16 |
| clarkb | subnetpools made this slightly better but have largely only been implemented for ipv6 | 17: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 |
| scas | fwiw, 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 disorder | 17:18 |
| *** e0ne has quit IRC | 17:18 | |
| clarkb | jaypipes: 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 net | 17:20 |
| jaypipes | scas: 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 |
| jaypipes | clarkb: no doubt | 17:21 |
| dhellmann | I 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 |
| jaypipes | clarkb: same with nova-volume etc | 17:21 |
| jaypipes | dhellmann: it would look like kube-api. | 17:21 |
| dhellmann | I meant more how would these sorts of discussions be different and how would the interactions between teams be different. | 17:23 |
| fungi | is that what oaktree wants to be when it grows up? | 17:23 |
| scas | jaypipes: indeed. and it sometimes comes down to someone in my situation overriding packaging decisions than going back upstream to change it properly | 17:23 |
| jaypipes | scas: ack | 17:23 |
| dhellmann | fungi : I guess partly? | 17:24 |
| dhellmann | ttx: I'm interested in understanding how the corporate bus factor is different from what we've been doing | 17:26 |
| dhellmann | ttx: you may want to try the "who-helped" command set in the goal-tools repo | 17:26 |
| dhellmann | it likely needs to be extended and it definitely needs to be documented | 17:26 |
| mnaser | ttx: interesting doc. surprised but not surprised about swift | 17:29 |
| mnaser | also.. designate = blizzard? | 17:30 |
| mugsie | yeah. eanderson is pretty active these days | 17:32 |
| mnaser | yay, that's cool | 17:34 |
| notmyname | ttx: what/what are the cutoffs used for bold or not? | 17:40 |
| scas | over the past several months, chef openstack has been mostly me. stackalytics tells most of the truth only because i wait and pester people for time | 17:41 |
| scas | my 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 lens | 17:53 |
| *** jaosorior has joined #openstack-tc | 18:13 | |
| *** gouthamr has quit IRC | 18:32 | |
| *** e0ne has joined #openstack-tc | 19:52 | |
| *** e0ne has quit IRC | 20:15 | |
| eandersson | we are also active in autoscaling (senlin) and k8s (magnum)! | 20:15 |
| *** cdent has quit IRC | 20:28 | |
| *** gouthamr_ has joined #openstack-tc | 20:29 | |
| *** gouthamr_ is now known as gouthamr | 20:29 | |
| dhellmann | scas : having lots of self-approved patches would likely have triggered a different red flag | 20:31 |
| scas | dhellmann: as i figured, which is why i almost never do it | 20:32 |
| * dhellmann nods | 20:32 | |
| scas | it's tempting when my throughput is hindred by available eyes, but i tend to view what i do for openstack through the maintainer lens | 20:33 |
| fungi | i 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-picked | 20:56 |
| fungi | while i wait (maybe months) for reviews | 20:56 |
| fungi | as long as i'm willing to scrap or rework my fork while my proposed change evolves | 21:01 |
| scas | my itch to scratch is making sure there's an upstream to follow :D | 21:14 |
| fungi | admirable! | 21:15 |
| *** zaneb has quit IRC | 21:17 | |
| *** cmurphy_vacation is now known as cmurphy | 21:22 | |
| dmsimard | dhellmann: 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 :p | 21:23 |
| *** gouthamr has quit IRC | 21:25 | |
| *** gouthamr has joined #openstack-tc | 21:26 | |
| *** zaneb has joined #openstack-tc | 21:29 | |
| eandersson | Yea - 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 |
| eandersson | Nothing better than constructive feedback,. | 21:49 |
| *** ian_ott has quit IRC | 21:51 | |
| *** mriedem has quit IRC | 21:52 | |
| *** mriedem has joined #openstack-tc | 21:56 | |
| scas | indeed. 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 noises | 22:03 |
| *** edmondsw has quit IRC | 22:04 | |
| *** edmondsw has joined #openstack-tc | 22:07 | |
| scas | from 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 reasons | 22:08 |
| *** edmondsw has quit IRC | 22:11 | |
| scas | wasn'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 corner | 22:19 |
| *** mriedem has quit IRC | 22:21 | |
| *** hongbin has quit IRC | 22:36 | |
| *** tosky has quit IRC | 23:08 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!