| *** jamesmcarthur has joined #openstack-tc | 00:00 | |
| *** Jeffrey4l has joined #openstack-tc | 00:08 | |
| *** jamesmcarthur has quit IRC | 00:09 | |
| *** tosky has quit IRC | 01:06 | |
| *** mriedem has quit IRC | 01:25 | |
| *** diablo_rojo has quit IRC | 01:56 | |
| *** jamesmcarthur has joined #openstack-tc | 02:05 | |
| *** jamesmcarthur has quit IRC | 02:09 | |
| *** jamesmcarthur has joined #openstack-tc | 02:23 | |
| *** jamesmcarthur has quit IRC | 03:20 | |
| *** jamesmcarthur has joined #openstack-tc | 04:35 | |
| *** ricolin has joined #openstack-tc | 04:59 | |
| *** whoami-rajat has joined #openstack-tc | 05:05 | |
| *** jamesmcarthur has quit IRC | 05:54 | |
| *** jamesmcarthur has joined #openstack-tc | 07:55 | |
| *** jamesmcarthur has quit IRC | 07:59 | |
| *** tosky has joined #openstack-tc | 08:27 | |
| *** dtantsur|afk is now known as dtantsur | 08:59 | |
| *** jpich has joined #openstack-tc | 09:00 | |
| *** whoami-rajat has quit IRC | 09:13 | |
| *** whoami-rajat has joined #openstack-tc | 09:25 | |
| *** jpich has quit IRC | 09:37 | |
| *** e0ne has joined #openstack-tc | 09:42 | |
| *** jpich has joined #openstack-tc | 09:51 | |
| *** jamesmcarthur has joined #openstack-tc | 09:56 | |
| *** jamesmcarthur has quit IRC | 10:00 | |
| *** smcginnis_away is now known as smcginnis | 10:34 | |
| * smcginnis dusts off his chair | 10:36 | |
| ttx | [ttx back: gone 305:05:59] | 11:15 |
|---|---|---|
| *** cdent has joined #openstack-tc | 11:41 | |
| *** whoami-rajat has quit IRC | 11:43 | |
| fungi | ouch | 13:09 |
| smcginnis | That's a good amount of time to be gone. | 13:10 |
| *** ianychoi has joined #openstack-tc | 13:17 | |
| cdent | welcome back | 13:25 |
| *** whoami-rajat has joined #openstack-tc | 13:30 | |
| dhellmann | tc-members: meeting reminder for ~90 minutes from now | 13:30 |
| dhellmann | er, 30 minutes | 13:30 |
| * cdent recovers from moment of out-of-sync panic | 13:30 | |
| dhellmann | I've been gone a week and can't remember how to read a calendar | 13:30 |
| dhellmann | computering is hard | 13:31 |
| fungi | i'm bad at computering too | 13:31 |
| fungi | but at least i should be thoroughly caffeinated | 13:31 |
| smcginnis | The caffeine is very good today. | 13:37 |
| * TheJulia uncloaks with a fresh coffee.... now to drink it | 13:42 | |
| openstackgerrit | Jeremy Stanley proposed openstack/governance master: Technical vision: hide implementation details https://review.openstack.org/628181 | 13:45 |
| fungi | that ^ was a lingering to-do item of mine from the forum | 13:45 |
| TheJulia | That looks awesome | 13:48 |
| fungi | awesomely delayed | 13:49 |
| cdent | fungi: I think you may have forgotten a referent for partitioning ref? | 13:51 |
| TheJulia | fungi: sometimes things can't but help be delayed. Life is often out of our control | 13:52 |
| fungi | cdent: possible. i didn't try to build locally to find out whether the implicit title references work like i remembered | 13:53 |
| cdent | fungi oh, sorry, I'm blind. I looked for the header and then couldn't find it, even though it is _right there_ | 13:54 |
| cdent | my caffeine is not good today | 13:54 |
| * smcginnis passes cdent an espresso shot | 13:55 | |
| cdent | mmm, yes please | 13:55 |
| * TheJulia continues to try and remove sleep from eyes | 13:55 | |
| * TheJulia expects laptop might move to espresso machine mid-meeting | 13:55 | |
| *** lbragstad has joined #openstack-tc | 13:57 | |
| fungi | you totally need an espresso dispenser built into your laptop | 14:00 |
| * fungi smells a new startup opportunity | 14:01 | |
| TheJulia | heh | 14:01 |
| smcginnis | USB espresso maker. That might be pushing the USB power specs. | 14:01 |
| lbragstad | i'd settle for a beer hat retrofitted for coffee mugs | 14:01 |
| dhellmann | #startmeeting tc | 14:01 |
| openstack | Meeting started Thu Jan 3 14:01:45 2019 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| *** openstack changes topic to " (Meeting topic: tc)" | 14:01 | |
| openstack | The meeting name has been set to 'tc' | 14:01 |
| dhellmann | happy new year, tc-members! | 14:01 |
| TheJulia | o/ | 14:01 |
| dhellmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001354.html agenda for this meeting | 14:01 |
| smcginnis | o/ | 14:01 |
| fungi | thanks dhellmann! | 14:01 |
| lbragstad | o/ | 14:01 |
| dhellmann | #topic roll call | 14:02 |
| dhellmann | tc-members, please indicate if you are present for the logs | 14:02 |
| *** openstack changes topic to "roll call (Meeting topic: tc)" | 14:02 | |
| cdent | ahoy | 14:02 |
| * fungi is present and accounted for | 14:02 | |
| mnaser | o/ | 14:02 |
| lbragstad | present | 14:02 |
| ttx | o/ | 14:02 |
| TheJulia | present | 14:03 |
| dhellmann | evrardjp, zaneb, and gmann all signed up on the wiki as not being able to be present today | 14:03 |
| dhellmann | let's start with old business | 14:04 |
| dhellmann | #topic technical vision for openstack | 14:04 |
| dhellmann | we have approved the first draft of the vision | 14:04 |
| dhellmann | #link https://governance.openstack.org/tc/reference/technical-vision.html | 14:04 |
| *** openstack changes topic to "technical vision for openstack (Meeting topic: tc)" | 14:04 | |
| dhellmann | we have an update proposed by gmann | 14:04 |
| dhellmann | #link https://review.openstack.org/#/c/621516/ | 14:04 |
| dhellmann | and another from fungi | 14:04 |
| dhellmann | #link https://review.openstack.org/628181 | 14:04 |
| dhellmann | should we consider to track this at a high-level or are we ready to remove this topic from the tracker now, and treat further updates as individual work items? | 14:04 |
| dhellmann | #link https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Technical_Vision_for_OpenStack | 14:04 |
| dhellmann | thoughts? | 14:04 |
| fungi | i think we can take the umbrella task off the tracker | 14:04 |
| cdent | I think we should keep it on until we use it to cause some kind of change | 14:05 |
| ttx | +1 | 14:05 |
| ttx | that was a +1 for fungi | 14:05 |
| cdent | The point of the creation of the vision was to have it leverage _something_ but it's not clear what the something is | 14:05 |
| fungi | so what is the task we're tracking at that point? | 14:05 |
| cdent | if it's just going to fade back into the reference background, then it was for naught | 14:06 |
| smcginnis | Future decisions? | 14:06 |
| cdent | "change stuff" :) | 14:06 |
| fungi | how do we know when that's accomplished? | 14:06 |
| cdent | I'm not certain, but since we don't know, it feels unfinishd | 14:06 |
| dhellmann | I thought the purpose of this document was to influence future decisions about new projects? | 14:06 |
| smcginnis | dhellmann: ++ | 14:06 |
| dhellmann | "to help clarify the boundary for where projects fit into OpenStack and where they may not" | 14:06 |
| TheJulia | My interpretation was it was to serve as an overall guiding light, new and old projects moving forward | 14:06 |
| mnaser | It seems like we’re not getting much new project additions (or rather sorry, new teams) | 14:07 |
| cdent | One of the major driving forces behind its creation was to change existing projects, by making the religion more clear | 14:07 |
| persia | I thought the purpose of the docunent was to help everyone (not just TC) understand shared common goals. | 14:07 |
| dhellmann | I do like the idea of using it to drive other changes, but that feels like a second thing | 14:07 |
| TheJulia | So I think it makes sense to keep it on the tracker. I feel that the discussion on gmann's edit just needs more time | 14:07 |
| TheJulia | mnaser: +1 | 14:07 |
| dhellmann | cdent : perhaps, although I thought we went to great lengths to start by documenting the current state of things | 14:07 |
| cdent | "start" | 14:08 |
| cdent | thus it's not ready to be done | 14:08 |
| mnaser | It seems like we’re maybe needing some work to be a more attractive home for projects. | 14:08 |
| fungi | we're bound to have future edits too though. i suppose getting through the ones brought up as needed during the forum session could be seen as completing the initial version | 14:08 |
| smcginnis | cdent: Are you thinking we now need to take this vision and review what we currently have to see how well they match up? | 14:08 |
| cdent | smcginnis: yes, that would be a good next step | 14:08 |
| TheJulia | I feel like we're at the next step point, so beyond edits, what is the next step for us? | 14:09 |
| TheJulia | popularize it? | 14:09 |
| TheJulia | further I guess | 14:09 |
| smcginnis | That makes senese to me. I was primarily thinking of the vision doc as a point to apply for future decisions, but using it as a way to judge our current state also has value. | 14:09 |
| cdent | I think we could invite people to express whether we're aligned with it, and what needs to change to make it more aspirational | 14:09 |
| cdent | because unless it has aspirations, it's not a vision | 14:10 |
| fungi | mnaser: attractive in what ways? (and how do you make sure what you change to make it more attractive to new projects doesn't make it less attractive to the ones which are already invested in driving the community we have?)... but also i'm not sure how that's relevant to the technical vision for cloud design | 14:10 |
| TheJulia | cdent: I completely agree, and I think that might be good feedback for projects to explicitly attempt to collect as part of planning for Train | 14:10 |
| cdent | TheJulia++ | 14:10 |
| dhellmann | hold that thought for later in the agenda :-) | 14:10 |
| cdent | yeah, making that an explicit todo would be a good concrete step | 14:10 |
| smcginnis | Train goal for each team to submit a | 14:11 |
| fungi | i like that idea | 14:11 |
| smcginnis | "vision review" self evaluation? | 14:11 |
| TheJulia | I like it | 14:11 |
| mnaser | fungi: afaik, the technical vision was created so we don’t have arbitrary discussions about if we can accept a project to be under OpenStack, that was my understanding | 14:11 |
| ttx | I think it's good to drive change using it, but not sure an umbrella task is helping -- I'd rather track individual change when we come up with it | 14:11 |
| mnaser | But it seems that no one is really applying to be new OpenStack projects, so it’s hard to see value in using it right now | 14:11 |
| dhellmann | which of you is going to lead the effort to ask teams to do the self-evaluation? | 14:12 |
| TheJulia | so, we should hold this discussion and proceed with the agenda for now | 14:12 |
| TheJulia | I think were on a good track tbh | 14:12 |
| fungi | mnaser: created to help guide those decisions, but there will still always be factors which come up that aren't clearly laid out in the vision and require further debate. i see it as a means of helping shape the debates we have | 14:12 |
| smcginnis | TheJulia: ++ | 14:12 |
| smcginnis | and... fungi: ++ | 14:12 |
| TheJulia | fungi: ++ as well | 14:13 |
| dhellmann | cdent : perhaps you want to sign up to lead that? | 14:13 |
| TheJulia | dhellmann: if it comes down to it, I can lead the effort to try and drive teams to self evaluate | 14:13 |
| cdent | dhellmann: yes, I'll take that | 14:13 |
| cdent | and am happy to work with TheJulia on it | 14:14 |
| dhellmann | #info cdent and TheJulia to work on initiative to have teams self-evaluate against the technical vision document | 14:14 |
| smcginnis | Thanks cdent and TheJulia | 14:14 |
| dhellmann | and it seems we agreed to leave the item on the tracker as-is for now | 14:14 |
| *** mriedem has joined #openstack-tc | 14:14 | |
| smcginnis | dhellmann: Yes, I believe so. At least for now. | 14:14 |
| dhellmann | cdent: would you please update that section of the wiki with the next step info | 14:15 |
| cdent | ✔ | 14:15 |
| dhellmann | thanks | 14:15 |
| dhellmann | next up: | 14:15 |
| dhellmann | #topic next step in TC vision/defining the role of the TC | 14:15 |
| dhellmann | we also approved a document explaining the role of the TC | 14:15 |
| dhellmann | #link https://governance.openstack.org/tc/reference/role-of-the-tc.html | 14:15 |
| *** openstack changes topic to "next step in TC vision/defining the role of the TC (Meeting topic: tc)" | 14:15 | |
| dhellmann | is there more work to do here, or are we ready to remove this from the tracker now? | 14:15 |
| dhellmann | #link https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Next_steps_in_TC_Vision_.2F_defining_role_of_the_TC | 14:15 |
| dhellmann | ttx, TheJulia, & cdent are listed as the drivers for this one | 14:16 |
| cdent | A bit before christmas I agreed to publicise and verify it with a wider audience | 14:16 |
| cdent | but I felt best to wait until later (i.e. now) to do that | 14:16 |
| ttx | yes that is the next step | 14:16 |
| cdent | the idea was "here's what we think we do, do you think that's true and right?" | 14:16 |
| ttx | (is there anything missing? etc) | 14:17 |
| cdent | (i'll update that on the wiki too, since I'm in there now) | 14:17 |
| TheJulia | I don't think so, I think we need to kind of keep it simple and fact based, and just see what we get | 14:17 |
| dhellmann | #info cdent to start discussion on the mailing list | 14:17 |
| dhellmann | cdent : thanks | 14:17 |
| dhellmann | I think that's covered then, unless anyone else has anything to add? | 14:18 |
| dhellmann | moving on then | 14:18 |
| dhellmann | #topic keeping up with python 3 releases | 14:18 |
| dhellmann | We have approved all of the patches for documenting the policy and for selecting the versions to be covered in Stein. | 14:18 |
| dhellmann | What are the next steps for ensuring that any implementation work is handled? | 14:18 |
| *** openstack changes topic to "keeping up with python 3 releases (Meeting topic: tc)" | 14:18 | |
| dhellmann | I feel like gmann signed the QA team up to work on some of this, and since he's out today maybe we should hold the discussion | 14:19 |
| *** mriedem has quit IRC | 14:19 | |
| smcginnis | Probably need to publicize better to the teams that they should be working towards 3.6 with 3.7 around the corner. | 14:20 |
| TheJulia | It would be good for there to be a second pass review by a team such as QA, but yeah, we should wait on that | 14:20 |
| dhellmann | maybe we can discuss this in an office hour when gmann is back from pto | 14:20 |
| smcginnis | That sounds good to me. | 14:20 |
| dhellmann | let's move on to the next topic | 14:20 |
| TheJulia | New mailing list, so re-publicizing sounds like a good idea | 14:20 |
| dhellmann | #topic Reviewing TC Office Hour Times and Locations | 14:21 |
| *** openstack changes topic to "Reviewing TC Office Hour Times and Locations (Meeting topic: tc)" | 14:21 | |
| dhellmann | #link https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Reviewing_TC_Office_Hour_Times_and_Locations | 14:21 |
| dhellmann | the most recent mailing list thread was resolved with no changes to the number of office hours | 14:21 |
| dhellmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000542.html | 14:21 |
| dhellmann | does anyone want to propose different times, or are we happy with the current schedule? | 14:21 |
| *** mriedem has joined #openstack-tc | 14:21 | |
| smcginnis | Should we do a meeting #vote? | 14:21 |
| smcginnis | I am for the status quo with this one. | 14:21 |
| ttx | status quo | 14:21 |
| dhellmann | if someone says they want to propose new times, I'll let them do that on the mailing list. otherwise, I consider this done. | 14:22 |
| smcginnis | I think the thread kind of leaned that way towards the later posts. | 14:22 |
| ttx | ++ | 14:22 |
| cdent | I think the thread resolve as "status quo" | 14:22 |
| TheJulia | I kind of am too | 14:22 |
| dhellmann | of course if the folks who aren't here want to do that later, that's fine, too | 14:22 |
| lbragstad | ++ | 14:22 |
| fungi | yeah, status quo for me too | 14:23 |
| dhellmann | #info we will keep the current meeting and office hour schedule | 14:23 |
| dhellmann | k | 14:23 |
| fungi | i concur that was the gist of the discussion on the ml | 14:23 |
| dhellmann | right, now for some new business items | 14:23 |
| dhellmann | #topic Train cycle goals selection update | 14:24 |
| dhellmann | Thank you, to lbragstad and evrardjp for agreeing to lead the selection process for the Train goals. | 14:24 |
| dhellmann | Do you have any updates to share with us this month? | 14:24 |
| *** openstack changes topic to "Train cycle goals selection update (Meeting topic: tc)" | 14:24 | |
| lbragstad | a couple of minor things | 14:24 |
| dhellmann | lbragstad started a thread to discuss the goals and seek champions | 14:24 |
| dhellmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000558.html | 14:24 |
| dhellmann | sorry, go ahead lbragstad | 14:24 |
| lbragstad | we're still pushing the discussion on the mailing list | 14:24 |
| lbragstad | there have been just a couple people to step up for the pre-work, so we're in discussions with those folks, too | 14:25 |
| dhellmann | great! | 14:25 |
| lbragstad | but other than that... evrardjp and i will be touching base next week | 14:26 |
| lbragstad | which will probably result in another nudge on the mailing list, or at least summarizing where the different goals stand | 14:26 |
| lbragstad | that's about all from our end | 14:26 |
| * dhellmann nods | 14:26 | |
| dhellmann | it would be good to have regular updates about those discussions and any pre-work on the mailing list to keep the goals in everyone's minds | 14:26 |
| lbragstad | i think so, too | 14:27 |
| lbragstad | i'll make sure to send one out after i meet with jp | 14:27 |
| dhellmann | which goals were the volunteers interested in helping with? | 14:27 |
| lbragstad | moving legacy clients to osc | 14:27 |
| lbragstad | there was some pre-work there that folks mentioned in the mailing list | 14:28 |
| dhellmann | some analysis, irrc | 14:28 |
| dhellmann | iirc | 14:28 |
| dhellmann | are there any other questions? | 14:28 |
| dhellmann | ok, next up then | 14:29 |
| dhellmann | #topic health check status for stein | 14:29 |
| dhellmann | #link https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams | 14:29 |
| *** openstack changes topic to "health check status for stein (Meeting topic: tc)" | 14:29 | |
| dhellmann | how is it going contacting the PTLs for the health check for stein? | 14:29 |
| dhellmann | does anyone have anything to raise based on what they have learned in their conversations? | 14:29 |
| TheJulia | I simply have not had time to get started since the last meeting. I'll hopefully be able to get that started in the next couple of days. | 14:30 |
| mnaser | I’ll personally admit I have not had the time to do mine. I plan to do them soon. It is a slow time in general right now anyhow | 14:30 |
| cdent | I've got nothing from my formal trackees, but I can say that in general I've heard a lot of people saying (not just because of the holidays): Not much reviewing happening. | 14:30 |
| ttx | Been putting that on pause over past month, will pick up again in January | 14:30 |
| ttx | Difficult to do over the holidays :) | 14:30 |
| cdent | That is: there is a dearth of regular reviewers and has been for a few months. | 14:30 |
| smcginnis | I have heard the same about lack of reviewing happening. | 14:31 |
| lbragstad | i've noticed a similar thread with my updates | 14:31 |
| fungi | my hope was that 1. entrenchment into the new ml along with 2. a return from the holiday black hole would make for a prime opportunity to start reaching out at a time and place where ptls and others on those teams are likely to follow up with answers and concerns | 14:31 |
| cdent | I reckon the concept of coherent teams is starting to fade. | 14:32 |
| cdent | which is a natural evoluation, but something our process and approach needs to catch up to | 14:32 |
| dhellmann | I wonder if that's an opportunity to fight back against the effect of Conway's Law | 14:32 |
| cdent | possibly | 14:33 |
| fungi | it does seem to me like we're getting more and more cross-project/casual involvement (though perhaps not as much as the reduction in project-centric involvement) | 14:33 |
| dhellmann | it's definitely something to keep an eye on | 14:34 |
| TheJulia | I've been thinking along fungi's line of thought, although it is going to vary for project to project | 14:34 |
| mnaser | I think we should try to come up with something to make OpenStack exciting. People still need it, they just don’t know they do | 14:34 |
| mnaser | We’re dealing with humans and emotions. If everyone else is working on that “other cool thing”, everyone will want to move towards working on it too | 14:35 |
| TheJulia | I think the only way to really make it exciting again is enable faster velocity. Our structures have kind of made it more and more difficult to maintain or increase velocity as time goes on | 14:35 |
| zhipeng | Big +1 mnaser | 14:35 |
| cdent | TheJulia++ | 14:35 |
| mnaser | As employers also get excited over that new other cool technology they move employees to other projects | 14:35 |
| mnaser | I agree with TheJulia as well on that | 14:36 |
| dhellmann | I wonder if a slower velocity focused on more interesting things wouldn't have the same effect as a faster overall velocity | 14:36 |
| mnaser | This initiative has to come from *somewhere*. I don’t know where. | 14:36 |
| fungi | i thought faster velocity was what contributors complained caused them to be unable to keep up? | 14:36 |
| dhellmann | mnaser: one of the bits of feedback we got from Alan back in Denver was that the TC needed to take on more of a "strategic leadership" role | 14:36 |
| fungi | "openstack: moves too fast to allow for casual contribution" | 14:36 |
| ttx | velocity and flow volume are related, but different | 14:36 |
| cdent | I think we need to be careful to not overestimate the potential here. OpenStack is mature. It will never be exciting again in the way it once was. We need to adapt to that, not try to force a carnival. | 14:37 |
| TheJulia | I think two pronged is going to be the only way. Begin to tear-down some of the limiting structure (like 2 +2s as a standard), and also try and have a few shiny things with lots of touch points | 14:37 |
| ttx | They are basically complaining about how large the river is, not how fast it goes | 14:37 |
| smcginnis | Big +1 cdent | 14:37 |
| mnaser | I agree cdent I think it’s a matter of putting things in a different context maybe | 14:37 |
| TheJulia | cdent: ++ | 14:37 |
| TheJulia | ttx: ++ | 14:37 |
| dhellmann | ttx: good metaphor | 14:37 |
| smcginnis | Very good. | 14:38 |
| cdent | mnaser: yes. rather than "lookie, shiny" it's 'look how much stuff is based on top of nice stron openstack' | 14:38 |
| cdent | s/stron/strong/ | 14:38 |
| mnaser | cdent: exactly. In my experience at kubecon, many people didn’t see that value | 14:38 |
| TheJulia | cdent: but that in its self could be shiny | 14:38 |
| ttx | I think we can still encourage more... visible endeavors. I like the work on the K8s "cloud provider" because it has practical result | 14:38 |
| smcginnis | I think the k8s thing is still partly due to deployment complexity. | 14:39 |
| smcginnis | It's great having multiple cloud provider options. | 14:39 |
| fungi | the linux kernel is far from being an exciting project (personal drama roller coaster aside), but still seems to manage a good amount of contribution and throughput | 14:39 |
| cdent | that's a two way street too. From deep within the bowels of (e.g.) nova it's hard to be aware of things like the cloud provider and feel a bit meh | 14:39 |
| smcginnis | But it's so, so easy for someone to just throw their cluster on AWS or others. | 14:39 |
| mnaser | I agree ttx. Explaining the cloud provider benefits to folks at kubecon was super exciting for them (oh I can do this stuff on the big 3 but on my own cloud?) | 14:39 |
| smcginnis | I'm sure they would be happy to have some control over their infra, but for many it's not possible due to how difficult it is for them to maintain their own cloud. | 14:39 |
| cdent | fungi: yes, but they've got a very mature process that's adapted to that. we don't, yet. | 14:40 |
| dhellmann | smcginnis : I've been hearing similar feedback about deployment complexity lately | 14:40 |
| mnaser | Yeah but magnum also solved that problem, and for deployment, I dunno, I feel like as a PTL of a deployment project, it’s really not that hard | 14:40 |
| ttx | We've been (rightly) focusing on the ops experience, but we should still do stuff that speaks to end users | 14:40 |
| mnaser | Write a YAML file and call a command | 14:40 |
| fungi | cdent: completely agree. that was more or less my point (in support of yours) | 14:40 |
| mnaser | Other tools even have UIs | 14:40 |
| mnaser | I think the deployment isn’t hard, i think historically it has been and people still think it’s that way. | 14:40 |
| cdent | yeah, historical baggage is a biggie | 14:41 |
| cdent | and upgrade baggage | 14:41 |
| smcginnis | Eh, I just recently rebuilt my basement cloud and was a little disheartened by how little that deployment ease has progressed. | 14:41 |
| mnaser | smcginnis: how did you deploy it? | 14:41 |
| dhellmann | mnaser : what we learned in Vancouver (?) was that operators were doing their own deployment for reasons like flexibility and moving *off* of their home-grown solutions was hard | 14:41 |
| smcginnis | mnaser: I started with ansible, then went back to following the install guides we publish on docs.o.o. | 14:42 |
| lbragstad | another thing i've heard from people is that even though they can write a yaml file and call a command, they usually want to understand all of what's happening when they do that | 14:42 |
| ttx | I place a lot of hope in the future "deployment toolkit features" classification taht will make it easier to pick your method | 14:42 |
| mnaser | dhellmann: I can name a few which then realIzed that was really hard and decided to switch back to an upstream thing | 14:42 |
| smcginnis | For two reasons: 1) Test the docs, 2) I needed a little more control without wanting to spend a week reading how to customize the ansible deployment. | 14:42 |
| dhellmann | mnaser : no doubt | 14:42 |
| mnaser | I think deployment tools maybe need a bit more work to make it easier. | 14:42 |
| dhellmann | yeah, #2 there is I think what leads people to roll their own | 14:42 |
| mnaser | (Except we don’t have much resources in OSA world unfortunately) | 14:43 |
| dhellmann | sometimes an all-in-one whizbang tool isn't as "easy" as a well-defined process | 14:43 |
| mnaser | so maybe tripleo has the bigger chance of success, theoretically. | 14:43 |
| dhellmann | but I think we're getting a bit in the weeds | 14:43 |
| mnaser | Yes | 14:43 |
| TheJulia | dhellmann: ++ | 14:43 |
| mnaser | I forgot what we were discussing initially :) | 14:43 |
| TheJulia | I was thinking that a minute or two ago while trying to come up with a cogent thought to express my perception | 14:44 |
| dhellmann | so let's move on | 14:44 |
| dhellmann | #topic next meeting | 14:44 |
| *** openstack changes topic to "next meeting (Meeting topic: tc)" | 14:44 | |
| dhellmann | #info the next TC meeting will be 7 February 2019 1400 UTC in #openstack-tc | 14:44 |
| dhellmann | If you have suggestions for topics for the next meeting, please add them to the wiki at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 14:44 |
| dhellmann | between now and then, I would like for all of you to spend time thinking about (and talking about) what the TC's goals should be for the rest of stein | 14:44 |
| ttx | ack | 14:45 |
| cdent | based on the conversation we just had, I think our goal should be that | 14:45 |
| fungi | sounds good. thanks dhellmann! | 14:45 |
| TheJulia | cdent: ++ | 14:45 |
| dhellmann | in denver we agreed to focus on a small number of items, and I would like us to pick 1-2 | 14:45 |
| cdent | we've got to adapt culture, soon | 14:45 |
| TheJulia | cdent: I guess the first step is a realistic self evaluation for projects | 14:45 |
| * cdent nods | 14:45 | |
| dhellmann | let's pick the *goal* and then discuss the implementation | 14:46 |
| fungi | also, let's be sure to have those discussions primarily on the ml and in gerrit | 14:46 |
| dhellmann | self-evaulation isn't an ends in itself; it's a means to gaining some insight, and *that* is the goal | 14:46 |
| TheJulia | yeah, first you have to know where you are to plot a course | 14:46 |
| cdent | fungi++ | 14:47 |
| dhellmann | #action tc-members consider goals for the TC for stein | 14:47 |
| smcginnis | train | 14:48 |
| dhellmann | we're still in stein | 14:48 |
| dhellmann | the train tc will be a different group, and should set their own goals | 14:48 |
| lbragstad | i think these are separate from community goals, right? | 14:48 |
| dhellmann | yes | 14:48 |
| smcginnis | Oh, things we still would like to accomplish. Gotcha. | 14:48 |
| dhellmann | what does this group of 13 people want top accomplish as a team | 14:48 |
| dhellmann | s/top/to/ | 14:48 |
| smcginnis | World peace. | 14:48 |
| dhellmann | think bigger, smcginnis | 14:48 |
| smcginnis | :) | 14:49 |
| dhellmann | that's all we had on the agenda for today, so I think we can close a bit early and have a short break before office hours | 14:49 |
| dhellmann | Thank you, everyone! | 14:49 |
| cdent | thanks dhellmann | 14:49 |
| TheJulia | Thanks! | 14:49 |
| lbragstad | thanks dhellmann | 14:49 |
| dhellmann | #endmeeting | 14:49 |
| *** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/" | 14:49 | |
| openstack | Meeting ended Thu Jan 3 14:49:50 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:49 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-01-03-14.01.html | 14:49 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-01-03-14.01.txt | 14:49 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-01-03-14.01.log.html | 14:49 |
| * lbragstad finds coffee quick | 14:50 | |
| *** lbragstad has quit IRC | 14:50 | |
| ttx | Thanks dhellmann ! | 14:50 |
| dhellmann | unfortunately I have an appointment in a little bit, so I'm not going to be around for a lot of the office hour, but I hope you continue some of the discussions we started in the meeting because I think those might lead to some good TC goals | 14:50 |
| TheJulia | So, if we were to encourage projects to perform a self evaluation, what sort of output would would we expect projects to generate. Keep in mind, not every aspect will apply, and maybe that is the key. Ask them, with-in their project team context, to draft a short document, bullet points perhaps, of items where they perceive them to greatly differ from the vision? | 14:52 |
| *** lbragstad has joined #openstack-tc | 14:53 | |
| smcginnis | I think we would need to provide some form or bullet points for them to use. | 14:53 |
| dhellmann | zaneb had several threads where he started similar discussions in the course of developing the vision. it would be useful to review those to see what the results were. | 14:53 |
| cdent | TheJulia: bullets per section sounds pretty good | 14:53 |
| cdent | the vision doc itself is very structured | 14:54 |
| TheJulia | smcginnis: maybe an example to reference? | 14:55 |
| dhellmann | why do we want teams to do the self-evaluation? | 14:56 |
| cdent | The outcome I'd like to see is something each project's tree which helps people know/experience/feel what the gap is so they can evaluate their own tasks for importance and relevance | 14:56 |
| cdent | too often work gets focused on details of feature requirements that are driven without regard to the big picture | 14:57 |
| TheJulia | ++ | 14:58 |
| TheJulia | and new comers might not have any good place to obtain a consumable picture of the things that could use improvement that are not necessarily direct features. | 14:59 |
| dhellmann | if the point is to eventually change projects so they more closely match the description in the vision, we need to make sure that's clear | 14:59 |
| TheJulia | a bug tracker 300-600 bugs wide... is just not consumable | 14:59 |
| TheJulia | That is a good point | 15:00 |
| cdent | yes. the point of the self-evaluation is to recognize where the gaps are and think about closing them | 15:00 |
| dhellmann | ok, well, there are 2 ways to close the gap, right? change the document to match reality and change reality to match the document. | 15:01 |
| TheJulia | well, first is to document reality | 15:01 |
| TheJulia | then from there the gap items can be enumerated and built into plans | 15:01 |
| cdent | dhellmann: I would think we want to encourage both | 15:01 |
| dhellmann | I think we need to be explicit about that, so there is no confusion | 15:02 |
| * TheJulia types that out now | 15:03 | |
| smcginnis | I think the other value of a self-evaluation is to provoke those teams to think about what any misalignments are that they have to see if that triggers any changes in their perspective. | 15:04 |
| dhellmann | that feels like the bigger long term gain | 15:05 |
| cdent | I'd like us to avoid being mealy-mouthed about change. We should be direct that the point is for services to discover and evolutionary path to being something that's described as correct | 15:05 |
| dhellmann | smcginnis : what's the story with the "review priority" thread? I must have missed the original discussion, and have no idea what that's about but it seems like something cinder is leading on? | 15:05 |
| cdent | I feel like one of the main reasons we've struggled over the years is that "correct" is too ambiguous and too de-centralized | 15:06 |
| dhellmann | I agree that being clear and direct with the intent is important | 15:06 |
| TheJulia | I concur | 15:06 |
| smcginnis | dhellmann: The review-priority was something I set up for Cinder after mugsie mentioned it to me in Berlin. | 15:07 |
| smcginnis | Not sure how long they have been using it. | 15:07 |
| dhellmann | and what does it do? | 15:07 |
| smcginnis | But it's a custom label in gerrit allowing teams to set prioritis on patches. | 15:07 |
| smcginnis | So my hope for Cinder was with reduced reviewers, if we can set a priority flag on some of the important work, we might be able to direct that limited attention to the things that really matter. | 15:08 |
| dhellmann | is it based on a cumulative vote? or is it just a flag? | 15:08 |
| smcginnis | He also said it was nice being able to set Review-Priority -1 to procedurally block things in a more explicit way than giving things a -2. | 15:08 |
| smcginnis | Just a flag. | 15:08 |
| dhellmann | got it | 15:09 |
| smcginnis | So really probably best only controlled by PTL, but Jay wanted all cores to be able to crowd source the work. | 15:09 |
| dhellmann | seems like an interesting idea; I look forward to hearing how it works out | 15:09 |
| smcginnis | dhellmann: It does allow creating nice dashboards like https://tiny.cc/CinderPriorities | 15:09 |
| scas | as someone who has had to work with reduced reviewer capacity for... three years now, having a way to prioritize what needs to be reviewed would be a nice to have | 15:10 |
| TheJulia | At least in ironic, we just keep a list in an etherpad and most people tend to honor those items and we consensus build on themes. We add to it as necessary during a given week.... but something in gerrit might work a lot better | 15:10 |
| smcginnis | TheJulia: Yeah, we've done the etherpad tracking for awhile too, to mixed results. | 15:11 |
| TheJulia | And I suspect settable by anyone is going to be a good feedback mechanism "no, your patch is not a project priority, changing priority" | 15:11 |
| smcginnis | My thought was a core with only 10 minutes to spare can just bookmark the dashboard and make a quick pass through the top ones. | 15:11 |
| scas | pre-hype, i had eight other cores i could potentially call upon. after the austin summit, that has settled around three to four reviewers including myself on a good day | 15:11 |
| scas | 'a good day' being when we all happen to be working on the same thing | 15:12 |
| smcginnis | scas: Could be interesting for you to implement, though with a smaller team I would wonder if the overhead of managing it would negate the value. | 15:12 |
| scas | smcginnis: i'll probably need to start hosting scheduled meetings again to get a bit more immediate feedback | 15:13 |
| scas | we are /very/ asynchronous | 15:13 |
| *** Bhujay has joined #openstack-tc | 15:15 | |
| *** Bhujay has quit IRC | 15:16 | |
| *** e0ne has quit IRC | 15:28 | |
| *** whoami-rajat has quit IRC | 15:39 | |
| openstackgerrit | Luigi Toscano proposed openstack/governance master: New Sahara repositories for split plugins https://review.openstack.org/628210 | 15:55 |
| openstackgerrit | Luigi Toscano proposed openstack/governance master: New Sahara repositories for split plugins https://review.openstack.org/628210 | 15:56 |
| openstackgerrit | Luigi Toscano proposed openstack/governance master: New Sahara repositories for split plugins https://review.openstack.org/628210 | 16:53 |
| *** ricolin has quit IRC | 17:35 | |
| *** jpich has quit IRC | 17:40 | |
| TheJulia | tc-members: Circling back to the discussion during the meeting of trying to engage projects to begin to identify their gaps to the vision, cdent and I have whipped up https://etherpad.openstack.org/p/project-vision-self-eval Please review and let us know if it covers concerns about explicitly and adequately paints the entire picture. | 17:51 |
| TheJulia | I like the s/corrected/closed/ a lot | 17:59 |
| dhellmann | TheJulia : I proposed a couple of edits, leaving the original text in place with strikethrough for comparison | 18:00 |
| cdent | dhellmann: what's the reasoning on the last change? "Our end goal..." | 18:01 |
| dhellmann | I moved that up to the previous sentence | 18:02 |
| dhellmann | don't bury the lede | 18:02 |
| cdent | hmmm, I think that's de-emphasised the lede | 18:02 |
| dhellmann | "improvement" is vague by itself | 18:02 |
| cdent | close with the hammer | 18:02 |
| dhellmann | it's your email, though | 18:02 |
| dhellmann | that's why I left them as proposed edits | 18:02 |
| cdent | your way is better, but means another hammer is needed | 18:03 |
| cdent | (I think) | 18:03 |
| TheJulia | I think I concur with cdent, but I'm going to go make a latte and let it roll around inside my brain for a few minutes | 18:03 |
| cdent | a summary along the lines of "c'mon everybuggy let's make all the things betters" | 18:03 |
| *** jamesmcarthur has joined #openstack-tc | 18:10 | |
| *** diablo_rojo has joined #openstack-tc | 18:11 | |
| clarkb | re deployment complexity, I think a lot of that complexity comes about as a direct result of making complicated decisions around networking. Infra ran infracloud and explicitly chose the simplest network setup and running openstack was much easier than many of the other systems we have to manage. Maybe we should get away from sdn by default if we need to further simplify things for users | 18:11 |
| TheJulia | I don't think a second hammer is needed upon re-reading. But I do like cdent's suggested summary from a few minutes ago | 18:12 |
| cdent | ✔ | 18:13 |
| TheJulia | But, I think adding it would be a little distracting | 18:13 |
| cdent | yes | 18:13 |
| cdent | clarkb: isn't sdn the market that's driving the bus right now? I agree it drives all the complexity. It would be nice is there was something like an "easy mode" for all the people who don't need that. | 18:14 |
| *** diablo_rojo has quit IRC | 18:15 | |
| clarkb | cdent: maybe? I think the k8s use case for example completely negates any need for openstack to sdn. And we do have easy modes. Its called provider networking (eg just use the networking in your datacenter) but we don't advertise/document it well | 18:15 |
| *** diablo_rojo has joined #openstack-tc | 18:15 | |
| TheJulia | I think part of the problem is people still want their enterprise style of networking available to them in their customized cloud deployment... OR need it to meet some opsec requirement | 18:16 |
| cdent | I'm probably biased/jaded by being within nova/placement for too long. Everything I've seen us do for the last two years is NFV-related. It's very annoying | 18:16 |
| TheJulia | cdent: Come work on ironic, I'll buy beer! ;) | 18:16 |
| * cdent has a bad case of finished what I started | 18:17 | |
| clarkb | TheJulia: ya and we should still offer that tooling. The problem is if you start with the install docs or $deployment tool you are thrown into that deep end of the pool from the start even if you don't need it | 18:17 |
| * TheJulia nods | 18:17 | |
| clarkb | TheJulia: the issue isn't that we support it, its that its our default | 18:17 |
| clarkb | its a terrible default for most new users | 18:17 |
| clarkb | (but I'm also biased and think nova net was the right design so I may be the wrong person to talk to) | 18:18 |
| TheJulia | clarkb: ++, the other and likely harder issue is requirements translation that I suspect can only be done after knowing the product | 18:18 |
| clarkb | we've also done a bad job explaining what is actually required for $functionality (though this has gotten better over time). You don't actually need cinder and swift to do a small compute only cloud for example | 18:20 |
| cdent | very true | 18:20 |
| clarkb | and vice versa, you don't need a compute cloud if you just want to expose storage | 18:20 |
| clarkb | and so new users with a constrained POC type use case are faced with this large array of things to learn and deploy when really they likely need something simpler to accomplish their goals (this has gotten better though) | 18:20 |
| clarkb | If we take the k8s example you get incredibly minimal functionality out of a base "default" install | 18:22 |
| clarkb | this helps keep it simple enough to understand while still being useful to prove something | 18:22 |
| clarkb | then you can add on the bits and pieces you want later (or redeploy with better overal understanding of what you want) | 18:23 |
| *** jamesmcarthur has quit IRC | 18:25 | |
| *** whoami-rajat has joined #openstack-tc | 18:25 | |
| fungi | kubernetes benefits from having a very (presently) popular use case satisfied by its base "default" install (container orchestration, i guess?) | 18:27 |
| *** jamesmcarthur has joined #openstack-tc | 18:28 | |
| *** jamesmcarthur has quit IRC | 18:28 | |
| clarkb | fungi: ya, but to do anything useful with it you need a network plugin and probably load balancer of some sort and persistent storage volumes | 18:28 |
| fungi | what is the *one* popular use case we would satisfy with a base "default" installation of openstack? | 18:28 |
| clarkb | similar to openstack, its just to actually test it on your laptop you don't need any of that yet | 18:28 |
| fungi | virtual machine management? | 18:28 |
| clarkb | fungi: ya I think manage VMs is one (even if networking is silly), and then the storage one which maybe is standalone swift (already popular) and cinder doing something | 18:29 |
| *** jamesmcarthur has joined #openstack-tc | 18:29 | |
| fungi | just wondering which simple subset we'd do for that. i mean, we do have https://governance.openstack.org/tc/reference/tags/starter-kit_compute.html i guess | 18:30 |
| clarkb | fungi: I've long wished that there was a way to run nova as a virt-install replacement | 18:30 |
| fungi | (glance+keystone+neutron+nova) | 18:30 |
| clarkb | (if we want to take the example to the extreme) | 18:30 |
| clarkb | in that case you wouldn't need glance or neutron | 18:31 |
| cdent | Is manage vms a use case? Or is it a solution to a use case? | 18:31 |
| cdent | that ^ is the crux of the openstack diffusion | 18:31 |
| clarkb | cdent: I think from the infra team's perspective manage VMs is the use case | 18:31 |
| clarkb | then we run tools like nodepool on top of that | 18:31 |
| cdent | isn't the use case "do massive ci"? | 18:32 |
| clarkb | cdent: that is the infra team's goal, openstack provides the use case of run VMs for that goal | 18:32 |
| cdent | and "run some services for a community"? | 18:32 |
| cdent | (which happen to use vms but that's an implementation detail | 18:32 |
| clarkb | (for a variety of reasons its been incredibly difficult for us to take advantage of features that try to do more within openstack's collection og tools. Limited deployment and inability to run "on" cloud, lack of reliability, etc) | 18:33 |
| fungi | cdent: that rabbit hole goes deep. you could in fact say the use case is "enable openstack development" | 18:34 |
| clarkb | and openstack for the most part does a really good job of that particular use case | 18:34 |
| clarkb | at least whenever I talk to people using the big clouds I'm often amazed at the behavior you have to put up with there | 18:34 |
| cdent | yes, but my point is that for a random person hacking in their basement "manage some vms" is not their goal | 18:34 |
| cdent | thus "hacking on openstack" isn't going to cross their radar _until_ they have some reason to manage some vms | 18:35 |
| clarkb | yup. Though it is probably a bit more common than you expect. Except that people like me with that use case end up using virt install | 18:36 |
| clarkb | and being sad beause you have to manually resize images and make copies from the golden image | 18:37 |
| clarkb | and then fight with making a config drive so that the upstream images work | 18:37 |
| * cdent nods | 18:39 | |
| *** jamesmcarthur has quit IRC | 18:40 | |
| *** jamesmcarthur has joined #openstack-tc | 18:40 | |
| clarkb | to pull on that thread even further, we are seeing a resurgence of VM management systems, but targeted at running VMs as containers | 18:42 |
| clarkb | I think it points to the idea that VMs are a really useful tool today and at the same time we lack tools to adequately take advantage of them | 18:43 |
| fungi | well, bikeshedding on the meaning of "use case" aside, what i meant to say was that the default base install of kubernetes seems to fill some common need people have other than learning/proof-of-concept deployments. trying to think if there's a similar need people have which some as-of-yet-undetermined default base install of openstack would satisfy | 18:43 |
| clarkb | (this doesn't mean nova should target that use case, just pointing out the use cases aren't far fetched) | 18:43 |
| clarkb | fungi: my example of virt install is the thing I think | 18:43 |
| *** dtantsur is now known as dtantsur|afk | 18:43 | |
| fungi | sure, seems like a reasonable straw man to start from | 18:43 |
| clarkb | fungi: basically to run VMs sanely you need to copy an image, resize it, then boot it with the appropriate libvirt flags and attach a config drive | 18:44 |
| clarkb | these are all things noav does today that do not require glance, neutron, cinder, swift, keystone, etc | 18:44 |
| clarkb | and is roughly equivalent to what you get out of a super simple k8s install | 18:44 |
| fungi | so you're arguing for "standalone nova" as the base default, i guess? | 18:45 |
| clarkb | ya, but I am also biased there because I've wanted that for a long time | 18:45 |
| cdent | dtroyer: what's that nova-api over hypervisor thing you've been playing with? | 18:46 |
| cdent | or am I remember it wrong | 18:46 |
| cdent | here we go: https://serverascode.com/2014/07/07/dwarf-openstack.html | 18:47 |
| cdent | clarkb: do you know that ^ | 18:48 |
| clarkb | cdent: ya there have been a few things over time. At one point with sqlite being a supported db backend you could mostly just run the daemons on demand using sqlite and get that too | 18:48 |
| clarkb | The issues haven't been so much in whether or not $thing is possible (in many cases we did support something similar simply bnecause openstack is so configurable) the issues were in making that a viable use case through documentation and steering people learning to simple options instead of complex defaults | 18:50 |
| clarkb | removing nova-net is an example of us moving away from options like that though | 18:50 |
| cdent | Do you think it would be possible to make a sort of "small cloud just for managing vms" packaging of openstack? | 18:53 |
| scas | in the maintenance of chef openstack, i've gone back and forth with myself over providing more complex defaults. i'm likely to settle on a happy medium of generating online content for consumption in the form of docs, posts and recordings for showcasing any of that, as opposed to trying to plan for a summit or conference | 18:53 |
| cdent | in other contexts that seems to be what people would be in a case like this: layer a nice boundary around the complexity | 18:53 |
| clarkb | cdent: I think it would've been possible when nova-net existed and sqlite was supported db backend. I don't think it would be likely to do without much effort today | 18:53 |
| clarkb | unfortunately the resource cost is high enough now that you need a machine bigger than my desktop to run openstack in a useful manner like that | 18:54 |
| scas | the lack of flashy changes can give the appearance of being dormant, at the extreme, as i've noticed | 18:54 |
| clarkb | so I guess its doable, but I need to upgrade hardware first | 18:54 |
| clarkb | related, I think a fair bit of gate instability is related to ^ with us being our own noisy neighbors in jobs :( | 18:55 |
| clarkb | (worth noting I don't necessarily think those decisions were wrong, but we optomized for a completely different set of users than the ones we seem to think are important today) | 18:57 |
| notmyname | this looks like a great discussion | 18:57 |
| notmyname | food for thought (or gas for the fire), perhaps one barrier in our community is that people get their hackles up when we start talking about a limited use case. I'll admit I'm part of that problem. I don't like "all you need is nova, because openstack is for managing VMs" because I feel like it's exclusionary and trivializes a lot of my work and the work of others. | 18:57 |
| clarkb | notmyname: I tried to be inclusive at the start of the discussion and mentioend swift and storage as another simple setup option | 18:58 |
| notmyname | so we end up with a zombocom version of openstack ("you can do aaanything at openstack") and people get confused | 18:58 |
| notmyname | careful wording like "if you need to do <Foo>, here's all you need" may help mitigate the people problem | 18:58 |
| clarkb | notmyname: I do think you are right that we have users on both sides of that aisle. Some want VMs (me), others want storage (you) | 18:58 |
| clarkb | and both are perfectly valid and can be made simpler thanthey are today (though swift does a really good job today, its moer the block storage story that could be simplified than object storage) | 18:58 |
| clarkb | notmyname: ++ | 18:58 |
| cdent | clarkb: agree on the own worst neighbor. I think part of that is also the economic factors of how conribution has happened: we've not been able to give value to "fast and light" or "cleaning up to be faster" as much as would be nice. | 18:59 |
| notmyname | the only person I'm calling out is myself. I'm not claiming anyone else is specifically saying one thing or another :-) | 18:59 |
| * cdent misses zombocom | 18:59 | |
| cdent | thanks for the reminder | 18:59 |
| fungi | cdent: no need to miss it | 18:59 |
| notmyname | seemed a fitting analogy :-) | 18:59 |
| fungi | still right where you left it | 18:59 |
| cdent | under a rock | 18:59 |
| clarkb | notmyname: the careful wording you mention is important though. Basically we should make it easy for people to focus on the subset of functionality that brings them to openstack initially | 19:00 |
| fungi | cdent: though apparently you (still) need a browser with shockwave flash support for the site | 19:00 |
| clarkb | notmyname: then that serves as a bridge into the larger set of thigns to worry about should that become useful to them | 19:00 |
| notmyname | clarkb: I agree | 19:00 |
| scas | to that point, notmyname, you hit on something that i see in my corner. swift 'works' if one puts in a 'few days' of dev time, but it's not immediately obvious because nobody has used it in, as we say in the south, a coon's age | 19:01 |
| scas | to the casual observer, it's just not there | 19:01 |
| notmyname | which is exactly what you want from infrastructure, but terrible for marketing ;-) | 19:01 |
| smcginnis | clarkb: "the issue isn't that we support it, its that its our default" 👍 | 19:09 |
| smcginnis | Saner defaults for a simpler deployment that can be tweaked for those needing a more complex scenario would be a great improvement. | 19:09 |
| scas | supporting k8s is something chef openstack can do, but it's also non-obvious because few are specifically working at that junction of technology | 19:10 |
| scas | three years in, i've been floating the idea of a project rename to something less trademarked | 19:12 |
| * TheJulia smiles at the reference to zombocom | 19:12 | |
| *** mriedem has quit IRC | 19:22 | |
| *** mriedem has joined #openstack-tc | 19:24 | |
| *** e0ne has joined #openstack-tc | 20:21 | |
| *** whoami-rajat has quit IRC | 20:35 | |
| *** e0ne has quit IRC | 20:37 | |
| *** jamesmcarthur has quit IRC | 20:53 | |
| *** e0ne has joined #openstack-tc | 20:54 | |
| *** jamesmcarthur has joined #openstack-tc | 21:03 | |
| *** jamesmcarthur has quit IRC | 21:08 | |
| *** jamesmcarthur has joined #openstack-tc | 21:28 | |
| *** jamesmcarthur has quit IRC | 21:43 | |
| *** bsilverman has joined #openstack-tc | 21:47 | |
| *** jamesmcarthur has joined #openstack-tc | 21:48 | |
| *** e0ne has quit IRC | 21:50 | |
| *** e0ne has joined #openstack-tc | 21:52 | |
| *** jamesmcarthur has quit IRC | 21:53 | |
| *** cdent has quit IRC | 21:56 | |
| *** e0ne has quit IRC | 21:57 | |
| *** jamesmcarthur has joined #openstack-tc | 23:20 | |
| *** ricolin has joined #openstack-tc | 23:55 | |
| *** mriedem has quit IRC | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!