Re: [openstack-dev] Proposing Zhang Guoqing as core for cloudkitty

[Gauvain Pocentek]

+1

Le 2016-11-04 19:13, Christophe Sauthier a écrit :

Hello developer mailing list folks,

I'd like to propose that we add Zhang Guoqing (zhangguoqing) as an
OpenStack cloudkitty
core reviewer.

He has been a member of our community for many months, contributing
very seriously in cloudkitty and cloudkitty-dashboard. He also
provided many reviews on both projects part as you can se in his
activity logs

http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60

During that time he learned from the mistakes he did and improved
both his communication and participation.

Overall I think Zhang Guoqing would make a great addition to the core
review team.

Current Cloudkitty cores, please respond with +1 or explain your
opinion if voting against... If there are no objection in the next 5
days I'll add him.

All the best,

Christophe


Christophe Sauthier   Mail :
christophe.sauth...@objectif-libre.com
CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la
Pause OpenStack
http://olib.re/pause-openstack

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposing Maxime Cottret as core for cloudkitty

[Gauvain Pocentek]

+1

Le 2016-11-04 19:19, Christophe Sauthier a écrit :

Hello developer mailing list folks,

I'd like to propose that we add Maxime Cottret (aolwas) as an
OpenStack cloudkitty
core reviewer.

He has been a member of our community for a few months. Working
mainly on the stabilisation/bug fixing of our project he really showed
some great communication capacity.

Those are all the reasons why I think Maxime Cottret would make a
great addition to the core review team.

Current Cloudkitty cores, please respond with +1 or explain your
opinion if voting against... If there are no objection in the next 5
days I'll add him.

All the best,

Christophe

http://stackalytics.com/report/contribution/cloudkitty/60
http://stackalytics.com/report/contribution/cloudkitty-dashboard/60


Christophe Sauthier   Mail :
christophe.sauth...@objectif-libre.com
CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la
Pause OpenStack
http://olib.re/pause-openstack

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Gauvain Pocentek]

Hi James,

Le 2016-06-08 12:20, James Page a écrit :

Hi

We're currently blocked on becoming an OpenStack project under the
big-tent by the licensing of the 26 OpenStack charms under GPL v3.

I'm proposing that we re-license the following code repositories as 
Apache 2.0:


  charm-ceilometer
  charm-ceilometer-agent
  charm-ceph
  charm-ceph-mon
  charm-ceph-osd
  charm-ceph-radosgw
  charm-cinder
  charm-cinder-backup
  charm-cinder-ceph
  charm-glance
  charm-hacluster
  charm-heat
  charm-keystone
  charm-lxd
  charm-neutron-api
  charm-neutron-api-odl
  charm-neutron-gateway
  charm-neutron-openvswitch
  charm-nova-cloud-controller
  charm-nova-compute
  charm-odl-controller
  charm-openstack-dashboard
  charm-openvswitch-odl
  charm-percona-cluster
  charm-rabbitmq-server
  charm-swift-proxy
  charm-swift-storage

The majority of contributors are from Canonical (from whom I have
permission to make this switch) with a further 18 contributors from
outside of Canonical who I will be directly contacting for approval in
gerrit as reviews are raised for each repository.


No problem on my side to change the license to apache 2.0.

Thanks for checking with us.

Gauvain




Any new charms and supporting repositories will be licensed under
Apache 2.0 from the outset.

Cheers

James
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cloudkitty] Remove inactive contributors from cloudkitty-core

[Gauvain Pocentek]

Le 2015-11-24 11:51, Stéphane Albert a écrit :

Hi,

Some people in the cloudkitty-core group are not active anymore. They
haven't produced a single contribution during the last cycle. Here is
the list of the two people:

- Adrian Turjak
- François Magimel

I think we should remove them from the group. We've got new faces in 
the

project, let's get some space for them ready :).

Are you guys OK with this?


+1




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][docs] config reference updates

[Gauvain Pocentek]

As you may know, the doc team generates docbook tables listing the 
configuration options for some OpenStack projects, including Neutron. 
This tables are used in the configuration reference. I've updated these 
tables in preparation for the Kilo release, but with the move of plugin 
to external repositories it's getting very complicated for the doc team 
to make sure that everything is listed and properly categorized.


Could driver developers check that the tables generated in 
https://review.openstack.org/177283 are correct?


The easiest way to validate that nothing's missing is to have a look at 
the neutron.flagmapping file, which is supposed to list all the 
available config options, along with the associated categories.


Thanks,

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

[Gauvain Pocentek]

Hi François,

I guess this mail was directed to me personally but I'll answer here, 
this might be useful for the translation teams.


