| *** tosky has quit IRC | 00:07 | |
| *** jamesmcarthur has joined #openstack-tc | 00:33 | |
| *** tonyb has quit IRC | 01:07 | |
| *** tonyb has joined #openstack-tc | 01:09 | |
| *** tonyb has quit IRC | 01:27 | |
| *** tonyb has joined #openstack-tc | 01:31 | |
| *** lbragstad has quit IRC | 01:43 | |
| *** jamesmcarthur has quit IRC | 01:43 | |
| *** lbragstad has joined #openstack-tc | 01:44 | |
| *** jamesmcarthur has joined #openstack-tc | 01:45 | |
| *** jamesmcarthur has quit IRC | 01:56 | |
| *** lbragstad has quit IRC | 02:09 | |
| *** diablo_rojo has quit IRC | 02:35 | |
| *** gcb_ has quit IRC | 03:14 | |
| *** gcb_ has joined #openstack-tc | 03:17 | |
| *** jamesmcarthur has joined #openstack-tc | 03:56 | |
| *** gcb_ has quit IRC | 04:17 | |
| *** Bhujay has joined #openstack-tc | 04:45 | |
| *** gcb_ has joined #openstack-tc | 04:53 | |
| *** gcb_ has quit IRC | 05:53 | |
| *** Bhujay has quit IRC | 06:07 | |
| *** gcb_ has joined #openstack-tc | 06:17 | |
| *** Bhujay has joined #openstack-tc | 06:18 | |
| evrardjp | good morning | 06:35 |
|---|---|---|
| *** openstackgerrit has joined #openstack-tc | 06:56 | |
| openstackgerrit | Tony Breeds proposed openstack/governance master: Begin the 'T' Release naming process https://review.openstack.org/600354 | 06:56 |
| *** e0ne has joined #openstack-tc | 06:58 | |
| *** dangtrinhnt has quit IRC | 07:02 | |
| *** dangtrinhnt has joined #openstack-tc | 07:40 | |
| *** tosky has joined #openstack-tc | 07:41 | |
| *** jpich has joined #openstack-tc | 07:47 | |
| *** gcb_ has quit IRC | 08:10 | |
| *** david-lyle has quit IRC | 08:14 | |
| *** dklyle has joined #openstack-tc | 08:15 | |
| *** cdent has joined #openstack-tc | 08:19 | |
| *** dtantsur|afk is now known as dtantsur | 08:25 | |
| *** gcb_ has joined #openstack-tc | 08:33 | |
| *** gcb_ has quit IRC | 08:38 | |
| *** gcb_ has joined #openstack-tc | 08:41 | |
| *** gcb_ has quit IRC | 08:45 | |
| *** annabelleB__ has joined #openstack-tc | 09:53 | |
| *** annabelleB__ has quit IRC | 09:57 | |
| ttx | Good read: https://rbtcollins.wordpress.com/2018/09/06/is-openstacks-mission-broken/ | 10:08 |
| cdent | ah, it's published now, good | 10:13 |
| cdent | I saw that yesterday when he asked for some proofing | 10:13 |
| cdent | I think the analysis is pretty good, but as usual implementing the suggestions is...difficult | 10:15 |
| *** e0ne has quit IRC | 10:15 | |
| evrardjp | cdent: I don't think it's difficult -- I think it's resource intensive | 10:37 |
| cdent | that's what diificult means | 10:37 |
| cdent | marshalling of resources has always been the problem for any desired changes in openstack | 10:37 |
| evrardjp | for example, if OSA could get a long running node, that would be done in all our commits of a branch :) We have hoped for some company to step in, and provide an external CI for that, but it never occured. | 10:38 |
| *** e0ne has joined #openstack-tc | 10:39 | |
| evrardjp | I am curious, and I'd like to compare how much money is injected by Google on k8s infra vs what is done in openstack | 10:40 |
| evrardjp | maybe that wouldn't be 100% representative, but give at least an order of magnitude to know if we need to improve on that side, and therefore can get more resources | 10:41 |
| cdent | that's a good line of questioning | 10:52 |
| * cdent finds lunch | 10:56 | |
| *** cdent has quit IRC | 11:02 | |
| *** cdent has joined #openstack-tc | 11:33 | |
| openstackgerrit | Mark Goddard proposed openstack/governance master: Add tenks under Ironic governance https://review.openstack.org/600411 | 11:33 |
| dims | o/ | 12:14 |
| * cdent waves at dims | 12:14 | |
| dims | reading the link from ttx :) | 12:15 |
| mrhillsman | o/ | 12:24 |
| *** cdent has quit IRC | 12:34 | |
| *** annabelleB has joined #openstack-tc | 12:38 | |
| *** e0ne has quit IRC | 12:41 | |
| *** jamesmcarthur has quit IRC | 12:52 | |
| *** jamesmcarthur has joined #openstack-tc | 12:52 | |
| *** lbragstad has joined #openstack-tc | 12:53 | |
| *** e0ne has joined #openstack-tc | 12:59 | |
| *** jamesmcarthur has quit IRC | 13:03 | |
| *** mriedem has joined #openstack-tc | 13:08 | |
| *** lbragstad has quit IRC | 13:09 | |
| TheJulia | good morning | 13:11 |
| *** lbragstad has joined #openstack-tc | 13:15 | |
| evrardjp | morning TheJulia mrhillsman! | 13:33 |
| evrardjp | and dims | 13:33 |
| mrhillsman | morning evrardjp | 13:34 |
| *** annabelleB has quit IRC | 13:37 | |
| *** cdent has joined #openstack-tc | 13:45 | |
| fungi | seems like mnaser might have some counterarguments to lifeless's blog post, particularly around the assertions that public cloud providers don't run close to master and therefore silo operations from upstream fixes | 13:49 |
| cdent | mnaser is a very valuable exception to what _seems_ to be the norm | 13:50 |
| jroll | I also don't believe running close to master inherently de-silos operations from upstream fixes | 13:53 |
| fungi | the other day i ran into an upstream horizon policy issue (introduced in rocky) in vexxhost, pointed it out to mnaser and within an hour he's tracked down what commit introduced the regression and pushed a fix up for review. i don't know how much less siloed you can reasonably expect | 13:55 |
| cmurphy | ha | 13:56 |
| cdent | it's a typical trope of your style of argument that you point out the exception to the rule, and thus _appear_ to think the rule is invalid | 13:56 |
| jroll | fungi: oh, I absolutely agree it makes it much easier. I don't believe it follows naturally, companies with broken org structures and/or broken incentives will still maintain the silo | 13:56 |
| cdent | this is something that I keep observing, and I wonder if it is intentional | 13:56 |
| fungi | i like to find possible holes in arguments, lest people think they are universally applicable | 13:57 |
| cdent | is anything universally applicable? | 13:57 |
| fungi | evrardjp: i don't think we have any concrete way of measuring the monetary value of various sorts of cloud resource donations and human donations member companies sink into our project, nor are there similar public numbers from google and pals about kubernetes/cncf, though they did make some statement in a keynote at oss last week highlighting the market value of the gce resources they were putting | 13:59 |
| fungi | behind the kubernetes ci which they're working to officially externalize under the linux foundation | 13:59 |
| * fungi hunts for the figure | 13:59 | |
| fungi | "$9 million" (presumably usd, though they were in canada when they delivered the keynote so not totally sure) | 14:00 |
| evrardjp | fungi: yeah I remember that they were announcing number | 14:01 |
| fungi | also wasn't clear if that's annual or the purchase cost of the hardware behind it or... | 14:01 |
| evrardjp | yeah that's the problem, we cannot really know what's behind that numbers | 14:01 |
| evrardjp | but it is maybe worth having a mechanism of evaluation, to know where we stand? | 14:03 |
| fungi | 1. i personally think it would be a meaningless data point because it would be in no way accurate nor based on any comparable metrics, and 2. i worry if we clued said donors into the actual estimated value of these resources it might give some of them pause to reevaluate the benefit to them | 14:06 |
| fungi | or at least give them the impression that their particular donation is unneeded because so many others are already pitching in | 14:07 |
| *** clarkb has joined #openstack-tc | 14:11 | |
| dims | fungi : agree on the impression. have heard that one | 14:14 |
| evrardjp | I agree on the impression too | 14:14 |
| fungi | continuing through lifeless's blog post there, i do agree that the community has leaned far too heavily on integration testing to find bugs that could be found through api contracts and unit tests. devstack is not (designed to be) a test tool (the old smoketests aside), it's intended as a means for a developer to quickly stand up an environment and try out a change they're working on | 14:15 |
| evrardjp | although I don't believe in being obscure is generally positive -- at some point any company can evaluate to pull out their support -- we need to be prepared, not hope for it to never happen | 14:15 |
| fungi | oh, we have infra donors walk away with some regularity | 14:16 |
| evrardjp | but the context was indeed to determine if we have enough resources to have long running instances that could allow further testing | 14:16 |
| *** AlanClark has joined #openstack-tc | 14:16 | |
| evrardjp | fungi: indeed -- the questions are "would it be realistic to have this kind of testing?" "how far are we?" | 14:17 |
| mnaser | fungi: thanks! Link to said post? | 14:17 |
| mnaser | Also, the 9 million is just an account with $3 million per year on it for 3 years | 14:17 |
| mnaser | Just a GCP account | 14:17 |
| evrardjp | mnaser: https://rbtcollins.wordpress.com/2018/09/06/is-openstacks-mission-broken/ | 14:17 |
| mnaser | And the multicloud thing.. I dunno. I had conversations and I was told “thanks, but no thanks” | 14:18 |
| * mnaser shrugs | 14:18 | |
| knikolla | o/ that's a very interesting blog post, and it also curiously touches upon one of the use cases we're trying to target with our federated cloud. aka: a place where the community can run a CI/CD public deployment of OpenStack. | 14:18 |
| smcginnis | I have a hard time picturing how the devstack-less testing would work in practice. | 14:19 |
| evrardjp | one could also say that infra regions are deployed with openstack too, right? | 14:19 |
| evrardjp | smcginnis: that's maybe something I can convince you over drinks, and many other deployement tools can do too:) | 14:20 |
| smcginnis | Hah, OK. | 14:20 |
| smcginnis | I see it working for nova patches, but some of the others that gets a bit hairy. | 14:21 |
| evrardjp | I mean that's closer to what's really happening for our users -- if that was the point | 14:21 |
| fungi | smcginnis: i wasn't saying we shouldn't use devstack or something like it to run integration tests, but that right now we have so little confidence in our api contracts between components and unit testing of those that we end up falling back on integration testing instead | 14:21 |
| smcginnis | fungi: Yeah, I was referring to the blog post comments on it. | 14:21 |
| smcginnis | I just don't think it's "omg-we-can’t-do-that-because-technical-reason-X-about-what-we-do-today", more " | 14:22 |
| smcginnis | omg-we-can’t-do-that-because-technical-reason-X" | 14:22 |
| dims | mnaser : fungi : one thought about that mission post, what if we as TC said that we discourage folks from assuming they have a fully working openstack installation from master/tip of all the projects. they should be relying on milestones instead. will that help encourage some slack on the reviews (help iterate better? instead of beating every review into submission) | 14:22 |
| clarkb | evrardjp: I think you need to more fully desrcibe what it is you are looking for before anyone can say if it is possible or not | 14:23 |
| evrardjp | clarkb: fair :) | 14:23 |
| smcginnis | Milestones are better than every commit, but I'm firmly in the release only camp. | 14:23 |
| clarkb | long running tests are currently possible by infras definition of such a thing | 14:23 |
| mnaser | meh | 14:24 |
| mnaser | I’m sorry. No one deploys from master and no one ever will | 14:24 |
| evrardjp | mnaser: in production you mean | 14:24 |
| smcginnis | mnaser: Apparently some did for a time. | 14:24 |
| mnaser | All were going to do is cause more pain and stuff needed to maintain to get this CI running | 14:24 |
| dims | mnaser : it's meh, but folks constantly bring that up as an issue | 14:24 |
| evrardjp | or even in tests from all the master branches from all the repos? | 14:24 |
| mnaser | Well, it didn’t really turn out very well, so | 14:24 |
| fungi | the main hole i see in lifeless's suggestion to run pre-merge testing against a persistent deployment is that's *even more* fragile, because injecting untrusted proposed changes from any random person off the street can compromise the integrity of that environment in unpredictable ways | 14:24 |
| mnaser | I don’t think it’s an exemplary thing to do | 14:25 |
| smcginnis | mnaser: And I think it contributed to some of the negative feelings towards OpenStack. | 14:25 |
| mnaser | We deployed Rocky from rc’s and it’s just fine. | 14:25 |
| evrardjp | fungi: but in that case, the functional test would fail,and no merge happens? I am confused | 14:25 |
| dims | yep. that's cool mnaser | 14:25 |
| mnaser | I don’t think the state of our integration environments has any problems. | 14:26 |
| fungi | evrardjp: the question is how you repair the persistent deployment after a proposed change trashes it | 14:26 |
| mnaser | Also, I dunno why everyone seems to want to talk about rearchitecting something from scratch that works. We’re splitting things even more to make teams work more efficiently | 14:26 |
| * smcginnis is not working around every messed up DB migration | 14:26 | |
| evrardjp | fungi: that becomes a technical issue? I mean snapshot and restore is something I can think off... | 14:26 |
| mnaser | Don’t know there seems to be a want to | 14:26 |
| mnaser | Merge it all | 14:27 |
| dims | fungi : i would not advocate that either ( pre-merge testing against a persistent deployment ) | 14:27 |
| dims | at least as the sole way to test stuff | 14:27 |
| mnaser | (I’m on mobile apologies for being so brief) | 14:27 |
| evrardjp | fungi: I am not sure what's the point of that part of the discussion -- I thought we'd hit a resource issue first before hitting a technical issue :) | 14:27 |
| fungi | evrardjp: we used to run our ci with persistent test nodes. rerunning jobs in a persistent server created a lot of manual labor refreshing and repairing and monitoring those persistent test environments. we invented nodepool so we could stop doing those things | 14:27 |
| evrardjp | (well that's a technical issue but I guess you understand me...) | 14:28 |
| knikolla | dims: maybe it doesn't have to be persistent. we have a lot of load from people running experiments that don't care about having their vms up for longer than the experiment runs. | 14:28 |
| dims | right | 14:28 |
| evrardjp | fungi: good to know -- but I am wondering if the state of the art has changed now :) | 14:28 |
| fungi | and in fact, earlier incarnations of nodepool did in fact build a prepared test environment and then boot snapshots of that | 14:29 |
| fungi | the problem there became, we serve lots of different projects, and they tend to run a lot of different kinds of jobs, and separately building and managing and updating all those various snapshots was nontrivial | 14:30 |
| fungi | so we went through a lengthy effort to strip down the environments to common bare minimums and design a system whereby the jobs themselves define and build what they need to be able to run | 14:31 |
| *** zbitter has joined #openstack-tc | 14:31 | |
| *** zaneb has quit IRC | 14:32 | |
| fungi | as a side effect, this also makes it possible for projects to test changes to their job environments simply by altering those definitions | 14:32 |
| * TheJulia needs to finish reading lifeless's post | 14:33 | |
| *** Bhujay has quit IRC | 14:34 | |
| knikolla | is there a middle ground between having each commit being deployable, and the long feedback cycle we currently have? | 14:34 |
| ttx | The trick is that having each commit be fully functional makes it really easy to release at any point, which is quite comfortable | 14:36 |
| clarkb | knikolla: I think some projects do already have that by demanding less that perfect commits and allowing for followup changes to address smaller concerns | 14:36 |
| clarkb | but you lose what ttx points out when you do that | 14:36 |
| knikolla | clarkb: ++ we do that in keystone | 14:36 |
| ttx | But yes, i think we can relax it a bit without creating a project integration nightmare | 14:36 |
| ttx | key word being "a bit" | 14:37 |
| ttx | We already do that to some extent | 14:37 |
| ttx | Like we don't do security advisories for security issues that were never in a formal release | 14:38 |
| ttx | simplifies the work of teh VMT substantially | 14:38 |
| dims | ++ ttx | 14:38 |
| clarkb | use of feature flags is the example lifeless always used | 14:39 |
| clarkb | as another method | 14:39 |
| TheJulia | knikolla: We tend to do that in ironic becuase we set the context with semver + our release model and that we had deployments we knew that were trailing master by a few weeks. We have multiple upgrade testing jobs as a result, and we do follow-up patches as possible or as we're able to kind of keep momentum moving forward. This has this nasty side effect of driving towards perfection for each change too, but setting the | 14:39 |
| TheJulia | tone regarding nitpicking has helped | 14:39 |
| edleafe | knikolla: Every patch has to pass all tests in order to merge (well, at least for any of the projects I work on). That makes it hard to do a step-wise improvement, as the intermediary steps may break things, and that patch can't ever merge | 14:39 |
| ttx | Basically you should not necessarily be able to deploy any commit... But every commit should pass tests ? | 14:39 |
| clarkb | edleafe: I disagree with that assertion | 14:39 |
| clarkb | you can do step wise improvements while tests pass | 14:40 |
| ttx | right, that ^ | 14:40 |
| fungi | also, if you defer testing to later, when tests run and find the bug it ends up in a backlog because fixing that is nobody's responsibility. if the ci system had found that bug before the change merged, the developer introducing the bug would have been required to fix it | 14:40 |
| clarkb | projects control the tests and the code they test. Its not like the tests are some immovable object that cannot improve too | 14:41 |
| pabelanger | +1 | 14:41 |
| TheJulia | We've had to turn off tests at times because of major issues | 14:42 |
| cdent | projects themselves are often immovable objects | 14:42 |
| TheJulia | We don't like doing it, but it is a necessary evil in order to sometimes get things sorted out. | 14:42 |
| evrardjp | clarkb: +1 | 14:42 |
| fungi | as more and more test definitions move under direct control of various projects, it's also increasingly easy for them to make those jobs non-voting or otherwise disabled during transitions | 14:42 |
| mugsie | yeah, we do it as well from time to time | 14:42 |
| pabelanger | TheJulia: was there much pain bringing them online again? | 14:42 |
| mugsie | (disable tests) | 14:42 |
| knikolla | valid points. | 14:42 |
| ttx | That said, I'm unconvinced that issue is the root of all evils. I'm much more convinced that aligning teams along code lines (rather than functional lines) is hurting us more at this point. | 14:42 |
| TheJulia | pabelanger: never really | 14:42 |
| knikolla | ttx: can you elaborate more on that? | 14:43 |
| edleafe | clarkb: Oh, I know it's *possible*. It's done all the time. I was replying to knikolla's question about "less than perfect commits" [t 18AO] | 14:43 |
| purplerbot | <clarkb> knikolla: I think some projects do already have that by demanding less that perfect commits and allowing for followup changes to address smaller concerns [2018-09-06 14:36:13.272578] [n 18AO] | 14:43 |
| TheJulia | ttx: +++++++ | 14:43 |
| ttx | (i.e. the eternal "compute node" ownership issue) | 14:43 |
| mugsie | pabelanger: usually the commit that fixes them would reenable them fir us, and everyone just needs a rrebase | 14:43 |
| edleafe | oops - wrong link | 14:43 |
| TheJulia | ttx: I also think we can't force teams to try to cross their comfort zones or boundaries. They are going to focus on solving the issue at hand or the itch that they are trying to scratch. | 14:43 |
| edleafe | This one: [t hCX] | 14:44 |
| purplerbot | <knikolla> is there a middle ground between having each commit being deployable, and the long feedback cycle we currently have? [2018-09-06 14:34:49.811387] [n hCX] | 14:44 |
| mugsie | ttx: yeah. I am more and more in agreement with the idea someone put forward of sig-node style ownership | 14:44 |
| ttx | knikolla: We have Conway's Law hitting us badly. From an operator perspective, you want a clean single agent doing work on every node, and what we have is a set of diverse things desogned by separate groups running on a single node | 14:44 |
| pabelanger | mugsie: TheJulia: Yah, I too have disabled a test in the past, mostly because something was wedge for the test side. However, that also usually meant I was breaking something somewhere. Thankfully wasn't openstack deliverable. | 14:44 |
| evrardjp | ttx: that's quite an architecture change | 14:45 |
| TheJulia | pabelanger: most of the time we've had to do it, it is because we were broken outside of our direct control by things such as grenade or branching | 14:45 |
| ttx | evrardjp: not so much. You should start by having a single group in charge of what ends up on the node | 14:45 |
| ttx | It's a social issue much more than a technical one | 14:45 |
| ttx | Nobody "owns" the node | 14:46 |
| mugsie | evrardjp: it is a small tech change, big cultural one | 14:46 |
| evrardjp | mugsie: yeah it was my point :) | 14:46 |
| TheJulia | except the social issues will take precedence and block the technical changes to achieve that | 14:46 |
| mugsie | (for various definitions of small of course) | 14:46 |
| mugsie | TheJulia: unfortunately | 14:46 |
| ttx | It does not have to be a big bang change. You can superpose structures, like creating a Node SIG | 14:47 |
| evrardjp | but if we come back to the problem statement listed in blog post, can we organise ourselves to fix what can/should be technically fixed? | 14:47 |
| ttx | The issue to make that happen is more a resource issue -- people have a hard time justifying extra time spent on openStack | 14:47 |
| ttx | so they tend to entrench in silos more and more | 14:48 |
| TheJulia | evrardjp: exactly, and I also think not everything fits into one singular definition of a single installable thing. | 14:48 |
| ttx | rather than join multiple teams all over | 14:48 |
| TheJulia | but the context switching and the knowledge to do that is easy for people in this channel to say that people should join and work in multiple teams at the same time... in reality to those who lack much of the context, it is really unreasonable. | 14:49 |
| cdent | TheJulia++ | 14:49 |
| ttx | yes | 14:49 |
| knikolla | there's also the huge time differential between doing the work, and seeing it in a release. and possibly missing a release which happens a lot with large changes. | 14:50 |
| scas | o/ | 14:50 |
| TheJulia | knikolla: This is true, and I felt really strongly about that when I was a newer contributor. But we do set a schedule.... and maybe it is the project management side of my brain thinking this, but people have to be aware of that schedule and try to generally meet it | 14:51 |
| ttx | knikolla: the usual tension between not enough releases (missing the boat, fast feedback) and too may releases (too much stable maintenance work) | 14:51 |
| ttx | many* | 14:51 |
| TheJulia | If a driver team doesn't make their supporting library changes in time, my hands are really bound in terms of allowing related patches to move foweward | 14:51 |
| evrardjp | anyway it was an instructive/useful blog post | 14:51 |
| * TheJulia realizes her brain has been broken by becoming a ptl | 14:52 | |
| knikolla | TheJulia, ttx: that usually bites me a lot since my work is more aligned with school semesters rather than OpenStack releases. | 14:52 |
| knikolla | and I have interns leaving right when I need them the most. | 14:53 |
| scas | i, too, feel the tension betweeen releasing too fast and not fast enough | 14:53 |
| TheJulia | knikolla: that is a common problem sadly :( | 14:53 |
| scas | as someone with a deploy focus, it's compounded because my stable work really doesn't start until the package teams have released their sets | 14:53 |
| TheJulia | knikolla: Part of that is why we pushed the anti-nitpicking changes, because so many new contributors would get hung up on minor things and blocked | 14:54 |
| * knikolla today i learned I'm not special! | 14:54 | |
| ttx | knikolla: we had a rather large discussion on changing the release cycle length last year... which concluded that 6-month was still a good trade-off between too often and not often enough. | 14:54 |
| TheJulia | knikolla: you are special in all sorts of awesome ways! Your running for TC! | 14:54 |
| knikolla | TheJulia: :) | 14:55 |
| ttx | Once you replace the word "release" with "stable branch", people are not so excited in having them more often | 14:55 |
| * TheJulia needs to go find migraine meds now | 14:55 | |
| TheJulia | (not this discussion, a extremely healthy pour at a local bar last night) | 14:55 |
| evrardjp | ttx: and having many of them to maintain too ;) | 14:55 |
| evrardjp | TheJulia: haha :) | 14:56 |
| ttx | evrardjp: exactly | 14:56 |
| knikolla | One of the things we are trying to offer in our public cloud, is the possibility to use a "CD" region, which is continually refreshed (not persistent) as a way to offer new features fast and iron out production bugs earlier. | 14:56 |
| evrardjp | it's always a question of balance -- all this post is about balance | 14:56 |
| evrardjp | well "always" | 14:56 |
| evrardjp | s/always/often/ : ) | 14:56 |
| scas | TheJulia: electrolytes! it's what plants crave! (no really) | 14:57 |
| evrardjp | I suppose the assertion "80% of test activity is not testing the code under test." is not 100% valid depending on the projects and contextes. But it seems it has been observed in places, and that can be technically challenged and improved | 14:57 |
| evrardjp | scas: :) | 14:57 |
| mriedem | so i guess office hours started 2 hours ago | 14:58 |
| * knikolla needs to run to a meeting. | 14:58 | |
| knikolla | thanks all for the discussion. | 14:58 |
| * TheJulia needs to run an errand too | 14:58 | |
| lbragstad | mriedem i double checked my calendar to make sure i had the meeting time right | 14:59 |
| * cmurphy waves | 15:00 | |
| EmilienM | hello | 15:00 |
| cdent | tc-members for the sake of protocol, here's a ping for the already happening office hours | 15:00 |
| cmurphy | lol | 15:00 |
| dims | yay :) | 15:01 |
| * zbitter reads scrollback | 15:01 | |
| ttx | I'm happy to see that we have candidates ! | 15:01 |
| *** zbitter is now known as zaneb | 15:01 | |
| * ttx checks recent additions | 15:01 | |
| zaneb | I'm definitely going to struggle to rank these candidates, so that's a good sign | 15:01 |
| ttx | With gmann that will make 9 | 15:02 |
| * cmurphy expecting at least one more | 15:02 | |
| ttx | Yes on one hand it's only 9, but it is a very strong set | 15:03 |
| *** jamesmcarthur has joined #openstack-tc | 15:03 | |
| ttx | I secretly hope people will factor all forms of diversity in their vote | 15:04 |
| ttx | But I've been disappointed by that in the past | 15:04 |
| cmurphy | ++ :/ | 15:04 |
| cdent | ttx for a french guy you seem to be underfueld in the existential dread department | 15:05 |
| scas | i shoulder enough of existential dread to share | 15:06 |
| ttx | But you have great recipes! | 15:06 |
| ttx | https://www.gocomics.com/calvinandhobbes/1986/10/16 | 15:07 |
| *** jamesmcarthur has quit IRC | 15:08 | |
| fungi | mriedem: yeah, lifeless kicked off an early office hour by offering some interesting observations and solutions | 15:08 |
| fungi | (via blog post, as that's how it's usually done) | 15:09 |
| mriedem | let me guess, this was sniffed out on twitter? | 15:09 |
| ttx | no, openstack planet! | 15:09 |
| * lbragstad sets https://rbtcollins.wordpress.com/2018/09/06/is-openstacks-mission-broken/ on mriedem's desk | 15:09 | |
| mriedem | oh i see, another blog that i don't read | 15:09 |
| dims | scroll to the end for a tldr :) | 15:09 |
| ttx | dims: there is also a Tl;DR at the start. | 15:10 |
| fungi | tl;dr bookended! | 15:10 |
| ttx | mriedem: technically, OpenStack planet is an aggregator, not a blog. :P | 15:10 |
| evrardjp | mriedem: haha | 15:10 |
| dims | ah i missed that :) | 15:10 |
| mriedem | ttx: yeah i knew | 15:10 |
| mriedem | but jesus who has the time | 15:11 |
| mriedem | to read all these things | 15:11 |
| ttx | But then I learned about Betteridge's law of headlines | 15:11 |
| mriedem | "are cats superior to dogs?! read on for my hot take!" | 15:11 |
| TheJulia | mriedem: ++++ | 15:11 |
| evrardjp | mriedem: apparently ttx has, that's why he brought it. | 15:11 |
| ttx | sorrrrry | 15:11 |
| evrardjp | mriedem: get your conclusions :p | 15:11 |
| evrardjp | ttx: :) | 15:11 |
| ttx | We have loooong mornings waiting for the US crowd to wake up | 15:12 |
| cmurphy | heh | 15:12 |
| ttx | and tehn it's madness until 10pm | 15:12 |
| cmurphy | it's so peaceful though | 15:12 |
| cmurphy | i get so many things done | 15:12 |
| dims | LOL ttx | 15:12 |
| ttx | so if you start real work before 11am you're dying by 8pm | 15:12 |
| evrardjp | cmurphy: yeah the problem is day ends at 11am | 15:12 |
| scas | 3am USian time is pure magic. the whole country is just barely starting to stir | 15:12 |
| scas | doesn't matter which USian time zone | 15:13 |
| scas | back to the main topic at hand, chef openstack exists in one of those places where it all depends on work that is openstack-adjunct, community wise | 15:15 |
| scas | there were talks about pulling in chef runs within rdo, but that never materialized (largely due to siloing and time constraints) | 15:16 |
| TheJulia | scas: the same could almost be said after 3pm pst | 15:16 |
| EmilienM | mriedem: s/read all these things/write all these things/ | 15:18 |
| lbragstad | ttx are there specific areas of diversity you're looking for? | 15:20 |
| mriedem | 20-something white males from the US midwest | 15:20 |
| ttx | lbragstad: gender, geographic... | 15:22 |
| ttx | lbragstad: but then I love you too. | 15:22 |
| lbragstad | ok - just curious, those were what i figured but i wasn't sure if you were implying something more specific by your comment | 15:22 |
| fungi | don't forget diversity of professional backgrounds | 15:23 |
| ttx | yes++ | 15:23 |
| * ttx looks up Denver weather | 15:23 | |
| mriedem | might get more diversity if the same people didn't stay on the tc for several years | 15:23 |
| mriedem | note: i'm in a shit mood today | 15:24 |
| ttx | That is true. Stepping down from chair was for me a first step | 15:24 |
| fungi | we seem to have ~50% turn-over at each election | 15:25 |
| * knikolla feels it important to point out that I’m a white male (as not to get undeserved diversity points) | 15:25 | |
| ttx | At the same time, some complained that the Foundation staff was not helping OpenStack as much as pilot projects, which was weird | 15:25 |
| ttx | so involvement is a two-edged sword | 15:26 |
| mriedem | who complained? | 15:26 |
| mriedem | board members? | 15:26 |
| mriedem | execs? | 15:26 |
| scas | perceptions are reality, in a lot of cases, sadly | 15:26 |
| ttx | mriedem: TC members | 15:26 |
| fungi | knikolla: but from the perspective of what you spend your time working on, that's significantly different from a lot of candidates | 15:26 |
| fungi | so unique perspectives | 15:26 |
| TheJulia | and unique perspectives help ground groups like the TC | 15:26 |
| mriedem | ttx: you can be involved in the tc w/o being an elected big whig | 15:26 |
| ttx | mriedem: some said that it's a lot easier to justify the time if you get the big whig | 15:27 |
| smcginnis | knikolla: :) | 15:27 |
| zaneb | mriedem: you can, but many employers make it easier if you're an elected bigwig | 15:27 |
| ttx | although that's probably not true of myself | 15:27 |
| cdent | I said I might be jealous about foundation staff helping pilot projects, in term of project management, which is sort of concrete weekly organization | 15:27 |
| cdent | which in some ways is much more practical than what the tc does | 15:28 |
| mriedem | i thought about running this time, had a list of stuff to put in an email and everything, | 15:28 |
| cdent | but I certainly wasn't complaining | 15:28 |
| mriedem | but it would totally distract from technical stuff i have to get done in nova in stein, | 15:28 |
| ttx | cdent: that was not just you :) | 15:28 |
| mriedem | and for that reason i'm not gonna run, for fear of actually being elected | 15:28 |
| ttx | 92F highs next week | 15:29 |
| zaneb | mriedem: that's sometimes the harder part, justifying the time to yourself | 15:29 |
| mriedem | but i don't think it helps to have the same people time and again in the echo chamber because they have the time | 15:29 |
| fungi | cdent: it's more like what the release team does, you mean? | 15:29 |
| zaneb | I agree but I feel like we've gotten better at rotating over the last few election cycles | 15:30 |
| zaneb | still not great at electing diverse candidates though :/ | 15:30 |
| fungi | ttx: it will be "a dry heat" | 15:31 |
| ttx | as long as we have 50% renewal at each election I feel like we have a good change/persistence mix | 15:31 |
| * fungi will be glad to experience a week of 92f temperatures without the 100% humidity he's been experiencing lately | 15:31 | |
| * TheJulia believes it is supposed to be 109F tomorrow | 15:32 | |
| cdent | fungi: I was thinking in terms of what ildikov and Anne do to help orchestrate activity in kata and edge. I'm not saying we need that in openstack, just that observing it, I was all "aw, that looks like a nice thing" | 15:33 |
| dims | and hogepodge in containers ... | 15:33 |
| fungi | yep, anne actually ended up beating the release management drum to get kata 1.0 out the door | 15:33 |
| fungi | but in all cases, the idea is to get members of those communities to take up those effort | 15:34 |
| fungi | sometimes they need coaching when it's an entire community of individuals who have never been exposed to frequent engagement in a f/loss community | 15:34 |
| dtroyer | What ildikov is doing for StarlingX is greatly appreciated, as right now it is basically two groups that… ^^^ what fungi says :) at least at the project management levels in our case | 15:35 |
| dtroyer | holding the light for all to gravitate toward so to speak… | 15:36 |
| *** tosky has quit IRC | 15:36 | |
| fungi | it comes with a lot of frightening unknowns: devising your own development schedules without product managers telling you what they are, talking directly to your users without a sales engineer to mediate, et cetera | 15:38 |
| ttx | the effort needed is different based on the maturity of the open collaboration culture in those projects | 15:38 |
| scas | the unknown unknowns are part of the perception. in the information age, it's easy to pull up someone's ml history, social profile or personal website to get a point-in-time read on their less-filtered thoughts, which feeds into perceptions, which causes a rift that doesn't really exist. i've seen it happen enough times where i'd consider it a tech worker constant | 15:42 |
| TheJulia | it also takes times for leaders to develop and grow in such environments in order to carry the flag forward | 15:42 |
| *** e0ne has quit IRC | 15:42 | |
| TheJulia | s/times/time/ | 15:42 |
| * dtroyer likes times better, it comes with a crossword puzzle… | 15:43 | |
| TheJulia | heh | 15:43 |
| *** jamesmcarthur has joined #openstack-tc | 15:49 | |
| scas | being that prevailing minds tend to have a common thread, like working in enterprise-style companies on software for said companies, there's not really any buffer between perception and reality. the trope of jumping to conclusions is so that there's a cult classic film about it | 15:50 |
| scas | but when you get a group of strong personalities from varied backgrounds, the perceptions do take a form of their own | 15:51 |
| ildikov | dtroyer: thanks and happy to help :) | 15:52 |
| ildikov | ttx: +1 | 15:52 |
| ildikov | I would say that with pilot projects it is important to have an initial setup of governance and processes so they can start to operate in a way which is not needed fr OpenStack in its current stage | 15:53 |
| ildikov | however based on experiences with feature development activities such as often mentioned multi-attach I personally believe that there is value in recognizing people who're willing to take on coordination activities | 15:54 |
| lbragstad | +1 | 15:55 |
| ildikov | as it is a very important but every now and then also a less fun activity | 15:55 |
| dims | +1 | 15:55 |
| ildikov | I'm not saying we need to create roles for this or change governance all of a sudden | 15:56 |
| scas | "it's a dirty job, but someone's gotta do it" | 15:57 |
| ildikov | but in case of cross-project work and more complex development activities it is good to keep this aspect in mind | 15:57 |
| ildikov | scas: +1 | 15:57 |
| lbragstad | we kinda already have roles for the coordination bit for community goals | 15:57 |
| knikolla | champions | 15:57 |
| ildikov | lbragstad: +1 | 15:58 |
| persia | I very strongly believe in separation between people who lead activities (e.g. champions) and people who review and authorise actiitivies (e.g. core reviewers of the governance repo). | 15:59 |
| cdent | lbragstad: Am I remember right that you championed a thing recently? When you did that did you just decide you were going to do that, or did you negotiate it with your employer? | 15:59 |
| persia | We're doing fairly well, except lots of folk expect the TC to do things, rather than expecting the TC to delegate things. | 15:59 |
| lbragstad | cdent at the time i wrote https://review.openstack.org/#/c/469954/ i was unemployed | 16:00 |
| cdent | was it a gambit? | 16:01 |
| scas | there's another perception that needs to be obliterated in the least humane way possible: that we're all doing this at the behest of our respective employer | 16:02 |
| lbragstad | i had plans to do that work when i was still involved with osic | 16:02 |
| lbragstad | if i had to put a label on it - i would say i was trying to follow up on what i said i was going to do as opposed to accepting work upstream to find work | 16:03 |
| cdent | scas: yeah, I'm not a fan of that perspective either, but trying to flesh out a picture | 16:04 |
| lbragstad | if that's what you're asking cdent | 16:04 |
| cdent | since "champions" are transitory but effortful it is interesting | 16:04 |
| scas | cdent: i think it has to do a lot with 'company affiliation' | 16:04 |
| cdent | lbragstad: yeah, that helps | 16:06 |
| persia | I think that it is a rare person that can spend their time on this project that doesn't have support or approval from some sponsor (most commonly employer), and that the sponsor has undue influence over actions taken by the person. That said, most of the actual actions are likely taken by the individual, and I submit that most individuals decide things needing doing, and then confirm with a sponsor, rather than doing as they are instructed to do. | 16:06 |
| persia | That said, if we entirely remove any affiliation, there is no incentive for folk to sponsor developers. If we highlight activities that we want done with praise that includes affiliation reporting, that may incent sponsors. | 16:06 |
| scas | right. that's swinging the pendulum to the extreme. 'i happen to work on openstack at X, but i am not X' is where i'm at in my head | 16:07 |
| lbragstad | but - that's not to say whatever some is working isn't going to have a significant or positive impact to how X uses OpenStack | 16:08 |
| lbragstad | someone* | 16:09 |
| lbragstad | or Y or Z for that matter | 16:09 |
| persia | I think whatever someone is working on is very likely to have a positive impact on how X uses OpenStack. Most folk, even those that entirely self-select activities, tend to do things that garner them praise from peers and supervisors. | 16:10 |
| jbryce | i think missed office hours, but i had a couple of items: 1) any tldr thoughts on the osf project email i sent last week 2) we're starting to sift through berlin keynote proposals and wanted to see if anyone here had any ideas they wanted to throw out (similar to what dhellmann and melwitt did in vancouver) | 16:10 |
| zaneb | jbryce: thanks for posting that update | 16:11 |
| smcginnis | Yep, nice update. Nothing stood out of concern for me. | 16:11 |
| mriedem | persia: as a data point, my management / employer has no idea i'm doing the upgrade-checkers goal | 16:12 |
| mriedem | i signed up after complaining about not making any traction on easing upgrades at all the various face to faces | 16:12 |
| mriedem | same way the extended maintenance thing happened | 16:12 |
| mriedem | my employer doesn't give a shit about that | 16:12 |
| mriedem | jbryce: do the community contributor awards on stage during keynotes, | 16:14 |
| mriedem | rather than during lunch on friday when no one from the "outside" is there | 16:14 |
| *** jamesmcarthur has quit IRC | 16:14 | |
| dims | mriedem : ++ | 16:14 |
| persia | mriedem: I still think you should be credited as a "leader" in our community for taking those on, and that some of that credit goes to your management/employer for giving you the freedom to take such decisions. | 16:14 |
| mriedem | persia: at the end of the day i'm not judged on getting those things done, | 16:15 |
| mriedem | it's my ass if i don't get what's on my annual goals done | 16:15 |
| mriedem | which means over time | 16:15 |
| lbragstad | ^ | 16:15 |
| dims | makes 3 of us ^ :) | 16:15 |
| lbragstad | only piling on here because i can attest to it first hand | 16:16 |
| * smcginnis waves from the clubhouse too | 16:16 | |
| dims | :) | 16:16 |
| scas | i'm from the 'entirely self-selected' camp, where my employer just happens to align with my public work | 16:16 |
| * persia tries very hard not to read that as "There is no point in valuing goal champions as leaders" and finds some less lucky people to argue with | 16:17 | |
| cdent | persia: except that you're talking to some of the most visible leaders in the community | 16:17 |
| scas | however, i believe that recognition needs to exist at all levels | 16:17 |
| cdent | so you need to take account of that | 16:18 |
| scas | without recognition, morale wanes | 16:18 |
| persia | cdent: Yes, who I believe get that way because of the policies of their sponsors, which policies I think it valuable to expose and reward. | 16:18 |
| cdent | dims, mriedem, smcginnis are, to put it mildly, powerhouses, but much of that power is commitment by themselves | 16:18 |
| mriedem | watch me go powerhouse my way into a haircut | 16:19 |
| dtroyer | also consider how many of us got to this position with our current employers… | 16:19 |
| *** mriedem is now known as mriedem_away | 16:19 | |
| jbryce | mriedem: thanks for the suggestion. it's good to hear that recognition would be welcome during keynote/all attendee time because it's different than the feedback we received around the original iteration of those awards and is why we moved them to a more "developer-centric" venue | 16:19 |
| dtroyer | in some cases the current gig may have been aided due to being on the road to leadersip already… | 16:19 |
| mriedem_away | jbryce: tbc, it was david medberry's idea in YVR | 16:20 |
| scas | another constant in technology is that tech-minded people tend to agree past one another often, and i've seen it in other f/loss communities. when you factor in an individual's personality, that agreement can become violent when largely constrained to bits of text on a screen | 16:20 |
| jbryce | i'm not sure if we can do them all during keynotes, but i'll put it on the list of things to figure out how to handle | 16:20 |
| clarkb | the problem with doing them in keynotes is very little of the group you are trying to recognize actually attend keynotes ime | 16:21 |
| *** jamesmcarthur has joined #openstack-tc | 16:21 | |
| smcginnis | Maybe a just a slide? | 16:21 |
| persia | jbryce: I think that those who are recognised and their peers would welcome such a ceremony in front of a larger audience. Some other membes of the audience may care less. The value of broader audience recognition to those recognised probably outweighs a few minutes of folk who don't care abiout how OpenStack is made being bored (why are they attending again?) | 16:21 |
| cdent | smcginnis++ | 16:21 |
| cdent | doesn't need to be a big deal, just a show and tell to that audience | 16:22 |
| cdent | later is the awarding | 16:22 |
| jbryce | persia: to be clear, the feedback i'm referring to was from the award recipients, not other attendees | 16:22 |
| persia | Interesting. Definitely unexpected. Thanks for the extra data. | 16:22 |
| scas | in another community i frequent, their annual conference concludes with a closing ceremony that includes the recognition of community awards | 16:22 |
| jbryce | thought the awards were cheesy, didn't want to get up in front of a big crowd, etc | 16:23 |
| jbryce | felt more comfortable and that it was more authentic doing it in a less formal environment with their peers | 16:23 |
| persia | It isn't nice to force people, but I wonder if "I don't want to stand up in front of everyone" correlates with things like "I don't want to put my name on the ballot for TC" | 16:23 |
| scas | yes and no. i have genuine issues presenting due to my background, but i did put my name on the list | 16:25 |
| cdent | persia: hmmm. If I had been called up in front of the keynotes to accept my "rebellious questioner" aware I might have been a bit reluctant | 16:26 |
| scas | a few releases ago, i'd have likely dismissed the notion entirely, musing something about work | 16:26 |
| cdent | but here I am on the tc | 16:26 |
| persia | cdent: So maybe not so much then :) | 16:26 |
| *** AlanClark has quit IRC | 16:28 | |
| jbryce | one option might be to do the less formal ceremony during lunch and then bring the recipients up as a group during the keynote. that way people can still have some fun during the presentations and individuals aren't necessarily singled out on a big stage. also helps meet the timing requirements | 16:29 |
| jbryce | (presentations meaning the presenting of the awards) | 16:30 |
| persia | Speaking as someone who missed an award by arriving to lunch late, that would also usefully serve as notice "Arrive to lunch on Friday on time" to the appropriate folk. | 16:31 |
| scas | jbryce: corollary to what i said above, chefconf (which has a similar cost barrier for attendees) holds their 'awesome community awards' ceremony at the end of the presentation track, so that those who want to follow along can show up, but there's no captive audience. lunch might be more interrupted by foodings to be as effective | 16:31 |
| zaneb | if we're going to do something can I also request that we not do it last thing in the keynote, when it's already 20 mins over time and 70% of the audience has left? | 16:35 |
| scas | attendance is about what you'd expect: a larger-than-needed room, but still a healthy amount of people from all backgrounds | 16:36 |
| scas | it, too, is recorded and distributed along with the presentations | 16:37 |
| *** jamesmcarthur has quit IRC | 16:37 | |
| *** jamesmcarthur has joined #openstack-tc | 16:39 | |
| scas | having a ceremony in morning keynotes, when i harken back to the superuser nomination i was part of, felt more like like it induced fatigue than celebrated accomplishment | 16:41 |
| *** jpich has quit IRC | 16:41 | |
| scas | being recognized is great, but a large group of people only wants to clap so much | 16:42 |
| *** dtantsur is now known as dtantsur|afk | 16:49 | |
| *** jaosorior has quit IRC | 17:00 | |
| *** jaosorior has joined #openstack-tc | 17:01 | |
| *** jamesmcarthur has quit IRC | 17:04 | |
| *** ChanServ sets mode: -rf | 17:13 | |
| *** jamesmcarthur has joined #openstack-tc | 17:17 | |
| *** jamesmcarthur_ has joined #openstack-tc | 17:17 | |
| *** jamesmcarthur has quit IRC | 17:21 | |
| *** e0ne has joined #openstack-tc | 17:34 | |
| *** jamesmcarthur_ has quit IRC | 17:39 | |
| *** dkrol has joined #openstack-tc | 17:39 | |
| *** diablo_rojo has joined #openstack-tc | 17:40 | |
| *** mriedem_away is now known as mriedem | 17:41 | |
| *** jamesmcarthur has joined #openstack-tc | 17:56 | |
| TheJulia | That is true... | 18:00 |
| smcginnis | I am looking forward to seeing everyone, but I know it's going to disrupt some things. | 18:00 |
| smcginnis | Oops, wrong window. | 18:01 |
| smcginnis | :) | 18:01 |
| mrhillsman | too late, showed your hand | 18:01 |
| smcginnis | Glad that was the last thing I had said. :P | 18:01 |
| *** e0ne has quit IRC | 18:01 | |
| mrhillsman | lol | 18:01 |
| lbragstad | :u | 18:01 |
| *** openstackgerrit has quit IRC | 18:05 | |
| *** e0ne has joined #openstack-tc | 18:06 | |
| *** e0ne has quit IRC | 18:08 | |
| *** melwitt is now known as melwitt_awaysick | 18:18 | |
| *** jaosorior has quit IRC | 18:27 | |
| * TheJulia raises an eyebrow | 18:27 | |
| *** jamesmcarthur has quit IRC | 18:40 | |
| *** jamesmcarthur has joined #openstack-tc | 18:50 | |
| *** e0ne has joined #openstack-tc | 19:05 | |
| mnaser | some really cool discussion i missed! | 19:14 |
| *** zaneb has quit IRC | 19:15 | |
| *** zaneb has joined #openstack-tc | 19:15 | |
| mnaser | jbryce: that update was really useful imho, it's very helpful to keep the community up to date of what's happening in the foundation side of things, i think at least on the tc side, a lot of us appreciated that update | 19:15 |
| mnaser | i'm not sure if it was sent to foundation ML only which might not have that much visiblity as the rest of the MLs though | 19:16 |
| *** ricolin_ has joined #openstack-tc | 19:17 | |
| *** ricolin_ has quit IRC | 19:17 | |
| *** ricolin has quit IRC | 19:19 | |
| *** cdent has quit IRC | 19:19 | |
| mriedem | it's not | 19:20 |
| fungi | well, it's foundation-specific changes. i suppose they could also cross-post that to... the various project announcement lists? or a bunch of different discussion lists? | 19:21 |
| *** ricolin has joined #openstack-tc | 19:21 | |
| fungi | certainly worth pointing out that post anywhere it seems relevant | 19:21 |
| mrhillsman | ++ | 19:24 |
| fungi | the only bit there that's particularly relevant to openstack-the-project is that it's proposed to be grandfathered in as an already confirmed project | 19:26 |
| fungi | most of the stuff it outlines is more important for pilot projects and those considering becoming pilot projects to be aware of | 19:27 |
| zaneb | yeah, it's mostly of interest to me as a foundation member, not so much as an openstack developer, so I think it's on the right list | 19:29 |
| zaneb | that said, there are a lot of foundation members who don't read the foundation list | 19:29 |
| mriedem | there was a question from jroll in the -dev list | 19:31 |
| jroll | well, given the fact that the foundation is no longer focused on only openstack, I think openstack folks might consider it interesting | 19:31 |
| mriedem | so i've replied to that with the link to http://lists.openstack.org/pipermail/foundation/2018-August/002617.html as follow up | 19:31 |
| jroll | mriedem: I only asked that because people pontificated about it here for an hour instead of just asking :) | 19:31 |
| mriedem | jroll: let us ask why there was just asking and not action shall we? | 19:35 |
| * mriedem digs in | 19:35 | |
| *** openstackgerrit has joined #openstack-tc | 19:41 | |
| openstackgerrit | Merged openstack/governance master: Update upgrade-checkers goal with storyboard info https://review.openstack.org/599759 | 19:41 |
| openstackgerrit | Merged openstack/governance master: Move mistral-extra under mistral repos https://review.openstack.org/597551 | 19:42 |
| openstackgerrit | Merged openstack/governance master: Retire some infra repositories - step 4 https://review.openstack.org/597639 | 19:42 |
| fungi | speculation over https://www.sdxcentral.com/articles/news/ebay-moves-away-from-openstack-embraces-kubernetes-and-docker/2018/09/ whether "moving away from OpenStack" means they're no longer using nova, or no longer using any openstack services. people outside the openstack inner circle do still seem to confuse "openstack" with nova itself (or at least nova's particular use cases) | 19:51 |
| mrhillsman | i think it is relevant as a whole because it is well openstack community | 19:51 |
| mrhillsman | in part it touches on the why so many MLs | 19:54 |
| mrhillsman | fungi i am also not sure what the purpose of that article was other than to get you to click on the title | 19:58 |
| mrhillsman | i mean click on it/read based on the title | 19:58 |
| fungi | mrhillsman: well, it includes a quote from ebays vp of platform engineering saying they are "moving away from OpenStack" but yes it would be interesting to find out whether he's misunderstood what the engineers have told him or whether that's really accurate | 20:00 |
| mrhillsman | or if she took that quote out of context | 20:00 |
| *** e0ne has quit IRC | 20:02 | |
| *** ricolin has quit IRC | 20:04 | |
| * mnaser doesn't understand this whole thing | 20:06 | |
| mnaser | "managed 167,000 virtual machines (VMs) and 4,000 applications." | 20:06 |
| mnaser | say very generously 100 VMs per machine .. thats ~1670 compute nodes at the very least | 20:07 |
| mnaser | you're gonna need a way to manage that physical infrastucture.. | 20:07 |
| mrhillsman | according to the talk at the boston summit ebay is supporting baremetal, gpu, and vms via k8s | 20:10 |
| mrhillsman | small footprint but moving quickly to go all k8s | 20:10 |
| clarkb | mrhillsman: that was all on top of openstack at that time fwiw | 20:10 |
| mrhillsman | but still on top of openstack | 20:11 |
| scas | my impression that i get from pieces like that is that 'people' expect 'openstack' to be more like a company-backed venture and not a collection of open source apis maintained by passionate individuals | 20:13 |
| mrhillsman | right, at the time, but moving quickly to go all k8s according to the talk, but yes, that article raises more questions rather than clearly state where/why no more openstack | 20:13 |
| scas | k8s is also a darling tech right now, still in the early parts of scaling the hype cliff. eventually, it'll see its cooling phase, but not before perceptions of it eating other communities from the inside fully manifest themselves | 20:15 |
| scas | we've not seen peak k8s yet. 2015 hasn't happened, metaphorically speaking | 20:16 |
| *** Guest32276 has joined #openstack-tc | 20:16 | |
| *** Guest32276 is now known as amrith | 20:16 | |
| mriedem | fungi: i was never speculating about openstack == nova | 20:17 |
| mriedem | or is this something else? | 20:18 |
| mriedem | oh i see, "and moving away from OpenStack" | 20:18 |
| mriedem | tbf, | 20:19 |
| mriedem | one of the rocky marketing articles noted that "now you can manage baremetal from nova!" | 20:19 |
| *** tosky has joined #openstack-tc | 20:19 | |
| jroll | well, that's not wrong | 20:19 |
| jroll | :P | 20:19 |
| scas | from the operator camp, i can say that those conversations have been happening at more places than ebay. when it gets filtered out to the publications, it tends to be misinterpreted or the message gets miscontrued. the blatant "we're dumping A for B, join us to change the world" is a signal that isn't being ignored at the IC level | 20:21 |
| jroll | yep, I've watched the same confusion at multiple employers now | 20:22 |
| scas | numerous people i know have shifted from openstack to either k8s or aws. there's almost no room in that group of technologists for any other option | 20:22 |
| *** jamesmcarthur has quit IRC | 20:27 | |
| scas | my umbrella statement includes a non-trivial amount of ex-rackers, for provenance | 20:28 |
| * mnaser grows increasingly frustrated with the k8s OR openstack thing | 20:31 | |
| scas | ++ | 20:31 |
| mnaser | i dunno why people don't understand that both have different use cases and compliment each other | 20:32 |
| mnaser | (forgive me) but you'd have to be pretty delusional to think every single org is going to adopt containers the right way™ | 20:32 |
| mnaser | we still got tons of folks using bare metal, cloud adoption just now is starting to pick up and that was a relatively easy transition | 20:32 |
| fungi | well, in the press anyway, dichotomies get you eyeballs. if there's no exciting conflict between the two technologies you can exploit in an article, fewer people will read it | 20:33 |
| mnaser | moving from bm => cloud is relatively simple, cloud => containerized is .. a whole *another* story | 20:33 |
| scas | playing realities off one another is what garners clicks. picture seeing something about openstack dominating in mainstream news. it has no 'substance' if there isn't a foil to compare it to, at least in the information age | 20:35 |
| scas | people are more skeptical of whizbang awesome if there is no baseline | 20:35 |
| scas | with startups branding themselves as the 'something of Z', the natural inclination is to look for something for comparison. openstack used to be compared to the giants of the day, but now it's lived long enough to become the villain to the k8s story | 20:40 |
| scas | the blagosphere, unfortunately, picks up on that with a laser focus | 20:41 |
| *** markvoelker has joined #openstack-tc | 20:52 | |
| TheJulia | I really feel that the hype curve encourages people to go "hey, look at what I did", and try to one-up each other. | 20:55 |
| *** dims has quit IRC | 20:55 | |
| scas | it does encourage a manner of subtle competition. some see it as friendly, some not so much | 20:58 |
| mnaser | why not say "hey i made a cool things which works even etter with your cool thing so we can make even coooler things" | 20:58 |
| scas | speaking from a USian perspective, there is a strong competitive nature that is baked into the very culture of the industry. collaboration has been something viewed more with skepticism than anything, as history has made a mockery of certain collaborative efforts. there's even a trope in the SF bay area about it, the bay bridge, comparing its newer, less robust, construction to that of the golden gate | 21:01 |
| scas | bridge | 21:01 |
| TheJulia | I think when people see competition, being collaborative kind of evaporates from the mental picture | 21:02 |
| TheJulia | scas: Similar experiences in my career so far as well, although no tropes like that... yet. | 21:03 |
| scas | TheJulia: i've lived all over the US over the past 15 years since leaving the solitude of small town america for 'the big city'. i picked up a thing or two :) | 21:04 |
| scas | 15? closer to 20, but nobody's counting | 21:05 |
| * TheJulia really tries to resist getting on a toxic corporate culture soapbox | 21:06 | |
| * TheJulia goes and back to code that she had her brain in earlier | 21:07 | |
| clarkb | funny story when I was a student at $engineering school we were getting reaccredited as an institution whose paperwork has value in the world and learned that the reason we did so little collaborative work as students was you can't get accredited if you can't show each individual student is learning $listofthingsrequired | 21:08 |
| clarkb | which unfortunately turns things competitive long before you enter the corporate wrold | 21:08 |
| TheJulia | clarkb: our society is broken :( | 21:09 |
| *** dims has joined #openstack-tc | 21:11 | |
| notmyname | don't give up hope! we can talk about the general "society" being broken, but we factor in to it! one of the most surprising things I've learned by being in the openstack community is how effective marketing can be | 21:24 |
| notmyname | my point is, we can be a part of the story that is told. if we are actually saying "use X and openstack together because they go better together", then that's something that can make a difference in how people talk about openstack and position it | 21:25 |
| notmyname | IMO that's one of the reasons the foundation has been doing their new stuff in the transition to "open infrastructure" instead of "open stack" | 21:26 |
| notmyname | I have my own strong opinions on where an how openstack is talked about and how we organize ourselves, and I'll be the first to agree with anyone saying that there are some really really hard problems to solve | 21:27 |
| notmyname | mostly around the people organization :-) | 21:28 |
| notmyname | I'm only trying to offer some hope that if we ourselves persist in focusing on solving problems for people in production (and not comparing ourselves to whatever the new hotness is), then we can continue to be proud of what we make and show how we can continue to work well with new tech as it comes along | 21:29 |
| notmyname | for example, didn't keystone get something working to make it work with k8s? that's great! we (as openstack) have a piece of tech designed to solve a particular problem, and it's being used to help new communities solve problems too. the k8s community is strong for it. and the openstack community is stronger for it | 21:31 |
| scas | my observation, from the deploy space, is that organizations comprised of people enter into a multi-year affair when it comes to infrastructure-level decisions, whether or not they immediately understand it. once something is in production, marketing has an opportunity to play realities off one another, and it can be very effective if the individual(s) are particularly salty on a given day | 21:31 |
| scas | we tech folk can get pretty salty, even the nicest of us | 21:31 |
| scas | it's the tragedy of knowledge work, and why people can violently agree with one another but not see it as agreeing | 21:32 |
| TheJulia | notmyname: you raise an excellent point that gives me quite a bit of deja vu | 21:32 |
| TheJulia | scas: that too is a very excellent point, at some point people are not on the same page and don't interpret the word being written or said as agreement | 21:35 |
| clarkb | notmyname: indeed. It helps to be explicit about what we have accomplished rather than only dwelling on the bad bits and I think we (opensatck) often do a poor job of that | 21:42 |
| clarkb | hell we just released rocky | 21:42 |
| mrhillsman | agree with notmyname as well and had a discussion with a few people re the same over the past couple of weeks | 21:44 |
| scas | clarkb: that's indemic to the nature of work, too. think to retrospectives that turned into self-flagellation sessions | 21:46 |
| clarkb | scas: with releases I think it also has to do with how easy and automated they have become as well. It used to involve a fairly significant group of individuals to get one out. Now a single person can do it and there are basically no fires | 21:47 |
| clarkb | scas: which means as a community we can effectively miss that we've bottled up a release and shipped it | 21:47 |
| scas | indeed. with the ease of things getting out the door, there's no big wind-up to a big bang | 21:47 |
| scas | chef openstack releases uses to be akin to the vogons hitting hyperspace. as tooling, methods and people matured, that volitility naturally settled down | 21:50 |
| scas | typos be damned, it's easy to lose track of what one has done positively. it's way easier to reflect on one's own shortcomings than what one has accomplished | 21:52 |
| scas | in f/loss, that positive reinforcement comes from people *not* making noise, which is not easy to use as motivation | 21:53 |
| mrhillsman | especially when there are plenty of folks willing and actively helping you to do just that :) | 21:53 |
| scas | in bsdland, which has had its own share of struggles, one person maintaining a super complex portion that 'everyone' needs/uses is not an uncommon thing | 21:55 |
| scas | but there's also next to no fanfare from corporations | 21:56 |
| fungi | the openstack foundation marketing team and others on staff have been persistently pushing a "here's how openstack and kubernetes compliment each other" story for the past couple years already, but there's a lot of entrenched "kubernetes replaces/is the new openstack" mindset out there already to counter | 21:56 |
| fungi | i know ttx has given talks and published articles about that topic, getting more people to do the same will hopefully help | 21:58 |
| fungi | osf presence has been regular at kubecon/cncf/related events | 22:00 |
| fungi | plus keynotes about complimentarity | 22:01 |
| fungi | at osf events | 22:01 |
| fungi | i'm sure they welcome all the help they can get in spreading the word about cooperation between communities and the software they create | 22:01 |
| *** mriedem is now known as mriedem_away | 22:02 | |
| *** mriedem_away has quit IRC | 22:02 | |
| *** dkrol has quit IRC | 22:21 | |
| *** diablo_rojo has quit IRC | 22:54 | |
| *** tosky has quit IRC | 22:59 | |
| *** diablo_rojo has joined #openstack-tc | 23:20 | |
| * jroll will try to help do his part as he productionizes some k8s-on-openstack things | 23:34 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!