Open Stack

On Wed, Feb 11, 2015 at 5:15 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Wed, Feb 11, 2015 at 12:03:58PM +0100, Pasquale Porreca wrote:
> > Thank you for all answers.
> > I know that meta data tags are "free" to use with any key/value, still
> > there are some specific values that triggers pieces of code in nova (or
> > maybe even in other components). In particular I am working on one of
> > these key/value, in my case it should enable the
> >
> > <bios rebootTimeout=value/>
> >
> > parameter in libvirt. Anyway even if my code is merged, no one will know
> > about it (except myself and the reviewers) if it is not documented
> > somewhere. A DocImpact flag was added to the commit message, but I still
> > don't know how to proper document it. I may create/update existing wiki
> > pages, but I would have preferred an official documentation: I was not
> > able to find the wiki page proposed by Daniel Berrange, even if I had
> > been searching exactly to something similar :(
> > It is very good that there is a work to objectify image meta, anyway is
> > there any recommendation  how to document it in the meanwhile?
>
> For people submitting patches to nova the expectation is simply that they
> add DocImpact and have a commit message that describes the usage of the
> new property. The docs team work from this data.


Technically, DocImpact creates a doc bug for the Launchpad project
indicated in a configuration file. It's not always an indicator for the doc
team to work from, it is the responsibility of each project to take care of
their impactful doc bugs.

For example, there were over 50 new bugs logged last week, and no way for a
centralized doc team to keep up with the incoming DocImpact requests, not
even to triage.

So please, spread the word wide and far that DocImpact is merely a
mechanism to track that further doc work is needed for the feature to be
completed.

Thanks,
Anne


> There's no current formal
> docs that I'd expect you to be editing/updating.
>
> > I would also know if there is any naming convention for image meta and
> > flavor extra-spec keys: in my case I used hw_reboot_timeoutand
> > hw:reboot_timeout respectively, but it is more a bios than hardware
> > feature and they are handled in nova/virt/libvirt/driver.py rather than
> > nova/virt/hardware.py so maybe the name choice was not so good.
>
> In terms of image metadata, broadly speaking, we're aiming to standardize
> on 3 name prefixes in Nova
>
>  'hw' - stuff that affects guest hardware configuration (this includes
>         the BIOS settings, since that's hardware firmware)
>  'os' - stuff that affects the guest operating system setup
>  'img' - stuff Nova uses related to managing images
>
> So, your choice of 'hw_reboot_timeout' for image and 'hw:reboot_timeout'
> for the flavour  is correct.
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150211/a8717bdc/attachment.html>