There's no existing translation for the HOT guide yet, and I'm not sure 
that now is the best time to get started. The (temporary standalone) HOT 
guide will end up as a user guide section, in docbook (not RST). I'm 
currently rewriting some sections and more content will be added soon, 
so expect lots of modifications. As soon as it's ready to be officially 
published in the user guide, the translation tools will import the 
docbook strings in transifex (that's the plan at least).


Gauvain

Le 2014-10-06 16:05, François Bureau a écrit :

Bonjour Gauvain,

Un gros bravo pour cette documentation sur Heat qui est très complète.

Est-ce que par hasard vous auriez déjà une version française ? ;)

Best,

F.

-----Message d'origine-
De : Gauvain Pocentek [mailto:gauvain.pocen...@objectif-libre.com]
Envoyé : lundi 6 octobre 2014 07:06
À : Tom Fifield
Cc : OpenStack Development Mailing List (not for usage questions);
openstack-d...@lists.openstack.org
Objet : Re: [openstack-dev] [Openstack-docs] Contributing to docs
without Docbook -- YES you can!

Le 2014-10-06 05:26, Tom Fifield a écrit :

On 04/10/14 04:03, Nick Chase wrote:


On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli
mailto:stef...@openstack.org>> wrote:
>  1. Pick an existing topic or create a new topic. For new
topics,
we're
> primarily interested in deployment scenarios.
>  2. Develop content (text and/or diagrams) in a format that
supports at
> least basic markup (e.g., titles, paragraphs, lists, 
etc.).

>  3. Provide a link to the content (e.g., gist on github.com
<http://github.com>, wiki page,
> blog post, etc.) under the associated topic.

Points 1-3 seem to be oriented at removing Launchpad from the
equation.
Is that all there is? I guess it makes sense to remove 
obstacles,

although editing the wiki (since it requires a launchpad account
anyway)
may not be the best way to track progress and see assignments.


No, really, the main change is in step 5.  Launchpad isn't the
problem, as far as we can tell; Docbook is.


Hi Nick,

As best I can tell - 'step 5' has been in place for at least the last
few summits at least, so this is not a change :) We have had a policy
where anyone can dump text in bug reports and we'll wrangle it. This
has been popular, see eg Marco Cossoni's contributions, but in my
opinion not widely enough communicated - so thanks for your efforts.


We actually have another way to work with developers, although it's
been only available for the new HOT guide. This guide is temporary, it
will become a part of the user guide. The interesting point is that
it's written in RST, and uses gerrit for reviews. So far we've had 2
core members of the heat team contributing content, and this content
has been reviewed by other members of the team.

The devs patches focused on content, not on the form of the content.
I suggested to accept the patches rapidly - as long as they're
technically correct - and to rework them later (what I've started to
do a couple days ago). The fact that we're using gerrit and that the
developers review each other work makes me more comfortable with the
quality of the content.

I'd really like to see this process extended to a larger part of the
documentation, although this might not be needed everywhere.

I had this workflow in mind:

* a dev sends a review to a temporary repo
* other devs can validate the information, and give their +1 when the
patch is ready
* a doc reviewer either requests more technical detail, or gives his
+2/accept
* the doc team reworks the patch and integrates it to the doc 
repository


I really think that the process worked for the HOT guide, and I'm
convinced that it could work for other parts of the doc (Cinder and
Neutron drivers doc for instance).

As a side note, we have a tool that converts RST to docbook. The hot
guide is automatically built using this tool
(http://docs.openstack.org/hot-guide/content/hot_guide_hot-guide.html).

Gauvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

[Gauvain Pocentek]

Le 2014-10-06 05:26, Tom Fifield a écrit :

On 04/10/14 04:03, Nick Chase wrote:


On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli 

> wrote:
>  1. Pick an existing topic or create a new topic. For new 
topics,

we're
> primarily interested in deployment scenarios.
>  2. Develop content (text and/or diagrams) in a format that
supports at
> least basic markup (e.g., titles, paragraphs, lists, etc.).
>  3. Provide a link to the content (e.g., gist on github.com
, wiki page,
> blog post, etc.) under the associated topic.

Points 1-3 seem to be oriented at removing Launchpad from the 
equation.

Is that all there is? I guess it makes sense to remove obstacles,
although editing the wiki (since it requires a launchpad account 
anyway)

may not be the best way to track progress and see assignments.


No, really, the main change is in step 5.  Launchpad isn't the 
problem,

as far as we can tell; Docbook is.


Hi Nick,

As best I can tell - 'step 5' has been in place for at least the last
few summits at least, so this is not a change :) We have had a policy
where anyone can dump text in bug reports and we'll wrangle it. This 
has

