| *** lbragstad has quit IRC | 00:26 | |
| fungi | https://aeva.online/2019/03/what-happened-to-openstack/ is a great piece, for those who haven't seen it | 00:32 |
|---|---|---|
| fungi | nice to see the rumors of openstack's demise have been greatly exaggerated | 00:33 |
| fungi | i don't agree with everything there, but it's nice to see a balanced take from inside the past of our community | 00:41 |
| *** wxy-xiyuan has joined #openstack-tc | 00:53 | |
| *** ricolin has joined #openstack-tc | 01:03 | |
| *** gouthamr has quit IRC | 01:48 | |
| *** jamesmcarthur has joined #openstack-tc | 01:55 | |
| *** whoami-rajat has joined #openstack-tc | 02:02 | |
| *** jamesmcarthur has quit IRC | 02:04 | |
| *** jamesmcarthur has joined #openstack-tc | 02:06 | |
| *** jamesmcarthur has quit IRC | 02:10 | |
| *** jamesmcarthur has joined #openstack-tc | 02:37 | |
| *** gouthamr has joined #openstack-tc | 02:50 | |
| *** jamesmcarthur has quit IRC | 02:51 | |
| *** jamesmcarthur has joined #openstack-tc | 02:54 | |
| *** jamesmcarthur has quit IRC | 03:10 | |
| *** jamesmcarthur has joined #openstack-tc | 03:10 | |
| *** jamesmcarthur has quit IRC | 03:57 | |
| *** jamesmcarthur has joined #openstack-tc | 04:35 | |
| *** jamesmcarthur has quit IRC | 04:44 | |
| *** jamesmcarthur has joined #openstack-tc | 04:48 | |
| *** jamesmcarthur has quit IRC | 04:52 | |
| *** jamesmcarthur has joined #openstack-tc | 05:00 | |
| *** jamesmcarthur has quit IRC | 05:35 | |
| *** jamesmcarthur has joined #openstack-tc | 06:03 | |
| *** jamesmcarthur has quit IRC | 06:09 | |
| *** dims has quit IRC | 06:24 | |
| *** e0ne has joined #openstack-tc | 06:24 | |
| *** dims has joined #openstack-tc | 06:26 | |
| *** e0ne has quit IRC | 06:33 | |
| *** dims has quit IRC | 06:36 | |
| *** dims has joined #openstack-tc | 06:37 | |
| *** jamesmcarthur has joined #openstack-tc | 06:40 | |
| *** jamesmcarthur has quit IRC | 06:44 | |
| *** e0ne has joined #openstack-tc | 06:46 | |
| *** Luzi has joined #openstack-tc | 06:51 | |
| *** jamesmcarthur has joined #openstack-tc | 06:56 | |
| *** jamesmcarthur has quit IRC | 07:01 | |
| *** e0ne has quit IRC | 07:07 | |
| *** flaper87 has quit IRC | 07:32 | |
| *** flaper87 has joined #openstack-tc | 07:33 | |
| *** e0ne has joined #openstack-tc | 08:17 | |
| *** jpich has joined #openstack-tc | 08:56 | |
| *** e0ne has quit IRC | 08:58 | |
| evrardjp | o/ | 08:59 |
| *** e0ne has joined #openstack-tc | 09:00 | |
| ttx | o/ | 09:00 |
| bauzas | morning | 09:11 |
| * ttx grabs extra coffee | 09:12 | |
| *** cdent has joined #openstack-tc | 09:15 | |
| cdent | is the the waning of the tuesday morning office hours a sign of the impending collapse of the EU? | 09:18 |
| cmurphy | maybe it's a bit of a self fulfilling cycle, no one starts major conversations at this time because everyone knows the real meeting is on thursday | 09:20 |
| * ttx tries to come up with a good Brexit pun and fails | 09:20 | |
| cdent | I think you've accomplished it ttx.Everyone has tried to come up with a good Brexit anything and failed | 09:21 |
| ttx | Oh, I have a topic! | 09:21 |
| ttx | I almost replied to https://twitter.com/mikal/status/1102684773707800576 this morning | 09:21 |
| ttx | Acknowledging that what was good for getting the period of abundance under control is probably no longer ideal today | 09:22 |
| *** dtantsur|afk is now known as dtantsur | 09:22 | |
| cdent | ah yes. it's a valid point. | 09:22 |
| ttx | and asking for a list of pain points for hobbyists | 09:22 |
| ttx | (since specs was not at the top of my pain point guesses) | 09:22 |
| cdent | how much nova do you do ttx? | 09:22 |
| cdent | The pain profile in nova is probably quite a bit different from some other projects | 09:23 |
| ttx | cdent: admittedly little. Was only involved around rootwrap/privsep really | 09:23 |
| cdent | for a casual person it is still very hard to get something merged without an insider buddy | 09:23 |
| cmurphy | in keystone we only use specs for pretty big changes, i wouldn't want to wild west those kinds of features with no specs | 09:24 |
| ttx | I think specs are generally a good idea -- but if unchecked they can evolve into a tool to hold off ideas/changes indefinitely | 09:25 |
| ttx | by forcing people through an infinite set of hoops | 09:25 |
| bauzas | there are pros and cons | 09:25 |
| ttx | My external impression was that the specs process was not too heavy though (including in Nova) | 09:26 |
| cdent | I think it depends on from where you are counting. If you look at specs that are done, it all looks pretty good | 09:26 |
| ttx | bauzas: do you know the bit mikal is referring to? Does he need a spec to get his thing done? | 09:27 |
| cdent | but if you look at features that were proposed in initial hand wavey terms, it is different | 09:27 |
| bauzas | my personal take on that is that the time we take on specs is identical to the time we would take on implementation discussions if we wouldn't have specs | 09:27 |
| cdent | (not to say that all features should see light, just thinking in terms of the perspective of the proposer) | 09:27 |
| bauzas | ttx: fwiw, nova also accepts non-spec features | 09:27 |
| ttx | bauzas: agree, it's a tool that structures discussion/group-approval that would likely happen anyway | 09:27 |
| bauzas | so, when we ask for a spec, it's because we need to discuss on the design | 09:27 |
| bauzas | but like I said, if we don't do this in the spec, then we need to do it in the implementation | 09:28 |
| cdent | ttx: I don't know what mikal's situation is, but I think for a lot of people, it isn't that they are stuck on spec, but rather there is a mental awareness of omg process that is hard for them to get over and hard for some projects (especially nova) to signal is not really there | 09:28 |
| bauzas | cdent: the problem that we have with specs is that sometimes owners prefer to just provide changes and fixing problems later | 09:29 |
| bauzas | in this case, they don't like specs because they think it's a non needed time | 09:29 |
| cdent | bauzas: that's not _the_ problem, that _a_ problem, of several | 09:29 |
| bauzas | yup, maybe | 09:29 |
| bauzas | I don't disagree with it, but fwiw I think the "writing" is not the problem | 09:30 |
| cdent | If you're a casual person who wants to get a feature into nova, if it is of any size, it's a multiple-month commitment | 09:32 |
| cdent | At which point it is not casual any more | 09:32 |
| cdent | That's not necessarily a bad thing: a feature that doesn't have future ownership and care and feeding is dangerous | 09:32 |
| cdent | But it is a thing that some casual people are very aware of | 09:33 |
| bauzas | I don't disagree, it can be difficult for some people to discuss with folks if they don't have time | 09:33 |
| bauzas | and we basically ask for that with specs | 09:34 |
| ttx | cdent: I think there are 3 types... Bug fix, non-disruptive feature (think: optionally exposing Nova internal metrics to prometheus), and disruptive feature (separate placement) | 09:34 |
| bauzas | like I said, I think the original writing is simple | 09:34 |
| ttx | The last category obviously needs a lot of planning | 09:34 |
| bauzas | ttx: yup, and we accept non-spec features like I said | 09:35 |
| ttx | because you don;t want to break anyone | 09:35 |
| bauzas | for the 2nd category | 09:35 |
| bauzas | https://docs.openstack.org/nova/latest/contributor/blueprints.html#specs | 09:35 |
| ttx | So it's really not "specs" or "not specs" -- it's "specs for the potentially-disruptive things" | 09:35 |
| cdent | In that case I would guess that one of the issues is confusion over what fits in the 2nd category | 09:35 |
| cdent | or rather: difference of opinion | 09:36 |
| bauzas | yeah, but we accept to discuss it in the meeting | 09:36 |
| bauzas | it's open | 09:36 |
| ttx | cdent: yes -- specs being used to control the scope rather than to avoid disruption | 09:36 |
| bauzas | it's not just us saying no or yes | 09:36 |
| bauzas | you can argue | 09:36 |
| cdent | "in the meeting" is itself excluding of casual contributors | 09:36 |
| bauzas | I'm open to changing this | 09:37 |
| cdent | you have to know about, find, and be aware of the social tropes of the meeting | 09:37 |
| bauzas | but I haven't seen any partial contributor complaining of it yet | 09:37 |
| cdent | because they don't show up. | 09:37 |
| bauzas | cdent: in general, new contributors write bugs | 09:37 |
| cdent | you can't judge what casual contributors who have decided to not bother, because we don't know them: they've not bothered | 09:38 |
| bauzas | cdent: when I was having time (heh) for upstream triage, I was redirecting to the blueprint process | 09:38 |
| bauzas | and people were showing up the week after | 09:38 |
| bauzas | cdent: agreed, my example is not a good one | 09:38 |
| cdent | you've seen the thing going round twitter lately with the ww2 plane and where it has been shot? | 09:39 |
| bauzas | it's not because I haven't seen problems that we don't have problems | 09:39 |
| bauzas | so, again, I'm open to engage a discusssion at the PTG on specs and trivial blueprints | 09:39 |
| cdent | survivorship bias is a _huge_ thing in how we have measured contribution in openstack, which means we are missing loads of important data | 09:39 |
| dtantsur | FWIW I haven't heard anyone complaining about joining an IRC meeting once to discuss their proposal. Unlike going to a PTG, for example. | 09:40 |
| dtantsur | (ironic has a similar process) | 09:40 |
| bauzas | my only concern is that I feel nothing can happen magically unless you (as an idea maker) can interact with the community | 09:40 |
| bauzas | and then, you need two things : 1/ see whether your idea is good, 2/ see whether you can implement it | 09:41 |
| ttx | The trick is to have an easy, discoverable first step, and then people guiding candidates through the contribution pipeline | 09:41 |
| bauzas | isn't the goal of the First Contact SIG to help with such contributors ? | 09:41 |
| bauzas | and we have documentation too | 09:42 |
| ttx | bauzas: it's more for first-time contributors than for "casual" contributors | 09:42 |
| ttx | Like mikal knows how to use Gerrit alright | 09:42 |
| bauzas | heh right | 09:42 |
| bauzas | but showing up at a meeting isn't a big deal right? | 09:42 |
| bauzas | and we're rotating | 09:43 |
| bauzas | but again, I'm open to alternative ideas | 09:43 |
| ttx | bauzas: I think showing up at a meeting is not a big ask -- as long as it's asked | 09:43 |
| bauzas | I just feel we necessarly need a synchronous time where owner and reviewers can discuss | 09:43 |
| bauzas | ttx: it is asked https://docs.openstack.org/nova/latest/contributor/blueprints.html#specs | 09:43 |
| bauzas | and https://specs.openstack.org/openstack/nova-specs/readme.html#trivial-specifications | 09:44 |
| ttx | bauzas: i wonder if there is no missing step between "Hmm, I'd like to try to contribute X to project Y" and "reading https://specs.openstack.org/openstack/nova-specs/readme.html" | 09:44 |
| bauzas | and I particularly like https://docs.openstack.org/nova/latest/contributor/process.html#how-do-i-get-my-code-merged | 09:44 |
| cdent | I think we are completely missing the point of "casual" | 09:45 |
| cdent | If we are saying go to these meetings and read all this stuff | 09:45 |
| cdent | that's not casual | 09:45 |
| ttx | bauzas: like CONTRIBUTING.rst does not really point to those docs | 09:45 |
| bauzas | 'casual' implies time, right | 09:45 |
| cdent | which may be fine. We might not be a casual place. | 09:45 |
| cdent | But if we want to be, lots of stuff needs to change, including that regular/core members of teams need to facillitate incoming code way more than they do currently | 09:46 |
| bauzas | ttx: that's a fairly good point | 09:46 |
| bauzas | cdent: accepting code is one thing, making sure it doesn't break our users is another thing, and that's why we require some design discussion | 09:47 |
| bauzas | cdent: this design discussion requires some time dedication from the owner | 09:47 |
| bauzas | the last phrase is what we expect *now* | 09:48 |
| cdent | bauzas: yes, what I'm suggesting is that sometimes a person may come along with a half-baked and half-done idea that it should be _our_ problem to bring to a good conclusion | 09:48 |
| ttx | bauzas: also not Nova-specific -- I'm pretty sure it's the case for all of our projects. We are relatively good at pointing to git/Gerrit doc, but not so much to project processes to get things done | 09:48 |
| cdent | consider how this works in a smaller open source project, where casual contribution is common, for example gabbi: | 09:48 |
| bauzas | ttx: oh yeah, indeed | 09:49 |
| dtantsur | finishing others patches doesn't scale | 09:49 |
| dtantsur | we try to do it for the most useful ones, but that's it | 09:49 |
| bauzas | dtantsur: for the moment, afaicu, we're even not talking code | 09:49 |
| cdent | a person comes along and says "I'd like to be able to do response_json_paths, but have interpolation on the left hand side, I think it would work like this, in method X but that's as far as I got" | 09:49 |
| cdent | then I finish it | 09:49 |
| bauzas | dtantsur: but just design | 09:49 |
| bauzas | cdent: like dtantsur said, it doesn't scale | 09:50 |
| bauzas | in particular when a large portion of contributors start having less time upstream for this | 09:50 |
| cdent | it only doesn't scale because we insist that core project members are also writing features, rather than facillitating incoming code/design | 09:50 |
| cdent | we need to adjust to the new economics | 09:50 |
| dtantsur | it's not that we insist on that | 09:50 |
| dtantsur | that's what we are paid for, largely | 09:51 |
| cdent | right, which is wrong and needs to be fixed | 09:51 |
| bauzas | it's also that knowing a largely distributed system isn't trivial | 09:51 |
| cdent | or | 09:51 |
| dtantsur | I strongly disagree on that, FWIW | 09:51 |
| cdent | we need to stop saying we can do lots of work | 09:51 |
| cdent | dtantsur: which "that" specifically? | 09:51 |
| dtantsur | cdent: "cores writing code must be fixed" | 09:52 |
| dtantsur | one reason being that most of us *like* writing code. the more important reason being that "outside" contributors rarely tend to take on foundational work. | 09:52 |
| cdent | dtantsur: I said feature code, not code | 09:52 |
| cdent | things like framework, tech debt, refactoring, etc, all the stuff we keep saying we need more of | 09:53 |
| cdent | would be in the hands of the regulars | 09:53 |
| dtantsur | from my experience, "outsiders" do not take complex feature tasks either. when they do, they quickly become cores. | 09:53 |
| cdent | we are maintainers | 09:53 |
| cdent | is "quickly becomes cores" still true? I though the available pool was shrinking dramatically across the board | 09:54 |
| dtantsur | well, when it happens - yes. the last person who became core on ironic, for example, started with heavy-lifting some long-forgotten features. | 09:55 |
| dtantsur | you sound as if we had a line of people eager to contribute large features. it's not quite true outside of the driver space. | 09:56 |
| cdent | no, I'm saying we don't have those people | 09:56 |
| cdent | and won't again | 09:56 |
| cdent | that was years ago, and we need to change, in many ways | 09:56 |
| dtantsur | we probably do, I just don't see how | 09:57 |
| dtantsur | well, relying so heavily on face-to-face meetings certainly doesn't help, but that's the only idea I have | 09:57 |
| cdent | I think two sort of opposing thoughts: | 09:58 |
| * dtantsur has checked: only one notable feature to ironic this cycle was contributed by a complete outside - smart NIC support (nearly falling under a vendor feature) | 09:58 | |
| cdent | 1) If we are going to continue to have a small number of unicorns who are "paid to work on openstack" the responsibilities of those people must be very focused on a) enabling other people, b) keeping their paying companies living up to their responsibilities | 09:59 |
| cdent | 2) kill all the unicorns because it was a really bad idea | 09:59 |
| cdent | We are bad at both 1.a and 1.b | 09:59 |
| cdent | systemically so, not because of individual decisions or intent | 10:00 |
| dtantsur | you're right, I'm still not sure what you suggest though | 10:02 |
| bauzas | cdent: 1.b) is unrealistic | 10:03 |
| cdent | I'm not suggesting anything yet, I'm trying to get us to admit there is a problem, which is the first step to fixing it. Thus far you're the first person to say "you're right", so that's a start. | 10:03 |
| cdent | bauzas: If that's the case we should lay down tools. All these companies are making money off upstream openstack. Are they expecting magical opensource bunnies to make it? | 10:04 |
| cdent | There is labour happening, creating value. | 10:04 |
| dtantsur | you assume all people are wise and plan ahead | 10:05 |
| dtantsur | history has proven you're wrong ;) | 10:05 |
| cdent | I don't assume, I hope. | 10:05 |
| cdent | In fact I assume people are not and do not, but _still_ hope. | 10:05 |
| bauzas | cdent: I wish we could live in a situation where corporate sponsors would dedicate resources to the projects without asking for ROI | 10:05 |
| cdent | the market for openstack is still billions. that's roi | 10:06 |
| cdent | it's not rocket science | 10:06 |
| zhipeng | cdent 1.b is extremely hard | 10:06 |
| dtantsur | the problem is the illusion of sustainability. we have survived pretty damn well so far, so people assume we will survive on with little to no help. | 10:06 |
| dtantsur | the best way to show they're wrong is to start falling apart, but we don't want to get there :) | 10:07 |
| cdent | zhipeng: I agree, it is definitely very hard | 10:07 |
| cdent | dtantsur: exactly! none of us is willing to let the strain show because we want the project to continue to be good, and thus we are putting ourselves into a cycle of heroics | 10:08 |
| cdent | if we admit "this is hard and needs help" the fear is that people will say "meh, no longer worth it" | 10:09 |
| cdent | that's a very real and legit and incredibly unforunate fear | 10:09 |
| zhipeng | Yes | 10:09 |
| zhipeng | Part of the answer lies around how to more closely involve users/customers | 10:10 |
| bauzas | cdent: what you're asking with 1.b) is a total flip of internal organisational work repartition, which is why I said it's unrealistic | 10:10 |
| zhipeng | Coz they will directly pressure the contributing company, thus provide a solution for 1.b | 10:11 |
| zhipeng | I've been experimenting this at least for cyborg for quite a while | 10:11 |
| bauzas | wait a sec | 10:12 |
| bauzas | customers ask for features already | 10:13 |
| bauzas | those features are already having resources allocated on them | 10:13 |
| bauzas | if there is a business ask, it's not a problem | 10:13 |
| cdent | zhipeng engaging with the end users is definitely an important factor | 10:14 |
| zhipeng | Business requirements changes all the time lol | 10:14 |
| bauzas | I thought 1.b) is more about letting contributors to set their own priorities without getting 'influenced' by business | 10:14 |
| ttx | We need a way to communicate that things "are going to fall apart", to get the organizations that have built a business on that thing to engage | 10:14 |
| cdent | ttx: yes. that's what I was hoping the "business case" or "job req" stuff might be able to do | 10:15 |
| ttx | because by the time those orgs realize by themselves things have fallen apart, it's probably too late | 10:15 |
| cdent | or at least be associated with | 10:15 |
| cdent | yes! | 10:15 |
| ttx | OSA is an interesting case for example -- the bulk of it was sustained by RAX people, and now it is at risk. It's still great and good, but unless its users get more involved the quality will drop | 10:16 |
| ttx | I think that point is hard to drive in generic communications. Personal emails to organizations you /know/ are relying on it might be more productive | 10:17 |
| cdent | do we have a list of big OSA-using shops? | 10:18 |
| ttx | on the Foundation side we have user survey data (although for deployment tools it's not high quality data imho). I bet mnaser has empirical data about using companies too | 10:19 |
| dtantsur | in my experience it ends up like "of course do whatever needed to keep the project healthy, BUT <list of business priorities to do yesterday>" | 10:19 |
| * cdent nods | 10:21 | |
| * cdent is much too familiar with that | 10:21 | |
| cmurphy | +1 | 10:22 |
| bauzas | dtantsur: I have the same feeling | 10:22 |
| bauzas | even if we become white knights that send a signal, it will all tie to the business opportunities | 10:22 |
| ttx | the missing link is making the organization understand that their business priorities depend on the project being healthy, not the other way around | 10:23 |
| bauzas | oh yeah... | 10:23 |
| dtantsur | ttx: I think they understand, they just underestimate how fragile upstreams can be | 10:23 |
| bauzas | anyway, whether they understand it or not, point is that OpenStack is now "mature" | 10:23 |
| ttx | yes, thanks to the heroic acts that cdent was mentioning, things appear ok until they are completely toasted | 10:23 |
| bauzas | so they're very willing to only allocate resources for direct business-case related work | 10:24 |
| dtantsur | yep. and fun point (getting back to the earlier discussion): it's easier for a core to shift priority to stuff before "BUT" than for a regular contributor IMO. | 10:24 |
| ttx | The only successful engagement we had was when we propose to retire a project that has no PTL or no release, and $someone shows up to save it | 10:25 |
| ttx | but that's arguably too late, a one-person (or one-org) effort won't really make that project successful, it will just make it survive a bit | 10:25 |
| dtantsur | We could dramatically reduce the number of features we accept. BUT it's again going to hurt outside contributors much more than companies with cores | 10:25 |
| ttx | dtantsur: I think they are gladly underestimating, too. keeps them on the winning side of the tragedy of commons. | 10:26 |
| dtantsur | heh | 10:26 |
| ttx | for some weirdly-twisted definition of "winning" | 10:27 |
| zhipeng | Maybe we should stop saying OpenStack is stable or mature now, we only identify features are stable/mature | 10:27 |
| ttx | "I'll win until everyone including me loses" | 10:27 |
| dtantsur | One thing that we (and personally TheJulia) has been actively trying to do is to engage ops in upstream. These people have a stronger interest in project's health than shiny stuff, usually. | 10:27 |
| * dtantsur prepares a sales pitch of ironic for tomorrow's Ops Meetup | 10:28 | |
| ttx | dtantsur: I think users are less likely to feel the tragedy of commons because they are not necessarily competing against each other | 10:28 |
| * dtantsur had to google "tragedy of commons" now :) | 10:28 | |
| ttx | It's more likely that a $IBM would wait for a $RedHat to take a bigger share so that they don't have to than say, a $Walmart to wait for a $CERN. | 10:29 |
| dtantsur | right | 10:29 |
| cmurphy | dtantsur: what's your strategy for engaging ops? | 10:29 |
| dtantsur | cmurphy: first reaching out, then trying to make their contributions as smooth as possible (kind of in spirit of what cdent was talking about earlier) | 10:29 |
| cmurphy | ++ | 10:30 |
| bauzas | dtantsur: it's unfortunately not sustainable as those ops can't allocate more than a few resources | 10:31 |
| bauzas | for example, Cells v2 is mostly ops-driven with CERN | 10:31 |
| bauzas | but I don't see CERN sustaining Nova in the long term | 10:31 |
| dtantsur | right. but they arguable can allocate some resources over long time (since they need $project_name running) | 10:31 |
| dtantsur | while e.g. with drivers there's tendency to drop code and walk away | 10:32 |
| bauzas | they can allocate resources, I agree | 10:32 |
| bauzas | but in general, they can't just allocate as many resources as a vendor | 10:32 |
| bauzas | take OVH | 10:32 |
| bauzas | they have business to run | 10:33 |
| dtantsur | right. this is <a lot of resources for short time> vs <tiny resources long term> | 10:33 |
| bauzas | so they can dedicate a few resources for sustaining OpenStack development | 10:33 |
| dtantsur | the former helps getting a lot done, but then few people have to maintain the result.. | 10:33 |
| bauzas | actually, I see your point and you're right | 10:34 |
| bauzas | involving ops will make the project more maintainable, it just won't guarantee a fast delivery pace | 10:34 |
| bauzas | but this is OK if you only care about the existing | 10:35 |
| cdent | [t ho92] is a great way to put things | 10:35 |
| purplerbot | <bauzas> involving ops will make the project more maintainable, it just won't guarantee a fast delivery pace [2019-03-05 10:34:55.687616] [n ho92] | 10:35 |
| dtantsur | it may be okay once the initial inflation period is over | 10:35 |
| mugsie | but even then, ops are probably running Juno/Newton or in some cases even as far back as havana, so getting them invovled to fix things is difficult as it could literally be years until they see the result of their contribution | 10:36 |
| * cdent senses the cliff-edge of "if we could just upgrade easily" approaching | 10:37 | |
| dtantsur | even people running Juno are helping us shaping modern ironic | 10:37 |
| bauzas | mugsie: yup, and that's why IMHO the main goal OpenStack should achieve is smooth upgrades | 10:37 |
| dtantsur | but yes, upgrades :) | 10:37 |
| mugsie | cdent: not even, thats never going to be the case for telco / enterprise | 10:37 |
| mugsie | the upgrade cycle is still going to be years | 10:38 |
| cdent | yes, which is why I was calling it a cliff-edge | 10:38 |
| cdent | it's a red herring, a trap | 10:38 |
| mugsie | and add in vendor lag, and pre prod testing + security | 10:38 |
| mugsie | cdent: ah, in that case +1000 | 10:38 |
| dtantsur | also some ops may have a QE/pre-QE environment with a later release | 10:38 |
| cdent | it has wasted enormous volumes of effort and created some horrible architecture | 10:38 |
| mugsie | dtantsur: all large scale ops will have that | 10:39 |
| dtantsur | then they can contribute based on these environments | 10:39 |
| mugsie | we had a labs group, who took latest LTS from $VENDOR, who qualified it, then it got passed to security, and the vendor cycle happened again for more fixes, then it went to engineering, who planned the deployment | 10:40 |
| mugsie | by the time it hit ops pre prod we were 18 months down the line | 10:40 |
| mugsie | dtantsur: in a lot of telcos (not all, but a lot) pre-QA and QA envs are separate from ops | 10:41 |
| dtantsur | I see | 10:41 |
| mugsie | and are at a much smaller scale, and do not have the same load put on them (VM count / network traffic / cpu usage etc). so w never saw the issues until it hit prod | 10:42 |
| dtantsur | what we hear from cool ppl from CERN is "okay, we hacked this downstream somehow for prod, now we want to do it properly for the future releases" | 10:42 |
| mugsie | and that works great in CERN (and I wish more users were like them), where there is a thought about long term | 10:43 |
| mugsie | but $BIGCO who buys from $VENDOR is in a completely different boat | 10:43 |
| dtantsur | yeah, I guess they have to put their trust for upstream health in $VENDOR | 10:44 |
| mugsie | and, there actual topology is limited by $VENDOR - I know we couldn't use cells (v1 or v2) in our prod envs as the deployment tool didn't support it | 10:44 |
| mugsie | their* | 10:44 |
| mugsie | ttx: does the foundation have numbers for users who go via vendors vs rolling their own ? | 10:45 |
| cdent | ttx: have you resolved to respond to mikal? | 10:54 |
| ttx | cdent: no I haven't, because I try to avoid complex discussions on Twitter... but feel free to | 11:07 |
| ttx | mugsie: We have numbers but that's really comparing apples to oranges -- those two groups have very different reporting patterns | 11:08 |
| ttx | so I would be wary of using that data for anything | 11:08 |
| cdent | ttx: I'm not sure I'm the best choice; I'd also say "ayup" | 11:15 |
| cdent | which is not particular helpful at furthering the discussion | 11:16 |
| cdent | i suppose if we really wanted to be transparent we could link to the logs of this talk, but that feels like it breaks protocol somehow | 11:16 |
| *** e0ne has quit IRC | 11:32 | |
| *** e0ne has joined #openstack-tc | 11:42 | |
| evrardjp | cdent: OSA is still used by rackspace private cloud existing customers + a few operators + opnfv community + many others, including individuals. We are more at risk now that the biggest actor has scaled down his investments, and ofc OSA will need to adapt to it -- reduce expectations. Which kinda links to previous conversation... | 12:10 |
| cdent | yeah, managing expectations is something we've not been excellent at, in part because we have avoided trying to speak with one voice | 12:11 |
| mugsie | and, there is always the nagging voice in the back of poeples heads "if I start managing this publicly, I will never get anyone else to join" | 12:12 |
| mugsie | I think OSA is in a better place than most though - ops using it have the drive to contribute to it, as moving to $CFGMGMT_TOOL is a non trivial amount of work | 12:14 |
| cdent | Yes. I think the best way for OSA to continue to get attention is to stay alive and be broken sometimes | 12:15 |
| evrardjp | totally I am not complaining -- we are just dependent on the implementation of the rest now | 12:15 |
| cdent | bugs breed contributors | 12:15 |
| evrardjp | haha -- they also scare some away | 12:15 |
| evrardjp | Most of my PTL time was spent on engaging new community members and giving them a sense of ownership or duty | 12:15 |
| evrardjp | "It's your use case, then let's make this official by testing it, so it can work for you forever... You just have to fix it when it breaks" | 12:16 |
| mugsie | evrardjp: ditto - though you seem to have done it better than me :) | 12:16 |
| evrardjp | I was in a more convenient place | 12:16 |
| evrardjp | but what I mean there is that it's mindset and it takes a large amount of time. I follow cdent on his idea that some features are to be implemented by drive by contributions, while larger refactorings and tech debt reduction have to be taken by anyone (while the most experts only will have the chance to do them0. | 12:18 |
| evrardjp | for me, the harder was to have people willing to become core. | 12:19 |
| mugsie | yeah - cores end up with the plumbing work | 12:19 |
| evrardjp | I didn't even want core to be forced to do this plumbing | 12:19 |
| evrardjp | I just wanted to increase the amount of cores to spread the load | 12:19 |
| evrardjp | and even that was difficult | 12:20 |
| evrardjp | And our project is not rocket science | 12:20 |
| mugsie | the issues for projects like OSA, is that there needs to be a level of consitancy across multiple repos (and possibly multiple teams if the compute team manages the osa-nova repos, dns does designate etc) | 12:22 |
| mugsie | it was one of the biggest issues in helion's ansible installer | 12:22 |
| evrardjp | it is, but it is not the hardest we saw | 12:22 |
| evrardjp | because some people didn't even want core on some repos they basically were the only ones to maintain | 12:22 |
| mugsie | :/ | 12:23 |
| evrardjp | they were afraid of engagement. | 12:23 |
| evrardjp | even if we say, that will take you a day per month max, it was the fact it was engaged somewhere that caused an issue | 12:23 |
| evrardjp | so I am truly behind the "let's allow more casual" | 12:23 |
| evrardjp | I just digged for solutions without ever finding the magic recipe | 12:24 |
| evrardjp | I just used the hammer method -- try being core, and let's talk about if it doesn;'t work for you | 12:24 |
| evrardjp | with mixed results | 12:24 |
| evrardjp | anyway... | 12:25 |
| evrardjp | sorry for that long monologue | 12:26 |
| mnaser | FYI: OSA has a huge amount of users, while I can’t dive into specific names, I can say that there’s a lot of big OpenStack users behind it and still growing with it | 12:26 |
| evrardjp | yes -- we are in a good shape | 12:26 |
| evrardjp | mnaser: this conversation started with the context of scaling the community | 12:26 |
| evrardjp | we just want to always scale more :) | 12:27 |
| mnaser | Unfortunately the % of users which end up is a lot less.. I’ve tried speaking with them and seeing if they can contribute and.. nothing | 12:27 |
| evrardjp | I meant scale out not scale up | 12:27 |
| mugsie | mnaser: yeah, it is a long poll to convert end users to active contributors | 12:27 |
| evrardjp | mnaser: yes I am not surprised | 12:27 |
| mnaser | I was just addressing ttx question about the OSA users | 12:27 |
| evrardjp | mnaser: haha ok :) It seems I have been there too :p | 12:28 |
| mnaser | The thing that irks me is that if you use nova, it might not be easy to contribute cause it’s python | 12:28 |
| mnaser | But with OSA, most ops already know ansible. | 12:28 |
| mnaser | So the barrier is much smaller | 12:29 |
| mnaser | Unfortunately it’s so much easier to edit a file in your local drive and ignore anything upstream | 12:29 |
| evrardjp | mnaser: do you mean our code is too good they never have to patch stuff up? Shocking! | 12:31 |
| evrardjp | ahahah | 12:31 |
| mugsie | and, in some cases (i know it was the case for a lot of our ops staff), we were dealing with the world being on fire, and they didn't have the spoons to go try fix anything upstream (or even make sure $VENDOR followed up on bugs) | 12:31 |
| mnaser | lols well if they do they just do it on the local file and call it a day | 12:31 |
| cdent | the spoons thing is one of the roots of this whole discussion | 12:34 |
| cdent | how can we help people have spoons, how can we help make sure they need as few as possible to be useful (to "us" and them) | 12:34 |
| mugsie | cdent: ++ | 12:37 |
| gmann | good morning | 12:38 |
| *** mriedem has joined #openstack-tc | 12:41 | |
| *** tosky has joined #openstack-tc | 12:48 | |
| *** openstackgerrit has joined #openstack-tc | 12:58 | |
| openstackgerrit | Artem Goncharov proposed openstack/governance master: Add Move legacy client CLIs to OSC goal to Train https://review.openstack.org/639376 | 12:58 |
| smcginnis | mugsie: According to a recent informal ops meetup poll, it was about 25% rolling their own installs, 10-20% starting to look at container deployments, and the rest using RHOSP, Mirantis, or other commercial solution. | 13:04 |
| mugsie | smcginnis: thanks - pretty close to what I was expecting, allowing for the self selection of people who go to an ops meetup | 13:05 |
| smcginnis | Regarding specs, in Cinder we've been pretty casual about it and only asked for specs to be written when the change is something that we think important to record the reasoning behind the change or if there needs to be some discussion about the right design. | 13:06 |
| smcginnis | mugsie: Yeah, obviously a very specific type of operator as part of that group. | 13:06 |
| smcginnis | I don't think we want or need to make feature development work that needs a spec written easier for casual contributors. Those kinds of things just aren't the kinds of things we want from someone that is just a casual contributor, in most cases. | 13:07 |
| smcginnis | Assuming we are only requiring specs on somewhat significant things. | 13:07 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: mention goal selection owners as a chair duty https://review.openstack.org/641009 | 13:14 |
| mnaser | \o/ | 13:17 |
| mnaser | hi all | 13:17 |
| openstackgerrit | Merged openstack/governance master: Get rid of popularity discussion in PTI https://review.openstack.org/638045 | 13:17 |
| openstackgerrit | Merged openstack/governance master: Add ``ceph-rbd-mirror`` charm and dependencies https://review.openstack.org/639068 | 13:17 |
| *** jamesmcarthur has joined #openstack-tc | 13:18 | |
| *** ijolliffe has joined #openstack-tc | 13:27 | |
| *** dtantsur is now known as dtantsur|brb | 13:31 | |
| *** jamesmcarthur has quit IRC | 13:31 | |
| fungi | well that was a busy tuesday office hour for a change! | 13:34 |
| * dhellmann had to go to eavesdrop to read the logs because they exceeded his scrollback buffer | 13:35 | |
| bauzas | tl;dr: we started from discussing about casual devs needing to discuss about features to how to have companies understanding that they need to help the upstream community :-) | 13:37 |
| *** marst has joined #openstack-tc | 13:38 | |
| *** jamesmcarthur has joined #openstack-tc | 13:46 | |
| *** marst has quit IRC | 13:56 | |
| fungi | as someone who spends most of his day fighting operational/social/reporting fires and then tries to find spare time to actually do development work, i think one of the main things we need to do is strip down and simplify contribution policies (much more than the processes). process is repeatable so a bit of added complexity is mostly just turning away contributions from folks who are highly unlikely to | 13:58 |
| fungi | stay engaged over the long term anyway. complex policies on the other hand (legal agreements, always open a bug when you're submitting a patch, propose a spec before you even start prototyping a new feature...) is what turns away the contributors who might otherwise stick around and grow into new maintainers for our projects | 13:58 |
| *** lbragstad has joined #openstack-tc | 14:06 | |
| *** jamesmcarthur has quit IRC | 14:06 | |
| smcginnis | ++ | 14:08 |
| cdent | I guess in my head I label all those things as process, but I guess they are actually policies about required process, or something like that? | 14:09 |
| smcginnis | Do we have projects that require a bug for every patch? | 14:10 |
| bauzas | fungi: simplifying process helps for sure | 14:10 |
| smcginnis | That's a corporate development policy that I've tried to educate against with some vendors contributing code. | 14:11 |
| bauzas | fungi: but in general, the OpenStack community doesn't propose a process because any bureaucracy, rather because we want to make sure that we discuss | 14:11 |
| bauzas | if we stop asking for design discussions, I'm not sure the maintenance will be better unfortunately | 14:12 |
| bauzas | but that said, I'm open to discuss on how to have casual contributors not being done because of our processes, and try to find an alternative that can help them | 14:12 |
| cdent | Unless I'm misunderstanding, I don't think anyone is suggesting that design is not discussed, rather that some of the processes whereby discussion happens may need adjustment | 14:12 |
| *** dklyle has joined #openstack-tc | 14:13 | |
| gmann | true, and not all code change need so much design discussion. Having process flexible and done by core team in background is very helpful for new contributors. | 14:16 |
| bauzas | gmann: good question, are you still okay for example with nova asking for a spec if you need a new API microversion ? | 14:17 |
| gmann | bauzas: for nova API case, yes. reason is it is change in user facing interface so doing it with more discussion , feedback is all required. | 14:18 |
| bauzas | so, see, in general, specs are not needed when you just want to provide a feature | 14:19 |
| bauzas | but the problem is that most of the features need a new API microversion in order to be used by users | 14:19 |
| gmann | how the feature is designed for internal layer, it is ok to discuss in many way like on ML, call, PTG, Forum etc | 14:19 |
| jroll | perhaps the fact that so many features require a lengthy design discussion (often escalating to in-person discussions), speaks to how difficult it is to safely add features to our software. seems like that is also an angle we could improve. | 14:20 |
| cdent | jroll++ | 14:21 |
| gmann | bauzas: yeah. spec for microversion is not difficult always. and if we change it in not so best way then we cannot change the API. | 14:21 |
| smcginnis | jroll: Great point | 14:21 |
| jroll | (note: I personally believe the spec process is designed to ensure the "right people" make sure the relatively intangible requirements are met (upgrades, scale, etc)) | 14:21 |
| bauzas | that's the problem with specs | 14:22 |
| gmann | ++ API guidlines and consistency etc | 14:22 |
| bauzas | people (at least me) don't really love to write it because it looks like a bureaucracy thing, but when I discuss with others, I discover things that I wasn't thinking | 14:23 |
| bauzas | upgrades is at least one big thing indeed | 14:23 |
| jroll | bauzas: the question isn't "are specs useful", it's "are specs (and similar process) keeping contributors away" | 14:23 |
| jroll | I agree it is a useful process | 14:23 |
| bauzas | jroll: sure I got that | 14:23 |
| bauzas | jroll: but that's a trade-off | 14:24 |
| bauzas | I'm okay with discussing how to simplify it | 14:24 |
| fungi | cdent: yeah, i suppose phrased as actual policies: changes will not be merged unless they refer to a bug report even when they're not actually fixing bugs (i know of several projects with this policy), and features won't be reviewed until there is a spec describing them even if they just consist of a handful of patches with clear commit messages conveying basically the same information... and blueprint | 14:24 |
| fungi | worship may fall into this category as well | 14:24 |
| bauzas | but that's my concern : any simplification for a feature would still need a design discussion | 14:25 |
| jroll | bauzas: yes, and we should always be questioning tradeoffs. the line between trading one thing for another moves frequently | 14:25 |
| bauzas | anyway, I need to go afk for a couple of mins | 14:25 |
| bauzas | jroll: i'm not opposed to this | 14:25 |
| fungi | bauzas: any reason design discussions can't/don't happen in review comments or mailing list threads? i get that some features are complex enough to need a guiding specification document so you can see if they implement what they meant to implement | 14:25 |
| bauzas | fungi: we could question this | 14:26 |
| gmann | fungi: good point and we really should make that flexible. i personally (where bug is needed) file bug and add it in cmt msg for author | 14:26 |
| bauzas | some other communities do this with ML | 14:26 |
| fungi | in the past, i've seen it work well to ask for a spec once a not-yet-merged feature implementation starts to get too complex, so that it's easier to see the whole picture | 14:26 |
| *** marst has joined #openstack-tc | 14:29 | |
| jroll | fwiw, I think projects are slowly moving to less and less process on their own. keystone is no longer doing blueprints, ironic is approving more RFEs without specs, nova has been more clear about "this needs a spec because X, but it's mostly just a formality at this point because we all agree" | 14:29 |
| jroll | but I doubt that message is reaching the wider audience of could-be-contributors | 14:29 |
| fungi | i often just fix bugs when i run across them and add commit messages describing the problem and solution. for egregious bugs sure it can help to add tracking for them independently in parallel with fixing them, so that users who are stumbling over them in old releases have an easier time seeing they're fixed if they just upgrade | 14:29 |
| fungi | but also plenty of open source projects just ask you to try to reproduce a bug with latest release or master because there's no way to know for sure if you've accidentally fixed something even | 14:30 |
| fungi | and yes, part of my point with relaxing contribution policy is that it will take time (quite possibly a very long time) for the stigma of former bureaucracy and red tape to fade in the public's memory | 14:31 |
| fungi | people don't bother trying to contribute because the project has a reputation for asking them to jump through all sorts of hoops first | 14:32 |
| cdent | agreed about faiding in memory. spanning that transition is what we kind of need to manage | 14:32 |
| cdent | get across the chasm, or fall in | 14:32 |
| cdent | (I don't mean to catastrophize, I don't think there's any real chance of utter failure) | 14:33 |
| fungi | yep, i get it | 14:33 |
| fungi | i'm still trying to work out the glue necessary to bridge the gap of compromise between "osf member companies need us to tell their legal counsel which employees contributed so they can add them to a ccla appendix" and "osf needs control over logins to code review and the ability to reject contributions before they merge" | 14:35 |
| fungi | designing our contributor process around a policy which assumes all contributors are working on behalf of some company (or at that those who aren't don't matter) can be very off-putting | 14:37 |
| cdent | quite | 14:39 |
| *** dtantsur|brb is now known as dtantsur | 14:40 | |
| zaneb | cdent: I feel like that discussion is incomplete without noting that OpenStack was in large portion built by magical open source bunnies, powered by dumb money (in the form of VCs and some large companies who should have had a business plan but inexplicably didn't) | 14:59 |
| cdent | I think maybe we are using the term magical open source bunnies somewhat differently, but I think you are saying: people were able to extract value off VC largesse and now that largesse is gone | 15:00 |
| cdent | That may be, but that period was relatively short wasn't it? HPE certainly wasn't VC largesse | 15:01 |
| cdent | I guess they are in the "large companies" container | 15:01 |
| zaneb | not mentioning names here but I did posit two categories of dumb money :) | 15:01 |
| *** e0ne has quit IRC | 15:02 | |
| *** Luzi has quit IRC | 15:02 | |
| zaneb | yes, there was no tragedy of the commons, because the commons was generously funded by organisations who didn't even end up taking a large/any share of the profits | 15:02 |
| cdent | I don't particularly feel any responsibility for the mistakes of VCs or large companies. There remain plenty of large (and small) companies who want to make a profit. And that means they need labor and should pay for it, even if they got it for free in the past because others in their cohort were dumb. | 15:03 |
| zaneb | that was obviously unsustainable, but it's also a difficult change for companies to adjust to | 15:03 |
| cdent | sure | 15:03 |
| cdent | but again: their problem | 15:03 |
| cdent | we need to make that clear | 15:04 |
| * cdent has no sympathy | 15:04 | |
| zaneb | like, maybe some companies really are expecting the magical open source bunnies to do it. it worked that way for them in the past | 15:04 |
| cdent | so we need to say, out loud, "nope, not no more" | 15:04 |
| zaneb | yes | 15:04 |
| mugsie | but $NEXT_BIG_THING has those free magic bunnies, so that becomes the focus | 15:04 |
| zaneb | yes again | 15:05 |
| cdent | damn those bunnies | 15:05 |
| mugsie | :) | 15:05 |
| smcginnis | Shh, I'm hinting wabbits. | 15:05 |
| smcginnis | *hunting | 15:05 |
| cdent | hinting (about the non existence of) wabbits is perhaps what we should be doing | 15:06 |
| mugsie | but yes - they do expect magic free resources - there are a few vendors who I end up fixing entire (prod) DNS deployments for, but they can't put someone on the project even part time | 15:06 |
| mugsie | or in some cases even package it fully in their distro | 15:06 |
| bauzas | I just feel we had this conversion previously a couple of times and nothing changed beyond our communication about "don't expect things to magically happen, rather provide resources" | 15:07 |
| mugsie | bauzas: we have | 15:07 |
| cdent | If at first you don't succeed, try try again | 15:07 |
| bauzas | so when we say 'their problems", it's actually ours | 15:07 |
| bauzas | and you know, I'm not schizophrenic | 15:07 |
| bauzas | I have a management chain | 15:08 |
| mugsie | something something einstien, repeating yourself, insantiy, something | 15:08 |
| bauzas | and I'm not in a tower with not provided feedback | 15:08 |
| bauzas | but still | 15:08 |
| bauzas | considering that us, contributors, we would get paid for any upstream work without being challenged on the ROI is IMHO a wishful thinking | 15:09 |
| cdent | nobody is suggesting that | 15:10 |
| mugsie | bauzas: yeap, but the problem (in my experience anyway) was not convincing my manager, it was his bosses bosses boss. and even then they agreed in principal, but when the product was slipping, "why are we wasting people on upstream work" was a standard response | 15:10 |
| bauzas | then I apologize on understanding | 15:10 |
| mugsie | doing commons is ROI, just longer term ROI than features | 15:10 |
| bauzas | but I just want to be pragmatic | 15:10 |
| cdent | that ^ | 15:10 |
| cdent | (commons) | 15:10 |
| smcginnis | Sometimes very longer term and not always easy to show. | 15:10 |
| mugsie | smcginnis: unfortunately | 15:10 |
| bauzas | take upstream bug triage | 15:11 |
| mugsie | ROI - as in your upstream base for your multi million $ product is not going to implode ROI, is very hard to quantify | 15:11 |
| bauzas | I dedicate around 25% of my weekly basis to do downstream bug triage | 15:11 |
| bauzas | wish I could dedicate 5% of this into upstream, it would be fantastic | 15:11 |
| bauzas | but that's not how things work here | 15:12 |
| bauzas | and don't say I haven't explained the Great Benefits of Upstream | 15:12 |
| bauzas | I even gave a talk at Sydney about it and I showed my management | 15:12 |
| bauzas | to* | 15:12 |
| bauzas | but crickets. | 15:13 |
| *** e0ne has joined #openstack-tc | 15:13 | |
| bauzas | so, I know we can wait for our sponsors to change, but I rather want us to focus on what we can reasonably achieve | 15:13 |
| bauzas | I don't disagree on simplifying our processes | 15:13 |
| bauzas | so that's at least one reasonable thing to discuss at the PTG | 15:14 |
| bauzas | (sorry about the monologue=) | 15:14 |
| mugsie | bauzas: not even at the PTG, on the ML | 15:14 |
| bauzas | projects have to sign-off too | 15:14 |
| bauzas | because processes are project-defined | 15:15 |
| mugsie | as people who do part time contributions will be less likely to be at the PTG, and we need them to contribute | 15:15 |
| bauzas | so we can engage a discussion with each of the projects | 15:15 |
| bauzas | mugsie: that's a fair point, ++ | 15:15 |
| zaneb | from a business perspective, companies are willing to invest in the commons if the market is growing. To the extent that OpenStack has been pigeonholed as a cheaper alternative to VMWare for forklifting your legacy workloads onto... that's a market that has a hard cap | 15:17 |
| bauzas | ++ | 15:17 |
| zaneb | a project that is seen to be the way that newly-developed applications will be deployed in the future has almost unlimited growth potential. those projects will attract more investment than you know what to do with | 15:17 |
| mugsie | see: Paris 2014 | 15:18 |
| zaneb | at one time OpenStack was seen that way. now k8s is. | 15:18 |
| zaneb | if we think that's wrong then we haven't succeeded in selling it | 15:19 |
| mnaser | thing is | 15:24 |
| mnaser | moving from physical => virtual is an easy leap | 15:24 |
| mnaser | most people will do it | 15:24 |
| mnaser | moving from virtual => containers .. | 15:24 |
| mnaser | that's a whole another story | 15:24 |
| mugsie | hell, we are still trying to get some stuff from physical -> virtual properly | 15:26 |
| zaneb | mnaser: it's a big leap for legacy applications. for greenfield development? not so much | 15:28 |
| mnaser | even greenfield | 15:28 |
| mnaser | i promise that once you enter the containers ecosystem | 15:28 |
| *** openstackgerrit has quit IRC | 15:28 | |
| mnaser | i GENUINELY wonder how anyone ever runs anything in prod | 15:28 |
| mnaser | i tried to get keystone once running. a simple python project. nothing magical | 15:29 |
| mnaser | wanna run something on a deploy like a db sync? nope, no existing construct for that | 15:29 |
| zaneb | which is why db_sync is a terrible pattern that should go away imho | 15:29 |
| cdent | db sync isn't anything you would have a s | 15:29 |
| cdent | yeah that | 15:29 |
| mnaser | want to quickly and easily get something stored locally and sync'd (i.e. fernet-keys) .. get back and start deploying storage | 15:30 |
| cdent | zaneb: https://review.openstack.org/#/c/619050/ | 15:30 |
| zaneb | keystone was not a greenfield project built with containers in mind | 15:30 |
| mnaser | it's as simple of a project that you can have though | 15:30 |
| zaneb | cdent: I've been meaning to propose on the ML that we do that for all of OpenStack | 15:30 |
| mnaser | that's a terrifying idea | 15:30 |
| mnaser | restart placement | 15:31 |
| mnaser | surprise, you've just killed your cloud for 2 hours because of some really big change | 15:31 |
| cdent | that sounds like data migrations, not schema migrations | 15:31 |
| zaneb | we already banned really big changes in migrations like 4 years ago | 15:32 |
| cdent | if you're are keeping the two separte, not big deal | 15:32 |
| mnaser | as an operator, knowing when im going to touch the db is a really neat thing. | 15:32 |
| cdent | if you've not updated the code, you wouldn't have new migrations, yeah? | 15:32 |
| mnaser | it's helpful in having steps in upgrades when we are running things on multiple hosts | 15:33 |
| cdent | which is why it's optional | 15:33 |
| fungi | the idea that commons effort is long-term roi may be part of the problem. modern business isn't looking for long-term anything because the people who run it hope to be acquired and deploy their golden parachutes and be off to the next big thing before that ever comes to pass... similarly their stockholders are looking to buy low and sell high and don't expect to necessarily even still be investing in | 15:34 |
| mnaser | right, that's good, but again, goes back to the idea that running stuff in containers is hard. | 15:34 |
| fungi | that company in a year or two | 15:34 |
| cdent | but in the placement case it's designed so that any of many tens of placemen containers will check if a sync is required and do it or not. if one does it, the rest don't | 15:34 |
| * cdent fist bumps fungi | 15:35 | |
| fungi | i recall a previous employer who was always courting potential buyers for his company saying that it was no longer sufficient to show your company made profit or even that it made more profit each year than the last. you needed to be able to show that the rate at which your profit increased was accelerating, because that's what investors are ultimately after | 15:35 |
| mnaser | fungi: man i agree so much on that | 15:37 |
| mnaser | all these big corps are out to just uh, build shareholder value | 15:37 |
| mnaser | which is nice and all | 15:37 |
| * mnaser doesn't have to do that | 15:37 | |
| cdent | is it? | 15:37 |
| *** jamesmcarthur has joined #openstack-tc | 15:37 | |
| mnaser | but the problem that it builds this super ridiclously inflated market of everything | 15:38 |
| fungi | yep | 15:38 |
| fungi | and also frustrating for people trying to build things in such an environment because there is little support from management to erect a sturdy structure when they only care that you do the bare minimum to keep it from toppling over until they find someone else to sell it to and make the complete rebuild no longer their problem | 15:39 |
| mnaser | its just a big priority problem | 15:40 |
| mnaser | but summed up well by what you said | 15:41 |
| fungi | all that is to say, i wonder if it's possible to argue/demonstrate that commons efforts also have a near-term roi | 15:43 |
| cdent | some types of commons work are probably good marketing fodder, | 15:44 |
| fungi | one such argument we've made in the past is that if your employees are helping fix these boring but necessary problems they tend to grow credibility and experience in the community which also makes it easier for them to work on your priorities... but that does still run into the two-masters priority battle problem | 15:44 |
| cdent | for instance "placement gets 50% performance improvement from judicious refactoring for sake of maitenance" <- true | 15:44 |
| fungi | yeah "costs less to run" is perhaps a good take on that | 15:45 |
| fungi | (easier to deploy and upgrade means your sysadmins are more efficient and can get more done, lighter weight means less hardware you need to throw at it, and so on) | 15:46 |
| cdent | yeah | 15:46 |
| fungi | maybe better quantization of commons efforts could be leveraged to show progress so it doesn't seem like the benefits are that far in the future? | 15:47 |
| fungi | though i see our goals process as kind of that already | 15:47 |
| fungi | we necessarily qantize communicy cycle goals to one release in the future | 15:48 |
| fungi | s/communicy/community/ | 15:48 |
| fungi | unrelated, but the final day voter outreach seems to have helped some. we're on the cusp of 20% turnout now (so better than rocky). 277 ballots cast out of 1390 | 15:53 |
| smcginnis | Awesome | 15:54 |
| fungi | 278 votes would be exactly 20% | 15:54 |
| prometheanfire | so close | 15:56 |
| mugsie | everyone check they have actually voted :) | 16:02 |
| mnaser | btw | 16:02 |
| mnaser | cncf toc call going on right now -- https://zoom.us/j/967220397 | 16:02 |
| mnaser | one of the things to discuss was that whole techcrunch thing | 16:02 |
| * mnaser will be listening in | 16:03 | |
| *** ricolin has quit IRC | 16:04 | |
| zaneb | fungi: the alternative view of that (and I wish I didn't have to be the one advocating for it) is that the value of a company is essentially the NPV of all future distributions. So *in theory* if you can increase the long-term value that will be reflected in the market in the short term, so even folks who intend to sell up next year still benefit from increasing long term value. in theory. | 16:09 |
| fungi | fair. the challenge becomes to demonstrate it | 16:09 |
| zaneb | I think one problem with that theory is that the long-term value is ultimately unknowable, so it's easier to change perceptions of that than to actually create future value | 16:10 |
| fungi | thanks for reporting on that mnaser! i'm on another conference call at the moment so couldn't listen in if i wanted to | 16:10 |
| mnaser | have projects considered using gsoc to help gather contributors? | 16:16 |
| fungi | we've had trouble convincing google that we qualify | 16:17 |
| mnaser | yikes | 16:18 |
| *** openstackgerrit has joined #openstack-tc | 16:18 | |
| openstackgerrit | Merged openstack/governance master: mention goal selection owners as a chair duty https://review.openstack.org/641009 | 16:18 |
| fungi | because our projects are funded already from their perspective (and also there may be cultural biases in google-centric communities against openstack on principle) | 16:18 |
| mnaser | i guess k8s is funded so i would assume gsoc doesn't give them anyone right | 16:19 |
| cdent | which principle/ | 16:19 |
| fungi | diablo_rojo may have more specific recollections | 16:19 |
| mnaser | the one where k8s growing benefits them and openstack growing doesn't | 16:20 |
| mnaser | :< | 16:20 |
| clarkb | dims has put together applications in the past iirc | 16:20 |
| clarkb | I'm not sure how much direct feedback they give, but dims may have that info | 16:20 |
| fungi | yeah, keep in mind that the underlying dynamic with gsoc is "google spends money to help your project out by paying an intern" | 16:20 |
| dims | clarkb : last i remember was that the details in our proposals are not clear enough for someone who is brand new to get started and do a good job. | 16:22 |
| dims | clarkb : there's a lot of hand holding that needs to be done during the application process which is hard as well. | 16:22 |
| cdent | dims: "not clear enough for someone who is brand new" is kind of openstack in a nutshell | 16:39 |
| cdent | I remember when I started I was told not too feel bad if I didn't really feel useful within a year | 16:39 |
| dims | yep cdent | 16:40 |
| cdent | which is sad making | 16:41 |
| cdent | I think I managed to buck that trend but I had the privilege of being a unicorn | 16:41 |
| fungi | i seem to recall we've also put in gsoc proposals for smaller sorts of efforts which ended up getting rejected, i just don't remember much of the feedback we got (if any) | 16:52 |
| fungi | we've tended to have better luck with outreachy, but a major differentiator there is that you have to find the outreachy funding rather than google providing it | 16:53 |
| mnaser | well, that was a lot more productive | 16:57 |
| *** jamesmcarthur has quit IRC | 16:57 | |
| mnaser | with the cnf topic up, jbeda brought up the idea behind making sure we don't compete across communities and that we need to work together to explain value of "when to use vms" and "when to use k8s" | 16:58 |
| mnaser | also, dan kohn from the cncf mentioned that quote was probably not the best and it had created a negative atmosphere which we're aiming to avoid | 16:59 |
| smcginnis | Glad to hear he recognizes that. | 16:59 |
| mnaser | maybe if anyone else was on that call can echo what else they heard from it | 16:59 |
| dims | i was :) they will put up the video soon, so everyone can hear the response from Dan and questions from Joe and Quinton | 17:00 |
| dhellmann | fungi , diablo_rojo , tonyb : is one of you planning to post the governance patch with the new TC members after the election tonight? or should I volunteer to do that? | 17:03 |
| fungi | dhellmann: in the past it's been the election officials to propose the patch, i think | 17:04 |
| fungi | so happy to do that as soon as election closes, though it'll be immediately before or during tc office hour | 17:04 |
| dhellmann | fungi : yeah, I would prefer that, but I'm happy to help, too | 17:05 |
| dhellmann | that sounds good | 17:05 |
| fungi | awesome. expect it between 00:00 and 02:00 utc | 17:05 |
| *** jamesmcarthur has joined #openstack-tc | 17:06 | |
| smcginnis | 6:38 left | 17:06 |
| -openstackstatus- NOTICE: Gerrit is being restarted for a configuration change, it will be briefly offline. | 17:11 | |
| *** jamesmcarthur has quit IRC | 17:14 | |
| dtantsur | mnaser: btw we do participate in Outreachy | 17:16 |
| hogepodge | dims: glad to hear that. staff call conflicted so I wasn't able drop in | 17:16 |
| hogepodge | mnaser: thanks for listening in | 17:18 |
| *** e0ne has quit IRC | 17:18 | |
| *** jamesmcarthur has joined #openstack-tc | 17:27 | |
| *** jpich has quit IRC | 17:33 | |
| bauzas | mnaser: well, did they said 'when to use VMs' when talking about OpenStack ? | 17:34 |
| bauzas | mnaser: because OpenStack can't be reduced to VMs obviously | 17:35 |
| bauzas | and Kube can spin VMs too | 17:35 |
| bauzas | so the dichotomy between when using Kube vs. other opensource projects shouldn't be made this way IMHO | 17:36 |
| mnaser | I think the idea was that first of all we don’t want to compete between communities first of all and then second when talking cnf va CNCF that each one has their use in specific contexts | 17:36 |
| bauzas | okay thanks for clarifying | 17:36 |
| *** marst has quit IRC | 17:51 | |
| *** e0ne has joined #openstack-tc | 18:19 | |
| fungi | dtantsur: "we" as in some openstack folks do participate in outreachy | 18:25 |
| fungi | i know this because of the flood of outreachy candidates competing to fix a variety of entry-friendly bugs in storyboard at the moment | 18:26 |
| dtantsur | yeah, right | 18:36 |
| *** mriedem has quit IRC | 18:37 | |
| *** mriedem has joined #openstack-tc | 18:39 | |
| *** jamesmcarthur has quit IRC | 18:52 | |
| *** e0ne has quit IRC | 19:17 | |
| *** jamesmcarthur has joined #openstack-tc | 19:21 | |
| *** jamesmcarthur_ has joined #openstack-tc | 19:24 | |
| *** jamesmcarthur has quit IRC | 19:25 | |
| *** dtantsur is now known as dtantsur|afk | 19:31 | |
| *** e0ne has joined #openstack-tc | 19:37 | |
| *** whoami-rajat has quit IRC | 20:22 | |
| fungi | dtantsur|afk: one of them was also looking at some ironic stuff, saw them mention looking at a bug for sushy | 20:50 |
| *** cdent has quit IRC | 20:51 | |
| fungi | don't forget everyone, board meeting is happening in 8 minutes; the open infrastructure projects confirmation process is on their agenda | 20:52 |
| mnaser | tc-members ^ Adding a highlight to that. Was just about to post — https://zoom.us/j/9574980705 | 20:52 |
| fungi | call details are also in http://lists.openstack.org/pipermail/foundation/2019-February/002714.html | 20:53 |
| fungi | side-channel discussions sometimes happen in the #openstack-board channel too | 20:53 |
| mugsie | fungi: mnaser thanks - I would have completely forgotten about it | 20:53 |
| smcginnis | There's also https://wiki.openstack.org/wiki/Governance/Foundation#OpenStack_Board_of_Director_Meetings - for completeness. | 20:56 |
| *** serverascode has joined #openstack-tc | 20:57 | |
| *** jamesmcarthur has joined #openstack-tc | 20:57 | |
| *** jamesmcarthur_ has quit IRC | 21:00 | |
| *** e0ne has quit IRC | 21:13 | |
| mnaser | tc-members: joint leadership is happening Sunday before summit. | 21:19 |
| fungi | you're faster than i am ;) | 21:20 |
| smcginnis | Maybe we should call it something other than "joint leadership" in Denver. :) | 21:20 |
| dhellmann | :rimshot: | 21:21 |
| smcginnis | Thanks, I'll be here all week. | 21:21 |
| mnaser | Lol smcginnis Took me a second to catch that one. | 21:21 |
| *** e0ne has joined #openstack-tc | 21:26 | |
| *** e0ne has quit IRC | 21:30 | |
| dims | LOL | 21:34 |
| *** ijolliffe has quit IRC | 21:40 | |
| dhellmann | Thank you, wendar, I appreciate the care with which you oversaw the whole process and collecting input from everyone | 21:50 |
| dhellmann | well, she's not here | 21:50 |
| zaneb | dhellmann: she is in #openstack-board | 21:51 |
| jbryce | for those of you who weren't following along, the board approved the guidelines for confirmation of new projects: https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmationGuidelines | 22:29 |
| jbryce | dhellmann one item that we have as part of the process is to solicit optional feedback from existing confirmed projects governance bodies about pilot projects that are going up for confirmation (kind of like amicus curiae briefs). is there a process that the tc would like us to follow to notify you of those opportunities? | 22:31 |
| dhellmann | jbryce : that's an excellent question. I will encourage the next chair to put that together (elections end today, we'll be changing chair asap afterwards) | 22:32 |
| jbryce | ok. sounds good | 22:32 |
| *** jamesmcarthur has quit IRC | 22:41 | |
| notmyname | https://releases.openstack.org/stein/schedule.html <-- seems to indicate that PTL nominations are this week. but I've see emails saying it "starts soon" and nothing official saying nominations are open. the linked pages from the schedule don't have any details. can someone please clarify the PTL election schedule, please? | 22:55 |
| diablo_rojo | notmyname, they will start today once we finish the TC election | 22:57 |
| notmyname | diablo_rojo: thanks for the update | 22:57 |
| gmann | notmyname: https://review.openstack.org/#/c/629749/ | 22:57 |
| *** jamesmcarthur has joined #openstack-tc | 22:57 | |
| diablo_rojo | notmyname, no problem :) Our tooling isn't currently built to handle both simultaneously so we will be doing a quick turn around. | 22:58 |
| *** jamesmcarthur has quit IRC | 22:58 | |
| *** jamesmcarthur has joined #openstack-tc | 22:58 | |
| smcginnis | Just over 45 minutes until the fun begins. | 22:59 |
| diablo_rojo | smcginnis, indeed. | 22:59 |
| fungi | yep | 23:00 |
| fungi | trying to scramble to cook dinner between board meeting and election ending | 23:00 |
| *** jamesmcarthur has quit IRC | 23:37 | |
| *** jamesmcarthur has joined #openstack-tc | 23:38 | |
| *** jamesmcarthur has quit IRC | 23:40 | |
| diablo_rojo | Three more minutes.. | 23:42 |
| fungi | bracing for results! | 23:43 |
| zaneb | interesting :) | 23:48 |
| diablo_rojo | Congrats ttx, asettle, mnaser, zaneb, jroll, ricolin, and mugsie :) | 23:48 |
| mnaser | Thanks diablo_rojo !! Welcome new faces jroll asettle and ricolin !! | 23:50 |
| *** ijolliffe has joined #openstack-tc | 23:50 | |
| fungi | huge thanks to bauzas and flwang for running and i really hope you both run again in ~6 months time! | 23:51 |
| diablo_rojo | bauzas and flwang please please run again in 6ish months! Thank you for running :) | 23:51 |
| fungi | with my election official hat off for a brief moment, i think everyone on the ballot would have made an excellent representative for the tc | 23:52 |
| fungi | i heard from lots of people that they had a particularly tough time ranking the candidates this time around | 23:52 |
| fungi | just happy we have as many interested and engaged community leaders as we do in openstack | 23:53 |
| fungi | and now i put my election official hat back on and propose some governance changes while i finish dinner | 23:53 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!