Re: [openstack-dev] [OpenStack-docs] [Magnum] Using common tooling for API docs

[Anne Gentle]

On Fri, Aug 19, 2016 at 2:27 AM, Shuu Mutou  wrote:

> >   AFAIK, the API WG adopted Swagger (OpenAPI) as common tool for API
> > docs.
> >   Anne, has not the adoption been changed? Otherwise, do we need to
> > maintain much RST files also?
> >
> >
> >
> > It does say either/or in the API WG guideline:
> > http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
>
> Yes. Also Ken'ichi Omichi said.
>
>
> > This isn't about a contest between projects for the best approach. This
> > is about serving end-users the best information we can.
>
> Yes. Correct information is the best information. The Accuracy is more
> important than web experience. When I was a user (and SIer), the document
> accuracy had not been kept. So we had to read source code at last. And now,
> as a developer (mainly UI plugins), I don't want maintain overlapped
> content several times (API source code, API reference, helps in client,
> helps in WebUI, etc). So I spend efforts to the spec auto-generation.
>
>
> > I'm reporting what I'm seeing from a broader viewpoint than a single
> project.
> > I don't have a solution other than RST/YAML for common navigation, and
> I'm
> > asking you to provide ideas for that integration point.
> >
> > My vision is that even if you choose to publish with OpenAPI, you would
> > find a way to make this web experience better. We can do better than this
> > scattered approach. I'm asking you to find a way to unify and consider
> the
> > web experience of a consumer of OpenStack services. Can you generate HTML
> > that can plug into the openstackdocstheme we are providing as a common
> tool?
>
> I need to know about the "common tools". Please, let me know what is
> difference between HTMLs built by Lars's patch and by common tools? Or can
> fairy-slipper do that from OpenAPI file?
>
>
Sure, sounds like there's some info missing that I can clarify.

All HTML built for OpenStack sites are copied via FTP. There's no
difference except for the CSS and JavaScript provided by openstackdocstheme
and built by os-api-ref.

Fairy-slipper is no longer being worked on as a common solution to serving
all OpenStack API information. It was used for migration purposes.

Lars's patch could find a way to use the CSS and JS to create a seamless
experience for end-users.

Anne



>
> Thanks,
> Shu
>
>
> > -Original Message-
> > From: Anne Gentle [mailto:annegen...@justwriteclick.com]
> > Sent: Wednesday, August 17, 2016 11:55 AM
> > To: Mutou Shuu(武藤 周) 
> > Cc: openstack-dev@lists.openstack.org; m...@redhat.com; Katou Haruhiko(加
> > 藤 治彦) ; openstack-d...@lists.openstack.org;
> > kenichi.omi...@necam.com
> > Subject: Re: [OpenStack-docs] [openstack-dev] [Magnum] Using common
> > tooling for API docs
> >
> >
> >
> > On Tue, Aug 16, 2016 at 1:05 AM, Shuu Mutou  >  > wrote:
> >
> >
> >   Hi Anne,
> >
> >   AFAIK, the API WG adopted Swagger (OpenAPI) as common tool for API
> > docs.
> >   Anne, has not the adoption been changed? Otherwise, do we need to
> > maintain much RST files also?
> >
> >
> >
> > It does say either/or in the API WG guideline:
> > http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html
> >
> >
> >
> >   IMO, for that the reference and the source code doesn't have
> > conflict, these should be near each other as possible as follow. And it
> > decreases maintainance costs for documents, and increases document
> > reliability. So I believe our approach is more ideal.
> >
> >
> >
> >
> > This isn't about a contest between projects for the best approach. This
> > is about serving end-users the best information we can.
> >
> >
> >   The Best: the references generated from source code.
> >
> >
> >
> > I don't want to argue, but anything generated from the source code
> suffers
> > if the source code changes in a way that reviewers don't catch as a
> > backwards-incompatible change you can break your contract.
> >
> >
> >   Better: the references written in docstring.
> >
> >   We know some projects abandoned these approach, and then they uses
> > RST + YAML.
> >   But we hope decreasing maintainance cost for the documents. So we
> > should not create so much RST files, I think.
> >
> >
> >
> >
> > I think you'll see the evolution of our discussions over the years has
> > brought us to this point in time. Yes, there are trade-offs in these
> > decisions.
> >
> >
> >
> >   I'm proceeding auto-generation of swagger spec from magnum source
> > code using pecan-swagger [1], and improving pecan-swagger with Michael
> > McCune [2].
> >   These will generate almost Magnum API specs automatically in
> > OpenAPI format.
> >   Also, these approach can be adopted by other APIs that uses pecan
> > and WSME.
> >   Please check this also.
> >
> >
> >
> > I ask you to consider the experience of someone consuming 

Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Gal Sagie]

