[nova] "future" specs and blueprints

Sean Mooney smooney at redhat.com
Thu Mar 28 14:30:54 UTC 2019


just top posing on my side thread re moving the specs intree.
we chatted a bit about this on the placement irc because i saw
a similar conversation there and we remvoed this from the agenda
for the PTG as the benifit of moving the specs with the history
is not outwighed by the effort need to do the move.

if people care about moving the specs in the future or feel
the benifit is worth it then cool but im going to drop this side topic for now.

On Thu, 2019-03-28 at 13:44 +0000, Sean Mooney wrote:
> On Thu, 2019-03-28 at 13:11 +0000, Jeremy Stanley wrote:
> > On 2019-03-28 11:21:28 +0000 (+0000), Sean Mooney wrote:
> > [...]
> > > im not really opposed to the ideas put forward here but can we
> > > kill the nova-specs repo and just move it to an in tree specs
> > > folder in the nova repo.
> > 
> > [...]
> > 
> > A few things you may want to consider with this plan:
> > 
> > 1. You release and branch nova but not nova-specs, so moving your
> > specs into nova means they will also now be released and branched as
> > a part of nova. When specs change on master, will you backport those
> > changes to the stable branch versions? Note that documentation is
> > published independently for each branch so you'll potentially have
> > different versions of the same spec published with documentation for
> > each branch.
> 
> if well we should never backport feature so the implies any intree changes
> to the specs are due to bugfixes. if the spec is updated in the same commit
> as the bug fix then when we backport it we ill also update it.
> i see this as an advangate as teh branched spec actully reflects what the current
> state is on the branch.
> > 
> > 2. The Nova team has other deliverable repos besides nova itself, so
> > if a spec is more relevant to another deliverable would it still
> > reside in the nova repo, or elsewhere?
> 
> 
https://github.com/openstack/governance/blob/9caae68a2852e6263b9f44b3152c7868bbcbf7db/reference/projects.yaml#L1973-L2011
> currntly nova deliverables are
> 
> nova nova-spec ptynon-novaclient and os-vif
> 
> os-vif does not ues spec unless we need to change somthing in nova itself.
> 
> python-nova client does not use specs either as client updates are covered
> by the spec that intoduced the nova feature.
> 
> so that just leave nova-spec and nova iteslf so i dont think this is an issue.
> 
> 
> > 
> > 3. Keeping specs with the rest of your in-repository documentation
> > makes it harder to use different Sphinx themes or configuration for
> > specs as opposed to other docs.
> 
> i did not suggest keeping the spec with the rest of the documentation.
> as kolla ansible does an i think a few others i am suggeting we create
> a specs folder in the root of the nova repo.
> https://github.com/openstack/kolla-ansible/tree/master
> as a result there should be no issue with using different sphinx themes or configuration
> 
> > 
> > 4. Most (all?) OpenStack specs repos currently publish to
> > specs.openstack.org rather than docs.openstack.org so this may make
> > Nova's harder to find (or may make them easier to find if most
> > people were expecting them to be in Nova's documentation, I can't
> > really say what random readers expect if anything).
> 
> since this will not be part of the docs tree i dont see why we cant
> continue to publish the spec to specs.openstack.org as they wont be part of the docs.
> 




More information about the openstack-discuss mailing list