18:01:21 <mfisch> #startmeeting Openstack Operators
18:01:22 <openstack> Meeting started Wed Dec 17 18:01:21 2014 UTC and is due to finish in 60 minutes.  The chair is mfisch. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:25 <openstack> The meeting name has been set to 'openstack_operators'
18:01:44 <mfisch> anyone here for the ops meeting?
18:01:46 <gfa> whoa, help included
18:01:47 <mdorman> o/
18:01:49 <mfisch> I suspect it may be quiet
18:01:52 <jlk> o/
18:01:57 <xavpaice> o/
18:01:59 <jlk> Here, while in a work stand up.
18:02:06 <gfa> here
18:02:07 <mfisch> welcome
18:02:08 <dvorak> here
18:02:17 <retr0h> here
18:02:27 <mfisch> the agenda is here: https://etherpad.openstack.org/p/openstack-operators-meeting-171214-agenda
18:02:44 <mfisch> I'd actually like to cover the mid-cycle meetup first
18:03:08 <mfisch> Unless Tom is here, the info I have from last week is that Tom working to schedule it now
18:03:15 <mdorman> cool
18:03:17 <mfisch> Does anyone have anything more firm on a date and time?
18:03:35 <mfisch> (that info is from Dec 9)
18:03:45 <xavpaice> is there a location?
18:03:49 <mfisch> not that I've heard
18:04:03 <mfisch> I will email Tom and poke him again
18:04:24 <mdorman> ask him to post on operators list if they still need a venue.  if htat’s needed, i may see if we can host it in phoenix
18:04:37 <gfa> i never went to a mid-cycle, is it better than summit? as an op
18:04:46 <xavpaice> I'd offer in New Zealand but it's a bit far
18:04:57 <mfisch> wfm but probably not my travel dept
18:05:06 <mfisch> #action mfisch to email Tom Fifeld (sp) and figure out when the ops midcycle meet up is
18:05:14 <mfisch> I'll just CC the list
18:05:20 <mdorman> cool
18:05:41 <mfisch> #topic sample config files
18:06:02 <mfisch> did anyone participate in the discussion yesterday that happened in the cross-project meeting?
18:06:19 <mdorman> i did
18:06:20 * harlowja a little
18:06:24 <mfisch> I also did
18:06:28 <mdorman> kris was sorta there
18:06:46 <mfisch> so I believe that the outcome was that devs know its a problem for us and are actively investigating/proposing solutions
18:06:51 <mfisch> but that no final agreement was reached
18:07:10 <jlk> I watched it, but didn't catch everything.
18:07:18 <mfisch> #link http://eavesdrop.openstack.org/meetings/crossproject/2014/crossproject.2014-12-16-21.01.log.txt
18:07:23 <mdorman> yeah i think the outcome is that someone was going to reply to the operators thread with some potential solutions.  to get a feeling for what people prefer
18:07:26 <jlk> there was desire to define a way to easily generate the docs, that's common across all the projects
18:07:36 <mfisch> I believe fungi owns the action
18:07:41 <mdorman> right
18:08:04 <mfisch> and that he's going to start the converstion on the ops list as well, I know many of us do not subscribe to dev
18:08:04 <fungi> yep, i will
18:08:19 <fungi> full plate, but hopefully later today
18:08:30 <mfisch> I have to say personally that this issue has come a long way since the bug I commented on wrt this was summarily closed
18:08:58 <mfisch> anything else on this mdorman or klindgren ?
18:09:10 <mfisch> (i'd suggest reading the minutes for the first half of that link)
18:09:13 <mdorman> don’ think so.  we’re happy with the progress as well
18:09:26 <mdorman> at least the discussion is happening
18:09:27 <fungi> in fairness, bugs opened without actionable solutions are often summarily closed. that doesn't mean they're non-negotiable and can't be reopened
18:09:28 <harlowja> i'd hopefully be able to propose another idea, but i'll wait for the ML proposal thread ;)
18:09:51 <klindgren> the only other hting - is I would like to not use tox do to do that generation
18:09:51 <mfisch> I'm okay with many options, I dont usually want to make pain for the devs
18:10:05 <klindgren> but if tox is jsut calling a script - I can call the script as well
18:10:13 <harlowja> pain for devs is ok, lol
18:10:24 <jlk> tox is doing things inside a venv which helps keep the systme from getting dirty
18:10:27 <mfisch> whats the reason for no tox? I know I have mine
18:10:40 <dvorak> seems like ideally the sample config files would both get generated the same way, and done centrally so everyone doesn't have to do it themselves.
18:10:47 <retr0h> mfisch: tox keeps things clean in venv
18:10:54 <klindgren> because tox install all the requirements for the service into a venv
18:11:04 <fungi> i get the impression the main use case for not doing it under tox is so that the version you generate locally on your server only has the relevant options based on the versions of libraries you have installed
18:11:11 <klindgren> and the versions tox installs via pip probably wont match what is installed on the system
18:11:39 <klindgren> fungi, exactly
18:11:42 <fungi> however, if we ship sample configurations from upstream, our ci will likely generate them under tox just because that's simple. we can still make sure tox isn't required
18:11:42 <mfisch> I dont quite understand the scope of the libraries problem, how many config options come from libs?
18:11:44 <mgagne> fungi: for such use cases, if you would override requirements.txt with your own pinned versions, that would be great
18:11:46 <xavpaice> in that way, tox is independant of the distro - isn't that a good thing?
18:12:07 <mgagne> mfisch: oslo.db, oslo.messaging?, keystonemiddleware
18:12:39 <mfisch> thx
18:12:40 <jlk> if there is concern about generated docs not matching system, that's definitely an argument against upstream providing pre-generated docs
18:12:46 <fungi> xavpaice: independent of the distro is a good thing if your services you're configuring are also independent of the distro
18:13:04 <mfisch> jlk: there's also value for me in seeing changes over time
18:13:09 <mgagne> xavpaice: looks to not be a good thing if your distro has older versions of libs than the ones found on pip, you won't have a sample config file fitting *your* environment
18:13:31 <klindgren> I would say you *might* not
18:13:45 <klindgren> I dont have a handle on how bad it would/could be...
18:13:49 <xavpaice> I thought requirements.txt can be set to specific versions - in which case we set a min supported version there
18:13:54 <jlk> can tox be taught when making the venv to include system libraries when possible?
18:13:58 <mfisch> klindgren: is your use case more package building? thats a bit different from mine
18:14:00 <xavpaice> doesn't help if newer versions change things though
18:14:04 <fungi> right, the point being that if you regenerate samples yourself then you have the option to generate them in the environment you're configuring, rather than using samples generated in an abatract/artificial environment disconnected from your deployment
18:14:06 <dvorak> so sounds like there are two issues, first being generating reference level configs and config docs for specific releaes (plus probably master), and the other being able to easily generate sample config files for specific environments
18:14:17 <mfisch> agreed
18:14:20 <mgagne> I think we have 2 or 3 use cases: those running against distro lib versions, ones running against trunk, ones running against pinned versions of libs
18:14:36 <harlowja> an idea; why haven't people thought that configs shouldn't change between major versions of packages?
18:14:58 <mgagne> harlowja: when should they change then?
18:15:07 <harlowja> *sorry in-between major versions
18:15:10 <jlk> harlowja: wouldn't that effectively prevent /any/ changes from config files happening?
18:15:11 <jlk> ah
18:15:13 <harlowja> they can change in the next major versions
18:15:15 <fungi> the third thing which was brought up was an ability to see how the samples change over time, though i'm not sure that's 100% tractable since it's nonlinear/branching depending on library releases not tied to the application being configured
18:15:17 <retr0h> don't think we started the meeting btw
18:15:23 <openstack> retr0h: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
18:15:26 <mfisch> I did it
18:15:30 <retr0h> or maybe we did :)
18:15:31 <mfisch> retr0h: I started it
18:15:40 <retr0h> mfisch: awesome - ignore me
18:15:44 <harlowja> jlk example, configs don't change for oslo.messaging in oslo.messaging 1.0 -> 1.999 (for example)
18:15:46 <xavpaice> it would be good to see changes in the configs, for when we upgrade packages
18:15:58 <mfisch> yes
18:15:58 <harlowja> just as u wouldn't expect an API to change, configs are somewhat like an API
18:16:05 <xavpaice> +1
18:16:22 <jlk> harlowja: I can buy that, if we're talking about "not changing in stable/juno"
18:16:30 <xavpaice> usually the release notes are pretty good in that respect
18:16:40 <harlowja> depends, oslo libraries don't really have stable/juno, but have version numbers
18:16:42 <mgagne> Should a git repository be the only place/reference for those sample config files? We have a matrix of possibilities. I don't see git answering this need if we have a plethora of combinaison.
18:16:44 <fungi> harlowja: definitely a topic for the oslo team to spearhead. i'm not at all opposed to option stability
18:16:46 <jlk> but for versions that are essentially "next release" that could be different, or the other thing will happen, the version nubmers will just change more frequently.
18:16:56 <dvorak> to clarify, they shouldn't change in a non-backwards compat way.  You can clearly introduce new options w/o breaking things in some cases.
18:16:58 <mfisch> I think lots of operators are not using stable branches
18:17:00 <harlowja> fungi it seems to be they would self-stabalize over time anyway
18:17:04 <xavpaice> I'm OK with adding new items, just not changing/deprecating existing items except on a major version change
18:17:08 <harlowja> fungi and this whole thing might be mute...
18:17:13 <mgagne> mfisch: I'm using stable branches =)
18:17:19 <fungi> harlowja: one can only hope, but we seem to grow wider faster than we grow higher
18:17:36 <harlowja> stop eating so much icecream!
18:17:36 <harlowja> lol
18:17:59 <harlowja> *wider faster joke...
18:18:12 <mfisch> okay so we should wrap this topic up. I think my advice would be to clearly state the use case you have in the TBD ML thread
18:18:13 <fungi> har
18:18:21 <dvorak> probably makes sense to concentrate on something managable to start with, I agree with fungi that this could get out of control pretty easily.
18:18:24 <mfisch> I'm not sure they all got through yesterday it was pretty noisy
18:18:54 <mfisch> anything else on this one?
18:18:56 <dvorak> personally I'd be happy to just see reference level sample configs for each project release + master
18:19:06 <fungi> dvorak: yeah, so my plan is to outline the discussion so far and request use cases to go along with any preferences people are indicating
18:19:12 <dvorak> wfm
18:19:14 <klindgren> someone else mentioned having config files for libs
18:19:33 <mgagne> klindgren: that's the main pain point of sample config files in tree
18:19:54 <klindgren> mgagne, this was more like oslo.db has its own ocnfig file
18:19:56 <alop> gah, sorry I'm late
18:20:10 <klindgren> so nova/neutron config doesn't change based upon included libs
18:20:27 <klindgren> up version of included libs*
18:20:29 <mgagne> klindgren: "the resulting content of a sample config file highly depends on the installed versions of those libraries."
18:20:30 <fungi> right, i think if there are good software development reasons to switch that model then they will be likely to happen, but don't want to have the tail wagging the dog where configuration defines software rather than the other way around
18:21:11 <xavpaice> would be nice to reduce some of the duplication between config files though
18:21:21 <klindgren> mgagne, right - for those options that come from librarys.
18:21:38 <klindgren> BUt no reason why nova couldn't keep up a nova.conf that has everything specific to nova in it
18:21:49 <gfa> i bet the version change in oslo.db will only change the options related to db, so the rest of the config file is 'static' for a fixed version of nova/neutron
18:21:58 <klindgren> right
18:22:06 <klindgren> gfa ^^ exactly
18:22:11 <mfisch> a nova.conf that had all the nova specific stuff would help
18:22:23 <gfa> so projects can ship all the config file but db, options
18:22:27 <mfisch> I mean it would solve most if not all of the things I've dug into in the past year
18:22:31 <alop> Isnt' that what the configuration reference is for?
18:22:49 <fungi> again, that's software design issues, so out of scope for the sample config publishing discussion, but definitely something good to talk to the oslo devs about
18:22:53 <mgagne> true, if we could have an online tool to generate the config file of the project and then you could select the lib versions you have and then combine the resulting configs.
18:23:09 <alop> I don't look at sample configs, specificaly because they are bad, I rely on the reference on the docs site
18:23:10 <jlk> that sounds.... fragile
18:23:18 <klindgren> eitherway - someone brought it up on the cross-project discussion
18:23:30 <klindgren> so I was jsut brining up here as well
18:23:38 <klindgren> bringing*
18:24:12 <mfisch> next topic?
18:24:16 <mfisch> or do we have more here
18:24:35 <alop> next
18:24:41 <mfisch> skipping around again
18:24:44 <mfisch> #topic mailing list
18:25:11 <mfisch> I've noticed since I joined the ML that we still get some traffic thats essentially people who've never used openstack before.
18:25:20 <mfisch> Does that belong on our ML and is it at a problem level?
18:25:34 <alop> I think we get CC'd a lot
18:25:49 <mdorman> personally i don’t think it’s an issue at this point
18:25:49 <alop> like, people write to openstack@lists, and openstack-operators, etc
18:25:53 <alop> yeah
18:25:55 <mfisch> ok
18:26:05 <mfisch> it has been quieter in terms of those messages, so moving on!
18:26:09 <mfisch> #topic packaging
18:26:12 <xavpaice> I think the traffic level on the list is still pretty low, and if we need can can always gently direct people to the right ml
18:26:15 <mdorman> i just try to not respond to stuff that’s not appropriate for the list
18:26:44 <mfisch> re packaging: There was some ML Threads about packaging coming out of the paris discussions
18:26:55 <alop> I actually think it's a great forum, because we're the ones who may likely have the answer
18:27:41 <dvorak> alop: nod, I think mfisch is talking about the "my first openstack" questions that come along occassionally.
18:27:41 <mfisch> I'm not sure what the next steps are or if anyone is working on it
18:27:46 <gfa> yes we may have the anwser, but IMO if you don'y know MTU you should not be doing openstack+gre
18:28:00 * mfisch reverts the topic
18:28:04 <alop> sorry
18:28:07 <alop> packaging
18:28:07 <mfisch> np
18:28:14 <mfisch> this is my first meeting
18:28:28 <xavpaice> re packaging, I wasn't at Paris, but I'm keen to be involved
18:28:32 <alop> so, I missed the convo in Paris (stuck in the nova thing)
18:28:43 <mfisch> the tl;dr was that lots of us are packaging
18:28:45 <xavpaice> it seems to me there's a bunch of people making packages
18:28:48 <mfisch> and we're all using different tools
18:29:11 <alop> and we want to make blessed generic packages?
18:29:15 <mfisch> we're using Jenkins debian glue I know klindgren uses anvil
18:29:23 <harlowja> + yahoo + cray
18:29:42 <mfisch> anvil sounds awesome except we dont use RHEL or its cousins
18:29:45 <xavpaice> we use ubuntu's tools, but with our own repos (stable + selected patches)
18:30:02 <harlowja> mfisch ya; i'll avoid the diving deep into anvil, but its not designed just for RHEL :)
18:30:05 <mgagne> I feel that most distro tools feel like a huge Rube Goldberg machine. And I feel the need to simplify it a bit to fit my own particular needs
18:30:45 <mfisch> There's also the philosophy argument. A guy from Redhat and to some extent the debian guy on the ML (who's name I cannot remember) both were wondering why ops are doing packaging
18:31:04 <harlowja> meh
18:31:04 <mgagne> Thomas Goirand it is
18:31:10 <mfisch> The resistance is duplication of effort and for some folks support issues I guess
18:31:11 <xavpaice> that's a good point though
18:31:19 <alop> because, both of those entities are slow to deliver changes upstream
18:31:25 <mfisch> absolutely
18:31:38 <xavpaice> we package cos we don't want to wait for distro packages to arrive
18:31:42 <mgagne> true
18:31:44 <klindgren> That and I have my own patches that I need ot run with as well
18:31:47 <dvorak> also, I don't really want my openstack services to be directly tied to the version of my operating system, which is kind of the case today with ubuntu
18:31:47 <klindgren> to*
18:31:51 <mgagne> The distro tools also don't answer our need to fork a project and apply our own custom patches.
18:31:55 <klindgren> plus they drop support for stuff
18:32:01 <klindgren> like juno is RHEL7 only
18:32:05 <mfisch> even if the distro packages the day it lands in a backport you might have 2 weeks to get it there
18:32:25 <klindgren> iirc Ubuntu dropped havana support at 2013.2.3?
18:32:29 <xavpaice> yup
18:32:29 <dvorak> mfisch: and you may have to take some other patch that you don't want.
18:32:34 <mfisch> yeah
18:32:40 <alop> Case in point, You find a bug, you report, you even submit a patch for it. The community may debate it for 6 months, meanwhile, your production is broken
18:32:42 <mfisch> nor do I have time to look at all the changes that come in the new package
18:32:50 <dvorak> lack of granulaity is a big issue, aside from speed and local patches
18:32:50 <mfisch> alop: thats absolutely happened here
18:32:55 <alop> here too
18:33:00 <klindgren> here too
18:33:02 <harlowja> that sounds impossible
18:33:03 <harlowja> haha
18:33:03 <mfisch> After upstream ignored it for 3 weeks it landed, then they ignored my backport for 4 more weeks.
18:33:18 <mdorman> i feel like we all generally understand the reasons for doing our own patching
18:33:18 <klindgren> backports are a *PAIN*
18:33:19 <xavpaice> I suspect that's why we all do our own packages
18:33:24 <mfisch> agreed
18:33:25 <mgagne> xavpaice: yep
18:33:28 <jlk> yeah
18:33:35 <jlk> every place I've seen does their own fashion of packages
18:33:47 <mfisch> so the paris talk was basically is there a way we can share what we do better?
18:33:48 <jlk> either actual OS packages, or python venvs, or containers using one or the other.
18:34:13 <xavpaice> so the barrier to package tools being more generic for us is the differences between RHEL based distros and Debian based?
18:34:29 <mgagne> I don't mean to diminish the work of Thomas but he kind of missed the point about *our* needs as operators
18:34:47 <dvorak> mgagne: and was a bit rude
18:34:49 <harlowja> xavpaice i'll just throw this out there (https://review.openstack.org/#/c/87875/ was a start of debian buliding for anvil; its not impossible...)
18:35:05 <mfisch> mgagne: agreed, we're not competing with debian, we have different needs
18:35:20 <dvorak> mfisch: I'd think common tooling would be the biggest thing.  We're all going to have local packages at different times
18:35:39 <mgagne> dvorak, mfisch: I can understand his frustration and need to vent but there was no opening about actually understanding our needs and answering it
18:35:44 <xavpaice> harlowja: I'll have to read that in detail :)
18:35:48 <mfisch> even common for ubuntu would help, sounds like most RHEL derivatives just use anvil
18:35:57 <harlowja> xavpaice also https://github.com/stackforge/anvil/commit/d435f548276 which adds venv building to anvil
18:36:06 <harlowja> *or at least the start of that building...
18:36:21 <dvorak> we use jenkins debian glue, and it seems better than using the native tools it wraps, but it's still a pain in the butt
18:37:08 <mfisch> So broadly I'd like to propose that we resurrect this discussion on the mailing list with the goal of setting an agenda/goal/etc for the mid-cycle meetup
18:37:18 <xavpaice> our changes to the ubuntu packages are so minor, that we can just use the source packages, and rebuild with our forked repo - easy for us but not particularly transportable
18:37:19 <mgagne> furthermore, we might have completely different philosophy around compat and versioning requirements. Installing in a venv is fine for some operators, it's not for Debian/Ubuntu/RHEL.
18:37:21 <harlowja> mfisch +1
18:37:41 <dvorak> xavpaice: that's basically what we're doing also, plus git-upstream
18:37:48 <mfisch> xavpaice: do you pull from upstream ubuntu for the debian/ folder when you do updates or just fork it once?
18:37:54 <mdorman> sounds like a good plan mfisch
18:37:55 <gfa> xavpaice +1
18:37:58 <xavpaice> regular plans
18:38:03 <xavpaice> s/plans/pulls
18:38:44 <xavpaice> I was playing with applying extra patches via quilt but it was hard to maintain
18:38:56 <mgagne> xavpaice: it's awful
18:38:57 <gfa> i would like to share backports, i don't have many for icehouse but i had more in havana time
18:39:03 <mgagne> xavpaice: that's my current workflow
18:39:14 <jlk> I really feel that any established environment is going to have a system already in place to manage patches
18:39:15 <gfa> i would like to see a dump-your-backport repo
18:39:15 <xavpaice> our devs in house use our copy of the upstream repo and add their own patches, but if quilt adds stuff they don't see it's hard to test properly
18:39:19 <jlk> and convergence is going to be... hard
18:39:28 <mgagne> xavpaice: even with gbp-pq
18:39:46 <jlk> RAX public cloud has one thing, rax private cloud has another, Blue Box has one (two), etc.. etc...
18:40:03 <dvorak> jlk: well, people come to it on their own terms, or stick with what they have.  the problem right now is that there isn't anything but completely canned packages or roll your own.  something in the middle might be nice
18:40:19 <jlk> yeah, that's just hard to do without strong opinions
18:40:19 <mgagne> jlk: goes to show that nobody feels the existing solutions answer their needs
18:40:22 <mfisch> The goal of operators was not to bless a one true way of doing anything like packaging but instead to share
18:40:37 <jlk> mgagne: many of the solutions are made behind closed doors to satisfy a product before being made public
18:40:45 <mfisch> take someone's elses work flow and fork it for your needs
18:40:51 <jlk> yeah
18:40:57 <mgagne> jlk: hehe, devs/operators' life
18:41:32 <mfisch> for packaging that might mainly be documenting stuff in a wiki or blog post rather than writing a new tool. It might also be  contributing your enhancements to whatever your upstream is
18:41:51 <jlk> I agree it would be nice to point at $something as a framework for consuming upstream source, adding in downstream changes, and producing an artifact at the end.
18:42:12 <jlk> queue fight over who's existing $thing becomes the reference.
18:42:19 <mfisch> agreed
18:42:26 <mgagne> jlk: true, those are the main challenging when starting packaging, there is no true reference/tutorial
18:42:29 <xavpaice> a wiki with some discussion of options and how others have achieved their goal would be good though
18:42:40 <jlk> superuser articles perhaps
18:42:41 <xavpaice> leaves the reader to make their own decision, but with information
18:42:42 <mfisch> sounds like an action is brewing
18:42:47 <alop> jlk: I was just thinking that
18:42:49 <jlk> on how each provider is managing their downstream changes and artifacts.
18:42:50 <dvorak> jlk: I'd be interested in just hearing what other people are doing at this point.  I know anvil sounds like it works well for a lot of people, but I don't know the workflow, pain points, etc.
18:43:12 <klindgren> I want to hear from someone using giftwrap as well
18:43:18 <mfisch> the best part of the conference is going to a CI discussion and realizing hey we're not totally off base on the made up way we use
18:44:03 <mfisch> any preference for wiki vs superuser (blog) in this?
18:44:11 <mfisch> we could always start with blog and migrate the info or vice-versa
18:44:20 <xavpaice> can anyone write a superuser article?
18:44:29 <mgagne> xavpaice: everyone should IMO
18:44:30 <mfisch> well they let me do it, so yeah
18:44:53 <xavpaice> just wondering if there's a barrier, like being a foundation member, or a certain size of deployment, etc
18:44:57 <mgagne> xavpaice: as there won't be one tool to show/explain
18:45:10 <jlk> I don't think there is a barrier
18:45:19 <mfisch> no barrier
18:45:28 <xavpaice> excellent, suits me then
18:45:36 <mfisch> xavpaice: ping me and I'll get you a name where you can get more info
18:45:44 <xavpaice> thanks
18:46:03 <xavpaice> maybe I should just chat to tom?
18:46:07 <mfisch> #action everyone to document their packaging process for sharing purposes
18:46:20 <mfisch> xavpaice: allison@openstack.org
18:46:36 * xavpaice thanks mfisch
18:46:47 <mfisch> okay final topic
18:46:54 <mfisch> by fiat I have cancelled the meeting on Christmas day
18:47:01 <jlk> +1
18:47:23 <mfisch> I wont be around much on new years eve either
18:47:29 <mfisch> so I'm voting to cancel that too
18:47:38 <xavpaice> +1
18:47:40 <mdorman> i think that’s reasonable
18:47:59 <mfisch> see you guys on Jan 7 then
18:48:00 <mfisch> anything else?
18:48:22 <mdorman> can you make a note to announce the next meeting a few days ahead on the ML?
18:48:36 <mfisch> yes. Was yesterday's announce too late?
18:48:37 <xavpaice> did we want to discuss the shared ops tools discussion on the ML?
18:48:45 <mdorman> mfisch: no that was fine
18:48:53 <mfisch> yes, lets do that xavpaice
18:48:57 <mfisch> xavpaice: can you kick off the convo?
18:49:18 <xavpaice> the tl;dr was that we all have tools for things like monitoring, graphs, etc
18:49:31 <xavpaice> there's a github for sharing some of these, but not much content
18:49:47 <xavpaice> some discussion around stackforge and some around an official OpenStack project
18:49:54 <mfisch> xavpaice: yeah I'm not sure what the future of said repo is, I think that it might go away at some point
18:50:04 <xavpaice> I'd be sad about that
18:50:08 <mfisch> I'd like to get Michael Chapman here to follow-up on that one
18:50:14 <xavpaice> unless it moved to stackforge
18:50:36 <xavpaice> might be a bit early for him, it's not even 8 here in NZ and we're two hours ahead
18:50:55 <mfisch> I think that stackforge is the theory, I wont say plan b/c I've not heard in awhile
18:51:20 <mfisch> okay folks, see you guys back in #openstack-operators
18:51:24 <mfisch> going once...
18:51:28 <mdorman> the concern about stackforge is that you have to do gating and what not
18:52:06 <mdorman> but yeah, can follow up on that discussion later.
18:52:21 <xavpaice> cool
18:52:25 <mfisch> agreed
18:52:30 <mfisch> thanks all
18:52:32 <mfisch> #endmeeting