| * dtroyer looks around… | 00:56 | |
| fungi | yeah, this is "office hours" | 01:05 |
|---|---|---|
| fungi | two of us this time! | 01:05 |
| *** hongbin has quit IRC | 01:07 | |
| dtroyer | woot! 100% increase | 01:08 |
| fungi | unsustainable | 01:09 |
| dtroyer | so I have not read logs from last week, pretty much anywhere, just skimmed the ML… what fun and exciting things did I miss? | 01:10 |
| dtroyer | :) | 01:10 |
| fungi | calls for the return of stackforge | 01:10 |
| fungi | return of stackforge's revenge returns ii | 01:11 |
| dtroyer | from a branding standpoint that may have been better… should we do that but not use a repo namespace? | 01:12 |
| fungi | i really don't know. part of the complaint is that no matter how we tag/label repositories on github people will think you have to install everything under the openstack namespace | 01:13 |
| fungi | and also that anything hosted from our infrastructure is officially part of openstack | 01:13 |
| dtroyer | are there non-apochryphal instances of that actually happening (thinking that, not doing it)? | 01:14 |
| dtroyer | the install part, not just the assumption that it is all official | 01:14 |
| fungi | this is mostly second-hand from the foundation marketing team, i think | 01:14 |
| fungi | well, more that they want to know what openstack is, see all those repos on github, and decide to use cloudstack instead because it's "simpler" | 01:15 |
| fungi | s/cloudstack/whatever's hot right now/ | 01:16 |
| fungi | ttx put together an etherpad to start trying to classify the unofficial repos we're hosting to see what we have exactly and to better inform our options | 01:18 |
| dtroyer | I can see the difficulty in understanding what things are | 01:18 |
| fungi | like, what things are closely related to official team work that might be able to join up, what things would be reasonable to encourage to apply as new official teams, et cetera | 01:18 |
| fungi | right now ~1/3 of the non-retired repositories we're hosting aren't under any official team | 01:19 |
| fungi | so i'm skeptical that reclassifying, moving or removing the unofficial 1/3 will make the official 2/3 seem that much less complex | 01:21 |
| dtroyer | I think you are right there | 01:21 |
| fungi | also concerned that we'll invest substantial (and increasingly valuable) community resources trying to implement any "solution" here will no real way to measure its efficacy | 01:21 |
| fungi | s/will/with/ | 01:22 |
| dtroyer | maybe the resources should go in to separating the notion that the repos hold any useful information like this, I'd have thought that merging stackforge into openstack would take away the laziness of companies resource allocatiors, is there indication that has not happened? | 01:22 |
| * dtroyer is skimming the ML thread | 01:23 | |
| fungi | there are easy(ish) things infra can do to clarify stuff on github, which i think we'll o regardless (normalize repo descriptions there to say that they're mirrors and from where, mark any not listed in governance as "unofficial community blah blah") | 01:24 |
| dtroyer | "OpenStack Stadium" :) | 01:24 |
| fungi | i've already, at jeblair's suggestion, gone ahead and added descriptions to our github orgs themselves clarifying some of that too | 01:24 |
| dtroyer | I think showing the official status in the repo description is a great idea… | 01:28 |
| fungi | normalizing the per-project descriptions will probably come as a shock to some (probably mostly newer) teams who may view github as a marketing outlet, but will require some dev work on the manage-projects script anyway so there's time to bring it up on the ml and try to make it less of a surprise | 01:29 |
| dtroyer | The Glance thread took a turn there… | 01:32 |
| fungi | yes, also we now have a trove rewrite thread | 01:32 |
| fungi | not sure if i should be concerned or encouraged that trove bounced from "we're in maintenance mode" to "let's rewrite this from scratch" | 01:33 |
| dtroyer | I saw that. I think that really should just be essentially a new project. but what I am wondering is if there are no production deployments (of any size anyway) what is the demand for the project? | 01:33 |
| fungi | in a matter of a couple months | 01:33 |
| dtroyer | exactly | 01:34 |
| fungi | i find the claim of no production deployments dubious, but maybe the providers offering the trove api aren't actually running trove? | 01:34 |
| fungi | i mean, infra and the foundation are making extensive use of trove database instances provided by rackspace in more than one region and were talking to vexxhost about getting it available there as well | 01:35 |
| dtroyer | this (threatening the future of a project or support app) has become the de facto way for people to speak up, I don't like that precedent, but it seems to work | 01:36 |
| fungi | gerrit, etherpad, paste, storyboard, openstackid.org, www.openstack.org and lots of other stuff are using trove | 01:36 |
| dtroyer | I don't know if rax is actually using Trove. They have a history if doing their own thing... | 01:36 |
| fungi | right, i have a suspicion that's the case there | 01:37 |
| dtroyer | yeah, but all of those things could also just use a self-built VM image containing the mysql that you want inside. do they use tham in a way via the Trove API to set that apart? | 01:37 |
| fungi | however, whatever they're using at rax does implement the trove api enough that troveclient works with it | 01:37 |
| dtroyer | I'd imagine it is your ansible/puppet bits that have that stuff in them | 01:38 |
| fungi | nah, we're not tying any automation into the trove api (yet at least) so _could_ manage mysql clusters on top of dedicated virtual machines, though the resizing capabilities are nice | 01:38 |
| dtroyer | I suspect that is the case for many of the actual Trove deployments. the comments in the thread about just using heat seem to point that way too | 01:39 |
| fungi | but could get that relatively easily by sticking the db files on cinder volumes and detaching/reattaching to replacement nova instances too | 01:40 |
| fungi | and adjusting a cname in dns | 01:40 |
| fungi | also, maintaining our own db servers would make it easier to secure (rackspace puts them all on a flat network with no packet filtering so any tenant can reach any trove instance if they know the ip address), would make our remote backups easier (their backup solution stores snapshots into the same region), and would allow us to apply more sane configuration (they apply nonstandard defaults that have a | 01:44 |
| fungi | significant performance impact on some of our applications) | 01:44 |
| dtroyer | sounds like a trove-lite VM/baremetal image with sane defaults and security config plus some sysadmin tooling would work well then? | 01:46 |
| fungi | we have workarounds for all those issues (not publishing the dns names of our databases, copying mysqldumps to other regions, maintaining "custom" configuration which reflects mysql upstream defaults) but they're unfortunarte | 01:47 |
| fungi | unfortunate | 01:47 |
| fungi | well, we have several former mysql devs on the team, so our options are pretty vast. but yes a trove-of-your-own would probably suffice too | 01:48 |
| fungi | on the glance situation, i'm not sure what to make of it yet. it does seem like since splitting from nova it spent a few years with a glut of developer bandwidth cramming in features with less regard for long-term maintainability of the codebase, and have (over the past couple years if you ask me) fallen below the necessary team size to deal with what's already there | 01:56 |
| fungi | i probably have a slightly skewed perspective there, having dealt with the vmt end of things with vulnerabilities reported on incomplete features which made it into releases without the necessary security measures to make them safe for actual production use | 01:59 |
| dtroyer | I've not looked at the service code in a while (years) but if it is still like the client lib, I think we have a better case for a replacement there than trove. how long before we get an Image API backed directly by Ceph? | 02:00 |
| fungi | well, also they're far from the only team under vulnerability management which is unable to focus on long-standing security issues, but it is one of my main concerns for them | 02:03 |
| fungi | and code complexity definitely exacerbates that situation | 02:03 |
| fungi | dtroyer: thanks for an engaging tc office hour! hopefully we'll get an increasing number of attendees in this slot over time | 02:05 |
| fungi | next tc office hour: 15:00 utc thursday | 02:06 |
| dtroyer | thanks for the update pointers fungi. catching up can be a firehose at times | 02:06 |
| fungi | you ain't kiddin' | 02:06 |
| *** emagana has joined #openstack-tc | 05:04 | |
| *** emagana has quit IRC | 05:17 | |
| *** jpich has joined #openstack-tc | 07:24 | |
| *** emagana has joined #openstack-tc | 07:29 | |
| *** emagana has quit IRC | 07:33 | |
| *** cdent has joined #openstack-tc | 11:37 | |
| *** purplerbot has joined #openstack-tc | 11:48 | |
| flaper87 | ttx: I just read this message, was traveling but yeah, thanks :) | 12:14 |
| *** cdent has quit IRC | 12:14 | |
| flaper87 | gosh, you guys have been talking :D | 12:15 |
| * flaper87 should look into this channel more often | 12:15 | |
| flaper87 | do we have an ics for office hours? Are they part of the openstack ics ? | 12:17 |
| flaper87 | should they be? | 12:17 |
| flaper87 | I guess we can edit the tc-meetings cal to add them | 12:17 |
| ttx | The current ics is rather strict about what channels it advertises | 12:18 |
| flaper87 | mmh, looking into irc-meetings | 12:19 |
| ttx | We could fix that, though. Or have another ics for random channels | 12:19 |
| flaper87 | I think we can just change the channel in that yaml | 12:19 |
| flaper87 | can't we ? | 12:19 |
| ttx | flaper87: no, validation checks that you're using #openstack-meeting* | 12:19 |
| flaper87 | ah, sorry, now I know what you meant | 12:19 |
| flaper87 | lemme check if I can change that | 12:20 |
| flaper87 | like, just add an exception for -tc | 12:20 |
| ttx | It's actually convenient to check for holes (just check how many meetings already happen) | 12:20 |
| ttx | flaper87: that was proposed in the past and rejected (by me actually) for that reason ^ | 12:20 |
| ttx | Three solutions -- create a separate calendar for "other stuff in the calendar", or just relax the rules and abandon the idea of easily finding empty slots in the "official" channels, or just say meetigns can happen anywhere logged | 12:22 |
| ttx | I was leaning towards the latter, which would remove most of the need to find "empty slots" | 12:22 |
| ttx | The main drawback being you can't get as easily pinged from random channels | 12:22 |
| flaper87 | So, I'd honestly start by adding openstack-tc for now and then have follow-up changes to remove the need for meeting channels | 12:22 |
| ttx | (or catch a mention in a random meeting) | 12:23 |
| flaper87 | because as much as I like the latter, we'll need some discussion on it | 12:23 |
| ttx | flaper87: that feels a bit... abusive since we rejected other's office hours in the past :) | 12:23 |
| flaper87 | oh, ok. I didn't know we had rejected other office hours in the past | 12:23 |
| flaper87 | then, lemme start the conversation upstream | 12:23 |
| flaper87 | s/upstream/ML/ | 12:24 |
| ttx | flaper87: there was an old thread about that somewhere | 12:24 |
| ttx | last time people complained about lack of empty slots | 12:24 |
| ttx | The main objections to just letting people meet anywhere are: | 12:24 |
| ttx | - how do we ensure the channel is logged/accessible | 12:24 |
| ttx | - we won't catch random mentions of our name as easily anymore | 12:25 |
| ttx | - might create a pile-up of meetings at peak times rather than force them to spread around | 12:25 |
| ttx | - increases silo effect | 12:25 |
| ttx | Main benefits being: | 12:26 |
| ttx | - No more scheduling nightmare | 12:26 |
| *** bauzas has quit IRC | 12:26 | |
| ttx | - More flexibility in listing things in the calendar | 12:26 |
| ttx | flaper87: so if you start another one, be sure to mention that history, will avoid peopleto repeat themselves ^ | 12:27 |
| flaper87 | yes | 12:27 |
| flaper87 | thanks for the recap | 12:28 |
| flaper87 | I'll try to also propose new solutions | 12:28 |
| flaper87 | rather than just saying: "So, ideas?" | 12:28 |
| ttx | I'd say as we move to more random meetings and offcie hours, the benefits start to outweigh the drawbacks | 12:28 |
| flaper87 | because it'd be cool to finally find a solution here | 12:28 |
| flaper87 | right, that's my feeling too | 12:28 |
| flaper87 | also, I think we can improve meetbot to do some checks for us as far as logging goes | 12:29 |
| ttx | We might want to crosscheck eavesdrop logging is set up for the channels specified in irc-meetings | 12:29 |
| ttx | i.e. as a gate test | 12:29 |
| flaper87 | ttx: you read my mind | 12:29 |
| flaper87 | :) | 12:29 |
| ttx | About pile up of meetings... We could still signal somehow that this is a very busy slot and you should consider moving elsewhere | 12:29 |
| ttx | but I suspect that when a team picks a time, it looks up for team members conflicts anyway | 12:30 |
| ttx | so it might be a non-issue, especially as we are no longer in, explosive growth phase | 12:30 |
| flaper87 | Also, the pile-up of meetings might resolve itself. If you schedule your meeting in a slot where some of the participants have conflicts, you may end up just moving it | 12:32 |
| flaper87 | well, that's an optimistic thought | 12:32 |
| ttx | right, that's what I meant. It still prioritizes current attendees vs. prospective ones, but meh, might be an acceptable compromise | 12:34 |
| *** bauzas has joined #openstack-tc | 13:24 | |
| *** hongbin has joined #openstack-tc | 14:20 | |
| *** emagana has joined #openstack-tc | 14:42 | |
| *** marst has joined #openstack-tc | 14:55 | |
| *** emagana has quit IRC | 15:03 | |
| *** emagana has joined #openstack-tc | 15:20 | |
| *** emagana has quit IRC | 15:25 | |
| *** emagana has joined #openstack-tc | 15:27 | |
| *** Rockyg has joined #openstack-tc | 15:41 | |
| *** jpich has quit IRC | 16:56 | |
| *** emagana has quit IRC | 17:27 | |
| *** emagana has joined #openstack-tc | 17:40 | |
| *** Rockyg has quit IRC | 18:17 | |
| *** marst has quit IRC | 18:27 | |
| *** marst has joined #openstack-tc | 18:28 | |
| *** emagana has quit IRC | 19:02 | |
| *** emagana has joined #openstack-tc | 19:02 | |
| *** emagana has quit IRC | 19:07 | |
| *** emagana has joined #openstack-tc | 19:17 | |
| *** emagana has quit IRC | 20:18 | |
| *** emagana has joined #openstack-tc | 20:24 | |
| *** emagana has quit IRC | 20:28 | |
| *** emagana has joined #openstack-tc | 21:28 | |
| *** marst has quit IRC | 22:33 | |
| *** emagana has quit IRC | 22:34 | |
| *** sdague has quit IRC | 23:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!