Wednesday, 2017-06-21

* dtroyer looks around…00:56
fungiyeah, this is "office hours"01:05
fungitwo of us this time!01:05
*** hongbin has quit IRC01:07
dtroyerwoot!  100% increase01:08
dtroyerso 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
fungicalls for the return of stackforge01:10
fungireturn of stackforge's revenge returns ii01:11
dtroyerfrom a branding standpoint that may have been better…   should we do that but not use a repo namespace?01:12
fungii 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 namespace01:13
fungiand also that anything hosted from our infrastructure is officially part of openstack01:13
dtroyerare there non-apochryphal instances of that actually happening (thinking that, not doing it)?01:14
dtroyerthe install part, not just the assumption that it is all official01:14
fungithis is mostly second-hand from the foundation marketing team, i think01:14
fungiwell, 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
fungis/cloudstack/whatever's hot right now/01:16
fungittx 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 options01:18
dtroyerI can see the difficulty in understanding what things are01:18
fungilike, 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 cetera01:18
fungiright now ~1/3 of the non-retired repositories we're hosting aren't under any official team01:19
fungiso i'm skeptical that reclassifying, moving or removing the unofficial 1/3 will make the official 2/3 seem that much less complex01:21
dtroyerI think you are right there01:21
fungialso concerned that we'll invest substantial (and increasingly valuable) community resources trying to implement any "solution" here will no real way to measure its efficacy01:21
dtroyermaybe 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 thread01:23
fungithere 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
fungii've already, at jeblair's suggestion, gone ahead and added descriptions to our github orgs themselves clarifying some of that too01:24
dtroyerI think showing the official status in the repo description is a great idea…01:28
funginormalizing 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 surprise01:29
dtroyerThe Glance thread took a turn there…01:32
fungiyes, also we now have a trove rewrite thread01:32
funginot 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
dtroyerI 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
fungiin a matter of a couple months01:33
fungii find the claim of no production deployments dubious, but maybe the providers offering the trove api aren't actually running trove?01:34
fungii 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 well01:35
dtroyerthis (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 work01:36
fungigerrit, etherpad, paste, storyboard,, and lots of other stuff are using trove01:36
dtroyerI don't know if rax is actually using Trove.  They have a history if doing their own thing...01:36
fungiright, i have a suspicion that's the case there01:37
dtroyeryeah, 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
fungihowever, whatever they're using at rax does implement the trove api enough that troveclient works with it01:37
dtroyerI'd imagine it is your ansible/puppet bits that have that stuff in them01:38
funginah, 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 nice01:38
dtroyerI 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 too01:39
fungibut could get that relatively easily by sticking the db files on cinder volumes and detaching/reattaching to replacement nova instances too01:40
fungiand adjusting a cname in dns01:40
fungialso, 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 a01:44
fungisignificant performance impact on some of our applications)01:44
dtroyersounds like a trove-lite VM/baremetal image with sane defaults and security config plus some sysadmin tooling would work well then?01:46
fungiwe 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 unfortunarte01:47
fungiwell, 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 too01:48
fungion 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 there01:56
fungii 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 use01:59
dtroyerI'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
fungiwell, 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 them02:03
fungiand code complexity definitely exacerbates that situation02:03
fungidtroyer: thanks for an engaging tc office hour! hopefully we'll get an increasing number of attendees in this slot over time02:05
funginext tc office hour: 15:00 utc thursday02:06
dtroyerthanks for the update pointers fungi.   catching up can be a firehose at times02:06
fungiyou ain't kiddin'02:06
*** emagana has joined #openstack-tc05:04
*** emagana has quit IRC05:17
*** jpich has joined #openstack-tc07:24
*** emagana has joined #openstack-tc07:29
*** emagana has quit IRC07:33
*** cdent has joined #openstack-tc11:37
*** purplerbot has joined #openstack-tc11:48
flaper87ttx: I just read this message, was traveling but yeah, thanks :)12:14
*** cdent has quit IRC12:14
flaper87gosh, you guys have been talking :D12:15
* flaper87 should look into this channel more often12:15
flaper87do we have an ics for office hours? Are they part of the openstack ics ?12:17
flaper87should they be?12:17
flaper87I guess we can edit the tc-meetings cal to add them12:17
ttxThe current ics is rather strict about what channels it advertises12:18
flaper87mmh, looking into irc-meetings12:19
ttxWe could fix that, though. Or have another ics for random channels12:19
flaper87I think we can just change the channel in that yaml12:19
flaper87can't we ?12:19
ttxflaper87: no, validation checks that you're using #openstack-meeting*12:19
flaper87ah, sorry, now I know what you meant12:19
flaper87lemme check if I can change that12:20
flaper87like, just add an exception for -tc12:20
ttxIt's actually convenient to check for holes (just check how many meetings already happen)12:20
ttxflaper87: that was proposed in the past and rejected (by me actually) for that reason ^12:20
ttxThree 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 logged12:22
ttxI was leaning towards the latter, which would remove most of the need to find "empty slots"12:22
ttxThe main drawback being you can't get as easily pinged from random channels12:22
flaper87So, I'd honestly start by adding openstack-tc for now and then have follow-up changes to remove the need for meeting channels12:22
ttx(or catch a mention in a random meeting)12:23
flaper87because as much as I like the latter, we'll need some discussion on it12:23
ttxflaper87: that feels a bit... abusive since we rejected other's office hours in the past :)12:23
flaper87oh, ok. I didn't know we had rejected other office hours in the past12:23
flaper87then, lemme start the conversation upstream12:23
ttxflaper87: there was an old thread about that somewhere12:24
ttxlast time people complained about lack of empty slots12:24
ttxThe main objections to just letting people meet anywhere are:12:24
ttx- how do we ensure the channel is logged/accessible12:24
ttx- we won't catch random mentions of our name as easily anymore12:25
ttx- might create a pile-up of meetings at peak times rather than force them to spread around12:25
ttx- increases silo effect12:25
ttxMain benefits being:12:26
ttx- No more scheduling nightmare12:26
*** bauzas has quit IRC12:26
ttx- More flexibility in listing things in the calendar12:26
ttxflaper87: so if you start another one, be sure to mention that history, will avoid peopleto repeat themselves ^12:27
flaper87thanks for the recap12:28
flaper87I'll try to also propose new solutions12:28
flaper87rather than just saying: "So, ideas?"12:28
ttxI'd say as we move to more random meetings and offcie hours, the benefits start to outweigh the drawbacks12:28
flaper87because it'd be cool to finally find a solution here12:28
flaper87right, that's my feeling too12:28
flaper87also, I think we can improve meetbot to do some checks for us as far as logging goes12:29
ttxWe might want to crosscheck eavesdrop logging is set up for the channels specified in irc-meetings12:29
ttxi.e. as a gate test12:29
flaper87ttx: you read my mind12:29
ttxAbout pile up of meetings... We could still signal somehow that this is a very busy slot and you should consider moving elsewhere12:29
ttxbut I suspect that when a team picks a time, it looks up for team members conflicts anyway12:30
ttxso it might be a non-issue, especially as we are no longer in, explosive growth phase12:30
flaper87Also, 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 it12:32
flaper87well, that's an optimistic thought12:32
ttxright, that's what I meant. It still prioritizes current attendees vs. prospective ones, but meh, might be an acceptable compromise12:34
*** bauzas has joined #openstack-tc13:24
*** hongbin has joined #openstack-tc14:20
*** emagana has joined #openstack-tc14:42
*** marst has joined #openstack-tc14:55
*** emagana has quit IRC15:03
*** emagana has joined #openstack-tc15:20
*** emagana has quit IRC15:25
*** emagana has joined #openstack-tc15:27
*** Rockyg has joined #openstack-tc15:41
*** jpich has quit IRC16:56
*** emagana has quit IRC17:27
*** emagana has joined #openstack-tc17:40
*** Rockyg has quit IRC18:17
*** marst has quit IRC18:27
*** marst has joined #openstack-tc18:28
*** emagana has quit IRC19:02
*** emagana has joined #openstack-tc19:02
*** emagana has quit IRC19:07
*** emagana has joined #openstack-tc19:17
*** emagana has quit IRC20:18
*** emagana has joined #openstack-tc20:24
*** emagana has quit IRC20:28
*** emagana has joined #openstack-tc21:28
*** marst has quit IRC22:33
*** emagana has quit IRC22:34
*** sdague has quit IRC23:11

Generated by 2.15.3 by Marius Gedminas - find it at!