| *** Sundar has joined #openstack-tc | 00:06 | |
| *** Sundar has quit IRC | 00:28 | |
| *** tjgresha_nope has joined #openstack-tc | 00:31 | |
| *** tjgresha has quit IRC | 00:32 | |
| *** tbarron_ has quit IRC | 00:32 | |
| *** timburke has quit IRC | 00:32 | |
| *** timburke has joined #openstack-tc | 00:34 | |
| *** sapd1 has quit IRC | 00:59 | |
| *** sapd1 has joined #openstack-tc | 00:59 | |
| *** sapd1 has quit IRC | 01:13 | |
| *** sapd1 has joined #openstack-tc | 01:14 | |
| *** jamesmcarthur has joined #openstack-tc | 01:34 | |
| *** lbragstad has quit IRC | 01:37 | |
| *** jamesmcarthur has quit IRC | 01:48 | |
| *** jamesmcarthur has joined #openstack-tc | 01:49 | |
| *** jamesmcarthur has quit IRC | 02:25 | |
| *** sapd1 has quit IRC | 03:25 | |
| *** jamesmcarthur has joined #openstack-tc | 03:25 | |
| *** sapd1 has joined #openstack-tc | 03:26 | |
| *** jamesmcarthur has quit IRC | 03:41 | |
| *** diablo_rojo has quit IRC | 03:50 | |
| *** whoami-rajat has joined #openstack-tc | 03:54 | |
| *** jamesmcarthur has joined #openstack-tc | 04:01 | |
| *** sapd1 has quit IRC | 04:07 | |
| *** sapd1 has joined #openstack-tc | 04:08 | |
| *** ricolin has joined #openstack-tc | 04:10 | |
| *** jamesmcarthur has quit IRC | 04:19 | |
| *** sapd1 has quit IRC | 04:28 | |
| *** sapd1 has joined #openstack-tc | 04:29 | |
| *** sapd1 has quit IRC | 04:37 | |
| *** sapd1 has joined #openstack-tc | 04:44 | |
| *** diablo_rojo has joined #openstack-tc | 04:50 | |
| *** sapd1 has quit IRC | 05:11 | |
| *** sapd1 has joined #openstack-tc | 05:25 | |
| *** e0ne has joined #openstack-tc | 05:28 | |
| *** sapd1 has quit IRC | 05:29 | |
| *** sapd1 has joined #openstack-tc | 05:29 | |
| *** sapd1 has quit IRC | 05:36 | |
| *** sapd1 has joined #openstack-tc | 05:37 | |
| *** Luzi has joined #openstack-tc | 05:41 | |
| *** prometheanfire has joined #openstack-tc | 05:43 | |
| *** prometheanfire has left #openstack-tc | 05:43 | |
| *** sapd1 has quit IRC | 05:46 | |
| *** sapd1 has joined #openstack-tc | 05:47 | |
| *** e0ne has quit IRC | 05:50 | |
| *** jaypipes has quit IRC | 05:50 | |
| *** jaypipes has joined #openstack-tc | 05:50 | |
| *** e0ne has joined #openstack-tc | 05:51 | |
| *** gouthamr has quit IRC | 05:56 | |
| *** sapd1 has quit IRC | 05:57 | |
| *** sapd1 has joined #openstack-tc | 05:58 | |
| *** gouthamr has joined #openstack-tc | 06:00 | |
| *** sapd1 has quit IRC | 06:07 | |
| *** e0ne has quit IRC | 06:08 | |
| *** whoami-rajat has quit IRC | 06:13 | |
| *** whoami-rajat has joined #openstack-tc | 06:25 | |
| *** sapd1 has joined #openstack-tc | 06:52 | |
| *** diablo_rojo has quit IRC | 06:56 | |
| *** zhurong has joined #openstack-tc | 07:16 | |
| *** jpich has joined #openstack-tc | 07:16 | |
| zhurong | #openstack-cyborg | 07:16 |
|---|---|---|
| zhurong | sorry for the wrong command | 07:17 |
| *** tosky has joined #openstack-tc | 07:39 | |
| *** e0ne has joined #openstack-tc | 07:49 | |
| *** e0ne has quit IRC | 07:51 | |
| *** e0ne has joined #openstack-tc | 07:56 | |
| *** dtantsur|afk is now known as dtantsur | 08:35 | |
| *** e0ne has quit IRC | 08:39 | |
| *** e0ne has joined #openstack-tc | 08:48 | |
| *** tbarron has joined #openstack-tc | 09:21 | |
| *** e0ne has quit IRC | 09:26 | |
| *** e0ne has joined #openstack-tc | 09:30 | |
| *** e0ne has quit IRC | 10:10 | |
| *** e0ne has joined #openstack-tc | 10:15 | |
| asettle | Morning o/ | 10:48 |
| asettle | Quiet in here today | 10:48 |
| evrardjp | indeed | 10:50 |
| *** e0ne has quit IRC | 10:51 | |
| *** e0ne has joined #openstack-tc | 10:57 | |
| smcginnis | Need more EU folks I guess. :) | 11:00 |
| smcginnis | And UK folks too. :P | 11:00 |
| mugsie | nah, less of them is better :) | 11:04 |
| evrardjp | mugsie: you mean you want a border? | 11:08 |
| evrardjp | :D | 11:08 |
| mugsie | around england? sure :D - Northern Ireland, Wales and Scotland are welcome to join the Celtic Union | 11:09 |
| *** e0ne has quit IRC | 11:17 | |
| asettle | mugsie, mateeeee. If. Fucking. Only. | 11:19 |
| asettle | You know what shits me off? Around 2006/7, Ireland opened up passport applications as far back as Great Grandparents. At the time, I was stupid, and was like "ha! Excellent. I'll get that one day" | 11:19 |
| asettle | No. No I won't. Because eventually the economy will recover and they won't be interested in weird foreigners a few too many gens back. | 11:20 |
| asettle | So guess who's in sunny England -.- | 11:20 |
| mugsie | at leats it is sunny? | 11:24 |
| asettle | Thats' true. It is lovely today. | 11:25 |
| asettle | tc-members - would appreciate further reviews on: https://review.openstack.org/647712 Just as a quick brief snapshot to convince everyone: This is quite an easy goal for the community to achieve. There's a POC linked from Ian Choi in the patch itself, and it has support from Monty and the infra team. We have a large portion of users that are offline (whether data centers, or our Chinese contingent) and this is a great way to ensure they have relevant | 11:31 |
| asettle | and up-to-date resources at their fingertips! This is also great for those that are consuming the documentation downstream. Many, many benefits! :D vote 1 PDF support! | 11:31 |
| asettle | \o/ | 11:31 |
| * asettle steps off soap box | 11:31 | |
| ttx | asettle: I was wondering if you planned another revision to address some of the comments.. or would rather have us approve this one and iterate | 11:35 |
| ttx | I guess that answers my question | 11:35 |
| asettle | Ah yes, sorry. Good point. I will fix up some of the comments for clarification IN the goal, but as mugsie commented, iterations are always doable after the fact. But we haven't had the full crew review, so it would be helpful to ensure everyone's got eyes | 11:36 |
| asettle | ... on the page | 11:36 |
| asettle | I presume everyone has eyeballs | 11:36 |
| *** ricolin has quit IRC | 11:37 | |
| jroll | with the code I've been reading lately, I might not have eyeballs soon | 12:10 |
| *** zhipeng has quit IRC | 12:11 | |
| *** jamesmcarthur has joined #openstack-tc | 12:13 | |
| dhellmann | asettle : I keep looking at the comments you left saying you're going to rewrite bits and waiting for the new draft... | 12:19 |
| asettle | dhellmann - *such* a disappointment to the crew ;) Actually, sorry, that is on me. But I've only really caught up with everything *today*. As I said above, another review incoming. But SUSE work taking precedence right now :) | 12:20 |
| dhellmann | oh, yeah, no pressure, I'm just explaining my lack of vote | 12:20 |
| asettle | Just wanted to ping those that hadn't had a look at the first iteration. | 12:20 |
| asettle | Before I went ahead and bulldozed it all | 12:20 |
| dhellmann | ok. I will review the version that's online when I get to my "work from atlanta" location in a couple of hours | 12:21 |
| asettle | Neat :) | 12:22 |
| *** jamesmcarthur has quit IRC | 12:34 | |
| *** lbragstad has joined #openstack-tc | 12:36 | |
| *** jamesmcarthur has joined #openstack-tc | 12:47 | |
| *** e0ne has joined #openstack-tc | 12:56 | |
| *** jamesmcarthur has quit IRC | 13:04 | |
| *** jpich has quit IRC | 13:17 | |
| *** jpich has joined #openstack-tc | 13:17 | |
| *** e0ne has quit IRC | 13:18 | |
| *** e0ne has joined #openstack-tc | 13:27 | |
| *** mriedem has joined #openstack-tc | 13:28 | |
| mnaser | diablo_rojo_phon, gmann: does anyone happen to have the WeChat account for any of the Tricircle team members? | 13:29 |
| mnaser | Horace from the foundation reached out and he'd like to talk to them to help bridge and simplify the discussion regarding the concerns that were brought up | 13:29 |
| *** ricolin has joined #openstack-tc | 13:55 | |
| *** ianychoi has quit IRC | 14:13 | |
| *** ianychoi has joined #openstack-tc | 14:14 | |
| *** Luzi has quit IRC | 14:24 | |
| *** e0ne has quit IRC | 14:27 | |
| *** e0ne has joined #openstack-tc | 14:31 | |
| gmann | mnaser: no, while bionic migration, I used PTL email ID to reach out - songbaisen@szzt.com.cn | 14:34 |
| *** e0ne has quit IRC | 14:34 | |
| gmann | mnaser: i was about to ping you on this. do you want me to explain the situation to Horace or you already did ? | 14:35 |
| *** e0ne has joined #openstack-tc | 14:41 | |
| mnaser | gmann: I haven't told horace too much details but maybe starting an email thread would be good (and including the info) -- he mentioned if he could get into their WeChat group | 14:47 |
| *** e0ne has quit IRC | 14:48 | |
| *** e0ne has joined #openstack-tc | 14:48 | |
| fungi | if it takes this long for an interested party to even just find out how to join that team's meeting, it seems very much not open (choice of platform aside) | 14:49 |
| gmann | mnaser: sure, i will start the email thread with related info. | 14:49 |
| *** dklyle has joined #openstack-tc | 14:51 | |
| mnaser | fungi: yeah, I only really saw Horace' message to me today, also he was on vacation AFAIK.. so we'll see | 14:53 |
| ttx | tc-members: another office hour! | 15:00 |
| TheJulia | o/ | 15:00 |
| gmann | o/ | 15:00 |
| ricolin | o/ | 15:00 |
| mugsie | o/ | 15:00 |
| evrardjp | o/ | 15:00 |
| zaneb | \o | 15:01 |
| lbragstad | o/ | 15:03 |
| mnaser | I'd like to bring attention to our etherpad for the PTG: https://etherpad.openstack.org/p/ptg-tc-train | 15:03 |
| mnaser | err | 15:03 |
| mnaser | oop | 15:03 |
| mnaser | https://etherpad.openstack.org/p/tc-train-ptg | 15:03 |
| mnaser | also, we have https://etherpad.openstack.org/p/denver-joint-leadership-meeting | 15:04 |
| mnaser | do we want to discuss some of that agenda? | 15:04 |
| * ttx reads | 15:06 | |
| *** e0ne has quit IRC | 15:08 | |
| * ttx cleans up | 15:09 | |
| ttx | mnaser: I'm trying to extract a strawman agenda for denver-joint-leadership-meeting | 15:11 |
| evrardjp | ttx: I am in agreement with you currently have | 15:12 |
| fungi | apologies for vomiting into the joint leadership etherpad | 15:12 |
| ttx | mnaser: do you knwo how much time we'll have? | 15:12 |
| ttx | fungi: as long as you vomit at the bottom, we stay dry at the top | 15:13 |
| *** e0ne has joined #openstack-tc | 15:13 | |
| fungi | heh | 15:13 |
| evrardjp | fungi: I just thought you liked your coffee strongly black | 15:13 |
| evrardjp | or is it about the amount of links? | 15:14 |
| fungi | amount of context overall, yes | 15:14 |
| fungi | just wanted to have some details on hand in case that topic got included | 15:14 |
| dhellmann | o/ | 15:15 |
| mnaser | ttx: I think I pinged Alan for this at some point | 15:15 |
| mnaser | I think my answer was "See what topics the TC comes up with and that'll give us an idea of how much time to slot." | 15:16 |
| ttx | we seem to have all afternoon, but shared with the other projects | 15:16 |
| ttx | so probably enough time for anything we'd like to cover | 15:16 |
| ttx | I was wondering if we'd like to do a "2 years after" review of the list of priorities that we established in Boston early 2017 | 15:17 |
| ttx | not TC-specific, but a good Board+TC exercise | 15:17 |
| * ttx adds to the bottom | 15:18 | |
| * mnaser wonders who's still around from that Boston review | 15:18 | |
| ttx | exactly. Also maybe time to start another cycle | 15:19 |
| mnaser | ttx: I don't think I was as involved at that time.. I'm a little curious about that 'review of list of priorities' | 15:20 |
| ttx | yeah, you're probably right | 15:21 |
| ttx | Little value in reviewing those. More value in asking if we should do it again and define current priorities | 15:21 |
| smcginnis | I think a quick review of what our stated priorities were at the time and a check to see if they are still relevant or not would be useful. | 15:22 |
| ricolin | smcginnis, +1 | 15:22 |
| ttx | As a reminder https://superuser.openstack.org/articles/community-leadership-charts-course-openstack/ | 15:23 |
| asettle | o/ hi hi sorry, bit delayed | 15:23 |
| fungi | there's no need to be sorry! | 15:24 |
| smcginnis | Item 4 "Simplifying the existing projects by reducing the number of supported configurations and options" actually sounds like a good cycle goal to me. Though one that would be hard to measure for "completeness". | 15:25 |
| gmann | asking if we need to do the same exercise for next cycles and so is useful than reviewing the 2 years old list. | 15:25 |
| mnaser | we'd have to propose doing that in a advance | 15:26 |
| asettle | smcginnis, I admit, that reads a lot more like a mantra,(?), rather than an achievable goal. Telling projects they need to reduce complexity by removing supported configs is super easy in theory, but it is not definitive in any way. | 15:27 |
| smcginnis | We've found a bunch of config options to deprecate in Cinder, but it's not an easy (or obvious?) thing to do. | 15:28 |
| mugsie | and a lot of projects may agree, but each person will want to hold on to their super special config | 15:28 |
| asettle | ^^ precisely. I can very quickly already envision individuals being divided based on what they worked on and implemented, therefore see as their project/baby | 15:29 |
| mugsie | but reducing the snowflake factor is a great goal - just not sure *how* we do it | 15:29 |
| asettle | Exactly. I do not disagree with it fundamentally, but... hard. | 15:29 |
| fungi | yes, we took a first stab at the low-hanging fruit there by deprecating/retiring whole projects we didn't really need or were otherwise redundant | 15:29 |
| dhellmann | would the technical vision work we did help focus that? | 15:29 |
| fungi | that transpired soon after the meeting (in the months thereafter) | 15:30 |
| asettle | How would you see the technical vision helping focus the efforts of removing support for supposedly redundant configs and options? | 15:30 |
| fungi | i do think the technical vision is a great tool to help continue the harder parts of that goal | 15:30 |
| asettle | I can't match the two, sorry. Can someone explain to me what they see here? | 15:30 |
| asettle | Also, moving window to monitor so I can read properly. | 15:30 |
| fungi | the technical vision is all about what we want openstack to be, and its purpose. removing features or whole projects which don't fit that vision simplifies the whole | 15:31 |
| dhellmann | if we have a vision for what we want openstack to be, and we have bits of openstack trying to support being something else, that helps us see where to trim and be "in line" with our vision | 15:31 |
| dhellmann | fungi is typing faster than I am today :-) | 15:31 |
| fungi | pruning our hedges, so to speak | 15:32 |
| dhellmann | if we don't use that vision to help us shape the project, what was the point of writing it? | 15:32 |
| asettle | Okay that's fair. But one of the things a lot of people are demanding for, is concise feedback from the TC. If we provide a vision that says "make you project simpler and betterer" that doesn't offer any assistance. Many will look at the project and go "yeah, it's fine, thanks tho" | 15:32 |
| *** e0ne has quit IRC | 15:32 | |
| dhellmann | sure, that's not actionable | 15:32 |
| dhellmann | "remove the ability to configure the location of X" is actionable | 15:33 |
| fungi | right, the feedback could be more along the lines of "deprecate and eventually remove bits which aren't justified by the vision" | 15:33 |
| dhellmann | "settle on 1 damn api for uploading images" is actionable | 15:33 |
| asettle | Right. Would need to be... concise-ish | 15:33 |
| mnaser | yeah. | 15:33 |
| mugsie | would taking a strawman project and giving examples help us communicate it to the other projects? | 15:33 |
| asettle | ^^ yes, excellent suggestion. | 15:33 |
| smcginnis | Low hanging for drivers has been, if there's a common san_username config option, stop adding vendora_username, vendorb_user, etc. | 15:34 |
| mnaser | "remove all references of API endpoints from your configs and use the service catalog" | 15:34 |
| dhellmann | the recent discussion about telemetry and monasca on the ML might be a good place to start | 15:34 |
| mugsie | well, not strawman, but a project with a friendly PTL who won't get mad at us | 15:34 |
| mugsie | dhellmann: yeah - good point | 15:34 |
| fungi | an early example is that shortly after we concluded simplification was a priority, we deprecated and then retired the "community app catalog" | 15:34 |
| dhellmann | maybe it's time to drop those bits of the telemetry project that duplicate what is in monasca | 15:34 |
| asettle | I was actually thinking problems might arise from a similar situation that we were discussing today mugsie - we may be removing "redundant" services, but are we sure who is consuming them? Designate's removal of designate-zone-manager ended up in a kick off from HP and RAX | 15:34 |
| asettle | Just as something to think about. | 15:34 |
| dhellmann | and get it back to focusing on collecting consumption data for billing | 15:35 |
| asettle | So that code exists in Designate, but it's never been removed becasue people use it. So... it's been made redundant and unsupported, but it lives on in the heart's of others ;) | 15:35 |
| mugsie | yup - there is 3 of those services in Designate | 15:35 |
| mugsie | and I will be rm-ing 2 of them | 15:35 |
| asettle | And how long have they been dead/active? | 15:35 |
| mugsie | (it is the biggest point of confusion for people installing it) | 15:36 |
| fungi | it's a fine line to walk, sure, because there's always going to be *somebody* out there who relied on the thing you're removing because you've determined it's not actually in scope for your project | 15:36 |
| mugsie | newton? | 15:36 |
| asettle | Right, that's a really long time. | 15:36 |
| asettle | My point is, we go ahead and walk this super fine line. Determining what is technically "redundant". We suddenly become the group that decides what projects are supposed to use. I see the use entirely, but I'm unsure of how well this would be received as an overall community goal. | 15:36 |
| dhellmann | maintaining everything forever isn't sustainable. we have to remember that the purpose of open source projects is to enable collaboration. if no one is collaborating on the maintenance, that's a big signal. | 15:37 |
| fungi | the idea is that you end up needing to weigh sustainability of teh project against maintaining features which you've determined aren't your future direction | 15:37 |
| smcginnis | dhellmann: ++ | 15:37 |
| dhellmann | it is not our responsibility to support everything anyone wants to use. it is our responsibility to ensure that the contributors to the project have a place to work together fairly. | 15:37 |
| fungi | asettle: i don't think the tc determines what is and isn't redundant in most cases | 15:37 |
| dhellmann | the tc, especially, is building *that* and not openstack, per se | 15:37 |
| asettle | Too true. But in the case of designate, you end up deprecating something that never gets removed. What's the odds this will happen at large(r) scale? | 15:37 |
| fungi | the tc helped guide the community in putting together a vision for what they want openstack to be/become, and the teams responsible for the services which make up openstack need to decide, in most cases, what does and doesn't fit | 15:38 |
| dhellmann | we've had this idea for ages that we can't ever break anything but I think that applies more to the way we do feature work than the way we maintain old things. If no one is there to maintain it, removing it after deprecation seems fine to me. | 15:39 |
| fungi | for the specific concern of lingering cruft, i expect we could improve our deprecation poilcies and better communicate them | 15:39 |
| mugsie | yeah, the fine line will come from the likes of PowerVMStackers and Nova (if the driver gets merged in tree) should that stay as something that fits? | 15:39 |
| asettle | Perhaps I'm being too negative, and I think I'm in a mood because I've ended up in about 3 technical debates today, but I guess I'm seeing what we're proposing here as contradictory to what we stand for as a technical committee. I think if we were able to draw up a strawman, we might find ourselves removing duplicates and doing the good deeds, but we also might find ourselves in a pickle and plenty of misplaced arguments by suggesting removals when | 15:39 |
| asettle | perhaps we're not entirely too sure what we are talking about. | 15:39 |
| dhellmann | fungi : and encourage teams to follow through on the removals | 15:40 |
| fungi | yep, follow through can be part of the policy | 15:40 |
| dhellmann | asettle : no one said it was going to be easy | 15:40 |
| mugsie | dhellmann: I think that is a policy we need to be more explict about - if it is not actively maintained, and starts causing issues, we can remove it | 15:40 |
| dhellmann | and yes, I agree, we need to talk about concrete changes | 15:40 |
| asettle | I'm not suggesting it should be either. But I'm saying that we might have other options that are more quantifiable at this point for a community goal. | 15:40 |
| dhellmann | mugsie : maybe the tc needs to write that policy down? | 15:41 |
| mugsie | we do | 15:41 |
| * dhellmann touches his nose and says "not it" | 15:41 | |
| * mugsie will add it to the list for the next flight :) | 15:41 | |
| dhellmann | asettle : oh, were we talking about this as a goal? I missed that bit | 15:41 |
| asettle | Ye | 15:41 |
| dhellmann | ok, well, I see it as a future looking thing but not a train cycle goal for sure | 15:41 |
| fungi | i assumed we'd ruled it out as being concrete enough for a viable cycle goal within a couple sentences | 15:42 |
| mnaser | speaking of goals | 15:42 |
| mnaser | it looks like no one volunteered to write anything about ipv6 | 15:42 |
| mugsie | yeah, I was think of this more as a general guidence thing from the TC | 15:42 |
| dhellmann | not everything we need to do is going to fit into that goal structure | 15:42 |
| mnaser | so I think I might have to write this up myself.. unless someone is inclined to pick it up | 15:42 |
| mugsie | mnaser: IPv6? | 15:42 |
| asettle | fungi, ha well I missed that bit, that's why I kept debating the point. My bad! | 15:42 |
| mnaser | community goal of support ipv6 by making sure we have devstack/tempest jobs that run ipv6 only | 15:43 |
| fungi | going back to the earlier example of the community app catalog, there were definitely still users of it, as well as an entire team developing and maintaining it. making the decision to cut that out of openstack was definitely not "easy" | 15:43 |
| gmann | mnaser: yeah , no response on email. I will write it during weekend. | 15:44 |
| fungi | however, it was competing with more established solutions in adjacent ecosystems we wanted to develop better ties with, and continuing that project could have ended up further isolating us from them | 15:44 |
| clarkb | as a point of input the complexity ops and users are concerned about isnt the type of complexity removed when aproject like app catalog goes away | 15:45 |
| mugsie | no, ops / users care about random hypervisor toggles, cinder drivers, networking gear interactions | 15:46 |
| fungi | yes, that was only one part | 15:46 |
| fungi | we definitely also talked about the need to reduce the "configurability disease" infecting most of our services | 15:46 |
| mnaser | thing is | 15:47 |
| zaneb | incidentally, we have said that we will include in every cycle a goal to update to that cycle's py3 Zuul config, but we haven't yet set that up for Train or sought goal champions. is there anybody who is not me who would like to kick that off? | 15:47 |
| mnaser | does anyone really install manually? | 15:47 |
| mugsie | e.g. for BigStorageCo, should I use iSCSI or NFS? Why? should I use the in tree driver, or the external one? | 15:47 |
| mnaser | most people just end up using a deployment tool | 15:47 |
| fungi | in the time since i think we've better refined that notion to something like "do the expected thing by default, and try to eliminate mandatory configuration parameters where possible" | 15:47 |
| zaneb | folks from the distros (especially Ubuntu) are very keen to see py37 support happen, so we may be able to find goal champions there | 15:47 |
| mugsie | mnaser: no, but the toggles can make a huge impact in some cases, and then you end up in the weeds | 15:47 |
| clarkb | mnaser: you still have to understand if nova converting all images to raw before boot is a desireable option | 15:48 |
| clarkb | and then tell the automated system to change the default if not | 15:48 |
| mugsie | I need 4 SRIOV nics, and a single NUMA zones, and 100GB RAM - how do I do that? | 15:48 |
| clarkb | and whether it is safe to tell kvm to play fast with disk writes | 15:48 |
| mugsie | or pinned CPU cores are getting steal form the hypervisor, and you endup manually editing libvirt XML pinsets | 15:49 |
| *** jamesmcarthur has joined #openstack-tc | 15:49 | |
| asettle | mnaser, people do for test deploys etc or for functionality testing. That, or training materials for sales eng etc. For actual production deploys, yeah, nobody does a manual install. | 15:49 |
| asettle | But we've always had that debate with docs | 15:50 |
| *** jamesmcarthur_ has joined #openstack-tc | 15:50 | |
| *** jamesmcarthur has quit IRC | 15:50 | |
| smcginnis | I try to go through and update my basement cloud using the manual deploy docs each cycle. But I'm odd that way. (In that I'm an OpenStack dev that actually runs it. :D ) | 15:51 |
| mugsie | but even people who use $TOOL, sometimes will have changes to the tool to support some $TOGGLE because some software that is being installed is only certifed is it is set to a specific value | 15:51 |
| asettle | Aye what the muggle said | 15:51 |
| clarkb | we have a lot of little toggles like those all over openstack that greatly impact how the cloud functions. We could be more opinionated at the expense of impacting more niche usecases (like infras test cloud we dont care about our data niche) | 15:51 |
| clarkb | fwiw I think there was a good push on removing redundant config options when this was first pushed | 15:53 |
| mnaser | yeah but infra's test cloud was very much a 'ci-focused' cloud which is a use case | 15:54 |
| mugsie | and a lot of the time it is not imediately obvious what the result of tweaking something is - you can very easily end ubp with the code and grep -r to find the potential impacts | 15:54 |
| jroll | apologies for missing office hours; had an appointment that ran much longer than I thought. /me reads back | 15:54 |
| asettle | jroll, you missed a part. We spoke about you a lot. | 15:54 |
| asettle | party* | 15:54 |
| jroll | perfect | 15:55 |
| asettle | Talked a little bit about fungi's hair and what's next for him. The ususal shenanigans. | 15:55 |
| clarkb | mnaser: ya I dont know wherethe balance is | 15:55 |
| *** diablo_rojo has joined #openstack-tc | 15:59 | |
| * fungi promises to bring his hair with him to denver | 15:59 | |
| cmurphy | even if you use a deployment tool it usually exposes most of the configuration options to you so you still have to understand them and manage them, so it doesn't really solve the complexity problem | 16:01 |
| cmurphy | honestly you kind of have to understand it pretty well because you have the extra layer of abstraction in managing it and you inevitably have to help with bugfixes | 16:02 |
| gmann | it might be good to find the exact list of projects and their config options which are painful on deployer side. bugs reported or people complains might be first step. | 16:04 |
| fungi | it's probably not that simple. the impression i get has less to do with particular projects or options and more to do with the aggregate volume of knowledge needed due to the sheer number of options across all of openstack | 16:06 |
| jroll | mnaser | most people just end up using a deployment tool <- so a point on this, the deployment tools still strive to expose all the knobs you can turn (in one way or another). for example, kolla-ansible has some built-in configs, but otherwise has you drop in extra config options in a neat little tree structure. | 16:08 |
| fungi | and much of that complexity may simply be intractable because openstack can't be expected to hide the complexity of the underlying choices made when selecting hardware for the deployment | 16:09 |
| jroll | mnaser: but at any rate, this isn't about making openstack easier to install (manually or otherwise), it's about making the *decisions* about *how and what* to install/configure easier | 16:09 |
| jroll | for example, we're building a new VM platform from scratch, and digging through how exactly I want neutron set up is a huge timesink | 16:09 |
| fungi | how much of that has to do with earlier decisions as to what brand and series of network gear was purchased? | 16:10 |
| jroll | that choice was easy - stay vendor-neutral | 16:10 |
| jroll | but things like DVR vs not, routed networks, subnetpools or not, etc | 16:10 |
| fungi | hardwareless networks! ;) | 16:10 |
| jroll | heh | 16:11 |
| jroll | if only! | 16:11 |
| fungi | the only actual way to have a vendor-neutral network is to not buy any network equipment | 16:11 |
| jroll | well, remain vendor-neutral at the openstack layer by using OVS or similar | 16:11 |
| jroll | (and again, OVS vs linuxbridge vs calico vs ... is another crippling decision) | 16:12 |
| clarkb | fwiw you want subnetpools particularly with ipv6. Very nice as a user to have that | 16:13 |
| fungi | i say this as a long-time former network engineer for a large service provider and telecommunications company. even if you decide to stick to open standard protocols for everything possible, a lot of your choices will still end up being constrained by what your selected devices can support | 16:13 |
| jroll | fair point | 16:15 |
| jroll | I've been running under the assumption we can define the networking gear, fwiw | 16:15 |
| fungi | so there is some degree of complexity neutron has no choice but to pass along to the operator, as a resuly | 16:15 |
| fungi | er, result | 16:16 |
| jroll | right, just some anecdata :) | 16:16 |
| fungi | i'm assuming the same goes for projects like ironic... is it reasonable to expect the service to guess whether servers use ipmi or something else? | 16:18 |
| *** ianychoi has quit IRC | 16:20 | |
| fungi | but places we can probably do better is where we currently have to configure one openstack service to know how to interact with another openstack service. when we control the software on both sides of the conversation, a variety of negotiation solutions become available | 16:20 |
| fungi | the keystone catalog improvements over the years have solved or opened up avenues for reducing some of that sort of complexity | 16:21 |
| mugsie | oh next week I will be working from PDT - and wont be around a huge amount | 16:25 |
| mugsie | I get back to Ireland 22/4 (just in time to turn around ad head back to denver). I will keep an eye on email / IRC etc | 16:26 |
| *** zbr has quit IRC | 16:34 | |
| *** jpich has quit IRC | 16:37 | |
| *** zbr has joined #openstack-tc | 16:41 | |
| *** ricolin has quit IRC | 16:44 | |
| asettle | Alright folks, adios o/ | 16:50 |
| *** dtantsur is now known as dtantsur|afk | 16:50 | |
| jroll | \o | 16:52 |
| *** jamesmcarthur has joined #openstack-tc | 16:52 | |
| *** jamesmcarthur_ has quit IRC | 16:56 | |
| *** penick has joined #openstack-tc | 17:16 | |
| *** Sundar has joined #openstack-tc | 17:30 | |
| *** jamesmcarthur has quit IRC | 17:35 | |
| *** zbr has left #openstack-tc | 17:43 | |
| *** jamesmcarthur has joined #openstack-tc | 17:47 | |
| *** jamesmcarthur has quit IRC | 17:54 | |
| *** jamesmcarthur has joined #openstack-tc | 17:56 | |
| *** jamesmcarthur has quit IRC | 17:58 | |
| *** jamesmcarthur has joined #openstack-tc | 17:59 | |
| *** jamesmcarthur has quit IRC | 18:01 | |
| *** jamesmcarthur has joined #openstack-tc | 18:02 | |
| *** gmann is now known as gmann_afk | 18:15 | |
| *** tosky has quit IRC | 18:26 | |
| *** jamesmcarthur has quit IRC | 18:26 | |
| *** jamesmcarthur has joined #openstack-tc | 18:28 | |
| *** e0ne has joined #openstack-tc | 19:11 | |
| *** gmann_afk is now known as gmann | 19:27 | |
| *** e0ne has quit IRC | 19:31 | |
| *** Sundar has quit IRC | 19:35 | |
| *** Sundar has joined #openstack-tc | 19:38 | |
| *** zaneb has quit IRC | 19:53 | |
| *** jamesmcarthur has quit IRC | 20:10 | |
| *** whoami-rajat has quit IRC | 21:03 | |
| *** tosky has joined #openstack-tc | 21:29 | |
| *** Sundar has quit IRC | 21:33 | |
| *** jamesmcarthur has joined #openstack-tc | 22:01 | |
| *** jamesmcarthur has quit IRC | 22:14 | |
| *** tosky has quit IRC | 22:15 | |
| *** tbarron has quit IRC | 23:21 | |
| *** aspiers has quit IRC | 23:21 | |
| *** corvus has quit IRC | 23:21 | |
| *** tbarron has joined #openstack-tc | 23:27 | |
| *** aspiers has joined #openstack-tc | 23:27 | |
| *** corvus has joined #openstack-tc | 23:27 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!