The entire core team voted +1.
I have added Vikas to Kuryr core team, Congrats and keep up the good work

Thanks
Gal.

On Thu, Aug 18, 2016 at 7:56 PM, Mohammad Banikazemi  wrote:

> +1
> Vikas has been working on various aspects of Kuryr with dedication for
> some time. So yes it's about time :)
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for Antoni Segura Puimedon ---08/16/2016
> 05:55:48 PM---Hi Kuryrs, I would like to propose Vikas Choudhary]Antoni
> Segura Puimedon ---08/16/2016 05:55:48 PM---Hi Kuryrs, I would like to
> propose Vikas Choudhary for the core team for the
>
> From: Antoni Segura Puimedon 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 08/16/2016 05:55 PM
> Subject: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork
> core
> --
>
>
>
> Hi Kuryrs,
>
> I would like to propose Vikas Choudhary for the core team for the
> kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
> at a very good rhythm in the past cycle and I believe he will help a lot to
> move kuryr forward.
>
> I would also like to propose him for the core team for the
> kuryr-kubernetes subproject since he has experience in the day to day work
> with kubernetes and can help with the review and refactoring of the
> prototype upstreaming.
>
> Regards,
>
> Antoni Segura Puimedon
> __
> 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 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
>
>


-- 
Best Regards ,

The G.
__
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] [TripleO] a new Undercloud install driven by Heat

[Joshua Harlow]

Our "TripleO" undercloud only requires a subset of the available
services that we run int the Overcloud. So ironic, heat, mistral,
zaqar, keystone, nova, swift, glance, neutron. These would mostly
satisfy our needs.



What I find interesting here is that there isn't much mention of 
jenkins, or something like it to produce the artifacts that the 
undercloud runs on-top of (likely from a combination of git sources, one 
for each project).


I would have thought jenkins (or equiv, zuul...) + some deployment tool 
(ansible, salt, rundeck, puppet, chef...) + ironic (for new hardware 
ingestion) would compose most of what people are using to get there 
'undercloud' working.


-Josh

__
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] [TripleO] a new Undercloud install driven by Heat

[Dan Prince]

On Wed, 2016-08-17 at 23:42 +, arkady_kanev...@dell.com wrote:
> What is the goal of undercloud?
> Primarily to deploy and manage/upgrade/update overcloud.
> It is not targeted for multitenancy and the only “application”
> running on it is overcloud.
> While it may have a couple of VMs running in undercloud it is more
> convenience than actual need.
>  
> So what are the OpenStack projects need to run in undercloud to
> achieve its primary goal?

Our "TripleO" undercloud only requires a subset of the available
services that we run int the Overcloud. So ironic, heat, mistral,
zaqar, keystone, nova, swift, glance, neutron. These would mostly
satisfy our needs.

>  
> Having robust undercloud so it can handle faults, like node or
> network failures, is more important than being able to deploy all
> OpenStack services on it.

I think we can have all of these things. By using Heat we are a step
closer to an HA undercloud. The fact that we can deploy all the other
services on the undercloud too may seem irrelevant, until it doesn't.
This sort of "everything can be in your undercloud" use case could be
quite cool in fact. I don't think we'd force the idea on anyone though
and if it takes some time for people to warm up to the latter use case
that is fine.

The primary points in doing all this are to help benefit the TripleO
undercloud via code and template re-use. I think this stands on its
own.

Dan