been popular, see eg Marco Cossoni's contributions, but in my opinion
not widely enough communicated - so thanks for your efforts.


We actually have another way to work with developers, although it's 
been only available for the new HOT guide. This guide is temporary, it 
will become a part of the user guide. The interesting point is that it's 
written in RST, and uses gerrit for reviews. So far we've had 2 core 
members of the heat team contributing content, and this content has been 
reviewed by other members of the team.


The devs patches focused on content, not on the form of the content. I 
suggested to accept the patches rapidly - as long as they're technically 
correct - and to rework them later (what I've started to do a couple 
days ago). The fact that we're using gerrit and that the developers 
review each other work makes me more comfortable with the quality of the 
content.


I'd really like to see this process extended to a larger part of the 
documentation, although this might not be needed everywhere.


I had this workflow in mind:

* a dev sends a review to a temporary repo
* other devs can validate the information, and give their +1 when the 
patch is ready
* a doc reviewer either requests more technical detail, or gives his 
+2/accept
* the doc team reworks the patch and integrates it to the doc 
repository


I really think that the process worked for the HOT guide, and I'm 
convinced that it could work for other parts of the doc (Cinder and 
Neutron drivers doc for instance).


As a side note, we have a tool that converts RST to docbook. The hot 
guide is automatically built using this tool 
(http://docs.openstack.org/hot-guide/content/hot_guide_hot-guide.html).


Gauvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

[Gauvain Pocentek]

Le 2014-09-08 17:10, Anne Gentle a écrit :
On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy  
wrote:



On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote:

    On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek
     wrote:

      Hi,

      A bit of background: I'm working on the publication of the HOT 
resources
      reference on docs.openstack.org [1]. This book is mostly 
autogenerated from
      the heat source code, using the sphinx XML output. To avoid 
publishing
      several references (one per released version, as is done for 
the
      OpenStack config-reference), I'd like to add information about 
the
      support status of each resource (when they appeared, when 
they've been

      deprecated, and so on).

      So the plan is to use the SupportStatus class and its 
`version`
      attribute (see https://review.openstack.org/#/c/116443/ [2] ). 
And the
      question is, what information should the version attribute 
hold?
      Possibilities include the release code name (Icehouse, Juno), 
or the
      release version (2014.1, 2014.2). But this wouldn't be useful 
for users

      of clouds continuously deployed.

      From my documenter point of view, using the code name seems 
the right

      option, because it fits with the rest of the documentation.

      What do you think would be the best choice from the heat devs 
POV?


    IMHO it should match the releases and tags
    (https://github.com/openstack/heat/releases [3]).


+1 this makes sense to me.  Couldn't we have the best of both worlds 
by
having some logic in the docs generation code which maps the 
milestone to

the release series, so we can say e.g

"Supported since 2014.2.b3 (Juno)"


I agree with the matching of releases, but let's set expectations for
how often it'll be generated. That is to say, each tag is a bit much
to ask. I think that even each milestone is asking a bit much. How
about each release and include the final rc tag (2014.2?)


This option looks good to me.

Gauvain




This would provide sufficient detail to be useful to both folks 
consuming

the stable releases and those trunk-chasing via CD?

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [4]




Links:
--
[1] http://docs.openstack.org
[2] https://review.openstack.org/#/c/116443/
[3] https://github.com/openstack/heat/releases
[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Defining what is a SupportStatus version

[Gauvain Pocentek]

Hi,

A bit of background: I'm working on the publication of the HOT 
resources reference on docs.openstack.org. This book is mostly 
autogenerated from the heat source code, using the sphinx XML output. To 
avoid publishing several references (one per released version, as is 
done for the OpenStack config-reference), I'd like to add information 
about the support status of each resource (when they appeared, when 
they've been deprecated, and so on).


So the plan is to use the SupportStatus class and its `version` 
attribute (see https://review.openstack.org/#/c/116443/ ). And the 
question is, what information should the version attribute hold? 
Possibilities include the release code name (Icehouse, Juno), or the 
release version (2014.1, 2014.2). But this wouldn't be useful for users 
of clouds continuously deployed.


From my documenter point of view, using the code name seems the right 
option, because it fits with the rest of the documentation.


What do you think would be the best choice from the heat devs POV?

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

[Gauvain Pocentek]

Le 2014-05-23 15:57, Anne Gentle a écrit :
On Fri, May 23, 2014 at 8:42 AM, Steven Hardy  
wrote:



On Fri, May 23, 2014 at 08:09:06AM -0500, Anne Gentle wrote:
On Fri, May 23, 2014 at 6:19 AM, Steven Hardy  
wrote:



On Fri, May 23, 2014 at 12:38:40PM +0200, Andreas Jaeger wrote:

On 05/23/2014 12:13 PM, Steven Hardy wrote:

[...]
I'll hold my hand up as one developer who tried to contribute but 
ran

away

screaming due to all the XML-java-ness of the current process.
I don't think markup complexity is a major barrier to 
contribution.

Needing
to use a closed source editor and download unfathomably huge 
amounts of

java to build locally definitely are though IMO/IME.
You do not need a closed sourced editor for XML - I'm using emacs 
and

others in the team use vi for it.
Sure, maybe "need" was the wrong word to use, my apologies. 
 Regardless,

the docs refer to a closed source tool being "encouraged", which
immediately discouraged me when trying to figure out the workflow.
I've tried editing XML in vim a few times, and although it's 
obviously

possible, it's far less painful when I'm dealing with other more
human-friendly formats.

Yes, it downloads a lot Java once. We also now build the documents 
as

part of the gate, so you can also check changes by clicking the
"checkbuild" target, it will show you the converted books,
Sure, that's good, but my (and I'd guess many others) preference is 
for
formats which can be easily built locally with only distro-provided 
tools,

not a huge pile of third party java.
Not trying to start a format-advocacy argument here, just trying to 
provide
a data-point that, if the success criteria is developer 
participation in
the docs process, then the current toolchain is definitely a 
barrier to

participation for some potential contributors.



Thanks for the discussions -- let's keep a tone of civility. 
Understand
that doc writers have specific tools that work well for them. That 
said, we

do want to collaborate more with our end users specifically.

My apologies if my remarks have been interpreted as uncivil, that was
definitely not my intention.

Oh no not at all, sorry -- my intent is that we are all staying civil
and it's good. :)
 

The only point I really wanted to convey was +1 on trying out an 
easier

markup, and thanks for bringing up the topic of a user orientated
orchestration guide - I would definitely like to contribute to the 
effort.

So we're still a little stuck on the tradeoffs -- with easier markup
we lose some features. 
For other generated reference docs, we maintain a set of python
scripts in openstack-doc-tools. Is it possible for someone to look
into generating the Heat template reference information outside of
Sphinx?


Yes, I can look into that.

The idea would be to generate some docbook from RST... So why not do it 
for the whole to-be-written heat user guide in that case?


What I get from this thread is that 1) docbook is the best format to 
use to generate a nice and feature-rich output, 2) developers don't want 
to write docbook. Without being able to handle a different format 
developers will no contribute, which is bad because they want, and we 
want them to contribute :)


So my feeling is that we should work on the tools to convert RST (or 
whatever format, but RST seems to be the "norm" for openstack projects) 
to docbook, and generate our online documentation from there. There are 
tools that can help us doing that, and I don't see an other solution 
that would make us move forward.


Anne, you talked about experimenting with the end user guide, and after 
the discussion and the technical info brought by Doug, Steve and Steven, 
I now think it is worth trying.


Thoughts?

Gauvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

[Gauvain Pocentek]

Le 2014-05-16 17:13, Anne Gentle a écrit :

On Thu, May 15, 2014 at 10:34 AM, Gauvain Pocentek
 wrote:


Hello,

This mail probably mainly concerns the doc team, but I guess that the 
heat team wants to know what's going on.


We've shortly discussed the state of heat documentation with Anne 
Gentle and Andreas Jaeger yesterday, and I'd like to share what we 
think would be nice to do.


Currently we only have a small section in the user guide that 
describes how to start a stack, but nothing documenting how to write 
templates. The heat developer doc provides a good reference, but I 
think it's not easy to use to get started.


So the idea is to add an "OpenStack Orchestration" chapter in the 
user guide that would document how to use a cloud with heat, and how 
to write templates.


I've drafted a spec to keep track of this at [0].


I'd like to experiment a bit with converting the End User Guide to an
easier markup to enable more contributors to it. Perhaps bringing in
Orchestration is a good point to do this, plus it may help address the
auto-generation Steve mentions. 

The loss would be the single sourcing of the End User Guide and Admin
User Guide as well as loss of PDF output and loss of translation. If
these losses are worthwhile for easier maintenance and to encourage
contributions from more cloud consumers, then I'd like to try an
experiment with it.


Using RST would probably make it easier to import/include the 
developers' documentation. But I'm not sure we can afford to loose the 
features you mention. Translations for the user guides are very 
important I think.


How would we review changes made in "external" repositories? The user 
guides are continuously published, this means that a change done in the 
heat/docs/ dir would quite quickly land on the webserver without a doc 
team review. I completely trust the developers, but I'm not sure that 
this is the way to go.




The experiment would be to have a new repo set up,
openstack/user-guide and use the docs-core team as reviewers on it.
Convert the End User Guide from DocBook to RST and build with Sphinx.
Use the oslosphinx tempate for output. But what I don't know is if
it's possible to build the automated output outside of the
openstack/heat repo, does anyone have interest in doing a proof of
concept on this? 


I'm not sure that this is possible, but I'm no RST expert.


I'd also like input on the loss of features I'm describing above. Is
this worth experimenting with?


Starting this new book sounds like a lot of work. Right now I'm not 
convinced it's worth it.


Gauvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

[Gauvain Pocentek]

Le 2014-05-15 18:32, Steve Baker a écrit :

On 15/05/14 11:54, Gauvain Pocentek wrote:

(Resending to add openstack-dev)

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

Le 2014-05-15 17:34, Gauvain Pocentek a écrit :

Hello,

This mail probably mainly concerns the doc team, but I guess that 
the

heat team wants to know what's going on.

We've shortly discussed the state of heat documentation with Anne
Gentle and Andreas Jaeger yesterday, and I'd like to share what we
think would be nice to do.

Currently we only have a small section in the user guide that
describes how to start a stack, but nothing documenting how to write
templates. The heat developer doc provides a good reference, but I
think it's not easy to use to get started.

So the idea is to add an "OpenStack Orchestration" chapter in the
user guide that would document how to use a cloud with heat, and how
to write templates.

I've drafted a spec to keep track of this at [0].

Let me know if this sounds OK to you all.

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

[0]:
https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates


Thanks for raising this, I do hope I can help writing the content.


Thanks!


In
addition to this, we will at some point need to port the resource
reference generation to this guide as well.


That would be nice. I'm not sure if the user guide is the proper book, 
but we'll figure out where to put this with the doc team.
One thing that would be really useful for users would be to have 
versioned references. Correct me if I'm wrong, but I think that only the 
trunk doc is published on the developers doc site. It makes it hard to 
know which resources are available for a specific version of openstack.


Thanks,
Gauvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

[Gauvain Pocentek]

(Resending to add openstack-dev)

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

Le 2014-05-15 17:34, Gauvain Pocentek a écrit :

Hello,

This mail probably mainly concerns the doc team, but I guess that the
heat team wants to know what's going on.

We've shortly discussed the state of heat documentation with Anne
Gentle and Andreas Jaeger yesterday, and I'd like to share what we
think would be nice to do.

Currently we only have a small section in the user guide that
describes how to start a stack, but nothing documenting how to write
templates. The heat developer doc provides a good reference, but I
think it's not easy to use to get started.

So the idea is to add an "OpenStack Orchestration" chapter in the
user guide that would document how to use a cloud with heat, and how
to write templates.

I've drafted a spec to keep track of this at [0].

Let me know if this sounds OK to you all.

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com

[0]: 
https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates


___
Openstack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Neutron] Docs for new plugins

[Gauvain Pocentek]

Hi,

Le 2014-03-17 16:01, Steve Gordon a écrit :

- Original Message -

Edgar:

I don't see the configuration options for the OpenDaylight ML2
MechanismDriver
added here yet, even though the code was checked in well over a week 
ago.

How long does it take to autogenerate this page from the code?

Thanks!
Kyle


Adding the docs list, I suspect there are two issues here. The first
is that the generation of the config-reference content is initiated
manually and potentially hasn't been done since this was added. The
second is that prior to running it the flag mappings file needs to be
updated [1], this maps a given configuration option to a group and is
the main hole in our current automation process for this guide.

Edgar/Kyle can you check whether the new options are listed in there
and we'll arrange to get this re-generated for rc1?


FYI I've just submitted an updated flagmappings (and generated tables) 
for review: https://review.openstack.org/#/c/81013/


Let me know if the options are there and correctly categorized.

Thanks,

Gauvain



[1]
http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/neutron.flagmappings

On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana  
wrote:



You should be able to add your plugin here:

http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html

Thanks,

Edgar

From: Mohammad Banikazemi 
Date: Monday, March 10, 2014 2:40 PM
To: OpenStack List 
Cc: Edgar Magana 
Subject: Re: [openstack-dev] [Neutron] Docs for new plugins

Would like to know what to do for adding documentation for a new 
plugin.

Can someone point me to the right place/process please.

Thanks,

Mohammad

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev