19:02:04 <annegent_> #startmeeting docteam
19:02:04 <openstack> Meeting started Wed Dec  3 19:02:04 2014 UTC and is due to finish in 60 minutes.  The chair is annegent_. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:07 <openstack> The meeting name has been set to 'docteam'
19:02:15 <annegent_> I'll go ahead and use "docteam" here so logs are easy to find
19:02:23 <AJaeger_> thanks, annegent_
19:02:29 <annegent_> who all is here?
19:02:32 <Sam-I-Am> hi
19:02:34 <zigo> o/
19:02:36 <AJaeger_> \o/
19:02:51 <AJaeger_> Enough to start ;)
19:02:54 <annegent_> and o/
19:02:55 <annegent_> cool
19:03:06 <annegent_> Okay, the agenda is in the mailing list post from today
19:03:38 <annegent_> #link http://lists.openstack.org/pipermail/openstack-docs/2014-December/005568.html
19:03:48 <annegent_> let's start with current status
19:03:50 <annegent_> #topic Description of current state
19:04:14 <annegent_> Lots of fact finding, I actually had to look up some stuff for this :)
19:04:24 <annegent_> So, we currently publish four Install Guides
19:04:34 <annegent_> from one directory in openstack-manuals repo
19:05:03 <annegent_> The files are automatically built and also the translation automation is in place for these.
19:05:56 <Sam-I-Am> yep
19:06:27 <annegent_> Last release, this blueprint addressed an audit of the install guides: https://blueprints.launchpad.net/openstack-manuals/+spec/installation-guide-improvements
19:06:47 <Sam-I-Am> still not finished, but pretty close.
19:06:53 <Sam-I-Am> huge amount of work
19:07:12 <annegent_> just the facts :)
19:07:43 <annegent_> oh also
19:07:50 <annegent_> #link
19:07:52 <annegent_> er
19:07:53 <annegent_> #link https://wiki.openstack.org/wiki/Documentation/InstallationGuideImprovements
19:08:20 <annegent_> The blueprint addressed "Replace openstack-config (crudini) commands with general configuration file editing."
19:09:17 <annegent_> There's a chapter about debconf output for the apt-debian version
19:09:30 <annegent_> #link http://docs.openstack.org/juno/install-guide/install/apt-debian/content/ch_debconf.html
19:09:56 <annegent_> And this one I had to look up, what's documented for DevStack?
19:10:20 <Sam-I-Am> what do you mean?
19:10:22 <annegent_> #link http://docs.openstack.org/developer/devstack/
19:10:31 <annegent_> Only Ubuntu 14.04 (Trusty), Fedora 20 and CentOS/RHEL 6.5 are documented here. OpenStack also runs and is packaged on other flavors of Linux such as OpenSUSE and Debian.
19:10:35 <annegent_> from that page ^^
19:10:48 <annegent_> I wanted to include that fact finding since Tom brought up DevStack in the thread
19:10:49 <Sam-I-Am> ahh
19:11:20 <zigo> As much as I know, what is written for Devstack in Ubuntu also works for Debian.
19:11:29 <annegent_> good to know
19:11:34 <annegent_> wasn't sure myself!
19:11:56 <annegent_> Then there are install tools documented by different companies in their own domains or doc sites
19:12:00 <zigo> There used to be a few glitches which were corrected, though it's been a long time I didn't try.
19:12:04 <annegent_> anything else relevant?
19:12:07 <annegent_> Oh I thought of one more thing.
19:12:23 <Sam-I-Am> some aspects of openstack are kernel specific (neutron comes to mind)
19:12:34 <AJaeger_> zigo: The document says that it works for Debian but that it's not documented further...
19:12:37 <Sam-I-Am> which might be why they support certain distro releases
19:12:39 <annegent_> I found this in the InstallationGuideImprovments wiki page "Modularize install guides for re-use as basic install guide for training guides.(dguitarbite/Pranav Salunke)" but I don't know how that was resolved exactly?
19:12:52 <zigo> AJaeger_: Perfect then!
19:13:11 <annegent_> because I think training plays into the goals for the install guide too, so wanted to bring that up while stating current state.
19:13:21 <annegent_> I think current state for training is "working on a blueprint?"
19:13:28 <annegent_> anyone know?
19:13:39 <AJaeger_> annegent_: they're still playing with the Install Guide, I helped them to build it only for Ubuntu, they did not profile at all
19:13:45 <Sam-I-Am> annegent_: the original idea is that the training guide would follow the install guide since it covers basic service installation
19:13:46 <annegent_> AJaeger_: ok
19:13:53 <AJaeger_> had a guide for "Debian;Ubuntu;Fedora;openSUSE" or something like that
19:13:57 <AJaeger_> That looked funny ;(
19:14:00 <annegent_> Sam-I-Am: in Paris they wanted their own chapter too
19:14:04 <annegent_> AJaeger_: heh
19:14:15 <annegent_> but I didn't know latest state there
19:14:17 <AJaeger_> Sam-I-Am: they're moving closer know
19:14:23 <AJaeger_> s/know/now/
19:14:31 <annegent_> Okay AJaeger_ was it basically a conditional but new guide?
19:14:33 <Sam-I-Am> annegent_: they could do X and get a version that meets the training guide needs (e.g., stick with neutron, not nova-or-neutron)
19:14:53 <AJaeger_> annegent_: it was our Install Guide, they just did not profile properly.
19:14:57 <annegent_> Sam-I-Am: yeah it was the mechanics of that we hadn't figured out
19:15:09 <annegent_> and those mechanics may be useful here, not real sure though
19:15:17 <annegent_> AJaeger_: ah ok
19:15:18 <Sam-I-Am> AJaeger_: last i spoke with them, they wanted a top-level guide that only includes the files they want
19:15:53 <AJaeger_> Sam-I-Am: We made some progress in Paris
19:16:05 <AJaeger_> but let's not discuss that further now
19:16:10 <Sam-I-Am> yes
19:16:17 <annegent_> ok, yeah don't want to dig too deep there, just wanted to know current state
19:16:42 <annegent_> which sounds like "training wants a certain install guide but haven't figured out how to build it yet"
19:16:43 <annegent_> yeah?
19:16:51 <Sam-I-Am> pretty much
19:16:56 <AJaeger_> yep
19:17:09 <annegent_> Okay let's move into stated goals then. I did some etherpad digging!
19:17:21 <annegent_> First, all the way back to Grizzly
19:17:23 <annegent_> #link https://etherpad.openstack.org/p/restructure-docs-session
19:17:38 <annegent_> My favorite quote, "What about for Havana, jettisoning the Install guides and focusing on configuration guides. Doc sequestration?"
19:17:44 <annegent_> now we all know that didnt' happen
19:17:54 <annegent_> there were board members who wanted to be sure there's an upstream install guide
19:18:02 <annegent_> so they gave us donated resources
19:18:11 <annegent_> But some other history is in there
19:18:36 <annegent_> themes like "Consistency for IP ranges" and "One happy path"
19:18:57 <annegent_> "One or two compute nodes" vs "all-in-one" was still being discussed
19:19:24 <annegent_> some audience analysis, and also asking "what is the main goal for the install?"
19:19:33 * sgordon sneaks in late
19:19:53 <annegent_> hey sgordon welcome
19:20:02 <annegent_> so, anyone want to throw out "main goal for install"
19:20:05 <annegent_> I can try
19:20:18 <Sam-I-Am> "basic working system"
19:20:45 <sgordon> look mum i ran a vm!
19:20:47 <annegent_> "As an admin, I want to try to install OpenStack to learn about how the components work together so that I can automate an install"
19:20:52 <sgordon> and it can download pictures of cats!
19:20:53 <Sam-I-Am> services and their interactions are too complex to figure out from a config reference
19:21:09 <Sam-I-Am> plus all the underlying dependencies (networking is hard)
19:21:15 <annegent_> "As a beginner, I want to install OpenStack on hardware I have available so that I can learn enough to ask more questions about OpenStack."
19:21:33 <Sam-I-Am> nothing works without networking, so we need a place to hand-hold
19:21:42 <zigo> annegent_: This is *not* a guide about teaching how to do automation, if it was the goal, then we failed it.
19:21:43 <Sam-I-Am> sgordon: lol
19:22:16 <Sam-I-Am> zigo: but once you have a manual installation, you know what your automation system needs to do
19:22:18 <annegent_> "As an architect, I want to install OpenStack enough times that I understand it well enough to provide an analysis for its applicability to my organization."
19:22:34 <zigo> Sam-I-Am: Yes, but that's not the goal, IMO.
19:22:52 <zigo> Just a consequence ...
19:22:55 <annegent_> zigo: but if automation needs to become a goal we'd revise, so this exercise is about us agreeing on the goals
19:23:10 <Sam-I-Am> configure prereqs, install and configure openstack services in a specific order, run openstack commands to populate services, etc.
19:23:11 <annegent_> In the early days, say 2 years ago, I always wanted an Install Guide that was one-up from DevStack.
19:23:13 <zigo> "As an OpenStack user, I want to know how to install OpenStack on multiple machines"
19:23:45 <annegent_> Closer to production than not. However as more complexity has gone into OpenStack, documenting production installs were not really possible.
19:24:06 <Sam-I-Am> plus the variations on 'production'
19:24:09 <annegent_> was? anyway, grammar is hard :)
19:24:23 <Sam-I-Am> like... do we include HA? how many of each service to we run? etc.
19:24:26 <annegent_> is it one up from devstack just due to the mulit-node-ness?
19:24:35 <Sam-I-Am> most peoples eyes would roll back before they even got to the openstack services
19:25:02 <Sam-I-Am> you'd always use multi-node in production
19:25:03 <annegent_> If the only goal is multi-node install then yes, HA comes into question. H.
19:25:08 <annegent_> er, I mean Hm.
19:25:14 <sgordon> does it tho
19:25:17 <zigo> I don't think HA is in the scope of the install-guide, unless we contain it to a specific chapter.
19:25:18 <Sam-I-Am> so it gives people an idea of how the services generally fit on different servers
19:25:28 <AJaeger_> Agreed, this is not a production ready setup - otherwise we would need to cover HA and scalability concerns
19:25:29 <sgordon> because at that point
19:25:37 <sgordon> you end up talking more about pacemaker or whatever
19:25:39 <sgordon> than openstack
19:25:54 <annegent_> "As an OpenStack aficionado, I want to install OpenStack services of interest to me to poke at so I can figure out what all the fuss is about."
19:26:16 <zigo> I don't know what you call "production", but for many users, it doesn't mean huge deployment with HA and 100s of machines.
19:26:18 <annegent_> Ok, so we're somewhere between "not really production" and "not devstack" -- I think that's fair.
19:26:24 <Sam-I-Am> i think one of the main goals is lowering the barrier to entry and giving people a usable system from which they can add more complexity later to support scalability, performance, security, etc.
19:26:40 <zigo> Many users have only a few compute nodes without HA, and are very happy with it.
19:26:40 <zigo> We need to have an answer for them too.
19:26:51 <annegent_> I think most companies are doing a better job at lowering the barrier to entry than we ever can do :)
19:26:54 <zigo> For such a complex setup, I don't think you'd be doing things by hand anyway.
19:26:58 <Sam-I-Am> the minimal # of things to do that ends up with a system that doesn't run in screen or disappear when you reboot (devstack)
19:27:03 <AJaeger_> annegent_: Agreed.
19:27:08 <annegent_> I think a goal is also "I need to install the open source cloud on open source platforms."
19:27:10 <AJaeger_> (but I'm biased ;)
19:27:21 <Sam-I-Am> frankly only jenkins should use devstack
19:27:33 <annegent_> so I actually don't think it's about lowering barrier, I think it's about describing complexity.
19:27:56 <annegent_> which may mean putting up barriers in some cases
19:28:37 <zigo> If we're about to describe HA setups, would you guys think it's ok to have it only in a single chapter?
19:28:40 <annegent_> Okay, so the goal for the Install Guide is "Readers should have a working OpenStack on minimal hardware using open source tooling."
19:28:49 <annegent_> zigo: we have a whole HA guide for that
19:29:24 <zigo> annegent_: Ok, so we shouldn't talk about HA at all in the install-guide no?
19:29:27 <annegent_> readers goals: understand complexity, understand OpenStack options, have a working install when they're done?
19:29:33 <Sam-I-Am> annegent_: also the case of 'i have an existing system and i want to try adding a new service to it, whats the minimal way to try it out?"
19:29:47 <Sam-I-Am> hence the topic-based install guide
19:29:49 <annegent_> zigo: we don't now, but we also could do a better job at pointers to other guides, I think
19:29:54 <AJaeger_> zigo, HA has it's only guide. I would rather enhance the HA guide so that it builds on top of what the Install Guide does...
19:30:05 <zigo> I'm all for pointers! :)
19:30:25 <annegent_> zigo: yeah I like pointers, it makes people less angry when the install guide doesn't do what _they_ think it should
19:30:37 <annegent_> I feel pretty comfortable defending and documenting those goals
19:30:51 <annegent_> I'll take an action to write that down in our wiki pages
19:30:59 <annegent_> as long as we're agreed
19:31:22 <annegent_> and we're okay with "minimal hardware" -- hm.
19:31:33 <Sam-I-Am> thats the barrier to entry thing
19:31:44 <Sam-I-Am> there's even people who dont have three nodes
19:31:48 <Sam-I-Am> or three VMs...
19:32:01 <annegent_> I can write use cases up, yep, it's up to us to define minimal.
19:32:11 <annegent_> I'm comfortable with 2 nodes minimal
19:32:21 <annegent_> not one node, I prefer to leave that to devstack
19:32:23 <Sam-I-Am> i've thrown around the idea of offering an all-in-one version of the install guide architecture
19:32:27 <annegent_> but can be dissuaded
19:32:43 <Sam-I-Am> lots of people understandably get fed up with devstack
19:33:06 <zigo> The biggest work for an all-in-one guide would be in Neutron, I believe.
19:33:13 <annegent_> Lots of people use devstack for production. Can't be helped apparently.
19:33:21 <zigo> Otherwise, there's not much change.
19:33:22 <Sam-I-Am> its not bad to document, however... the issue comes with troubleshooting.
19:33:23 <annegent_> Oh, and one more bit of history
19:33:25 <annegent_> #link https://etherpad.openstack.org/p/installation-guide-audit
19:33:35 <Sam-I-Am> trying to trace networking problems on a single node is a pain
19:33:39 <annegent_> that was from prior to that blueprint
19:33:45 <annegent_> I don't see much about goals in it though.
19:33:45 <Sam-I-Am> also trying to get a mental image of how it all sticks together
19:33:55 <Sam-I-Am> this is why i tend to downplay all-in-ones
19:34:01 <annegent_> yeah to me, single node doesn't meet the goal of "understand complexity"
19:34:09 <Sam-I-Am> sure, they use less hardware, but they make things overly complex
19:34:15 <Sam-I-Am> and you'd never have an AIO in production
19:34:16 <zigo> Sam-I-Am: I agree.
19:34:20 <annegent_> yeah
19:34:21 <Sam-I-Am> so the config doesn't really apply
19:34:30 <Sam-I-Am> you can easily grow the two-node/three-node arch
19:34:35 <annegent_> so let's make sure we've got the right audience in mind also
19:34:41 <sgordon> Sam-I-Am, for all in one would we be better off giving people pointers to throwing it up in VMs on a single machine...
19:34:45 <Sam-I-Am> much of it is just config duplication with new IPs
19:34:48 <annegent_> "poking at OpenStack" or "OpenStack planner"?
19:34:56 <sgordon> Sam-I-Am, thus allowing us to use same path for rest of instructions
19:35:02 <Sam-I-Am> sgordon: we mention using VMs and i think a lot of people choose that route
19:35:09 <sgordon> right
19:35:10 <Sam-I-Am> there's some caveats though
19:35:27 <annegent_> we pretty much think the audience doesn't have a lot of spare hardware laying around?
19:35:39 <annegent_> nor are they likely to do a manual install in any permanent system, right?
19:35:42 <AJaeger_> And the scripts of the training team set up the Install Guide architecture.
19:35:53 <AJaeger_> So, if you want to have an automatic setup, just uses their scripts!
19:36:00 <AJaeger_> (all in three VMs)
19:36:14 <Sam-I-Am> annegent_: people do manual installs on actual hardware
19:36:16 <sgordon> annegent_, i think our audience depends!
19:36:21 <zigo> annegent_: It's quite easy to get a single machine running multiple VMs to just try OpenStack.
19:36:25 <annegent_> okay
19:36:38 <annegent_> so our audience, more likely to do VMs or find hardware?
19:36:42 <AJaeger_> zigo: agreed, I'll do it on my laptop ;)
19:36:48 <AJaeger_> annegent_: yeah
19:36:49 <Sam-I-Am> annegent_: depends on their goals
19:36:58 <annegent_> Sam-I-Am: go on
19:37:14 <annegent_> Sam-I-Am: goes into task analysis, which I also want to hear more about
19:37:18 <sgordon> i really think the answer is both
19:37:20 <Sam-I-Am> annegent_: you can't do a lot of realistic testing with VMs due to performance issues
19:37:30 <sgordon> i dont think we could pigeon hole whether they will do VMs or find hardware
19:37:35 <annegent_> task: proof of concept for work vs. task: home lab prior to work (Thinking of the BMW guy)
19:38:05 <Sam-I-Am> i've been working with someone the last few weeks who is using the install guide arch as a minimal way to test single-network-node performance
19:38:07 <annegent_> task: install many times to learn enough to automate (that's the task I hear at user groups where I ask about the install guide)
19:38:23 <annegent_> task: install with different configs for compare/contrast?
19:38:35 <annegent_> ^^ wow is that really one of their tasks, ouch
19:38:38 <Sam-I-Am> lots of novanet-vs-neutron goes on
19:38:50 <annegent_> I say ouch because that makes my fingers and wrists ache
19:38:51 <Sam-I-Am> and soon there will be dvr-vs-l3ha
19:39:13 <Sam-I-Am> the networking guide builds minimal dvr and l3ha architectures off the install guide neutron architecture
19:39:13 <annegent_> zigo: I know you had some tasks, one was "task: set up a small private cloud" I believe
19:39:24 <zigo> Yeah.
19:39:37 <annegent_> zigo: multi node, right?
19:39:53 <zigo> I had some feedback from users using the install-guide for that.
19:39:58 <zigo> Yup.
19:40:07 <annegent_> okay
19:40:10 <annegent_> any other tasks?
19:40:34 <Sam-I-Am> annegent_: did you cover the "i want to try swift" case?
19:40:38 <Sam-I-Am> or $optionalservice
19:40:49 <annegent_> oh yeah that too, we decided 3 nodes was okay for swift, right?
19:40:57 <annegent_> task: set up storage-only cloud
19:40:59 <Sam-I-Am> sometimes people build a minimal install, then add $optionalservice to try it out
19:41:03 <zigo> Single controler that also does networking, multiple compute, and often a small Ceph cluster.
19:41:03 <zigo> I by the way would think it'd be great to cover Ceph in the install-guide.
19:41:09 <Sam-I-Am> swift was a bad choice there. lets say cinder :)
19:41:16 <annegent_> task: add on a service to an existing OpenStack cloud
19:41:40 <annegent_> zigo: I want to document only upstream OpenStack please :)
19:41:43 <AJaeger_> I would not add ceph setup to the guide
19:41:48 <annegent_> zigo: and not get into governance/politics
19:42:00 <sgordon> where is the fun in that
19:42:00 <zigo> Ceph is often prefered to swift for small clouds, so that it does both object storage & volume in a distributed way.
19:42:04 <annegent_> sgordon: hee
19:42:22 <annegent_> zigo: sure, but why would I use sparse resources for a non-OpenStack project?
19:42:26 <Sam-I-Am> pretty sure the audience doesn't need more complexity
19:42:28 <AJaeger_> Looking at the November OpenStack users survey, the majority of installations uses ceph - so integration of an existing ceph cluster is something we probably should document somewhere
19:42:28 <sgordon> my take is that if someone wants to write a module for X
19:42:32 <sgordon> would we reject it
19:42:44 <zigo> annegent_: Because it's what people use in real deployments.
19:42:50 <Sam-I-Am> ceph feels like an HA thing?
19:42:55 <sgordon> not really
19:42:59 <annegent_> I worry about maintenance ongoing
19:43:00 <sgordon> any more than swift is
19:43:04 <AJaeger_> This is something that belongs in one of the other guides
19:43:09 <annegent_> ceph implements the swift api I think
19:43:22 <annegent_> yeah I want more narrow definition for install guide
19:43:25 <Sam-I-Am> well, for another meeting :)
19:43:29 <annegent_> heck we barely get to newly incubated now
19:43:36 <annegent_> newly integrated I mean
19:43:43 <annegent_> ok is that all the tasks?
19:43:49 <AJaeger_> We document the OpenStack setup in the Install Guide. And any other hardware or software enhancements will be documented elsewhere
19:44:03 <zigo> annegent_: It does, and soon we'll be able to use only swift-proxy with everything else on Ceph.
19:44:13 <Sam-I-Am> annegent_: "where do i go from here" probably covers HA, ceph, automation, etc.
19:44:21 <annegent_> pointers, yep.
19:44:25 <zigo> (currently, there's only a ceph back-end for the object filesystem storage, so it's not great...)
19:44:25 <Sam-I-Am> security...
19:44:56 <annegent_> scope: chosen audiences and tasks
19:45:01 <Sam-I-Am> we can include things like that at the end of the install guide "hey your VM works... now you can install $optionalservices and if you're ready to join the big leagues, check these docs"
19:45:04 <annegent_> scope: only integrated OpenStack projects
19:45:11 <Sam-I-Am> annegent_: i hear there is an openstack-ansible thing :)
19:45:14 <annegent_> scope: open source tooling
19:45:24 <annegent_> scope: enable translation
19:45:35 <annegent_> I think all those scopes are agreed to?
19:45:35 <AJaeger_> such a generic chapter "Next steps" would be a welcome addition. But let's make it short and abstract
19:45:49 <annegent_> oh one more scope:
19:45:51 <Sam-I-Am> AJaeger_: we have the structure already.
19:46:11 <Sam-I-Am> AJaeger_: it was one of the icehouse neutron reorg topics
19:46:14 <annegent_> who are the maintainers as we go towards more and more added services? the project teams or distro teams or upstream team?
19:46:52 <annegent_> and then really we can dive into solutions, I think we've laid out a lot of the considerations to keep in mind
19:46:57 <Sam-I-Am> annegent_: i dont mind adding content to the install guide, but i would like a source of "here are the minimal requirements, here is a minimal tested working config, maybe some diagrams"
19:47:07 <annegent_> (hopefully 15 mins is enough to work on solutions)
19:47:30 <Sam-I-Am> those of us that maintain the install guide generally know how services need to fit in
19:48:16 <annegent_> so upstream docs is the maintainer? Or is it a chapter maintainer per service?
19:48:25 <AJaeger_> Sam-I-Am: Next steps currently points to the next chapter. I was thinking of a total new chapter - but then let's call it differently. But that's another discussion, not for now
19:48:33 <sgordon> i think it depends
19:48:34 <Sam-I-Am> annegent_: we'd lose consistency with chapter maintainers
19:48:42 <Sam-I-Am> this has happened before
19:48:43 <sgordon> trove is an example where it seems there is a dedicated resource
19:48:53 <sgordon> but i think most people contribute across the guide
19:48:57 <sgordon> not to a single section
19:49:08 <Sam-I-Am> i dont necessarily need to write the content, but i definitely want to be involved before it gets merged
19:49:10 <annegent_> sgordon: yeah there's definitely not a "glance maintainer" for example
19:49:19 <annegent_> there's a "nova neutron glance keystone" set
19:49:24 <annegent_> and a "swift" set
19:49:36 <annegent_> and a "added on services" set that may be more easily distributed
19:49:37 <sgordon> we might see more of the trove-style approach as more *aaS are added
19:49:40 <Sam-I-Am> if we had project docs liasons, they would get poked at prior to release saying "did anything change that affects the install guide? here's what we do now"
19:49:42 <zigo> Do we really have to establish this kind of rules? Sometimes, chaos works out well ... :P
19:49:42 <sgordon> but not sure it applies now
19:50:08 <annegent_> zigo: heh. yeah I hear that a lot, and will have to get more towards chaos this release, completely understand that
19:50:12 <Sam-I-Am> zigo: any way to reduce the chaos that is openstack is a good idea.
19:50:15 <annegent_> but for now I'm holding the line for install / config
19:50:24 <annegent_> since those are release deliverables
19:50:40 <Sam-I-Am> people have one goal: launch a VM
19:51:07 <annegent_> When I play out the distributed teams route, I nearly always figure we'd have to give up conditional per-distro output.
19:51:13 <Sam-I-Am> and we get them there in a step-by-step process so it isn't all magic
19:51:29 <annegent_> and I'm not ready to give that up yet
19:51:48 <annegent_> cept for those who just want to store something
19:52:02 <annegent_> and ping the vm
19:52:21 <Sam-I-Am> annegent_: given persistent packaging issues, i'd like to install just openstack from source, but rely on the distro for dependencies (read: rpc)
19:52:37 <Sam-I-Am> then we can pretty much be distro-agnostic as long as you meet the dependency requirements
19:52:42 <annegent_> Sam-I-Am: for ease of documenting as a goal?
19:53:08 <annegent_> dependency-management are the value add from a distro right?
19:53:18 <Sam-I-Am> the conditionals and testing all these distros is a lot of overhead... and we also don't see packages until after release.
19:53:28 <AJaeger_> annegent_: and also integration into the distribution, for example start/stop scripts
19:53:52 <Sam-I-Am> AJaeger_: thats one caveat, but we have things to write those.
19:53:58 <annegent_> real basic question, do distros need their OpenStack Install docs on docs.openstack.org?
19:54:23 <AJaeger_> It's also distros versus products.
19:54:28 <zigo> annegent_: It's not at least for Ubuntu, as I'm doing all of their work in this regard! :)
19:54:50 <zigo> (I mean, they did zero dependency packaging for Juno...)
19:54:50 <AJaeger_> For our OpenStack product - SUSE Cloud - we have the documentation including Crowbar for setup at the SUSE pages. I think Red Hat does it similar...
19:54:55 <annegent_> not their value add? Heh. We document for them too. All take no give?
19:55:09 <sgordon> annegent_, well i think we put them there for manual install instructions
19:55:20 <sgordon> if it wasnt using the packaged install there we would focus on RDO site
19:55:27 <sgordon> (same as we do for automation w/ packstack)
19:55:54 <Sam-I-Am> some other distros have their own install guides, but often wrapped around products (read: automation)... sometimes pay products.
19:55:54 <zigo> I do believe it's important for me to have docs in the official OpenStack site.
19:56:05 <annegent_> so Sam-I-Am if there was this non-packaged way to install, what becomes the doc dependency for maintenance? Ansible scripts?
19:56:20 <sgordon> i would hope not
19:56:24 <Sam-I-Am> i also hear that the distro-specific docs dont always go to the level of detail we do with explaining stuff. explaining stuff is a BIG part of the install guide.
19:56:31 <annegent_> zigo: okay, seems that way for debian and ubuntu (I dont' know of Canonical docs site ?)
19:56:32 <zigo> There's no "products" or "vendor" in my case, so we do rely on community, and nobody will do a specific Debian install-guide.
19:57:05 <annegent_> sgordon: you would hope not, referring to?
19:57:16 <zigo> Sam-I-Am: Yeah, that's the point. The install-guide really goes into details which is good.
19:57:17 <sgordon> annegent_, your comment wrt ansible
19:57:24 <Sam-I-Am> annegent_: yeah, ansible scripts.
19:57:30 <sgordon> it would seem weird to go to all this effort to keep specific automation tools out of the guide
19:57:32 <sgordon> then annoint one
19:57:37 <Sam-I-Am> annegent_: we have a good source of those, though.
19:57:42 <annegent_> sgordon: ok, yeah want to uncover what we would be dependent upon working (and what we would have to troubleshoot)
19:57:48 <AJaeger_> annegent_: Do we have to finish soon or can we stay longer in the room?
19:57:56 <annegent_> AJaeger_: ah, time got away
19:57:58 <annegent_> Looking
19:58:13 <annegent_> yeah Octavia's in here next
19:58:21 <annegent_> Ok, let's make sure we know what we can do next.
19:58:22 <Sam-I-Am> can we beat them up?
19:58:24 <annegent_> I want to document our goals
19:58:28 <rm_work> Sam-I-Am: T_T
19:58:30 <annegent_> state the audience
19:58:31 <sbalukoff> ...
19:58:33 <Sam-I-Am> lol
19:58:33 <annegent_> state the tasks
19:58:43 <annegent_> on the mailing list and wiki
19:58:52 <annegent_> I'd also like to hear from training team
19:59:04 <Sam-I-Am> we didnt get to solutions, so maybe another meeting?
19:59:18 <annegent_> and I'll add it to the doc team agenda for next week, which is 1400 UTC (right?) Wed.
19:59:29 <Sam-I-Am> yep
19:59:31 <annegent_> "it" being "solution discussion for Install Guide"
19:59:39 <annegent_> does that work?
19:59:49 <Sam-I-Am> sure. might consume the entire hour :P
20:00:07 <annegent_> there's only four to choose from :)
20:00:17 <annegent_> Okay, handing it over, thanks for making it work all.
20:00:19 <annegent_> #endmeeting