<div dir="ltr">This definitely falls under the scope of the documentation effort. Alas, we still don't even have the folsom->grizzly process fully documented yet <<a href="https://bugs.launchpad.net/openstack-manuals/+bug/1087483">https://bugs.launchpad.net/openstack-manuals/+bug/1087483</a>>.<div>
<br></div><div>I added a new bug for documenting grizzly->havana <<a href="https://bugs.launchpad.net/openstack-manuals/+bug/1199773">https://bugs.launchpad.net/openstack-manuals/+bug/1199773</a>>. <div><br></div>
<div>Lorin<br><div><br></div><div style><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 8:43 AM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Tom Fifield" <<a href="mailto:tom@openstack.org">tom@openstack.org</a>><br>
> To: <a href="mailto:openstack-docs@lists.openstack.org">openstack-docs@lists.openstack.org</a><br>
> Sent: Tuesday, July 9, 2013 8:34:25 PM<br>
> Subject: Re: [Openstack-docs] Linking to external install guides<br>
><br>
> On 10/07/13 00:48, Steve Gordon wrote:<br>
> > ----- Original Message -----<br>
> >> From: "Lorin Hochstein" <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>><br>
> >> To: "Steve Gordon" <<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>><br>
> >> Cc: "Anne Gentle" <<a href="mailto:annegentle@justwriteclick.com">annegentle@justwriteclick.com</a>>,<br>
> >> <a href="mailto:openstack-docs@lists.openstack.org">openstack-docs@lists.openstack.org</a><br>
> >> Sent: Tuesday, July 9, 2013 10:38:26 AM<br>
> >> Subject: Re: [Openstack-docs] Linking to external install guides<br>
> >><br>
> >> On Mon, Jul 8, 2013 at 3:36 PM, Steve Gordon <<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>> wrote:<br>
> >><br>
> >>> ----- Original Message -----<br>
> >>>> From: "Anne Gentle" <<a href="mailto:annegentle@justwriteclick.com">annegentle@justwriteclick.com</a>><br>
> >>>> To: "Lorin Hochstein" <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>><br>
> >>>> Cc: <a href="mailto:openstack-docs@lists.openstack.org">openstack-docs@lists.openstack.org</a><br>
> >>>> Sent: Monday, July 8, 2013 11:03:05 AM<br>
> >>>> Subject: Re: [Openstack-docs] Linking to external install guides<br>
> >>>><br>
> >>>> So, for the last few releases, I would update<br>
> >>>> <a href="http://www.openstack.org/software/start/" target="_blank">http://www.openstack.org/software/start/</a> with links to the downstream<br>
> >>>> deployment documentation. It was natural at the time.<br>
> >>>><br>
> >>>> What has changed as of last week is that documentation is now an<br>
> >>>> official<br>
> >>>> "Program" and we'll need to propose the goals for the documentation and<br>
> >>>> make a scope for release docs. To me, this change means we should be<br>
> >>>> more<br>
> >>>> tight and targeted with our install docs as they'll be part of the<br>
> >>>> integrated release.<br>
> >>><br>
> >>> Downstream deployment materials tend to cover arguably more streamlined<br>
> >>> approaches to deployment, such as Foreman, PackStack, Ansible, JuJu, etc.<br>
> >>> The flip side however is these deployment methods are not considered part<br>
> >>> of OpenStack itself and may not in fact be ready to deploy a new release<br>
> >>> on<br>
> >>> day dot. These approaches also don't necessarily have 1:1 equivalents<br>
> >>> across distributions.<br>
> >>><br>
> >>> For these reasons my feeling is the documentation "program" should be<br>
> >>> concentrated on delivering accurate manual installation steps at release<br>
> >>> time in a consolidated installation guide as suggested in the restructure<br>
> >>> blueprint [1]. I don't think however this precludes also linking the<br>
> >>> distribution specific materials somewhere as they become available, it<br>
> >>> just<br>
> >>> wouldn't be a blocker to the integrated release?<br>
> >>><br>
> >>> -Steve<br>
> >>><br>
> >>> [1] <a href="https://wiki.openstack.org/wiki/Blueprint-restructure-documentation" target="_blank">https://wiki.openstack.org/wiki/Blueprint-restructure-documentation</a><br>
> >>><br>
> >><br>
> >><br>
> >> At the last design summit, we talked about the doc team no longer<br>
> >> maintaining any install documentation at all going forward, leaving that<br>
> >> entirely to downstream projects. I really do think that's the way we<br>
> >> should<br>
> >> go. I'm hesitant to maintain docs on a fully manual install (i.e., from<br>
> >> source tarballs), since we really don't want people to do that.<br>
> ><br>
> > Yes, I realize now I should have clarified that by "manual" I still meant<br>
> > using packages - just without aids like those listed in my previous mail.<br>
> > I think trying to create and maintain documentation of from source<br>
> > installation that would potentially be even harder than this, despite the<br>
> > (potential) issues with packaged builds lagging behind the source release.<br>
> ><br>
> >> It means that documentation on how to do an install won't exist until the<br>
> >> downstream projects write these up, but since we recommend installing from<br>
> >> downstream packages, I think that's unavoidable. Since we're seeing a lot<br>
> >> more support for OpenStack downstream these days, I think those projects<br>
> >> have more of an incentive to get their packages and docs ready ASAP after<br>
> >> a<br>
> >> release.<br>
> ><br>
> > My understanding is that at least RPM/DEB packages are likely to be<br>
> > available *very* shortly after the actual release for Havana.<br>
><br>
> I'll take a bullish line, which may not necessarily be achievable:<br>
><br>
> """<br>
> On the day that the press release for Havana is sent out, we need -by<br>
> hook or by crook!- to have installation instructions for RHEL and<br>
> Ubuntu, and ideally SUSE and Debian too.<br>
> """<br>
><br>
> I'm thinking: "if you can't install the software, then it's not really a<br>
> release, is it?". Release day is our time to shine :)<br>
<br>
</div></div>Well, another huge gap that I think exists here is if you can't upgrade from the previous release it's not really a release. Currently I think this is a huge problem regardless of installation method because the only documentation available for upgrades appears to be some per-project notes in the release notes Wiki page. A bit tangential perhaps and not sure this is really just a documentation problem but thought I would bring it up.<br>
<div class="im"><br>
> So, feasibility/sanity check:<br>
> * This is unlikely to be provided in time by our friends at RH or<br>
> Canonical, leaving:<br>
> Option 1: Delay the press release<br>
> Option 2: DIY<br>
><br>
> Personally, I think Option 1 would be terrible for the community's<br>
> "feelings", and tying OpenStack to particular product offerings is not<br>
> something we should probably be doing :)<br>
<br>
</div>I've sent a query regarding build schedules for RDO on rdo-list [1]. No doubt there is package tweaking to be done but nightlies are already being built from trunk:<br>
<br>
<a href="http://repos.fedorapeople.org/repos/openstack/openstack-trunk/" target="_blank">http://repos.fedorapeople.org/repos/openstack/openstack-trunk/</a><br>
<br>
Thanks,<br>
<br>
Steve<br>
<br>
[1] <a href="https://www.redhat.com/archives/rdo-list/2013-July/msg00057.html" target="_blank">https://www.redhat.com/archives/rdo-list/2013-July/msg00057.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</div>