>  
> Arkady
> -Original Message-
> From: Dan Prince [mailto:dpri...@redhat.com] 
> Sent: Friday, August 05, 2016 6:35 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> Subject: Re: [openstack-dev] [TripleO] a new Undercloud install
> driven by Heat
> 
> On Fri, 2016-08-05 at 12:27 +0200, Dmitry Tantsur wrote:
> > On 08/04/2016 11:48 PM, Dan Prince wrote:
> > > 
> > > Last week I started some prototype work on what could be a new
> way 
> > > to install the Undercloud. The driving force behind this was some
> of 
> > > the recent "composable services" work we've done in TripleO so 
> > > initially I called in composable undercloud. There is an
> etherpad 
> > > here with links to some of the patches already posted upstream
> (many 
> > > of which stand as general imporovements on their own outside the 
> > > scope of what I'm talking about here).
> > > 
> > > https://etherpad.openstack.org/p/tripleo-composable-undercloud
> > > 
> > > The idea in short is that we could spin up a small single process
> > > all-
> > > in-one heat-all (engine and API) and thereby avoid things like 
> > > Rabbit, and MySQL. Then we can use Heat templates to drive the 
> > > Undercloud deployment just like we do in the Overcloud.
> > I don't want to sound rude, but please no. The fact that you have
> a 
> > hammer does not mean everything around is nails :( What problem
> are 
> > you trying to solve by doing it?
> 
> Several problems I think.
> 
> One is TripleO has gradually moved away from elements. And while we
> still use DIB elements for some things we no longer favor that tool
> and instead rely on Heat and config management tooling to do our
> stepwise deployment ordering. This leaves us using instack-undercloud 
> a tool built specifically to install elements locally as a means to
> create our undercloud. It works... and I do think we've packaged it
> nicely but it isn't the best architectural fit for where we are going
> I think. I actually think that from an end/user contribution
> standpoint using t-h- t could be quite nice for adding features to
> the Undercloud.
> 
> Second would be re-use. We just spent a huge amount of time in Newton
> (and some in Mitaka) refactoring t-h-t around composable services. So
> say you add a new composable service for Barbican in the Overcloud...
> wouldn't it be nice to be able to consume the same thing in your
> Undercloud as well? Right now you can't, you have to do some of the
> work twice and in quite different formats I think. Sure, there is
> some amount of shared puppet work but that is only part of the
> picture I think.
> 
> There are new features to think about here too. Once upon a time
> TripleO supported multi-node underclouds. When we switched to
> instack- undercloud we moved away from that. By switching back to
> tripleo-heat- templates we could structure our templates around
> abstractions like resource groups and the new 'deployed-server' trick
> that allow you to create machines either locally or perhaps via
> Ironic too. We could avoid Ironic entirely and always install the
> Undercloud on existing servers via 'deployed-server' as well.
> 
> Lastly, there is container work ongoing for the Overcloud. Again, I'd
> like to see us adopt a format that would allow it to be used in the
> Undercloud as well as opposed to having to re-implement features in
> the Over and Under clouds all the time.
> 
> > 
> > Undercloud installation is already sometimes fragile, but it's 
> > probably the least fragile part right now (at least from my 
> > 

Re: [openstack-dev] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Eduardo Gonzalez]

Thanks all for the support. I will do my best.

Regards

On Fri, Aug 19, 2016, 9:28 PM Steven Dake (stdake)  wrote:

> Eduardo,
>
> Their was a unanimous response in votes with no veto on this core reviewer
> nomination.  As a result, voting is closed early.
>
> Welcome to the Kolla core review team!  Looking for further good work from
> you!  I have added you to the kolla-core team in gerrit.  You should have
> access to full +2/-2 voting rights on patches, as well as voting rights on
> Kolla's policy votes.  If you need a primer ping me or another core
> reviewer.
>
> Regards
> -steve
>
>
> From: Steven Dake 
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, August 18, 2016 at 4:09 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [vote][kolla] Core nomination proposal for
> Eduardo Gonzalez Gutierrez (egonzales90 on irc)
>
> Kolla Core Review Team:
>
> I am nominating Eduardo for the core reviewer team.  His reviews are
> fantastic, as I'm sure most of you have seen after looking over the review
> queue.  His 30 day stats place him at #3 by review count [1] and 60 day
> stats [2] at #4 by review count.  He is also first to review a significant
> amount of the time – which is impressive for someone new to Kolla.  He
> participates in IRC and he has done some nice code contribution as well [3]
> including the big chunk of work on enabling Senlin in Kolla, the dockerfile
> customizations work, as well as a few documentation fixes.  Eduardo is not
> affiliated with any particular company.  As a result he is not full time on
> Kolla like many of our other core reviewers.  The fact that he is part time
> and still doing fantastically well at reviewing is a great sign of things
> to come :)
>
> Consider this nomination as my +1 vote.
>
> Voting is open for 7 days until August 24th.  Joining the core review team
> requires a majority of the core review team to approve within a 1 week
> period with no veto (-1) votes.  If a veto or unanimous decision is reached
> prior to August 24th, voting will close early.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/30
> [2] http://stackalytics.com/report/contribution/kolla/60
> [3]
> https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22
>
> __
> 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 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