| *** mriedem has quit IRC | 00:01 | |
| *** jamesmcarthur has joined #openstack-tc | 00:11 | |
| *** jamesmcarthur has quit IRC | 00:15 | |
| *** dklyle has joined #openstack-tc | 00:53 | |
| *** tosky has quit IRC | 00:55 | |
| *** diablo_rojo has quit IRC | 01:25 | |
| *** jamesmcarthur has joined #openstack-tc | 01:30 | |
| *** jamesmcarthur has quit IRC | 01:57 | |
| *** jamesmcarthur has joined #openstack-tc | 02:29 | |
| *** jamesmcarthur has quit IRC | 02:44 | |
| *** jamesmcarthur has joined #openstack-tc | 02:51 | |
| *** gagehugo has quit IRC | 02:55 | |
| *** jamesmcarthur has quit IRC | 02:57 | |
| *** jamesmcarthur has joined #openstack-tc | 02:57 | |
| *** jamesmcarthur has quit IRC | 03:03 | |
| *** jamesmcarthur has joined #openstack-tc | 03:08 | |
| *** dklyle has quit IRC | 03:22 | |
| *** jamesmcarthur has quit IRC | 03:24 | |
| *** jamesmcarthur has joined #openstack-tc | 03:27 | |
| *** jamesmcarthur has quit IRC | 03:56 | |
| *** jamesmcarthur has joined #openstack-tc | 04:03 | |
| *** gagehugo has joined #openstack-tc | 04:04 | |
| *** jamesmcarthur has quit IRC | 04:05 | |
| *** zaneb has quit IRC | 04:28 | |
| *** gagehugo has quit IRC | 05:12 | |
| *** jamesmcarthur has joined #openstack-tc | 06:06 | |
| *** jamesmcarthur has quit IRC | 06:11 | |
| *** ifat_afek has joined #openstack-tc | 06:19 | |
| *** ifat_afek has left #openstack-tc | 07:12 | |
| *** Luzi has joined #openstack-tc | 07:33 | |
| *** dklyle has joined #openstack-tc | 08:07 | |
| *** dklyle has quit IRC | 08:27 | |
| *** jpich has joined #openstack-tc | 09:19 | |
| *** tosky has joined #openstack-tc | 09:37 | |
| *** e0ne has joined #openstack-tc | 09:41 | |
| *** zaneb has joined #openstack-tc | 09:51 | |
| *** cdent has joined #openstack-tc | 10:42 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Clarify release management for murano deliverables https://review.openstack.org/624951 | 10:44 |
|---|---|---|
| *** dtantsur|afk is now known as dtantsur | 10:53 | |
| *** dangtrinhnt has quit IRC | 11:32 | |
| *** dangtrinhnt has joined #openstack-tc | 11:33 | |
| *** mriedem has joined #openstack-tc | 12:42 | |
| *** e0ne has quit IRC | 12:51 | |
| *** jamesmcarthur has joined #openstack-tc | 13:28 | |
| *** jamesmcarthur has quit IRC | 13:30 | |
| *** jamesmcarthur has joined #openstack-tc | 13:32 | |
| *** e0ne has joined #openstack-tc | 13:35 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Mark dib-utils release-management:deprecated https://review.openstack.org/624996 | 13:37 |
| *** jamesmcarthur has quit IRC | 13:40 | |
| openstackgerrit | Merged openstack/governance master: add openstack annual report to chair duties https://review.openstack.org/624790 | 13:40 |
| openstackgerrit | Merged openstack/governance master: update check-review-status to look for rejection by delegate https://review.openstack.org/624711 | 13:46 |
| *** e0ne has quit IRC | 13:49 | |
| *** tosky has quit IRC | 13:56 | |
| *** e0ne has joined #openstack-tc | 13:57 | |
| *** tosky has joined #openstack-tc | 14:00 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: document the topic tags for each house rule https://review.openstack.org/625004 | 14:02 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: add explicit house rule for documentation changes https://review.openstack.org/625005 | 14:02 |
| *** irclogbot_3 has quit IRC | 14:02 | |
| *** irclogbot_3 has joined #openstack-tc | 14:08 | |
| *** jamesmcarthur has joined #openstack-tc | 14:11 | |
| *** jamesmcarthur has quit IRC | 14:16 | |
| *** jamesmcarthur has joined #openstack-tc | 14:31 | |
| *** AlanClark has joined #openstack-tc | 14:51 | |
| *** gagehugo has joined #openstack-tc | 14:59 | |
| ttx | Office hour! | 15:01 |
| gmann | o/ | 15:01 |
| *** jamesmcarthur has quit IRC | 15:02 | |
| dhellmann | o/ | 15:02 |
| *** jamesmcarthur has joined #openstack-tc | 15:03 | |
| lbragstad | o/ | 15:04 |
| *** jamesmcarthur has quit IRC | 15:04 | |
| dhellmann | we should be ready to land the python policy updates early next week (actually the 15th, but that is Saturday) | 15:04 |
| dhellmann | we have a couple of other updates ready to go for tomorrow | 15:05 |
| dhellmann | gmann : where do things stand with https://review.openstack.org/#/c/621516/ ? is that ready for review? | 15:05 |
| *** jamesmcarthur has joined #openstack-tc | 15:06 | |
| cdent | o/ | 15:06 |
| gmann | dhellmann: i think so, i updated that from ttx and cdent comments and love to hear more feedback there | 15:06 |
| dhellmann | sounds good | 15:07 |
| evrardjp | o/ | 15:07 |
| dhellmann | I noticed a couple of gaps in the documentation for our house voting rules, and proposed changes to address them earlier today | 15:07 |
| cdent | I left a comment on https://review.openstack.org/#/c/622400/ about some of the questions I'd like to see us answer next. Does anyone have ideas on how we should pursue that? | 15:11 |
| dhellmann | it looks like we could use some more work on the stein runtime patch: https://review.openstack.org/611080 | 15:11 |
| * dhellmann looks at cdent's comments | 15:11 | |
| ttx | cdent: good question (and good questions). I'd say we should merge the base doc, them trigger a series of threads about each of your questions | 15:12 |
| *** ifat_afek has joined #openstack-tc | 15:12 | |
| cdent | yeah, I definitely want to merge it, I just wasnt thinking of much of a way to do next steps | 15:12 |
| ttx | maybe combine "are we doing these things" and "of the things we are doing are we doing them effectively?" | 15:12 |
| dhellmann | yeah, starting with a ML discussion seems like a good first step. and those might eventually be topics for office hours or meetings | 15:12 |
| cdent | I think those are definitely different questions | 15:13 |
| cdent | because some things we are doing are not in the toc | 15:13 |
| ttx | but keep "are these the things the community wants?" and "how do we make sure these things are done without needing heroes?" as separqte questions | 15:13 |
| cdent | s/toc/doc/ | 15:13 |
| * fungi will catch up on office hour scrollback once the security sig meeting calms down a smidge more | 15:13 | |
| ttx | ok so the question is "are there things we are doing that are not there" | 15:13 |
| dhellmann | what sorts of things are we doing that aren't documented? | 15:13 |
| cdent | i'm not certain, just rather assume so | 15:13 |
| cdent | it's more of a coverage thing, rather than an assertion | 15:14 |
| dhellmann | ok, well, imo, it's all of our responsibility to ensure that we differentiate between the things we want to do, the things we should do, and the things we must do. and that we prioritize the musts and let go of the wants. | 15:14 |
| cdent | but yeah, an ML discussion seems like a good way to go | 15:15 |
| cdent | let of the wants, yes | 15:15 |
| evrardjp | cdent: good questions indeed | 15:15 |
| ttx | also things we do but with a different hat | 15:15 |
| dhellmann | because as we've discussed several times this cycle, this team does not have infinite capacity | 15:15 |
| cdent | I'm great with the questions, less good with the answers | 15:15 |
| cdent | For me all of the questions lead up to the "without heroics" one. That's sort of my current axe. | 15:16 |
| dhellmann | ttx: yes, fair point | 15:16 |
| cdent | but I'm entirely unsure how to approach it, as I'm my own worst enemy on that front | 15:16 |
| ttx | dhellmann: especially there are things I care about that would rather fit under release management, or pure community cheerleading | 15:16 |
| dhellmann | I'm a little concerned that we categorize anything that takes a lot of work as heroics, and look for formal structures in places where social bonds are what we really need, but yeah I do share the sentiment somewhat that we need to support the people doing the "takes a lot of work" items better | 15:17 |
| dhellmann | ttx: sure. I mean that the TC should not try to drive or monitor those things as the TC | 15:18 |
| ttx | yeah. completely agree | 15:18 |
| dhellmann | we've all gotten used to wearing multiple hats at the same time, and I think we need to be more conscious of only wearing one hat at a time | 15:18 |
| cdent | I think we may be approaching the concept of heroics differently. Lots of work is not heroic. Working all the time out of sense of responsibility or whatever kind of pressure is heroic. | 15:19 |
| ttx | like the difference between "TC members must drive cross-project work" vs. "TC members are in a good position to also drive cross-project work" | 15:19 |
| *** jamesmcarthur has quit IRC | 15:19 | |
| cdent | "I have a queue that > 2 years long, but I try to mash it into six months" <- heroic | 15:19 |
| cdent | "I'm doing these 2 years of work in 2 years" <- lots of work | 15:20 |
| dhellmann | yes, that's a good distinction | 15:20 |
| dhellmann | the discussion about the encrypted volumes comes to mind as an example of something that is going to take a lot of work and for which people seem to want a formal structure as a short cut | 15:21 |
| dhellmann | I think ttx made that point on the ML thread? | 15:21 |
| dhellmann | at least the point that it's going to take a lot of work :-) | 15:21 |
| ttx | from the outside people see a technical problem (digest their thing into bits that are reviewable) and underestimate the social work they need to do to get general assentment on the plan and get it near the top of the review pile | 15:23 |
| ttx | and to be fair, we haven't talked that much about that aspect | 15:24 |
| ttx | we've kept on pointing at technical obstacles like spec review etc | 15:25 |
| dhellmann | I do think we need to talk about that more. I'm a little worried that if we document something very specific, people will look at it as a process rather than guidance and when they check the boxes and their work isn't approved they'll be upset | 15:25 |
| cdent | Yes. But talking about social challenges is something we've always struggled with. | 15:25 |
| ttx | while awareness and minshare is at least as important | 15:25 |
| cdent | we tend to fall into holes when trying to unwind the social challanges | 15:26 |
| ttx | cdent: well, we are technical people with slightly atrophied social skills | 15:26 |
| cdent | speak for yourself. all my skills are atrophied | 15:26 |
| ttx | lol | 15:26 |
| cdent | openstack has ruined me as a human | 15:26 |
| ttx | cdent: could just be age. At least I blame my fleeing neurons | 15:27 |
| cdent | definitely a factor | 15:27 |
| cdent | "awareness" is a key thing. Take matt's recently message about gate fracas. We all know there's a gate fracas but seeing it written down as what amounts to a story or set of stories is far more compelling than looking at the elastic recheck page. And stories are how groups motivate. | 15:28 |
| dhellmann | ++ | 15:29 |
| cdent | And sometimes they have to be told over and over and over before they do any good | 15:29 |
| cdent | so a "role" we can "support" is storyteller, perhaps | 15:29 |
| cdent | someone who helps to keep the narrative cohered | 15:30 |
| cdent | which sounds a bit like a pm, but I think its something a bit different becase of the social arena we are in | 15:30 |
| dhellmann | it was a bit enlightening to ask the PTLs to give me the #1 thing their teams were most proud to be working on in stein | 15:31 |
| * TheJulia reads and digests | 15:31 | |
| dhellmann | I like the idea of framing things as a story | 15:31 |
| cdent | a pm works in the workplace because you have to be there | 15:32 |
| TheJulia | That does tend to help with contextual acceptance. Less to rebel against from an authority standpoitn | 15:32 |
| gmann | +1. that work in many cases as practical solution | 15:32 |
| cdent | but we're more like people who gather around a campfire | 15:32 |
| *** jamesmcarthur has joined #openstack-tc | 15:32 | |
| cdent | a story is more telling | 15:32 |
| TheJulia | For a story, the person telling it knows they have to set the context | 15:33 |
| TheJulia | else the story will not make any sense | 15:33 |
| * dhellmann wishes that was automatically true | 15:34 | |
| TheJulia | I guess that is a high hope :( | 15:34 |
| dhellmann | people have to learn to do it, that's all I meant | 15:34 |
| * TheJulia joins cdent in the corner of ruined humans | 15:34 | |
| TheJulia | That is true | 15:35 |
| dhellmann | this feels like an idea with some meat on it. cdent, do you have ideas for next steps? | 15:35 |
| cdent | welcome TheJulia, we have weighted blankets, warm drinks, and silence | 15:35 |
| TheJulia | I also think people need to be open to listening | 15:35 |
| TheJulia | cdent: <3 | 15:35 |
| cdent | dhellmann: I'll think on it, but it only really just occurred to me in this form right now, in the telling (irony?) so it needs to digest a bit | 15:36 |
| * dhellmann nods | 15:36 | |
| cdent | I'll chew on it over the new year, and rejoin it here, and we can tell a few more stories and see where it is. | 15:37 |
| cdent | I've got another query/topic if that one has reached a reasonable stopping point, but don't want to move on yet, if not. | 15:38 |
| dhellmann | go for it | 15:38 |
| cdent | I'm asking this as a nova person, not as a tc person, but I want "non-vested leadership advice" so asking here: I've had some inquiries from $work about exploring the options of moving the vmware virt driver out of nova and keep it on the side as a third party driver. The main motivating factor is velocity. | 15:40 |
| cdent | I feel a bit in the middle on this, so awkward. | 15:40 |
| openstackgerrit | Jimmy McArthur proposed openstack/governance master: Adding - in OpenStack-Ansible * Trying to provide consistency w/ Docs * Stick with preferred naming convention https://review.openstack.org/625032 | 15:41 |
| cdent | I'll ping melwitt and mriedem so they're aware I've asked but this isn't really about the technically issues, nor even the internal to nova social issues, but more in the sense of "ugh, meh, but yeah, I kinda get it" | 15:41 |
| dhellmann | what sort of advice are you looking for? | 15:41 |
| evrardjp | cdent: isn't this a conversation for the nova channel? :p | 15:41 |
| cdent | evrardjp: the reason I'm asking here is because of the "non-vested" thing I said above | 15:42 |
| cdent | the advice I'm after is twofold: | 15:42 |
| cdent | a) Is this the sort of thing I should be trying to discourage for the sake of coherency and a public appearance of "health" | 15:43 |
| cdent | b) I'm deeply of two minds on decomposition and third party "plugin-like" things are healthy and we've seen lots of different approaches (cinder, neutron and nova all behave somewhat differently on this front) and it could be that the effort is better spent in some fashion. Ideas? | 15:45 |
| fungi | it feeds back into the earlier "driver teams" discussion too | 15:46 |
| mriedem | cdent: hyper-v already has an out of tree variant of their driver | 15:46 |
| cdent | This is something that's been batted around for months, but was only seriously brought up this morning and my instant reaction was...I'm going to need more input on this | 15:46 |
| mriedem | like powervm | 15:46 |
| mriedem | they do feature work on the out of tree driver and then try to upstream things into the nova repo | 15:46 |
| mriedem | per the usual process, | 15:46 |
| cdent | mriedem: yeah, and I think that's the model the people proposing this are wanting to follow, and maybe it will be fine | 15:46 |
| mriedem | and the out of tree thing goes into product | 15:46 |
| fungi | would the folks working on the vmware driver seek recognition as an official team (a la powervmstackers)? | 15:46 |
| dhellmann | what options are you considering? | 15:46 |
| fungi | (and winstackers) | 15:46 |
| ttx | fungi: except the driver forks are not part of those teams | 15:47 |
| cdent | dhellmann: just info gathering at this point | 15:47 |
| fungi | ttx: true, they're more about the ancillary toolchains i suppose | 15:47 |
| *** AlanClark has quit IRC | 15:48 | |
| dhellmann | cdent : ok, well, I don't quite understand yet what advice you're looking for. :-/ | 15:48 |
| dhellmann | is the question, should I be discouraging $work from forking a driver? | 15:48 |
| dhellmann | or is it, should we be considering moving drivers out of the nova tree? | 15:48 |
| dhellmann | or something else? | 15:48 |
| fungi | (and is it possible to move those drivers out of the nova tree or are they too tied to nova internals to be extracted cleanly?) | 15:48 |
| mriedem | "should we be considering moving drivers out of the nova tree?" that debate already happened years ago several times | 15:48 |
| gmann | cdent: and what all issue it solve ? like one mriedem mentioned about doing production feature in third party driver and then push in upstream ? | 15:49 |
| mriedem | it probably doesn't need to happen again | 15:49 |
| dhellmann | mriedem : right, and I don't want to reopen it, I'm just trying to understand cdent's question | 15:49 |
| mriedem | fungi: there is no versioned interface between nova-compute and the virt driver | 15:49 |
| mriedem | so we can break it at any time | 15:49 |
| mriedem | and have | 15:49 |
| fungi | yeah, last i heard the nova team insists there's no clean way to move drivers out of tree, so it's all about maintaining forks right? | 15:49 |
| dhellmann | if I take off my tc hat and just have my open source contributor hat on, then I have no particular interest in arguing with someone that they should not fork a driver because that doesn't cause me any extra work or perceivable harm | 15:50 |
| fungi | and the benefits/challenges of trying to synchronize your product fork with an upstream community-maintained codebase | 15:50 |
| mriedem | note that i'm not aware of any priority efforts vmware is trying to get into nova, | 15:50 |
| mriedem | there are a couple of specs but they are stalled and stuck back on rocky... | 15:50 |
| mriedem | so if vmware really cared about feature velocity in nova for their driver, they'd put forth more of an effort | 15:50 |
| mriedem | like what ibm has done releases past with the powervmdriver | 15:51 |
| gmann | that is imp point | 15:51 |
| fungi | as a user of free software which sometimes has alternative forked driver bits, i can say i'm far more inclined to ignore those and stick with the mainline drivers instead even if they lack support for some stuff | 15:51 |
| dhellmann | if I put my TC hat back on, I agree with mriedem that as long as we are providing a place for collaboration to happen, we can lead the horse to water but can't make it drink | 15:51 |
| cdent | mriedem: right that's part of the issue here. there are two sides of the coin and as far as I can tell the vmware side of the coin is "we just don't have the will to get over the (mostly historical) burdens of nova contribution" | 15:51 |
| mriedem | vmware live migration support was one for a long time, but we always said "show up with ci and we'll talk" | 15:51 |
| mriedem | which took years | 15:51 |
| fungi | the burdens of nova contribution are, on balance, likely smaller than the burdens of maintaining a fork and keeping it viable over timer | 15:52 |
| *** Luzi has quit IRC | 15:52 | |
| cdent | there is a desire to step to the side so that the nova-process can be sidestepped | 15:52 |
| fungi | er, time | 15:52 |
| cdent | and the entire downstream diff can be upstreamed (but to somewhere else). So it is a little bit like starlingx, but not to the same extent | 15:53 |
| mriedem | if you're a vio customer you're already locked into a vendor b/c of vcenter, so i doubt customers would really know or care about the difference either way | 15:53 |
| fungi | especially considering what maintaining a forked hypervisor driver probably means, in this case, is maintaining a fork of nova (the largest and arguably most complex component of one of the biggest and highest-velocity open source projects of all time) | 15:53 |
| mriedem | if you're using vcenter you likely don't care about open source | 15:53 |
| cdent | I'm mostly in agreement with mriedem on this, in the sense that, the same effort will need to be done, doing it somewhere else won't help much | 15:53 |
| fungi | the pain will probably be different, but at least no better | 15:54 |
| cdent | And this conversation is doing exactly what I was hoping it would, revealing some of the many issues more clearly, and in one place | 15:54 |
| gmann | that can be needed or can work if large amount if features going in driver which cannot be sycned up with upstream process and speed | 15:54 |
| dhellmann | it feels like we want to convince them not to do something, but that's not the same as "we must convince them" so I think our energy would be better spent on other things | 15:54 |
| gmann | s/if/of | 15:55 |
| fungi | often the path these efforts go down is that the fork lags behind, eventually means you're stuck maintaining forks of other related projects at that point, backporting critical/security fixes, and explaining to customers why they can't upgrade to an openstack with newer features | 15:55 |
| cdent | i think in this case the idea would not be to fork all of nova, just have an "external driver" and track the (sometimes changing) interface to it | 15:56 |
| fungi | it is, in short, a trap which leads lots of companies to conclude that "selling open source" isn't worth the risk | 15:56 |
| gmann | Fiware is facing the similar fork issue on ceilometer and monasca. i am suggesting them to upstream the thing and use upstream version | 15:56 |
| cdent | the underlying belief in this is feature velocity would be increased and be less constrained | 15:58 |
| dhellmann | there's only one way to know for sure if that's true | 15:58 |
| dhellmann | it's the top of the hour, so before tc-members drop offline I want to reiterate my request for input on https://etherpad.openstack.org/p/openstack-2018-annual-report | 16:00 |
| dhellmann | I'll be around for a bit if anyone wants to talk about it | 16:00 |
| * lbragstad gawked at that yesterday for a bit and couldn't come up with anything that was missing | 16:00 | |
| TheJulia | cdent: I like the external driver idea, I also dislike it because of how intertwined the code path is. :(\ | 16:01 |
| dhellmann | I could use some help on the awkward prose at the bottom | 16:01 |
| * lbragstad looks | 16:01 | |
| TheJulia | but only specifically for nova to spawn an instance. | 16:01 |
| cdent | TheJulia: yes. In a perfect universe an external driver would be easy and normal, but that's not the universe we are in. If we have that universe than a thousand flowers might bloom... | 16:02 |
| TheJulia | "might" We've not had the best luck with people writing external ironic drivers, but those that do tend to also just not upstream them it seems. or only need to hack on one portion because they need some special behavior in their environment. :( Nova is definitely a different case though. | 16:03 |
| * cdent nods | 16:05 | |
| TheJulia | I know that if ironic had better ability to get code merged into our virt driver, it would make all of our lives easier, but we're that one case where the boundary starts to blur for all the $reasons | 16:05 |
| TheJulia | so better to try and keep it in-tree and all | 16:06 |
| ttx | dhellmann: I don't think we should take credit for the ML unification... i think that was more of a concerted all-community (so TC+UC, or meta SIG) effort | 16:06 |
| fungi | yes, not a tc-only thing | 16:06 |
| dhellmann | ttx: yeah, placing that in a separate paragraph was meant to make it separate from TC stuff. I need an intro sentence there to make that more clear, I guess. | 16:06 |
| ttx | FWIW I plan to mention it in the Meta SIG report, so it will appear somewhere | 16:07 |
| fungi | i was wearing my opendev/infra hat when driving the mechanics of the merger | 16:07 |
| dhellmann | maybe the rephrasing I just did addresses it? | 16:07 |
| ttx | (I'll mention it in the meta SIG report as something that helps further breaking the barriers) | 16:07 |
| dhellmann | ok, I could leave it out entirely if you think it fits better elsewhere | 16:07 |
| fungi | to clarify, the bits above the "draft text" line are brainstorming/background not destined for the report in that form? and the report consists of the bits below "draft text"? | 16:08 |
| dhellmann | fungi : yes | 16:09 |
| fungi | thanks | 16:09 |
| *** morgan is now known as kmalloc | 16:09 | |
| *** e0ne has quit IRC | 16:30 | |
| *** e0ne has joined #openstack-tc | 16:30 | |
| *** tosky has quit IRC | 16:43 | |
| *** tosky has joined #openstack-tc | 16:44 | |
| *** jpich has quit IRC | 16:54 | |
| *** jamesmcarthur has quit IRC | 16:59 | |
| *** dtantsur is now known as dtantsur|afk | 17:27 | |
| mnaser | fwiw: i have spoken with a lot of users of openstack here at kubecon | 17:28 |
| mnaser | and there's a large perception of problems across ways folks ran into issues when they used openstack in some weird combination | 17:28 |
| mnaser | so by adding more ways and combinations, we actually risk of adding more wasys of shooting yourself in the foot | 17:29 |
| mnaser | having said that, we have processes in place that you have to go through to land code in order to make sure our deliverables are stable | 17:32 |
| mnaser | if we let people work at their own pace, they might make it quicker, but we lose control, and someone uses openstack with $vendor_driver and the experience is poor and we get more "openstack sux" comments | 17:32 |
| mnaser | in some sense, the added control we have slows the project a bit but keeps it reliable and maintains its reputation, which is important | 17:33 |
| mnaser | (sorry, done with my wall of text) | 17:33 |
| *** ianychoi has quit IRC | 17:42 | |
| TheJulia | mnaser: was there any commonality in the weird combonations? | 17:58 |
| *** ifat_afek has quit IRC | 18:01 | |
| lbragstad | yeah - that was my next question | 18:01 |
| lbragstad | curious if the combinations are combinations within OpenStack services, if they were combinations involving external services, or both? | 18:02 |
| clarkb | ime everyone tries to get fancy with networking | 18:04 |
| TheJulia | or, thoughts of using or sticking openstack into a problem a particular way | 18:04 |
| cdent | It is perhaps not all that surprising, but I think that having an open and accepting ecosystem is exactly the way to get our code robust, flexible and healthy. Combinations are _good_. That they expose bugs is _good_. The problem is that we don't fix them clearly enough | 18:04 |
| cdent | Trying to control things is anathema to the entire idea of what we're trying to do (I think) | 18:04 |
| clarkb | but it goes back to randy bias making statements that there is no such thing as a production vanilla cloud because its impossible to do. So there is a mindset you have to go out and buy random vendor stuff to run openstack, rather than use the stuff we do test (and actually test quite a bit) | 18:05 |
| *** e0ne has quit IRC | 18:11 | |
| *** e0ne has joined #openstack-tc | 18:15 | |
| *** e0ne has quit IRC | 18:16 | |
| mugsie | networking and storage seem to be our snowflake items | 18:46 |
| mugsie | and storage is a kind of out of tree driver - the Dell team didn't want to keep upstreaming fixes to openstack/cinder and forked cinder to keep a public up to date driver | 18:48 |
| smcginnis | mugsie: You mean for the drivers in use at OAuth? | 18:58 |
| smcginnis | If so, which of the Dell drivers? | 18:59 |
| mugsie | smcginnis: no, in Verizon - the VNX drivers | 18:59 |
| mugsie | see https://github.com/emc-openstack/vnx-direct-driver | 19:00 |
| mugsie | namely "Copy the cinder/volume/drivers/emc/vnx folder to where Cinder codes are deployed." | 19:00 |
| smcginnis | Thanks- interesting. | 19:01 |
| cdent | mugsie: fatigue, impatience, something else? | 19:06 |
| mugsie | I honestly don't know | 19:06 |
| mugsie | it does make getting driver updates from our OpenStack vendor more interesting | 19:07 |
| smcginnis | Looks like that is for Newton? | 19:07 |
| smcginnis | That was part of the reason for creating the driverfixes branches in Cinder. | 19:07 |
| mugsie | it does seem to co-incide with a lot of Dell storage staff moving to other oportunities, so it might have been a culture change | 19:14 |
| dhellmann | yeah, I wonder how the EM branch status will impact these sorts of decisions as folks start moving up to EM versions | 19:15 |
| dhellmann | that's interesting. I just joined a k8s sig group on groups.google.com and the sig chair sent me a meeting invitation for their meetings. I don't know if I'll join, but it felt like a nice sort of "hey there new person, here's something you might like to know about" outreach step | 19:17 |
| *** diablo_rojo has joined #openstack-tc | 19:42 | |
| mugsie | that does seem like a good welcoming step | 19:43 |
| *** e0ne has joined #openstack-tc | 19:53 | |
| *** tosky has quit IRC | 19:56 | |
| *** tosky has joined #openstack-tc | 19:57 | |
| *** e0ne has quit IRC | 19:58 | |
| *** diablo_rojo has quit IRC | 20:34 | |
| *** diablo_rojo has joined #openstack-tc | 20:36 | |
| *** diablo_rojo has quit IRC | 20:41 | |
| *** bauzas has quit IRC | 20:42 | |
| *** bauzas has joined #openstack-tc | 20:46 | |
| *** jamesmcarthur has joined #openstack-tc | 20:52 | |
| fungi | clarkb: yes, i agree a big part of it is people want to try to get fancy with networking and assume openstack is going to somehow magically make networking concepts simple enough they can wrap their heads around them | 20:57 |
| fungi | doomed | 20:57 |
| *** ianychoi has joined #openstack-tc | 20:59 | |
| openstackgerrit | Jimmy McArthur proposed openstack/governance master: Adding - in OpenStack-Ansible https://review.openstack.org/625032 | 21:00 |
| *** mriedem has quit IRC | 21:02 | |
| jamesmcarthur | dhellmann: re https://review.openstack.org/#/c/625032/ should I abandon this patch and submit a new one with a "Display name"? | 21:14 |
| jamesmcarthur | It's a little odd b/c OpenStack-Ansible seems to be the only one with this problem | 21:15 |
| jamesmcarthur | And correcting their name would seem to me to be the correct path. But I understand if it ends up breaking things in other areas. | 21:15 |
| *** mriedem has joined #openstack-tc | 21:26 | |
| dhellmann | jamesmcarthur : I'm not sure, tbh. | 21:30 |
| dhellmann | evrardjp, mnaser : do you have any thoughts on ^^ ? | 21:31 |
| dhellmann | jamesmcarthur : Openstackclient and OpenStackSDK are similarly "mushed together" | 21:32 |
| mnaser | jamesmcarthur: dhellmann having looked at it, i have noticed openstack ansible has always been labeled as OpenStack-Ansible, even in our projects.yaml in governance, etc | 21:32 |
| mnaser | oh wait | 21:32 |
| mnaser | whah. i'm pretty sure we had a dash ~somewhere~ | 21:32 |
| dhellmann | openstack-helm has a dash in their name | 21:33 |
| dhellmann | openstack charms has a space it seems | 21:33 |
| dhellmann | jamesmcarthur : can you give more details about the effect that making no change will have on whatever you're doing? | 21:34 |
| mnaser | i'm indifferent but if it helps make someone's downstream life easier in consuming projects.yaml | 21:36 |
| mnaser | then im for it | 21:36 |
| dhellmann | it looks like the command line tool is "openstack-ansible", as are many of the git repos | 21:36 |
| dhellmann | it's hard to search for these names | 21:37 |
| dhellmann | http://codesearch.openstack.org/?q=openstack-ansible&i=nope&files=&repos= | 21:37 |
| dhellmann | vs. | 21:38 |
| dhellmann | http://codesearch.openstack.org/?q=OpenStackAnsible&i=nope&files=&repos= | 21:38 |
| mnaser | i know over time i've seen a lot of the OSA team type it out as "OpenStack-Ansible" | 21:45 |
| mnaser | and this is like folks who are allll the way from the start of the project | 21:45 |
| jamesmcarthur | Right - we had several people from the project come to us and ask to make sure that it always had the dash. | 21:47 |
| jamesmcarthur | This was at the first Denver PTG. | 21:47 |
| jamesmcarthur | The problem it's causing from our side is on the Project Map | 21:48 |
| jamesmcarthur | dhellmann: ^ | 21:48 |
| jamesmcarthur | We have everything set to display as openstack-ansible and that's what we use to match the project up on the projectmap.yaml and other pieces | 21:48 |
| dhellmann | ok, well, looking at that second search output a change of name is going to break some relationships in the releases and election repos in addition to the map | 21:49 |
| jamesmcarthur | But the governance has it displayed as OpenStackAnsible, so we keep ingesting it as a separate project | 21:49 |
| dhellmann | so I think before we approve it we would at least want depends-on patches for all of those places filed so those things don't stay broken for very long | 21:49 |
| jamesmcarthur | Yeah - I'm happy to just make an adjustment on our side and a "DisplayName" would help. However, that would mean every single project would have to have one. | 21:50 |
| jamesmcarthur | Let's pursue whatever causes the least things to break, I'd say :) | 21:50 |
| dhellmann | I don't object to having the name changed, and that may ultimately be less confusing | 21:51 |
| dhellmann | mnaser : if the osa team wants the rename, maybe you can get someone from the team to work with jamesmcarthur on those other patches? | 21:52 |
| mnaser | we're a bit short on people unfortunately, with a ton of folks on vacation. how can we identify all those other places that depend on it? | 21:53 |
| dhellmann | that search above is one place to start | 21:54 |
| dhellmann | announcing the name change on the ML would be a good idea, too | 21:54 |
| clarkb | we won't need to rename git repos will we? | 21:55 |
| dhellmann | no, they already have the "-" in the name | 21:56 |
| dhellmann | and really, I'm only worried about the places that do validation based on looking up team names | 21:59 |
| dhellmann | we should look at openstack-manuals, too, although I think that's all repo-based so it should be ok | 21:59 |
| jamesmcarthur | I really didn't mean to cause a big kerfluffle, but this is what Gerrit is for :) | 22:00 |
| jamesmcarthur | @mnasar this is not a big hurry from my side. Just trying to cross things off my list. | 22:00 |
| jamesmcarthur | sorry mnasar: ^ | 22:01 |
| dhellmann | jamesmcarthur : oh, it's not a kerfuffle, it's just going to be a little more work than adding a byte to a file :-) | 22:01 |
| jamesmcarthur | I thought it would all be so simple. | 22:02 |
| dhellmann | this is openstack, nothing is ever simple | 22:02 |
| dhellmann | it's unintended consequences all the way down | 22:03 |
| *** dklyle has joined #openstack-tc | 22:05 | |
| *** david-lyle has joined #openstack-tc | 22:09 | |
| jamesmcarthur | ha! | 22:10 |
| *** dklyle has quit IRC | 22:12 | |
| *** david-lyle has quit IRC | 22:23 | |
| *** lbragstad has quit IRC | 22:37 | |
| *** jamesmcarthur has quit IRC | 22:47 | |
| *** jamesmcarthur has joined #openstack-tc | 23:04 | |
| *** jamesmcarthur has joined #openstack-tc | 23:05 | |
| scas | the not-dead chef openstack also has a variable name, but codesearch.o.o only keys off of openstack-chef that i've found | 23:07 |
| *** tosky has quit IRC | 23:27 | |
| *** jamesmcarthur has joined #openstack-tc | 23:39 | |
| *** mriedem has quit IRC | 23:41 | |
| *** jamesmcarthur has quit IRC | 23:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!