[openstack-dev] [api] [senlin] [keystone] [ceilometer] [telemetry] Questions about api-ref launchpad bugs
Qiming Teng
tengqim at linux.vnet.ibm.com
Wed May 11 01:08:54 UTC 2016
On Tue, May 10, 2016 at 07:53:19AM -0500, Anne Gentle wrote:
> Great questions, so I'm copying the -docs and -dev lists to make sure
> people know the answers.
>
> On Tue, May 10, 2016 at 5:14 AM, Atsushi SAKAI <sakaia at jp.fujitsu.com>
> wrote:
>
> > Hello Anne
> >
> > I have several question when I am reading through etherpad's (in
> > progress).
> > It would be appreciated to answer these questions.
> >
> > 1)Should api-ref launchpad **bugs** be moved to each modules
> > (like keystone, nova etc)?
> > Also, this should be applied to moved one's only or all components?
> > (compute, baremetal Ref.2)
> >
> > Ref.
> > https://etherpad.openstack.org/p/austin-docs-newtonplan
> > API site bug list cleanup: move specific service API ref bugs to
> > project's Launchpad
> >
> > Ref.2
> > http://developer.openstack.org/api-ref/compute/
> > http://developer.openstack.org/api-ref/baremetal/
>
>
> Yes! I definitely got agreement from nova team that they want them. Does
> anyone have a Launchpad script that could help with the bulk filter/export?
> Also, are any teams concerned about taking on their API reference bugs?
> Let's chat.
>
>
> >
> >
> > 2)Status of API-Ref
> > a)Why keystone and senlin are no person at this moment?
> >
> >
> >
> Keystone -- after the Summit, keystone had someone sign up [1], but sounds
> like we need someone else. Brant, can you help us find someone?
>
> Senlin -- Qiming Teng had asked a lot of questions earlier in the process
> and tested the instructions. Qiming had good concerns about personal
> bandwidth limits following along with all the changes. Now that it's
> settled, I'll follow up (and hoping the senlin team is reading the list).
Well, I should have spoken up that we are already moving in that
direction. So far we have migrated quite some APIs into the new format.
Will let the team know when we have finished the migration for senlin.
When working on this migration, I do have some suggestions to improve
the sphinx extensions. For example, whether a parameter is optional
should be specified from where it is referenced (i.e. the RST files)
rather than where it is defined (i.e. the parameters.yaml file). Other
than that, the migration is smooth.
We were not doing a batch commit for the migration. We see this another
chance to cleanse any mistakes in API doc and/or API code. So we are
manually adding API docs one resource after another.
Regards,
Qiming
> > b)What is your plan for sahara and ceilometer?
> > (It seems already exist the document.)
> >
>
> Yes, these are two I had seen already have RST, but they do not use the
> helpful Sphinx extensions.
>
> Sahara -- Mike McCune, we should chat about the plans. Are you okay with
> moving towards the common framework and editing the current RST files to
> use the rest_method and rest_parameters Sphinx directives?
>
> Ceilometer -- sorry, Julien, I hadn't reached out individually to you.
> Could you let me know your plans for the RST API reference docs?
>
>
> > c)When is the table's status changed to "Done"?
> > nova (compute) and ironic (baremetal) seems first patch merged
> > and see the document already.
> >
>
> I'll change those two to Done.
>
> Thanks for asking -
> Anne
>
>
> >
> >
> > Ref.
> > [1]
> > https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
> >
> >
> > Thanks
> >
> > Atsushi SAKAI
> >
>
>
>
> --
> Anne Gentle
> www.justwriteclick.com
More information about the OpenStack-dev
mailing list