Re: [openstack-dev] [senlin][stable] Nominating chenyb4 to Senlin Stable Maintainers Team

[Qiming Teng]

+2 from me.

Thanks.
 - Qiming

On Mon, Sep 10, 2018 at 09:56:10AM -0700, Duc Truong wrote:
> Hi Senlin Stable Team,
> 
> I would like to nominate Yuanbin Chen (chenyb4) to the Senlin stable
> review team. Yuanbin has been doing stable reviews and shown that he
> understands the policy for merging stable patches [1].
> 
> Voting is open for 7 days. Please reply with your +1 vote in favor or
> -1 as a veto vote.
> 
> [1] 
> https://review.openstack.org/#/q/branch:%255Estable/.*+reviewedby:cybing4%2540gmail.com
> 
> Regards,
> 
> Duc (dtruong)
> 
> __
> 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

Re: [openstack-dev] [goals][python3] mixed versions?

[Mathieu Gagné]

On Thu, Sep 13, 2018 at 10:14 PM, Doug Hellmann  wrote:
> Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400:
>> On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann  wrote:
>> > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:
>> >> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann  
>> >> wrote:
>> >> >
>> >> > IIRC, we also talked about not supporting multiple versions of
>> >> > python on a given node, so all of the services on a node would need
>> >> > to be upgraded together.
>> >> >
>> >>
>> >> Will services support both versions at some point for the same
>> >> OpenStack release? Or is it already the case?
>> >>
>> >> I would like to avoid having to upgrade Nova, Neutron and Ceilometer
>> >> at the same time since all end up running on a compute node and
>> >> sharing the same python version.
>> >
>> > We need to differentiate between what the upstream community supports
>> > and what distros support. In the meeting in Vancouver, we said that
>> > the community would support upgrading all of the services on a
>> > single node together. Distros may choose to support more complex
>> > configurations if they choose, and I'm sure patches related to any
>> > bugs would be welcome.
>>
>> We maintain and build our own packages with virtualenv. We aren't
>> bound to distribution packages.
>
> OK, I should rephrase then. I'm talking about the limits on the
> tests that I think are useful and reasonable to run upstream and
> for the community to support.
>
>> > But I don't think we can ask the community
>> > to support the infinite number of variations that would occur if
>> > we said we would test upgrading some services independently of
>> > others (unless I'm mistaken, we don't even do that for services
>> > all using the same version of python 2, today).
>>
>> This contradicts what I heard in fishbowl sessions from core reviewers
>> and read on IRC.
>> People were under the false impression that you need to upgrade
>> OpenStack in lock steps when in fact, it has never been the case.
>> You should be able to upgrade services individually.
>>
>> Has it changed since?
>
> I know that some deployments do upgrade components separately, and
> it works in some configurations.  All we talked about in Vancouver
> was how we would test upgrading python 2 to python 3, and given
> that the community has never, as far as I know, run upgrade tests
> in CI that staggered the upgrades of components on a given node,
> there seemed no reason to add those tests just for the python 2 to
> 3 case.
>
> Perhaps someone on the QA team can correct me if I'm wrong about the
> history there.
>

Or maybe it's me that misinterpreted the actual impact of not
supported 2 versions of Python at the same time.

Lets walk through an actual upgrade scenario.

I suppose the migration to Python 3 will happen around Stein and
therefore affects people upgrading from Rocky to Stein. At this point,
an operator should already be running Ubuntu Bionic which supports
both Python 2.7 and 3.6.

If that operator is using virtualenv (and not distribution packages),
it's only a matter a building new virtualenv using Python 3.6 for
Stein instead. This means installing both Python 2.7/3.6 on the same
node should be enough to upgrade and switch to Python 3.6 on a per
project/service basis.

My main use case is with the compute node which has multiple services
running. Come to think of it, it's a lot less impactful than I
thought.

Let me know if I got some details wrong. But if the steps are similar
to what I described above, I no longer have concerns or objections.

I think the only people who could be concerned is those doing rolling
upgrading, which could impact RPC message encoding as described by
Thomas. But you are already addressing it so I will just read and see
where this is going.

Thanks

--
Mathieu

__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Doug Hellmann]

Excerpts from Matthew Treinish's message of 2018-09-13 23:21:43 -0400:
> On Fri, Sep 14, 2018 at 10:09:26AM +0900, Ian Y. Choi wrote:
> > When I test PDF builds on current nova repo with master branch, it seems
> > that the rst document is too big
> > (876 pages with error) and more dealing with overcoming memory problems
> > was needed.
> > I would like to think how to overcome this, but it would be also nice if
> > someone shares advices or comments on this.
> 
> Hmm, I wasn't able to even get that far. When I tried a vanilla pdf build
> from nova master it only compiled 540 pages before it errored out on capacity
> exceeded. I know that the limit is adjustable in a config file, but I'm not
> sure if there is a more dynamic method for adjusting it.

The content is organized into sections based on audience/purpose now
(install, user, api, etc.). The latex builder supports extracting
different sections of the content to create separate output files by
starting at a different root file. I wonder if that's another reasonable
approach for us to take here?

Doug

__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Matthew Treinish]

On Fri, Sep 14, 2018 at 10:09:26AM +0900, Ian Y. Choi wrote:
> First of all, thanks a lot for nice summary - I would like to deeply
> read and put comments later.
> 
> And @mtreinish, please see my reply inline:
> 
> Matthew Treinish wrote on 9/14/2018 5:09 AM:
> > On Thu, Sep 13, 2018 at 07:23:53AM -0600, Doug Hellmann wrote:
> >> Excerpts from Michel Peterson's message of 2018-09-13 10:04:27 +0300:
> >>> On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
> >>> wrote:
> >>>
>  The longer version is that we want to continue to use the existing
>  tox environment in each project as the basis for the job, since
>  that allows teams to control the version of python used, the
>  dependencies installed, and add custom steps to their build (such
>  as for pre-processing the documentation). So, the new or updated
>  job will start by running "tox -e docs" as it does today. Then it
>  will run Sphinx again with the instructions to build PDF output,
>  and copy the results into the directory that the publish job will
>  use to sync to the web server. And then it will run the scripts to
>  build translated versions of the documentation as HTML, and copy
>  the results into place for publishing.
> 
> >>> Just a question out of curiosity. You mention that we still want to use 
> >>> the
> >>> docs environment because it allows fine grained control over how the
> >>> documentation is created. However, as I understand, the PDF output will
> >>> happen in a more standardized way and outside of that fine grained 
> >>> control,
> >>> right? That couldn't lead to differences in both documentations? Do we 
> >>> have
> >>> to even worry about that?
> >> Good question.  The idea is to run "tox -e docs" to get the regular
> >> HTML, then something like
> >>
> >>.tox/docs/bin/sphinx-build -b latex doc/build doc/build/latex
> >>cd doc/build/latex
> >>make
> >>cp doc/build/latex/*.pdf doc/build/html
> > To be fair, I've looked at this several times in the past, and sphinx's 
> > latex
> > generation is good enough for the simple case, but on more complex documents
> > it doesn't really work too well. For example, on nova I added this a while 
> > ago:
> >
> > https://github.com/openstack/nova/blob/master/tools/build_latex_pdf.sh
> 
> After seeing what the script is doing, I wanna divide into several parts
> and would like to tell with some generic approach:
> 
> - svg -> png
>  : PDF builds ideally convert all svg files into PDF with no problems,
> but there are some realistic problems
>    such as problems on determining bounding sbox size on vector svg
> files, and big memory problems with lots of tags in svg files.
>  : Maybe it would be solved if we check all svg files with correct
> formatting,
>    or if all svg files are converted to png files with temporal changes
> on rst file (.svg -> .png), wouldn't it?

Yeah we will have to do either. In my experience just converting to png images
is normally easier.

> 
> - non-latin code problems:
>  : By default, Sphinx uses latex builder, which doesn't support
> non-latin codes and customized fonts [1].
>    Documentation team tried to make use of xelatex instead of latex in
> Sphinx configuration and now it is overridden
>    on openstackdocstheme >=1.20. So non-latin code would not generate
> problems if you use openstackdocstheme >=1.20.

Ok sure, using XeTex will solve this problem. I typically still just use
pdflatex so back when I pushed that script (which was over 3 years ago)
I was trying to fix it by converting the non-latin characters by using latex
symbol equivalents for those characters. (which is a feature built-in to
sphinx, but it just misses a lot of symbols)

> 
> - other things
>  : I could not capture the background on other changes such as
> additional packages.
>    If u provide more background on other things, I would like to
> investigate on how to approach by changing a rst file
>    to make compatible with pdf builds or how to support all pdf builds
> on many project repos as much as possible.

The extra packages were part of the attempt to fix the non-latin characters
using latex symbols. Those packages are just added there so you can call
\checkmark and \ding{54} instead of ✔ and ✖.

> 
> When I test PDF builds on current nova repo with master branch, it seems
> that the rst document is too big
> (876 pages with error) and more dealing with overcoming memory problems
> was needed.
> I would like to think how to overcome this, but it would be also nice if
> someone shares advices or comments on this.

Hmm, I wasn't able to even get that far. When I tried a vanilla pdf build
from nova master it only compiled 540 pages before it errored out on capacity
exceeded. I know that the limit is adjustable in a config file, but I'm not
sure if there is a more dynamic method for adjusting it.

-Matt Treinish

> 
> 
> [1] https://tug.org/pipermail/xetex/2011-September/021324.html
> [2] 

Re: [openstack-dev] [octavia] Optimize the query of the octavia database

[Jeff Yang]

Thanks:
I found the correlative patch in neutron-lbaas:
https://review.openstack.org/#/c/568361/

The bug was marked high level by our QA team. I need to fix it as soon
as possible.
 Does Michael Johnson have any good suggestion? I am willing to
complete the
 repair work of this bug. If your patch still takes a while to prepare.

Michael Johnson  于2018年9月14日周五 上午7:56写道：

> This is a known regression in the Octavia API performance. It has an
> existing story[0] that is under development. You are correct, that
> star join is the root of the problem.
> Look for a patch soon.
>
> [0] https://storyboard.openstack.org/#!/story/2002933
>
> Michael
> On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
>  wrote:
> >
> > This was solved in neutron-lbaas recently, maybe we could adopt the same
> method for Octavia?
> >
> > Sent from my iPhone
> >
> > On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
> >
> > Hi, All
> >
> > As octavia resources increase, I found that running the "openstack
> loadbalancer list" command takes longer and longer. Sometimes a 504 error
> is reported.
> >
> > By reading the code, I found that octavia will performs complex left
> outer join queries when acquiring resources such as loadbalancer, listener,
> pool, etc. in order to only make one trip to the database.
> > Reference code: http://paste.openstack.org/show/730022 Line 133
> > Generated SQL statements: http://paste.openstack.org/show/730021
> >
> > So, I suggest that adjust the query strategy to provide different join
> queries for different resources.
> >
> > https://storyboard.openstack.org/#!/story/2003751
> >
> >
> __
> > 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
>
> __
> 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

Re: [openstack-dev] [goals][python3] mixed versions?

[Doug Hellmann]

Excerpts from Mathieu Gagné's message of 2018-09-13 20:09:12 -0400:
> On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann  wrote:
> > Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:
> >> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann  
> >> wrote:
> >> >
> >> > IIRC, we also talked about not supporting multiple versions of
> >> > python on a given node, so all of the services on a node would need
> >> > to be upgraded together.
> >> >
> >>
> >> Will services support both versions at some point for the same
> >> OpenStack release? Or is it already the case?
> >>
> >> I would like to avoid having to upgrade Nova, Neutron and Ceilometer
> >> at the same time since all end up running on a compute node and
> >> sharing the same python version.
> >
> > We need to differentiate between what the upstream community supports
> > and what distros support. In the meeting in Vancouver, we said that
> > the community would support upgrading all of the services on a
> > single node together. Distros may choose to support more complex
> > configurations if they choose, and I'm sure patches related to any
> > bugs would be welcome.
> 
> We maintain and build our own packages with virtualenv. We aren't
> bound to distribution packages.

OK, I should rephrase then. I'm talking about the limits on the
tests that I think are useful and reasonable to run upstream and
for the community to support.

> > But I don't think we can ask the community
> > to support the infinite number of variations that would occur if
> > we said we would test upgrading some services independently of
> > others (unless I'm mistaken, we don't even do that for services
> > all using the same version of python 2, today).
> 
> This contradicts what I heard in fishbowl sessions from core reviewers
> and read on IRC.
> People were under the false impression that you need to upgrade
> OpenStack in lock steps when in fact, it has never been the case.
> You should be able to upgrade services individually.
> 
> Has it changed since?

I know that some deployments do upgrade components separately, and
it works in some configurations.  All we talked about in Vancouver
was how we would test upgrading python 2 to python 3, and given
that the community has never, as far as I know, run upgrade tests
in CI that staggered the upgrades of components on a given node,
there seemed no reason to add those tests just for the python 2 to
3 case.

Perhaps someone on the QA team can correct me if I'm wrong about the
history there.

Doug

__
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] About microversion setting to enable nested resource provider

[Naichuan Sun]

Thank you very much, Eric.
Will check the patches.

BR.
Naichuan Sun

-Original Message-
From: Eric Fried [mailto:openst...@fried.cc] 
Sent: Thursday, September 13, 2018 11:14 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] About microversion setting to enable nested 
resource provider

There's a patch series in progress for this:

https://review.openstack.org/#/q/topic:use-nested-allocation-candidates

It needs some TLC. I'm sure gibi and tetsuro would welcome some help...

efried

On 09/13/2018 08:31 AM, Naichuan Sun wrote:
> Thank you very much, Jay.
> Is there somewhere I could set microversion(some configure file?), Or just 
> modify the source code to set it?
> 
> BR.
> Naichuan Sun
> 
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Thursday, September 13, 2018 9:19 PM
> To: Naichuan Sun ; OpenStack Development 
> Mailing List (not for usage questions) 
> 
> Cc: melanie witt ; efr...@us.ibm.com; Sylvain 
> Bauza 
> Subject: Re: About microversion setting to enable nested resource 
> provider
> 
> On 09/13/2018 06:39 AM, Naichuan Sun wrote:
>> Hi, guys,
>>
>> Looks n-rp is disabled by default because microversion matches 1.29 : 
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/plac
>> e
>> ment/handlers/allocation_candidate.py#L252
>>
>> Anyone know how to set the microversion to enable n-rp in placement?
> 
> It is the client which must send the 1.29+ placement API microversion header 
> to indicate to the placement API server that the client wants to receive 
> nested provider information in the allocation candidates response.
> 
> Currently, nova-scheduler calls the scheduler reportclient's
> get_allocation_candidates() method:
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a5
> 34410b5df/nova/scheduler/manager.py#L138
> 
> The scheduler reportclient's get_allocation_candidates() method currently 
> passes the 1.25 placement API microversion header:
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a5
> 34410b5df/nova/scheduler/client/report.py#L353
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a5
> 34410b5df/nova/scheduler/client/report.py#L53
> 
> In order to get the nested information returned in the allocation candidates 
> response, that would need to be upped to 1.29.
> 
> Best,
> -jay
> __
>  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
__
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] About microversion setting to enable nested resource provider

[Naichuan Sun]

Hi, Sylvain,

Thank you very much for the information. It is pity that I can’t attend the 
meeting.
I have a concern about reshaper in multi-type vgpu support.
In the old vgpu support, we only have one vgpu inventory in root resource 
provider, which means we only support one vgpu type. When do reshape, placement 
will send allocations(which include just one vgpu resource allocation 
information) to the driver, if the host have more than one pgpu/pgpug(which 
support different vgpu type), how do we know which pgpu/pgpug own the 
allocation information? Do we need to communicate with hypervisor the confirm 
that?

Thank you very much.

BR.
Naichuan Sun

From: Sylvain Bauza [mailto:sba...@redhat.com]
Sent: Thursday, September 13, 2018 11:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] About microversion setting to enable nested 
resource provider

Hey Naichuan,
FWIW, we discussed on the missing pieces for nested resource providers. See the 
(currently-in-use) etherpad https://etherpad.openstack.org/p/nova-ptg-stein and 
lookup for "closing the gap on nested resource providers" (L144 while I speak)

The fact that we are not able to schedule yet is a critical piece that we said 
we're going to work on it as soon as we can.

-Sylvain

On Thu, Sep 13, 2018 at 9:14 AM, Eric Fried 
mailto:openst...@fried.cc>> wrote:
There's a patch series in progress for this:

https://review.openstack.org/#/q/topic:use-nested-allocation-candidates

It needs some TLC. I'm sure gibi and tetsuro would welcome some help...

efried

On 09/13/2018 08:31 AM, Naichuan Sun wrote:
> Thank you very much, Jay.
> Is there somewhere I could set microversion(some configure file?), Or just 
> modify the source code to set it?
>
> BR.
> Naichuan Sun
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Thursday, September 13, 2018 9:19 PM
> To: Naichuan Sun mailto:naichuan@citrix.com>>; 
> OpenStack Development Mailing List (not for usage questions) 
> mailto:openstack-dev@lists.openstack.org>>
> Cc: melanie witt mailto:melwi...@gmail.com>>; 
> efr...@us.ibm.com; Sylvain Bauza 
> mailto:sba...@redhat.com>>
> Subject: Re: About microversion setting to enable nested resource provider
>
> On 09/13/2018 06:39 AM, Naichuan Sun wrote:
>> Hi, guys,
>>
>> Looks n-rp is disabled by default because microversion matches 1.29 :
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/place
>> ment/handlers/allocation_candidate.py#L252
>>
>> Anyone know how to set the microversion to enable n-rp in placement?
>
> It is the client which must send the 1.29+ placement API microversion header 
> to indicate to the placement API server that the client wants to receive 
> nested provider information in the allocation candidates response.
>
> Currently, nova-scheduler calls the scheduler reportclient's
> get_allocation_candidates() method:
>
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/manager.py#L138
>
> The scheduler reportclient's get_allocation_candidates() method currently 
> passes the 1.25 placement API microversion header:
>
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L353
>
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L53
>
> In order to get the nested information returned in the allocation candidates 
> response, that would need to be upped to 1.29.
>
> Best,
> -jay
> __
> 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

__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Ian Y. Choi]

First of all, thanks a lot for nice summary - I would like to deeply
read and put comments later.

And @mtreinish, please see my reply inline:

Matthew Treinish wrote on 9/14/2018 5:09 AM:
> On Thu, Sep 13, 2018 at 07:23:53AM -0600, Doug Hellmann wrote:
>> Excerpts from Michel Peterson's message of 2018-09-13 10:04:27 +0300:
>>> On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
>>> wrote:
>>>
 The longer version is that we want to continue to use the existing
 tox environment in each project as the basis for the job, since
 that allows teams to control the version of python used, the
 dependencies installed, and add custom steps to their build (such
 as for pre-processing the documentation). So, the new or updated
 job will start by running "tox -e docs" as it does today. Then it
 will run Sphinx again with the instructions to build PDF output,
 and copy the results into the directory that the publish job will
 use to sync to the web server. And then it will run the scripts to
 build translated versions of the documentation as HTML, and copy
 the results into place for publishing.

>>> Just a question out of curiosity. You mention that we still want to use the
>>> docs environment because it allows fine grained control over how the
>>> documentation is created. However, as I understand, the PDF output will
>>> happen in a more standardized way and outside of that fine grained control,
>>> right? That couldn't lead to differences in both documentations? Do we have
>>> to even worry about that?
>> Good question.  The idea is to run "tox -e docs" to get the regular
>> HTML, then something like
>>
>>.tox/docs/bin/sphinx-build -b latex doc/build doc/build/latex
>>cd doc/build/latex
>>make
>>cp doc/build/latex/*.pdf doc/build/html
> To be fair, I've looked at this several times in the past, and sphinx's latex
> generation is good enough for the simple case, but on more complex documents
> it doesn't really work too well. For example, on nova I added this a while 
> ago:
>
> https://github.com/openstack/nova/blob/master/tools/build_latex_pdf.sh

After seeing what the script is doing, I wanna divide into several parts
and would like to tell with some generic approach:

- svg -> png
 : PDF builds ideally convert all svg files into PDF with no problems,
but there are some realistic problems
   such as problems on determining bounding sbox size on vector svg
files, and big memory problems with lots of tags in svg files.
 : Maybe it would be solved if we check all svg files with correct
formatting,
   or if all svg files are converted to png files with temporal changes
on rst file (.svg -> .png), wouldn't it?

- non-latin code problems:
 : By default, Sphinx uses latex builder, which doesn't support
non-latin codes and customized fonts [1].
   Documentation team tried to make use of xelatex instead of latex in
Sphinx configuration and now it is overridden
   on openstackdocstheme >=1.20. So non-latin code would not generate
problems if you use openstackdocstheme >=1.20.

- other things
 : I could not capture the background on other changes such as
additional packages.
   If u provide more background on other things, I would like to
investigate on how to approach by changing a rst file
   to make compatible with pdf builds or how to support all pdf builds
on many project repos as much as possible.

When I test PDF builds on current nova repo with master branch, it seems
that the rst document is too big
(876 pages with error) and more dealing with overcoming memory problems
was needed.
I would like to think how to overcome this, but it would be also nice if
someone shares advices or comments on this.


With many thanks,

/Ian

[1] https://tug.org/pipermail/xetex/2011-September/021324.html
[2] https://review.openstack.org/#/c/552070/5/openstackdocstheme/ext.py@227

> To work around some issues with this workflow. It was enough to get the
> generated latex to actually compile back then. But, that script has bitrotted
> and needs to be updated, because the latex from sphinx for nova's docs no
> longer compiles. (also I submitted a patch to sphinx in the meantime to
> fix the check mark latex output) I'm afraid that it'll be a constant game
> of cat and mouse trying to get everything to build.
>
> I think that we'll find that on most projects' documentation we will need
> to massage the latex output from sphinx to build pdfs.
>
> -Matt Treinish
>
>> We would run the HTML translation builds in a similar way by invoking
>> sphinx-build from the virtualenv repeatedly with different locale
>> settings based on what translations exist.
>>
>> In my earlier comment, I was thinking of the case where a team runs
>> a script to generate rst content files before invoking sphinx to
>> build the HTML. That script would have been run before the PDF
>> generation happens, so the content should be the same. That also
>> applies for anyone using sphinx add-ons, which will be 

Re: [openstack-dev] [release][searchlight] Need rights to create stable branches and tags

[Trinh Nguyen]

Hi Thierry,

Thanks for the information. I will look into those.

Bests,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Fri, Sep 14, 2018 at 5:30 AM Thierry Carrez 
wrote:

> Trinh Nguyen wrote:
> > Dear Release Management team,
> >
> > As we're reaching the Stein-1 milestone, I would like to prepare the
> > branches and tags. According to the documents, it's the job of the
> > Release Management team but it also says I as the PTL can do it. I
> > wonder which is the best way because Searchlight has missed several
> > milestones.
> >
> > It would be great if anyone in the Release Management team can give me
> > some advice.
>
> As PTL, you should request tags (releases) by proposing a change to the
> openstack/releases repository. The process is explained in
>
> https://releases.openstack.org/reference/using.html#requesting-a-release
>
> and also in:
>
>
> https://docs.openstack.org/project-team-guide/release-management.html#how-to-release
>
> No rights are actually needed, we just check that the requester is the
> PTL or the designated release liaison before approving the request.
>
> Let us know if you have other questions !
>
> --
> Thierry Carrez (ttx)
>
> __
> 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

Re: [openstack-dev] [goals][python3] mixed versions?

[Mathieu Gagné]

On Thu, Sep 13, 2018 at 7:41 PM, Doug Hellmann  wrote:
> Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:
>> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann  wrote:
>> >
>> > IIRC, we also talked about not supporting multiple versions of
>> > python on a given node, so all of the services on a node would need
>> > to be upgraded together.
>> >
>>
>> Will services support both versions at some point for the same
>> OpenStack release? Or is it already the case?
>>
>> I would like to avoid having to upgrade Nova, Neutron and Ceilometer
>> at the same time since all end up running on a compute node and
>> sharing the same python version.
>
> We need to differentiate between what the upstream community supports
> and what distros support. In the meeting in Vancouver, we said that
> the community would support upgrading all of the services on a
> single node together. Distros may choose to support more complex
> configurations if they choose, and I'm sure patches related to any
> bugs would be welcome.

We maintain and build our own packages with virtualenv. We aren't
bound to distribution packages.


> But I don't think we can ask the community
> to support the infinite number of variations that would occur if
> we said we would test upgrading some services independently of
> others (unless I'm mistaken, we don't even do that for services
> all using the same version of python 2, today).

This contradicts what I heard in fishbowl sessions from core reviewers
and read on IRC.
People were under the false impression that you need to upgrade
OpenStack in lock steps when in fact, it has never been the case.
You should be able to upgrade services individually.

Has it changed since?

--
Mathieu

__
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] [octavia] Optimize the query of the octavia database

[Michael Johnson]

This is a known regression in the Octavia API performance. It has an
existing story[0] that is under development. You are correct, that
star join is the root of the problem.
Look for a patch soon.

[0] https://storyboard.openstack.org/#!/story/2002933

Michael
On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
 wrote:
>
> This was solved in neutron-lbaas recently, maybe we could adopt the same 
> method for Octavia?
>
> Sent from my iPhone
>
> On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
>
> Hi, All
>
> As octavia resources increase, I found that running the "openstack 
> loadbalancer list" command takes longer and longer. Sometimes a 504 error is 
> reported.
>
> By reading the code, I found that octavia will performs complex left outer 
> join queries when acquiring resources such as loadbalancer, listener, pool, 
> etc. in order to only make one trip to the database.
> Reference code: http://paste.openstack.org/show/730022 Line 133
> Generated SQL statements: http://paste.openstack.org/show/730021
>
> So, I suggest that adjust the query strategy to provide different join 
> queries for different resources.
>
> https://storyboard.openstack.org/#!/story/2003751
>
> __
> 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

__
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-operators] [all] Consistent policy names

[Michael Johnson]

In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
which maps to the "os--api::" format.

I selected it as it uses the service-type[1], references the API
resource, and then the method. So it maps well to the API reference[2]
for the service.

[0] https://docs.openstack.org/octavia/latest/configuration/policy.html
[1] https://service-types.openstack.org/
[2] 
https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer

Michael
On Wed, Sep 12, 2018 at 12:52 PM Tim Bell  wrote:
>
> So +1
>
>
>
> Tim
>
>
>
> From: Lance Bragstad 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Wednesday, 12 September 2018 at 20:43
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , OpenStack Operators 
> 
> Subject: [openstack-dev] [all] Consistent policy names
>
>
>
> The topic of having consistent policy names has popped up a few times this 
> week. Ultimately, if we are to move forward with this, we'll need a 
> convention. To help with that a little bit I started an etherpad [0] that 
> includes links to policy references, basic conventions *within* that service, 
> and some examples of each. I got through quite a few projects this morning, 
> but there are still a couple left.
>
>
>
> The idea is to look at what we do today and see what conventions we can come 
> up with to move towards, which should also help us determine how much each 
> convention is going to impact services (e.g. picking a convention that will 
> cause 70% of services to rename policies).
>
>
>
> Please have a look and we can discuss conventions in this thread. If we come 
> to agreement, I'll start working on some documentation in oslo.policy so that 
> it's somewhat official because starting to renaming policies.
>
>
>
> [0] https://etherpad.openstack.org/p/consistent-policy-names
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
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] [goals][python3] mixed versions?

[Doug Hellmann]

Excerpts from Mathieu Gagné's message of 2018-09-13 14:12:56 -0400:
> On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann  wrote:
> >
> > IIRC, we also talked about not supporting multiple versions of
> > python on a given node, so all of the services on a node would need
> > to be upgraded together.
> >
> 
> Will services support both versions at some point for the same
> OpenStack release? Or is it already the case?
> 
> I would like to avoid having to upgrade Nova, Neutron and Ceilometer
> at the same time since all end up running on a compute node and
> sharing the same python version.

We need to differentiate between what the upstream community supports
and what distros support. In the meeting in Vancouver, we said that
the community would support upgrading all of the services on a
single node together. Distros may choose to support more complex
configurations if they choose, and I'm sure patches related to any
bugs would be welcome. But I don't think we can ask the community
to support the infinite number of variations that would occur if
we said we would test upgrading some services independently of
others (unless I'm mistaken, we don't even do that for services
all using the same version of python 2, today).

Doug

__
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] [goals][python3] mixed versions?

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-09-13 12:08:08 -0600:
> On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:
> > > Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> > > > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> > > > > The process of operators upgrading Python versions across their
> > fleet came
> > > > > up this morning. It's fairly obvious that operators will want to do
> > this in
> > > > > a rolling fashion.
> > > > >
> > > > > Has anyone considered doing this in CI? For example, running
> > multinode
> > > > > grenade with python 2 on one node and python 3 on the other node.
> > > > >
> > > > > Should we (openstack) test this situation, or even care?
> > > > >
> > > >
> > > > This came up in a Vancouver summit session (the python3 one I think).
> > General consensus there seemed to be that we should have grenade jobs that
> > run python2 on the old side and python3 on the new side and test the update
> > from one to another through a release that way. Additionally there was
> > thought that the nova partial job (and similar grenade jobs) could hold the
> > non upgraded node on python2 and that would talk to a python3 control plane.
> > > >
> > > > I haven't seen or heard of anyone working on this yet though.
> > > >
> > > > Clark
> > > >
> > >
> > > IIRC, we also talked about not supporting multiple versions of
> > > python on a given node, so all of the services on a node would need
> > > to be upgraded together.
> > >
> > > Doug
> >
> > I spent a little time talking with the QA team about setting up
> > this job, and Attila pointed out that we should think about what
> > exactly we think would break during a 2-to-3 in-place upgrade like
> > this.
> >
> > Keeping in mind that we are still testing initial installation under
> > both versions and upgrades under python 2, do we have any specific
> > concerns about the python *version* causing upgrade issues?
> >
> 
> A specific example brought up in the ironic room was the way we encode
> exceptions in oslo.messaging for transmitting over RPC. I know that we've
> found encoding bugs in that in the past, and one can imagine that RPC
> between a service running on py2 and a service running on py3 could have
> similar issues.

Mixing python 2 and 3 components of the same service across nodes
does seem like an interesting case. I wonder if it's something we
could build a functional test job in oslo.messaging for, though,
without having to test every service separately. I'd be happy if
someone did that.

> It's definitely edge cases that we'd be catching here (if any), so I'm
> personally fine with assuming it will just work. But I wanted to pose the
> question to the list, as we agreed this isn't only an ironic problem.

Yes, definitely. I think it's likely to be a bit of work to set up the
jobs and run them for all services, which is why I'm trying to
understand if it's really needed. Thinking through the cases on the list
is a good way to get folks to poke holes in any assertions, so I
appreciate that you started the thread and that everyone is
participating.

Doug

__
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] podman: varlink interface for nice API calls

[Emilien Macchi]

I suggest that we continue the discussion in this freshly created specs:
https://review.openstack.org/602480

http://logs.openstack.org/80/602480/2/check/openstack-tox-docs/9da610c/html/specs/stein/podman.html

Any feedback and inputs are welcome.
Thanks,

On Thu, Sep 13, 2018 at 3:36 AM Bogdan Dobrelya  wrote:

> On 8/27/18 6:38 PM, Fox, Kevin M wrote:
> > I think in this context, kubelet without all of kubernetes still has the
> value that it provides an abstraction layer that podmon/paunch is being
> suggested to handle.
> >
> > It does not need the things you mention, network, sidecar, scaleup/down,
> etc. You can use as little as you want.
> >
> > For example, make a pod yaml per container with hostNetwork: true. it
> will run just like it was on the host then. You can do just one container.
> no sidecars necessary. Without the apiserver, it can't do scaleup/down even
> if you wanted to.
> >
> > It provides declarative yaml based management of containers, similar to
> paunch. so you can skip needing that component.
>
> That would be a step into the right direction IMO.
>
> >
> > It also already provides crio and docker support via cri.
> >
> > It does provide a little bit of orchestration, in that you drive things
> with declarative yaml. You drop in a yaml file in
> /etc/kubernetes/manifests, and it will create the container. you delete it,
> it removes the container. If you change it, it will update the container.
> and if something goes wrong with the container, it will try and get it back
> to the requested state automatically. And, it will recover the containers
> on reboot without help.
> >
> > Thanks,
> > Kevin
> >
> > 
> > From: Sergii Golovatiuk [sgolo...@redhat.com]
> > Sent: Monday, August 27, 2018 3:46 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
> nice   API calls
> >
> > Hi,
> >
> > On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra 
> wrote:
> >> On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk  >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra 
> wrote:
>  On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker 
> wrote:
> >>> Steve mentioned kubectl (kubernetes CLI which communicates with
> >>
> >>
> >> Not sure what he meant. May be I miss something, but not heard of
> 'kubectl
> >> standalone', though he might have meant standalone k8s cluster on every
> node
> >> as you think.
> >>
> >>>
> >>> kube-api) not kubelet which is only one component of kubernetes. All
> >>> kubernetes components may be compiled as one binary (hyperkube) which
> >>> can be used to minimize footprint. Generated ansible for kubelet is
> >>> not enough as kubelet doesn't have any orchestration logic.
> >>
> >>
> >> What orchestration logic do we've with TripleO atm? AFAIK we've provide
> >> roles data for service placement across nodes, right?
> >> I see standalone kubelet as a first step for scheduling openstack
> services
> >> with in k8s cluster in the future (may be).
> >
> > It's half measure. I don't see any advantages of that move. We should
> > either adopt whole kubernetes or doesn't use its components at all as
> > the maintenance cost will be expensive. Using kubelet requires to
> > resolve networking communication, scale-up/down, sidecar, or inter
> > services dependencies.
> >
> >>
> >
> > This was a while ago now so this could be worth revisiting in the
> > future.
> > We'll be making gradual changes, the first of which is using podman
> to
> > manage single containers. However podman has native support for the
> pod
> > format, so I'm hoping we can switch to that once this transition is
> > complete. Then evaluating kubectl becomes much easier.
> >
> >> Question. Rather then writing a middle layer to abstract both
> >> container
> >> engines, couldn't you just use CRI? CRI is CRI-O's native language,
> >> and
> >> there is support already for Docker as well.
> >
> >
> > We're not writing a middle layer, we're leveraging one which is
> already
> > there.
> >
> > CRI-O is a socket interface and podman is a CLI interface that both
> sit
> > on
> > top of the exact same Go libraries. At this point, switching to
> podman
> > needs
> > a much lower development effort because we're replacing docker CLI
> > calls.
> >
>  I see good value in evaluating kubelet standalone and leveraging it's
>  inbuilt grpc interfaces with cri-o (rather than using podman) as a
> long
>  term
>  strategy, unless we just want to provide an alternative to docker
>  container
>  runtime with cri-o.
> >>>
> >>> I see no value using kubelet without kubernetes IMHO.
> >>>
> >>>
> 
> >>
> >>
> >> Thanks,
> >> Kevin
> >> 
> >> From: Jay Pipes [jaypi...@gmail.com]
> >> 

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

[Jeremy Stanley]

On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote:
[...]
> Again, I'm not saying TC members should be doing all of the work
> themselves. That's not realistic, especially when critical parts
> of any major effort are going to involve developers from projects
> on which none of the TC members are active contributors (e.g.
> nova). I want to see TC members herd cats, for lack of a better
> analogy, and help out technically (with code) where possible.

I can respect that. I think that OpenStack made a mistake in naming
its community management governance body the "technical" committee.
I do agree that having TC members engage in activities with tangible
outcomes is preferable, and that the needs of the users of its
software should weigh heavily in prioritization decisions, but those
are not the only problems our community faces nor is it as if there
are no other responsibilities associated with being a TC member.

> Given the repeated mention of how the "help wanted" list continues
> to not draw in contributors, I think the recruiting role of the TC
> should take a back seat to actually stepping in and helping work
> on those items directly. For example, Sean McGinnis is taking an
> active role in the operators guide and other related docs that
> continue to be discussed at every face to face event since those
> docs were dropped from openstack-manuals (in Pike).

I completely agree that the help wanted list hasn't worked out well
in practice. It was based on requests from the board of directors to
provide some means of communicating to their business-focused
constituency where resources would be most useful to the project.
We've had a subsequent request to reorient it to be more like a set
of job descriptions along with clearer business use cases explaining
the benefit to them of contributing to these efforts. In my opinion
it's very much the responsibility of the TC to find ways to
accomplish these sorts of things as well.

> I think it's fair to say that the people generally elected to the
> TC are those most visible in the community (it's a popularity
> contest) and those people are generally the most visible because
> they have the luxury of working upstream the majority of their
> time. As such, it's their duty to oversee and spend time working
> on the hard cross-project technical deliverables that operators
> and users are asking for, rather than think of an infinite number
> of ways to try and draw *others* to help work on those gaps.

But not everyone who is funded for full-time involvement with the
community is necessarily "visible" in ways that make them electable.
Higher-profile involvement in such activities over time is what gets
them the visibility to be more easily elected to governance
positions via "popularity contest" mechanics.

> As I think it's the role of a PTL within a given project to have a
> finger on the pulse of the technical priorities of that project
> and manage the developers involved (of which the PTL certainly may
> be one), it's the role of the TC to do the same across openstack
> as a whole. If a PTL doesn't have the time or willingness to do
> that within their project, they shouldn't be the PTL. The same
> goes for TC members IMO.

Completely agree, I think we might just disagree on where to strike
the balance of purely technical priorities for the TC (as I
personally think the TC is somewhat incorrectly named).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [release][searchlight] Need rights to create stable branches and tags

[Thierry Carrez]

Trinh Nguyen wrote:
> Dear Release Management team,
> 
> As we're reaching the Stein-1 milestone, I would like to prepare the
> branches and tags. According to the documents, it's the job of the
> Release Management team but it also says I as the PTL can do it. I
> wonder which is the best way because Searchlight has missed several
> milestones.
> 
> It would be great if anyone in the Release Management team can give me
> some advice.

As PTL, you should request tags (releases) by proposing a change to the
openstack/releases repository. The process is explained in

https://releases.openstack.org/reference/using.html#requesting-a-release

and also in:

https://docs.openstack.org/project-team-guide/release-management.html#how-to-release

No rights are actually needed, we just check that the requester is the
PTL or the designated release liaison before approving the request.

Let us know if you have other questions !

-- 
Thierry Carrez (ttx)

__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Matthew Treinish]

On Thu, Sep 13, 2018 at 07:23:53AM -0600, Doug Hellmann wrote:
> Excerpts from Michel Peterson's message of 2018-09-13 10:04:27 +0300:
> > On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
> > wrote:
> > 
> > > The longer version is that we want to continue to use the existing
> > > tox environment in each project as the basis for the job, since
> > > that allows teams to control the version of python used, the
> > > dependencies installed, and add custom steps to their build (such
> > > as for pre-processing the documentation). So, the new or updated
> > > job will start by running "tox -e docs" as it does today. Then it
> > > will run Sphinx again with the instructions to build PDF output,
> > > and copy the results into the directory that the publish job will
> > > use to sync to the web server. And then it will run the scripts to
> > > build translated versions of the documentation as HTML, and copy
> > > the results into place for publishing.
> > >
> > 
> > Just a question out of curiosity. You mention that we still want to use the
> > docs environment because it allows fine grained control over how the
> > documentation is created. However, as I understand, the PDF output will
> > happen in a more standardized way and outside of that fine grained control,
> > right? That couldn't lead to differences in both documentations? Do we have
> > to even worry about that?
> 
> Good question.  The idea is to run "tox -e docs" to get the regular
> HTML, then something like
> 
>.tox/docs/bin/sphinx-build -b latex doc/build doc/build/latex
>cd doc/build/latex
>make
>cp doc/build/latex/*.pdf doc/build/html

To be fair, I've looked at this several times in the past, and sphinx's latex
generation is good enough for the simple case, but on more complex documents
it doesn't really work too well. For example, on nova I added this a while ago:

https://github.com/openstack/nova/blob/master/tools/build_latex_pdf.sh

To work around some issues with this workflow. It was enough to get the
generated latex to actually compile back then. But, that script has bitrotted
and needs to be updated, because the latex from sphinx for nova's docs no
longer compiles. (also I submitted a patch to sphinx in the meantime to
fix the check mark latex output) I'm afraid that it'll be a constant game
of cat and mouse trying to get everything to build.

I think that we'll find that on most projects' documentation we will need
to massage the latex output from sphinx to build pdfs.

-Matt Treinish

> 
> We would run the HTML translation builds in a similar way by invoking
> sphinx-build from the virtualenv repeatedly with different locale
> settings based on what translations exist.
> 
> In my earlier comment, I was thinking of the case where a team runs
> a script to generate rst content files before invoking sphinx to
> build the HTML. That script would have been run before the PDF
> generation happens, so the content should be the same. That also
> applies for anyone using sphinx add-ons, which will be available
> to the latex builder because we'll be using the version of sphinx
> installed in the virtualenv managed by tox.
> 


signature.asc
Description: PGP signature
__
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-sigs] Open letter/request to TC candidates (and existing elected officials)

[Samuel Cassiba]

On Thu, Sep 13, 2018 at 9:14 AM, Fox, Kevin M  wrote:
> How about stated this way,
> Its the tc's responsibility to get it done. Either by delegating the 
> activity, or by doing it themselves. But either way, it needs to get done. 
> Its a ball that has been dropped too much in OpenStacks history. If no one is 
> ultimately responsible, balls will keep getting dropped.
>
> Thanks,
> Kevin

I see the role of TC the same way I do the PTL hat, but on more of a
meta scale: too much direct involvement can stifle things. On the
inverse, not enough involvement can result in people saying one's work
is legacy, to be nice, or dead, at worst.

All too often, we humans get hung up on the definitions of words,
sometimes to the point of inaction. It seems only when someone says
sod it do things move forward, regardless of anyone's level of
involvement.

I look to TC as the group that sets the tone, de facto product owners,
to paraphrase from OpenStack's native tongue. The more hands-on an
individual is with the output, TC or not, a perception arises that a
given effort needs only that person's attention; thereby, setting a
much different narrative than might otherwise be immediately noticed
or desired.

The place I see TC is making sure that there is meaningful progress on
agreed-upon efforts, however that needs to exist. Sometimes that might
be recruiting, but I don't see browbeating social media to be
particularly valuable from an individual standpoint. Sometimes that
would be collaborating through code, if it comes down to it. From an
overarching perspective, I view hands-on coding by TC to be somewhat
of a last resort effort due to individual commitments.

Perceptions surrounding actions, like the oft used 'stepping up'
phrase, creates an effect where people do not carve out enough time to
effect change, becoming too busy, repeat ad infinitum.

Best,
Samuel

__
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] [goals][python3] mixed versions?

[Mathieu Gagné]

On Wed, Sep 12, 2018 at 2:04 PM, Doug Hellmann  wrote:
>
> IIRC, we also talked about not supporting multiple versions of
> python on a given node, so all of the services on a node would need
> to be upgraded together.
>

Will services support both versions at some point for the same
OpenStack release? Or is it already the case?

I would like to avoid having to upgrade Nova, Neutron and Ceilometer
at the same time since all end up running on a compute node and
sharing the same python version.

--
Mathieu

__
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] [goals][python3] mixed versions?

[Jim Rollenhagen]

On Wed, Sep 12, 2018 at 2:28 PM, Doug Hellmann 
wrote:

> Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:
> > Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> > > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> > > > The process of operators upgrading Python versions across their
> fleet came
> > > > up this morning. It's fairly obvious that operators will want to do
> this in
> > > > a rolling fashion.
> > > >
> > > > Has anyone considered doing this in CI? For example, running
> multinode
> > > > grenade with python 2 on one node and python 3 on the other node.
> > > >
> > > > Should we (openstack) test this situation, or even care?
> > > >
> > >
> > > This came up in a Vancouver summit session (the python3 one I think).
> General consensus there seemed to be that we should have grenade jobs that
> run python2 on the old side and python3 on the new side and test the update
> from one to another through a release that way. Additionally there was
> thought that the nova partial job (and similar grenade jobs) could hold the
> non upgraded node on python2 and that would talk to a python3 control plane.
> > >
> > > I haven't seen or heard of anyone working on this yet though.
> > >
> > > Clark
> > >
> >
> > IIRC, we also talked about not supporting multiple versions of
> > python on a given node, so all of the services on a node would need
> > to be upgraded together.
> >
> > Doug
>
> I spent a little time talking with the QA team about setting up
> this job, and Attila pointed out that we should think about what
> exactly we think would break during a 2-to-3 in-place upgrade like
> this.
>
> Keeping in mind that we are still testing initial installation under
> both versions and upgrades under python 2, do we have any specific
> concerns about the python *version* causing upgrade issues?
>

A specific example brought up in the ironic room was the way we encode
exceptions in oslo.messaging for transmitting over RPC. I know that we've
found encoding bugs in that in the past, and one can imagine that RPC
between a service running on py2 and a service running on py3 could have
similar issues.

It's definitely edge cases that we'd be catching here (if any), so I'm
personally fine with assuming it will just work. But I wanted to pose the
question to the list, as we agreed this isn't only an ironic problem.

// jim
__
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] [goals][upgrade-checkers] Week R-31 update

[Ben Nemec]

On 09/12/2018 01:57 PM, Doug Hellmann wrote:

Excerpts from Ben Nemec's message of 2018-09-12 13:51:16 -0600:


On 09/04/2018 06:49 PM, Matt Riedemann wrote:

On 9/4/2018 6:39 PM, Ben Nemec wrote:

Would it be helpful to factor some of the common code out into an Oslo
library so projects basically just have to subclass, implement check
functions, and add them to the _upgrade_checks dict? It's not a huge
amount of code, but a bunch of it seems like it would need to be
copy-pasted into every project. I have a tentative topic on the Oslo
PTG schedule for this but figured I should check if it's something we
even want to pursue.


Yeah I'm not opposed to trying to pull the nova stuff into a common
library for easier consumption in other projects, I just haven't devoted
the time for it, nor will I probably have the time to do it. If others
are willing to investigate that it would be great.



Okay, here's a first shot at such a library:
https://github.com/cybertron/oslo.upgradecheck

Lots of rough edges that would need to be addressed before it could be
released, but it demonstrates the basic idea I had in mind for this. The
upgradecheck module contains the common code, and __main__.py is a demo
use of the code.

-Ben



Nice! Let's get that imported into gerrit and keep iterating on it to
make it usable for the goal. Maybe we can get one of the projects most
interested in working on this goal early to help with testing and UX
feedback.



Okay, I got all the test jobs working and even added a few basic unit 
tests. I think it's about ready for import so I'll take a look at doing 
that soon.


__
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-sigs] Open letter/request to TC candidates (and existing elected officials)

[Zhipeng Huang]

On Thu, Sep 13, 2018 at 10:15 AM Fox, Kevin M  wrote:

> How about stated this way,
> Its the tc's responsibility to get it done. Either by delegating the
> activity, or by doing it themselves. But either way, it needs to get done.
> Its a ball that has been dropped too much in OpenStacks history. If no one
> is ultimately responsible, balls will keep getting dropped.
>
> Thanks,
> Kevin
>

+1 Kevin
-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [octavia] Optimize the query of the octavia database

[Erik Olof Gunnar Andersson]

This was solved in neutron-lbaas recently, maybe we could adopt the same method 
for Octavia?

Sent from my iPhone

On Sep 13, 2018, at 4:54 AM, Jeff Yang 
mailto:yjf1970231...@gmail.com>> wrote:


Hi, All

As octavia resources increase, I found that running the "openstack loadbalancer 
list" command takes longer and longer. Sometimes a 504 error is reported.

By reading the code, I found that octavia will performs complex left outer join 
queries when acquiring resources such as loadbalancer, listener, pool, etc. in 
order to only make one trip to the database.
Reference code: http://paste.openstack.org/show/730022 Line 133
Generated SQL statements: http://paste.openstack.org/show/730021

So, I suggest that adjust the query strategy to provide different join queries 
for different resources.

https://storyboard.openstack.org/#!/story/2003751

__
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

Re: [openstack-dev] [openstack][infra]Including Functional Tests in Coverage

[Chris Dent]

On Wed, 12 Sep 2018, Michael Johnson wrote:


We do this in Octavia. The openstack-tox-cover calls the cover
environment in tox.ini, so you can add it there.


We've got this in progress for placement as well:

https://review.openstack.org/#/c/600501/
https://review.openstack.org/#/c/600502/

It works well and is pretty critical in placement because most of
the "important" tests are functional.
--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] About microversion setting to enable nested resource provider

[Sylvain Bauza]

Hey Naichuan,
FWIW, we discussed on the missing pieces for nested resource providers. See
the (currently-in-use) etherpad
https://etherpad.openstack.org/p/nova-ptg-stein and lookup for "closing the
gap on nested resource providers" (L144 while I speak)

The fact that we are not able to schedule yet is a critical piece that we
said we're going to work on it as soon as we can.

-Sylvain

On Thu, Sep 13, 2018 at 9:14 AM, Eric Fried  wrote:

> There's a patch series in progress for this:
>
> https://review.openstack.org/#/q/topic:use-nested-allocation-candidates
>
> It needs some TLC. I'm sure gibi and tetsuro would welcome some help...
>
> efried
>
> On 09/13/2018 08:31 AM, Naichuan Sun wrote:
> > Thank you very much, Jay.
> > Is there somewhere I could set microversion(some configure file?), Or
> just modify the source code to set it?
> >
> > BR.
> > Naichuan Sun
> >
> > -Original Message-
> > From: Jay Pipes [mailto:jaypi...@gmail.com]
> > Sent: Thursday, September 13, 2018 9:19 PM
> > To: Naichuan Sun ; OpenStack Development
> Mailing List (not for usage questions) 
> > Cc: melanie witt ; efr...@us.ibm.com; Sylvain Bauza
> 
> > Subject: Re: About microversion setting to enable nested resource
> provider
> >
> > On 09/13/2018 06:39 AM, Naichuan Sun wrote:
> >> Hi, guys,
> >>
> >> Looks n-rp is disabled by default because microversion matches 1.29 :
> >> https://github.com/openstack/nova/blob/master/nova/api/openstack/place
> >> ment/handlers/allocation_candidate.py#L252
> >>
> >> Anyone know how to set the microversion to enable n-rp in placement?
> >
> > It is the client which must send the 1.29+ placement API microversion
> header to indicate to the placement API server that the client wants to
> receive nested provider information in the allocation candidates response.
> >
> > Currently, nova-scheduler calls the scheduler reportclient's
> > get_allocation_candidates() method:
> >
> > https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a
> 534410b5df/nova/scheduler/manager.py#L138
> >
> > The scheduler reportclient's get_allocation_candidates() method
> currently passes the 1.25 placement API microversion header:
> >
> > https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a
> 534410b5df/nova/scheduler/client/report.py#L353
> >
> > https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a
> 534410b5df/nova/scheduler/client/report.py#L53
> >
> > In order to get the nested information returned in the allocation
> candidates response, that would need to be upped to 1.29.
> >
> > Best,
> > -jay
> > 
> __
> > 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
>
__
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] About microversion setting to enable nested resource provider

[Eric Fried]

There's a patch series in progress for this:

https://review.openstack.org/#/q/topic:use-nested-allocation-candidates

It needs some TLC. I'm sure gibi and tetsuro would welcome some help...

efried

On 09/13/2018 08:31 AM, Naichuan Sun wrote:
> Thank you very much, Jay.
> Is there somewhere I could set microversion(some configure file?), Or just 
> modify the source code to set it?
> 
> BR.
> Naichuan Sun
> 
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com] 
> Sent: Thursday, September 13, 2018 9:19 PM
> To: Naichuan Sun ; OpenStack Development Mailing 
> List (not for usage questions) 
> Cc: melanie witt ; efr...@us.ibm.com; Sylvain Bauza 
> 
> Subject: Re: About microversion setting to enable nested resource provider
> 
> On 09/13/2018 06:39 AM, Naichuan Sun wrote:
>> Hi, guys,
>>
>> Looks n-rp is disabled by default because microversion matches 1.29 : 
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/place
>> ment/handlers/allocation_candidate.py#L252
>>
>> Anyone know how to set the microversion to enable n-rp in placement?
> 
> It is the client which must send the 1.29+ placement API microversion header 
> to indicate to the placement API server that the client wants to receive 
> nested provider information in the allocation candidates response.
> 
> Currently, nova-scheduler calls the scheduler reportclient's
> get_allocation_candidates() method:
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/manager.py#L138
> 
> The scheduler reportclient's get_allocation_candidates() method currently 
> passes the 1.25 placement API microversion header:
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L353
> 
> https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L53
> 
> In order to get the nested information returned in the allocation candidates 
> response, that would need to be upped to 1.29.
> 
> Best,
> -jay
> __
> 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

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

[Ghanshyam Mann]

  On Thu, 13 Sep 2018 08:05:17 +0900 Lance Bragstad  
wrote  
 > 
 > 
 > On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley  wrote:
 > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
 >  [...]
 >  > So I encourage all elected TC members to work directly with the
 >  > various SIGs to figure out their top issue and then work on
 >  > managing those deliverables across the community because the TC is
 >  > particularly well suited to do so given the elected position.
 >  [...]
 >  
 >  I almost agree with you. I think the OpenStack TC members should be
 >  actively engaged in recruiting and enabling interested people in the
 >  community to do those things, but I don't think such work should be
 >  solely the domain of the TC and would hate to give the impression
 >  that you must be on the TC to have such an impact.
 > 
 > I agree that relaying that type of impression would be negative, but I'm not 
 > sure this specifically would do that. I think we've been good about letting 
 > people step up to drive initiatives without being in an elected position [0].
 > IMHO, I think the point Matt is making here is more about ensuring sure we 
 > have people to do what we've agreed upon, as a community, as being mission 
 > critical. Enablement is imperative, but no matter how good we are at it, 
 > sometimes we really just needs hands to do the work.
 > [0] Of the six goals agreed upon since we've implemented champions in 
 > Queens, five of them have been championed by non-TC members (Chandan 
 > championed two, in back-to-back releases).  -- 

True, doing any such cross project work  does not or should not require to be 
TC. And i do not think anyone has objection on this statement. 

Yes, recruiting the people is the key things here and TC can play the ownership 
role in this. I am sure having more and more people involved in such cross 
project work will surly help to find the new leaders. There are lot of 
contributors, who might have bandwidth but not coming up for cross project 
help. Such initiate from TC can help them to come forward.  And any other cross 
project work lead by non-TC will always be great example for TC to encourage 
the other contributors for such activity. 

But key point here is, if there is no one stepped up for priority cross project 
work(much needed for openstack production use case) then, TC can play role to 
find/self owner for that work. 

-gmann

 >  Jeremy Stanley
 >  __
 >  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
 > 



__
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] [release][searchlight] Need rights to create stable branches and tags

[Trinh Nguyen]

Dear Release Management team,

As we're reaching the Stein-1 milestone, I would like to prepare the
branches and tags. According to the documents, it's the job of the Release
Management team but it also says I as the PTL can do it. I wonder which is
the best way because Searchlight has missed several milestones.

It would be great if anyone in the Release Management team can give me some
advice.

Best regards,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
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] About microversion setting to enable nested resource provider

[Naichuan Sun]

Thank you very much, Jay.
Is there somewhere I could set microversion(some configure file?), Or just 
modify the source code to set it?

BR.
Naichuan Sun

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Thursday, September 13, 2018 9:19 PM
To: Naichuan Sun ; OpenStack Development Mailing List 
(not for usage questions) 
Cc: melanie witt ; efr...@us.ibm.com; Sylvain Bauza 

Subject: Re: About microversion setting to enable nested resource provider

On 09/13/2018 06:39 AM, Naichuan Sun wrote:
> Hi, guys,
> 
> Looks n-rp is disabled by default because microversion matches 1.29 : 
> https://github.com/openstack/nova/blob/master/nova/api/openstack/place
> ment/handlers/allocation_candidate.py#L252
> 
> Anyone know how to set the microversion to enable n-rp in placement?

It is the client which must send the 1.29+ placement API microversion header to 
indicate to the placement API server that the client wants to receive nested 
provider information in the allocation candidates response.

Currently, nova-scheduler calls the scheduler reportclient's
get_allocation_candidates() method:

https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/manager.py#L138

The scheduler reportclient's get_allocation_candidates() method currently 
passes the 1.25 placement API microversion header:

https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L353

https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L53

In order to get the nested information returned in the allocation candidates 
response, that would need to be upped to 1.29.

Best,
-jay
__
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] Open letter/request to TC candidates (and existing elected officials)

[Ghanshyam Mann]

  On Thu, 13 Sep 2018 00:47:27 +0900 Matt Riedemann  
wrote  
 > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring 
 > this up separately.
 > 
 > Kristi said:
 > 
 > "Ultimately, this list isn’t exclusive and I’d love to hear your and 
 > other people's opinions about what you think the I should focus on."
 > 
 > Well since you asked...
 > 
 > Some feedback I gave to the public cloud work group yesterday was to get 
 > their RFE/bug list ranked from the operator community (because some of 
 > the requests are not exclusive to public cloud), and then put pressure 
 > on the TC to help project manage the delivery of the top issue. I would 
 > like all of the SIGs to do this. The upgrades SIG should rank and 
 > socialize their #1 issue that needs attention from the developer 
 > community - maybe that's better upgrade CI testing for deployment 
 > projects, maybe it's getting the pre-upgrade checks goal done for Stein. 
 > The UC should also be doing this; maybe that's the UC saying, "we need 
 > help on closing feature gaps in openstack client and/or the SDK". I 
 > don't want SIGs to bombard the developers with *all* of their 
 > requirements, but I want to get past *talking* about the *same* issues 
 > *every* time we get together. I want each group to say, "this is our top 
 > issue and we want developers to focus on it." For example, the extended 
 > maintenance resolution [2] was purely birthed from frustration about 
 > talking about LTS and stable branch EOL every time we get together. It's 
 > also the responsibility of the operator and user communities to weigh in 
 > on proposed release goals, but the TC should be actively trying to get 
 > feedback from those communities about proposed goals, because I bet 
 > operators and users don't care about mox removal [3].

I agree on this and i feel this is real value  we can add with current 
situation where contributors are less in almost all of the projects. When we 
set goal for any cycle, we should have user/operator/SIG weightage on priority 
in selection checklist and categorize the goal into respective category/tag 
something like "user-oriented"  or "coding-oriented"(only developer/maintaining 
code benefits).  And then we concentrate more on first category and leave 
second one more on project team. Project team further can plan the second 
catagory items as per their bandwidth and priority.  I am not saying 
code/developer oriented goals should not be initiated by TC but those should be 
on low priority list kind of. 

-gmann

 > 
 > I want to see the TC be more of a cross-project project management 
 > group, like a group of Ildikos and what she did between nova and cinder 
 > to get volume multi-attach done, which took persistent supervision to 
 > herd the cats and get it delivered. Lance is already trying to do this 
 > with unified limits. Doug is doing this with the python3 goal. I want my 
 > elected TC members to be pushing tangible technical deliverables forward.
 > 
 > I don't find any value in the TC debating ad nauseam about visions and 
 > constellations and "what is openstack?". Scope will change over time 
 > depending on who is contributing to openstack, we should just accept 
 > this. And we need to realize that if we are failing to deliver value to 
 > operators and users, they aren't going to use openstack and then "what 
 > is openstack?" won't matter because no one will care.
 > 
 > So I encourage all elected TC members to work directly with the various 
 > SIGs to figure out their top issue and then work on managing those 
 > deliverables across the community because the TC is particularly well 
 > suited to do so given the elected position. I realize political and 
 > bureaucratic "how should openstack deal with x?" things will come up, 
 > but those should not be the priority of the TC. So instead of 
 > philosophizing about things like, "should all compute agents be in a 
 > single service with a REST API" for hours and hours, every few months - 
 > immediately ask, "would doing that get us any closer to achieving top 
 > technical priority x?" Because if not, or it's so fuzzy in scope that no 
 > one sees the way forward, document a decision and then drop it.
 > 
 > [1] 
 > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
 > [2] 
 > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
 > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html
 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > __
 > 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: 

Re: [openstack-dev] [goals][python3] mixed versions?

[Ghanshyam Mann]

  On Thu, 13 Sep 2018 22:10:48 +0900 Doug Hellmann  
wrote  
 > Excerpts from Thomas Goirand's message of 2018-09-13 12:23:32 +0200:
 > > On 09/13/2018 12:52 AM, Chris Friesen wrote:
 > > > On 9/12/2018 12:04 PM, Doug Hellmann wrote:
 > > > 
 > > >>> This came up in a Vancouver summit session (the python3 one I think).
 > > >>> General consensus there seemed to be that we should have grenade jobs
 > > >>> that run python2 on the old side and python3 on the new side and test
 > > >>> the update from one to another through a release that way.
 > > >>> Additionally there was thought that the nova partial job (and similar
 > > >>> grenade jobs) could hold the non upgraded node on python2 and that
 > > >>> would talk to a python3 control plane.
 > > >>>
 > > >>> I haven't seen or heard of anyone working on this yet though.
 > > >>>
 > > >>> Clark
 > > >>>
 > > >>
 > > >> IIRC, we also talked about not supporting multiple versions of
 > > >> python on a given node, so all of the services on a node would need
 > > >> to be upgraded together.
 > > > 
 > > > As I understand it, the various services talk to each other using
 > > > over-the-wire protocols.  Assuming this is correct, why would we need to
 > > > ensure they are using the same python version?
 > > > 
 > > > Chris
 > > 
 > > There are indeed a few cases were things can break, especially with
 > > character encoding. If you want an example of what may go wrong, here's
 > > one with Cinder and Ceph:
 > > 
 > > https://review.openstack.org/568813
 > > 
 > > Without the encodeutils.safe_decode() call, Cinder over Ceph was just
 > > crashing for me in Debian (Debian is full Python 3 now...). In this
 > > example, we're just over the wire, and it was supposed to be the same.
 > > Yet, only an integration test could have detect it (and I discovered it
 > > running puppet-openstack on Debian).

I think that should be detected by py3 ceph job  
"legacy-tempest-dsvm-py35-full-devstack-plugin-ceph". Was that failing or 
anyone checked its status during failure. This job is experimental in cinder 
gate[1] so i could not get its failure data from health-dashboard.
May be we should move it to check pipeline to cover cinder+ceph for py3 ?

[1] 
https://github.com/openstack-infra/project-config/blob/4eeec4cc6e18dd8933b16a2ddda75b469b893437/zuul.d/projects.yaml#L3471

-gmann
 > 
 > Was that caused (or found) by first running cinder under python 2
 > and then upgrading to python 3 on the same host? That's the test
 > case Jim originally suggested and I'm trying to understand if we
 > actually need it.
 > 
 > Doug
 > 
 > __
 > 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

Re: [openstack-dev] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Doug Hellmann]

Excerpts from Michel Peterson's message of 2018-09-13 10:04:27 +0300:
> On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
> wrote:
> 
> > The longer version is that we want to continue to use the existing
> > tox environment in each project as the basis for the job, since
> > that allows teams to control the version of python used, the
> > dependencies installed, and add custom steps to their build (such
> > as for pre-processing the documentation). So, the new or updated
> > job will start by running "tox -e docs" as it does today. Then it
> > will run Sphinx again with the instructions to build PDF output,
> > and copy the results into the directory that the publish job will
> > use to sync to the web server. And then it will run the scripts to
> > build translated versions of the documentation as HTML, and copy
> > the results into place for publishing.
> >
> 
> Just a question out of curiosity. You mention that we still want to use the
> docs environment because it allows fine grained control over how the
> documentation is created. However, as I understand, the PDF output will
> happen in a more standardized way and outside of that fine grained control,
> right? That couldn't lead to differences in both documentations? Do we have
> to even worry about that?

Good question.  The idea is to run "tox -e docs" to get the regular
HTML, then something like

   .tox/docs/bin/sphinx-build -b latex doc/build doc/build/latex
   cd doc/build/latex
   make
   cp doc/build/latex/*.pdf doc/build/html

We would run the HTML translation builds in a similar way by invoking
sphinx-build from the virtualenv repeatedly with different locale
settings based on what translations exist.

In my earlier comment, I was thinking of the case where a team runs
a script to generate rst content files before invoking sphinx to
build the HTML. That script would have been run before the PDF
generation happens, so the content should be the same. That also
applies for anyone using sphinx add-ons, which will be available
to the latex builder because we'll be using the version of sphinx
installed in the virtualenv managed by tox.

Doug

__
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] About microversion setting to enable nested resource provider

[Jay Pipes]

On 09/13/2018 06:39 AM, Naichuan Sun wrote:

Hi, guys,

Looks n-rp is disabled by default because microversion matches 1.29 : 
https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L252


Anyone know how to set the microversion to enable n-rp in placement?


It is the client which must send the 1.29+ placement API microversion 
header to indicate to the placement API server that the client wants to 
receive nested provider information in the allocation candidates response.


Currently, nova-scheduler calls the scheduler reportclient's 
get_allocation_candidates() method:


https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/manager.py#L138

The scheduler reportclient's get_allocation_candidates() method 
currently passes the 1.25 placement API microversion header:


https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L353

https://github.com/openstack/nova/blob/0ba34a818414823eda5e693dc2127a534410b5df/nova/scheduler/client/report.py#L53

In order to get the nested information returned in the allocation 
candidates response, that would need to be upped to 1.29.


Best,
-jay

__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2018-09-13 08:14:30 +0200:
> I like the plan, thanks! One suggestion below:
> 
> The translated documents are build for releasenotes already in a similar 
> way as proposed. here we update the index.rst file on the fly to link to 
> all translated versions, see the bottom of e.g. 
> https://docs.openstack.org/releasenotes/openstack-manuals/
> 
> I suggest that you look also as part of building how to link to PDFs and 
> translated documents.
> 
> For reference, the logic for releasenotes translation is here:
> http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/build-releasenotes/tasks/main.yaml#n10

Ah, yes, that's a detail I left out. I want to add a directive to
the theme to list those other formats and versions, so we don't
have to edit the content of the file on the fly.

> I would appreciate if you handle releasenotes the same way as other 
> documents, so if you want to change releasenotes in the end, please do

Good idea.

Doug

__
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] [goals][python3] mixed versions?

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-09-13 12:23:32 +0200:
> On 09/13/2018 12:52 AM, Chris Friesen wrote:
> > On 9/12/2018 12:04 PM, Doug Hellmann wrote:
> > 
> >>> This came up in a Vancouver summit session (the python3 one I think).
> >>> General consensus there seemed to be that we should have grenade jobs
> >>> that run python2 on the old side and python3 on the new side and test
> >>> the update from one to another through a release that way.
> >>> Additionally there was thought that the nova partial job (and similar
> >>> grenade jobs) could hold the non upgraded node on python2 and that
> >>> would talk to a python3 control plane.
> >>>
> >>> I haven't seen or heard of anyone working on this yet though.
> >>>
> >>> Clark
> >>>
> >>
> >> IIRC, we also talked about not supporting multiple versions of
> >> python on a given node, so all of the services on a node would need
> >> to be upgraded together.
> > 
> > As I understand it, the various services talk to each other using
> > over-the-wire protocols.  Assuming this is correct, why would we need to
> > ensure they are using the same python version?
> > 
> > Chris
> 
> There are indeed a few cases were things can break, especially with
> character encoding. If you want an example of what may go wrong, here's
> one with Cinder and Ceph:
> 
> https://review.openstack.org/568813
> 
> Without the encodeutils.safe_decode() call, Cinder over Ceph was just
> crashing for me in Debian (Debian is full Python 3 now...). In this
> example, we're just over the wire, and it was supposed to be the same.
> Yet, only an integration test could have detect it (and I discovered it
> running puppet-openstack on Debian).

Was that caused (or found) by first running cinder under python 2
and then upgrading to python 3 on the same host? That's the test
case Jim originally suggested and I'm trying to understand if we
actually need it.

Doug

__
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] [octavia] Optimize the query of the octavia database

[Jeff Yang]

Hi, All

As octavia resources increase, I found that running the "openstack
loadbalancer list" command takes longer and longer. Sometimes a 504 error
is reported.

By reading the code, I found that octavia will performs complex left outer
join queries when acquiring resources such as loadbalancer, listener, pool,
etc. in order to only make one trip to the database.
Reference code: http://paste.openstack.org/show/730022 Line 133
Generated SQL statements: http://paste.openstack.org/show/730021

So, I suggest that adjust the query strategy to provide different join
queries for different resources.

https://storyboard.openstack.org/#!/story/2003751
__
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] About microversion setting to enable nested resource provider

[Naichuan Sun]

Hi, guys,

Looks n-rp is disabled by default because microversion matches 1.29 : 
https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L252
Anyone know how to set the microversion to enable n-rp in placement?
Thank you very much.

BR.
Naichuan Sun
__
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] [goals][python3] mixed versions?

[Thomas Goirand]

On 09/13/2018 12:52 AM, Chris Friesen wrote:
> On 9/12/2018 12:04 PM, Doug Hellmann wrote:
> 
>>> This came up in a Vancouver summit session (the python3 one I think).
>>> General consensus there seemed to be that we should have grenade jobs
>>> that run python2 on the old side and python3 on the new side and test
>>> the update from one to another through a release that way.
>>> Additionally there was thought that the nova partial job (and similar
>>> grenade jobs) could hold the non upgraded node on python2 and that
>>> would talk to a python3 control plane.
>>>
>>> I haven't seen or heard of anyone working on this yet though.
>>>
>>> Clark
>>>
>>
>> IIRC, we also talked about not supporting multiple versions of
>> python on a given node, so all of the services on a node would need
>> to be upgraded together.
> 
> As I understand it, the various services talk to each other using
> over-the-wire protocols.  Assuming this is correct, why would we need to
> ensure they are using the same python version?
> 
> Chris

There are indeed a few cases were things can break, especially with
character encoding. If you want an example of what may go wrong, here's
one with Cinder and Ceph:

https://review.openstack.org/568813

Without the encodeutils.safe_decode() call, Cinder over Ceph was just
crashing for me in Debian (Debian is full Python 3 now...). In this
example, we're just over the wire, and it was supposed to be the same.
Yet, only an integration test could have detect it (and I discovered it
running puppet-openstack on Debian).

Cheers,

Thomas Goirand (zigo)

__
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] podman: varlink interface for nice API calls

[Bogdan Dobrelya]

On 8/27/18 6:38 PM, Fox, Kevin M wrote:

I think in this context, kubelet without all of kubernetes still has the value 
that it provides an abstraction layer that podmon/paunch is being suggested to 
handle.

It does not need the things you mention, network, sidecar, scaleup/down, etc. 
You can use as little as you want.

For example, make a pod yaml per container with hostNetwork: true. it will run 
just like it was on the host then. You can do just one container. no sidecars 
necessary. Without the apiserver, it can't do scaleup/down even if you wanted 
to.

It provides declarative yaml based management of containers, similar to paunch. 
so you can skip needing that component.


That would be a step into the right direction IMO.



It also already provides crio and docker support via cri.

It does provide a little bit of orchestration, in that you drive things with 
declarative yaml. You drop in a yaml file in /etc/kubernetes/manifests, and it 
will create the container. you delete it, it removes the container. If you 
change it, it will update the container. and if something goes wrong with the 
container, it will try and get it back to the requested state automatically. 
And, it will recover the containers on reboot without help.

Thanks,
Kevin


From: Sergii Golovatiuk [sgolo...@redhat.com]
Sent: Monday, August 27, 2018 3:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for nice   
API calls

Hi,

On Mon, Aug 27, 2018 at 12:16 PM, Rabi Mishra  wrote:

On Mon, Aug 27, 2018 at 3:25 PM, Sergii Golovatiuk 
wrote:


Hi,

On Mon, Aug 27, 2018 at 5:32 AM, Rabi Mishra  wrote:

On Mon, Aug 27, 2018 at 7:31 AM, Steve Baker  wrote:

Steve mentioned kubectl (kubernetes CLI which communicates with



Not sure what he meant. May be I miss something, but not heard of 'kubectl
standalone', though he might have meant standalone k8s cluster on every node
as you think.



kube-api) not kubelet which is only one component of kubernetes. All
kubernetes components may be compiled as one binary (hyperkube) which
can be used to minimize footprint. Generated ansible for kubelet is
not enough as kubelet doesn't have any orchestration logic.



What orchestration logic do we've with TripleO atm? AFAIK we've provide
roles data for service placement across nodes, right?
I see standalone kubelet as a first step for scheduling openstack services
with in k8s cluster in the future (may be).


It's half measure. I don't see any advantages of that move. We should
either adopt whole kubernetes or doesn't use its components at all as
the maintenance cost will be expensive. Using kubelet requires to
resolve networking communication, scale-up/down, sidecar, or inter
services dependencies.





This was a while ago now so this could be worth revisiting in the
future.
We'll be making gradual changes, the first of which is using podman to
manage single containers. However podman has native support for the pod
format, so I'm hoping we can switch to that once this transition is
complete. Then evaluating kubectl becomes much easier.


Question. Rather then writing a middle layer to abstract both
container
engines, couldn't you just use CRI? CRI is CRI-O's native language,
and
there is support already for Docker as well.



We're not writing a middle layer, we're leveraging one which is already
there.

CRI-O is a socket interface and podman is a CLI interface that both sit
on
top of the exact same Go libraries. At this point, switching to podman
needs
a much lower development effort because we're replacing docker CLI
calls.


I see good value in evaluating kubelet standalone and leveraging it's
inbuilt grpc interfaces with cri-o (rather than using podman) as a long
term
strategy, unless we just want to provide an alternative to docker
container
runtime with cri-o.


I see no value using kubelet without kubernetes IMHO.







Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, August 23, 2018 8:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for
nice
API calls

Dan, thanks for the details and answers. Appreciated.

Best,
-jay

On 08/23/2018 10:50 AM, Dan Prince wrote:


On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes  wrote:


On 08/15/2018 04:01 PM, Emilien Macchi wrote:


On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi mailto:emil...@redhat.com>> wrote:

   More seriously here: there is an ongoing effort to converge
the
   tools around containerization within Red Hat, and we, TripleO
are
   interested to continue the containerization of our services
(which
   was initially done with Docker & Docker-Distribution).
   We're looking at how these containers could be managed by k8s
one
   day but way before that we plan to swap out Docker and join
CRI-O
   efforts, which seem to be 

Re: [openstack-dev] [senlin] Nominations to Senlin Core Team

[x Lyn]

+1 to both, looking forward to their future contribution.

> On Sep 11, 2018, at 12:59 AM, Duc Truong  wrote:
> 
> Hi Senlin Core Team,
> 
> I would like to nominate 2 new core reviewers for Senlin:
> 
> [1] Jude Cross (jucr...@blizzard.com)
> [2] Erik Olof Gunnar Andersson (eanders...@blizzard.com)
> 
> Jude has been doing a number of reviews and contributed some important
> patches to Senlin during the Rocky cycle that resolved locking
> problems.
> 
> Erik has the most number of reviews in Rocky and has contributed high
> quality code reviews for some time.
> 
> [1] 
> http://stackalytics.com/?module=senlin-group=marks=rocky_id=jucr...@blizzard.com
> [2] 
> http://stackalytics.com/?module=senlin-group=marks_id=eandersson=rocky
> 
> Voting is open for 7 days.  Please reply with your +1 vote in favor or
> -1 as a veto vote.
> 
> Regards,
> 
> Duc (dtruong)
> 
> __
> 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

Re: [openstack-dev] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Michel Peterson]

On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
wrote:

> The longer version is that we want to continue to use the existing
> tox environment in each project as the basis for the job, since
> that allows teams to control the version of python used, the
> dependencies installed, and add custom steps to their build (such
> as for pre-processing the documentation). So, the new or updated
> job will start by running "tox -e docs" as it does today. Then it
> will run Sphinx again with the instructions to build PDF output,
> and copy the results into the directory that the publish job will
> use to sync to the web server. And then it will run the scripts to
> build translated versions of the documentation as HTML, and copy
> the results into place for publishing.
>

Just a question out of curiosity. You mention that we still want to use the
docs environment because it allows fine grained control over how the
documentation is created. However, as I understand, the PDF output will
happen in a more standardized way and outside of that fine grained control,
right? That couldn't lead to differences in both documentations? Do we have
to even worry about that?
__
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] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Andreas Jaeger]

I like the plan, thanks! One suggestion below:

The translated documents are build for releasenotes already in a similar 
way as proposed. here we update the index.rst file on the fly to link to 
all translated versions, see the bottom of e.g. 
https://docs.openstack.org/releasenotes/openstack-manuals/


I suggest that you look also as part of building how to link to PDFs and 
translated documents.


For reference, the logic for releasenotes translation is here:
http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/build-releasenotes/tasks/main.yaml#n10

I would appreciate if you handle releasenotes the same way as other 
documents, so if you want to change releasenotes in the end, please do


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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