[openstack-dev] [Forum] Fault Management/Monitoring for NFV/Edge/5G/IoT

[Yuki Kasuya]

Hi All,

I've created an etherpad for Fault Management/Monitoring for  
NFV/Edge/5G/IoT. It'll take place on Tuesday, May 22, 4:40pm-6:10pm @  
Room 221-222. If you have any usecase/idea/challenge for FM at these new  
area, could you join this forum and add any topic/comment to etherpad.


https://etherpad.openstack.org/p/YVR-fm-monitoring

Best regards,
Yuki

--
-
KDDI Research, Inc.
Integrated Core Network Control
And Management Laboratory
Yuki Kasuya
yu-kas...@kddilabs.jp
+81 80 9048 8405

__
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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Matthew Thode]

On 18-05-17 13:51:06, Tony Breeds wrote:
> On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote:
> > On 18-05-16 17:07:09, Doug Hellmann wrote:
> > > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
> > > > Sphinx has breaking changes (yet again) and we need to figure out how to
> > > > deal with it.  I think the fix will be simple for affected projects, but
> > > > we should probably move forward on this.  The error people are getting
> > > > seems to be 'Field list ends without a blank line; unexpected unindent.'
> > > > 
> > > > I'd like to keep on 1.7.4 and have the affected projects fix the error
> > > > so we can move on, but the revert has been proposed (and approved to get
> > > > gate unbroken for them).  https://review.openstack.org/568248  Any
> > > > advice from the community is welcome.
> > > > 
> > > 
> > > Is it sphinx, or docutils?
> > > 
> > > Do you have an example of the error?
> > > 
> > 
> > From https://bugs.launchpad.net/networking-midonet/+bug/1771092
> > 
> > 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error:
> > 2018-05-13 14:22:06.176967 | ubuntu-xenial | 
> > /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring
> >  of 
> > midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field
> >  list ends without a blank line; unexpected unindent.
> > 
> 
> Perhaps the sphinx parser just got more strict?
> 

Yep

-- 
Matthew Thode (prometheanfire)


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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Tony Breeds]

On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote:
> On 18-05-16 17:07:09, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
> > > Sphinx has breaking changes (yet again) and we need to figure out how to
> > > deal with it.  I think the fix will be simple for affected projects, but
> > > we should probably move forward on this.  The error people are getting
> > > seems to be 'Field list ends without a blank line; unexpected unindent.'
> > > 
> > > I'd like to keep on 1.7.4 and have the affected projects fix the error
> > > so we can move on, but the revert has been proposed (and approved to get
> > > gate unbroken for them).  https://review.openstack.org/568248  Any
> > > advice from the community is welcome.
> > > 
> > 
> > Is it sphinx, or docutils?
> > 
> > Do you have an example of the error?
> > 
> 
> From https://bugs.launchpad.net/networking-midonet/+bug/1771092
> 
> 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error:
> 2018-05-13 14:22:06.176967 | ubuntu-xenial | 
> /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring
>  of 
> midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field
>  list ends without a blank line; unexpected unindent.
> 

Adding something like:

(.docs) [tony@thor networking-midonet]$ ( cd ../neutron && git diff )
diff --git a/neutron/db/l3_db.py b/neutron/db/l3_db.py
index 33b5d99b1..66794542a 100644
--- a/neutron/db/l3_db.py
+++ b/neutron/db/l3_db.py
@@ -1091,8 +1091,8 @@ class L3_NAT_dbonly_mixin(l3.RouterPluginBase,
 :param internal_subnet: The subnet for the fixed-ip.
 :param external_network_id: The external network for floating-ip.
 
-:raises: ExternalGatewayForFloatingIPNotFound if no suitable router
-is found.
+:raises: ExternalGatewayForFloatingIPNotFound if no suitable router \
+ is found.
 """
 
 # Find routers(with router_id and interface address) that
(.docs) [tony@thor networking-midonet]$ ( cd ../os-vif && git diff )
diff --git a/os_vif/plugin.py b/os_vif/plugin.py
index 56566a6..2a437a6 100644
--- a/os_vif/plugin.py
+++ b/os_vif/plugin.py
@@ -49,10 +49,11 @@ class PluginBase(object):
 Given a model of a VIF, perform operations to plug the VIF properly.
 
 :param vif: `os_vif.objects.vif.VIFBase` object.
-:param instance_info: `os_vif.objects.instance_info.InstanceInfo`
-object.
-:raises `processutils.ProcessExecutionError`. Plugins implementing
-this method should let `processutils.ProcessExecutionError`
+:param instance_info: `os_vif.objects.instance_info.InstanceInfo` \
+  object.
+
+:raises `processutils.ProcessExecutionError`. Plugins implementing \
+this method should let `processutils.ProcessExecutionError` \
 bubble up.
 """
 
@@ -63,9 +64,10 @@ class PluginBase(object):
 
 :param vif: `os_vif.objects.vif.VIFBase` object.
 :param instance_info: `os_vif.objects.instance_info.InstanceInfo`
-object.
-:raises `processutils.ProcessExecutionError`. Plugins implementing
-this method should let `processutils.ProcessExecutionError`
+  object.
+
+:raises `processutils.ProcessExecutionError`. Plugins implementing \
+this method should let `processutils.ProcessExecutionError` \
 bubble up.
 """
 
fixes the midonet docs build for me (locally) on sphinx 1.7.4.  I'm far from a
sphinx expert but the chnages to neutron and os-vif seem correct to me.

Perhaps the sphinx parser just got more strict?

Yours Tony.


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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Michael Johnson]

The Octavia project had other breakage due to sphinx > 1.7 but we have
already resolved those issues.

Back story: the way arguments are handled for apidoc changed.
An example patch for the fix would be: https://review.openstack.org/#/c/568383/

Michael (johnsom)

On Wed, May 16, 2018 at 1:59 PM, Matthew Thode
 wrote:
> Sphinx has breaking changes (yet again) and we need to figure out how to
> deal with it.  I think the fix will be simple for affected projects, but
> we should probably move forward on this.  The error people are getting
> seems to be 'Field list ends without a blank line; unexpected unindent.'
>
> I'd like to keep on 1.7.4 and have the affected projects fix the error
> so we can move on, but the revert has been proposed (and approved to get
> gate unbroken for them).  https://review.openstack.org/568248  Any
> advice from the community is welcome.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> 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] [Zun] Relocate jobs from openstack/zun to openstack/zun-tempest-plugin

[Hongbin Lu]

On Wed, May 16, 2018 at 7:02 PM, James E. Blair  wrote:

> Hongbin Lu  writes:
>
> > The goal of those patches is to move the job definitions and playbooks
> from
> > openstack/zun to openstack/zun-tempest-plugin. The advantages of such
> > change are as following:
> >
> > * Make job definitions closer to tempest test cases so that it is optimal
> > for development and code reviews workflow. For example, sometime, we can
> > avoid to split a patch into two repos in order to add a simple tempest
> test
> > case.
> > * openstack/zun is branched and openstack/zun-tempest-plugin is
> branchless.
> > Zuul job definitions seem to fit better into branchless context.
> > * It saves us the overhead to backport job definitions to stable branch.
> > Sometime, missing a backport might lead to gate breakage and blocking
> > development workflow.
>
> Just a minor clarification: it's not always the case that branchless is
> better.
>
> Jobs which operate on repos that are branched are likely to be easier to
> work with in the long run, as whatever configuration is specific to the
> branch appears on that branch, instead of somewhere else.
>
> Further, there shouldn't be a need to backport changes once the initial
> jobs are set up.  In the future, when you branch master to stable/foo,
> you'll automatically get a copy of the job that's appropriate for that
> point in time, and you only need to update it if you're already updating
> the software on that branch.  Older versions of jobs on stable branches
> can continue to use their old configuration.
>
> For jobs which should perform the same function on all branches, it is
> easier to have those defined in branchless repos.  But in either case,
> you can accomplish the same thing without moving jobs.  In a branched
> repo, you can add a "branches: .*" matcher, and in a branchless repo,
> you can add multiple variants for each branch.
>
> The new v3-native devstack jobs are branched, and are defined in the
> devstack repo.  They define how to set up devstack for each branch.  But
> the tempest jobs (which build on top of the devstack jobs), are not
> branched (just like tempest), since they are designed to run the same
> way on all branches.
>
> I don't know enough about the situation to recommend one way or the
> other for Zun.  But I do want to emphasize that the best answer depends
> on the circumstances.
>

Hi Jim,

Thanks a lot for sharing your expertise. Based on what you said, I
re-visited the Zun's situation and think the branchless approach might not
be better.

In before, I ran into a situation that I wanted to write a tempest test
case with a specific API microversion. In order to get it setup, it seems I
need to submit three patches: a tempest test case (at zun-tempest-plugin),
a tempest config to populate the min/max microversion (at zun master) and a
backport (at zun stable/queens). A simple change that needs to be splited
into three patches made me revisit the current layout and explore the
branchless approach that are exercised in neutron [1].

I am re-visiting the situation now and leaning to the branched approach
because the setup of microversion min/max seems to be just once per branch.
However, I am not sure though how often we will run into a similar
situation that a change in tempest test case is coupled with job config. If
it frequently happens in the future, switching to branchless approach might
be more convenient.

[1]
https://github.com/openstack/neutron-tempest-plugin/blob/master/.zuul.yaml

Best regards,
Hongbin


>
> -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
>
__
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] [cyborg] [nova] Cyborg quotas

[Alex Xu]

2018-05-17 1:24 GMT+08:00 Jay Pipes :

> On 05/16/2018 01:01 PM, Nadathur, Sundar wrote:
>
>> Hi,
>> The Cyborg quota spec [1] proposes to implement a quota (maximum
>> usage) for accelerators on a per-project basis, to prevent one project
>> (tenant) from over-using some resources and starving other tenants. There
>> are separate resource classes for different accelerator types (GPUs, FPGAs,
>> etc.), and so we can do quotas per RC.
>>
>> The current proposal [2] is to track the usage in Cyborg agent/driver. I
>> am not sure that scheme will work, as I have indicated in the comments on
>> [1]. Here is another possible way.
>>
>>   * The operator configures the oslo.limit in keystone per-project
>> per-resource-class (GPU, FPGA, ...).
>>   o Until this gets into Keystone, Cyborg may define its own quota
>> table, as defined in [1].
>>   * Cyborg implements a table to track per-project usage, as defined in
>> [1].
>>
>
> Placement already stores usage information for all allocations of
> resources. There is already even a /usages API endpoint that you can
> specify a project and/or user:
>
> https://developer.openstack.org/api-ref/placement/#list-usages
>
> I see no reason not to use it.
>
> There is already actually a spec to use placement for quota usage checks
> in Nova here:
>
> https://review.openstack.org/#/c/509042/


FYI, I'm working on a spec which append to that spec. It's about counting
quota for the resource class(GPU, custom RC, etc) other than nova built-in
resources(cores, ram). It should be able to count the resource classes
which are used by cyborg. But yes, we probably should answer Matt's
question first, whether we should let Nova count quota instead of Cyborg.


>
>
> Probably best to have a look at that and see if it will end up meeting
> your needs.
>
>   * Cyborg provides a filter for the Nova scheduler, which checks
>> whether the project making the request has exceeded its own quota.
>>
>
> Quota checks happen before Nova's scheduler gets involved, so having a
> scheduler filter handle quota usage checking is pretty much a non-starter.
>
> I'll have a look at the patches you've proposed and comment there.
>
> 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-dev] [nova] Apply_cells to allow automation of nova-manage cells_v2 commands

[David G. Bingham]

Yo Nova Gurus :-),

We here at GoDaddy are getting hot and heavy into Cells V2 these days and would 
like to propose an enhancement or maybe see if something like this is already 
in the works.

Need:
To be able to “synchronize” cells from a specified file (git controlled, or 
inventory generated).

Details:
We are thinking about adding a new method to nova-manage called “apply-cells” 
that would take a json/yaml file and “make-it-so”. This method would make the 
cells in the DB match exactly that of what the spec says matching on the cell’s 
name. Internally it calls its own create_cell, update_cell, and delete_cell 
commands to get it done.

We already have a POC in the works. Are you aware of any others who have made 
requests for something like this? Ref: https://review.openstack.org/#/c/568987/

Thanks a ton,

David Bingham (wwriverrat on IRC)
__
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] [Openstack-operators] [Forum] [QA] Etherpad for Users / Operators adoption of QA tools / plugins sessions

[Ghanshyam Mann]

Hi All,

I've created the below etherpad for the QA feedback sessions[1] which
is schedule on Monday, May 21, 1:30 pm.  This contains the basic
agenda and feedback items we are planning to discuss in this sessions.

If you have any additional items to add or modify, please feel free to do that.

Hope to see you all next week and have safe travel.

.. 1 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21742/users-operators-adoption-of-qa-tools-plugins

-gmann

__
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] [cinder] Project Team Dinner at Vancouver Summit

[Jay S Bryant]

Team,

We discussed having a team dinner like we have done in the past during 
today's team meeting.  It sounded like most people would be available 
Tuesday evening, so that is the evening I am planning for.


If you are able to attend please add your name to the etherpad [1] by 
Sunday 5/20 so that I can make reservations.


Thank you!

Jay

[1] https://etherpad.openstack.org/p/YVR18-cinder-dinner


__
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] [Zun] Relocate jobs from openstack/zun to openstack/zun-tempest-plugin

[James E. Blair]

Hongbin Lu  writes:

> The goal of those patches is to move the job definitions and playbooks from
> openstack/zun to openstack/zun-tempest-plugin. The advantages of such
> change are as following:
>
> * Make job definitions closer to tempest test cases so that it is optimal
> for development and code reviews workflow. For example, sometime, we can
> avoid to split a patch into two repos in order to add a simple tempest test
> case.
> * openstack/zun is branched and openstack/zun-tempest-plugin is branchless.
> Zuul job definitions seem to fit better into branchless context.
> * It saves us the overhead to backport job definitions to stable branch.
> Sometime, missing a backport might lead to gate breakage and blocking
> development workflow.

Just a minor clarification: it's not always the case that branchless is
better.

Jobs which operate on repos that are branched are likely to be easier to
work with in the long run, as whatever configuration is specific to the
branch appears on that branch, instead of somewhere else.

Further, there shouldn't be a need to backport changes once the initial
jobs are set up.  In the future, when you branch master to stable/foo,
you'll automatically get a copy of the job that's appropriate for that
point in time, and you only need to update it if you're already updating
the software on that branch.  Older versions of jobs on stable branches
can continue to use their old configuration.

For jobs which should perform the same function on all branches, it is
easier to have those defined in branchless repos.  But in either case,
you can accomplish the same thing without moving jobs.  In a branched
repo, you can add a "branches: .*" matcher, and in a branchless repo,
you can add multiple variants for each branch.

The new v3-native devstack jobs are branched, and are defined in the
devstack repo.  They define how to set up devstack for each branch.  But
the tempest jobs (which build on top of the devstack jobs), are not
branched (just like tempest), since they are designed to run the same
way on all branches.

I don't know enough about the situation to recommend one way or the
other for Zun.  But I do want to emphasize that the best answer depends
on the circumstances.

-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

[openstack-dev] [Zun] Relocate jobs from openstack/zun to openstack/zun-tempest-plugin

[Hongbin Lu]

Hi all,

I have a series of patches for moving gate jobs from openstack/zun to
openstack/zun-tempest-plugin:

https://review.openstack.org/#/q/topic:relocate-zun-jobs+(status:open+OR+status:merged)

Moving forward those patches will incur a period of time that our gate will
have no tempest tests coverage. Therefore, I will have to fast-approve
those series of patches to minimize the transition period, so I sent this
email to collect feedback before performing the fast-approval .

The goal of those patches is to move the job definitions and playbooks from
openstack/zun to openstack/zun-tempest-plugin. The advantages of such
change are as following:

* Make job definitions closer to tempest test cases so that it is optimal
for development and code reviews workflow. For example, sometime, we can
avoid to split a patch into two repos in order to add a simple tempest test
case.
* openstack/zun is branched and openstack/zun-tempest-plugin is branchless.
Zuul job definitions seem to fit better into branchless context.
* It saves us the overhead to backport job definitions to stable branch.
Sometime, missing a backport might lead to gate breakage and blocking
development workflow.

All, what do you think? If there is no concern, I will fast-approve the
series of patches in a few days.

Best regards,
Hongbin
__
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] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lingxian Kong]

Thanks for your reply, @Doug and @Jim

Cheers,
Lingxian Kong


On Thu, May 17, 2018 at 2:23 AM Jim Rollenhagen 
wrote:

> On Wed, May 16, 2018 at 9:55 AM, Doug Hellmann 
> wrote:
>
>> Excerpts from Lingxian Kong's message of 2018-05-16 11:12:01 +1200:
>> > Hi,
>> >
>> > Maybe I missed the original discussion, I found the 'mutable'
>> configuration
>> > implementation relies on oslo.service, but is there any guide for the
>> > projects using cotyledon instead?
>>
>> oslo.service implements the signal handler natively, but the feature
>> does not rely on oslo.service. The method in oslo.config that does the
>> work makes no assumptions about what triggers it. We did this on purpose
>> to support projects that do not use oslo.service.
>>
>> I don't know enough about cotyledon to tell you how to do it, but you
>> need to set up a signal handler so that SIGHUP invokes the
>> mutate_config_files() method of the ConfigOpts instance being used by
>> the application.
>>
>
> This was asked in another thread, see my reply :)
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html
>
> // 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
>
__
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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Matthew Thode]

On 18-05-16 17:07:09, Doug Hellmann wrote:
> Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
> > Sphinx has breaking changes (yet again) and we need to figure out how to
> > deal with it.  I think the fix will be simple for affected projects, but
> > we should probably move forward on this.  The error people are getting
> > seems to be 'Field list ends without a blank line; unexpected unindent.'
> > 
> > I'd like to keep on 1.7.4 and have the affected projects fix the error
> > so we can move on, but the revert has been proposed (and approved to get
> > gate unbroken for them).  https://review.openstack.org/568248  Any
> > advice from the community is welcome.
> > 
> 
> Is it sphinx, or docutils?
> 
> Do you have an example of the error?
> 

From https://bugs.launchpad.net/networking-midonet/+bug/1771092

2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error:
2018-05-13 14:22:06.176967 | ubuntu-xenial | 
/home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring
 of 
midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field
 list ends without a blank line; unexpected unindent.

-- 
Matthew Thode (prometheanfire)


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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500:
> Sphinx has breaking changes (yet again) and we need to figure out how to
> deal with it.  I think the fix will be simple for affected projects, but
> we should probably move forward on this.  The error people are getting
> seems to be 'Field list ends without a blank line; unexpected unindent.'
> 
> I'd like to keep on 1.7.4 and have the affected projects fix the error
> so we can move on, but the revert has been proposed (and approved to get
> gate unbroken for them).  https://review.openstack.org/568248  Any
> advice from the community is welcome.
> 

Is it sphinx, or docutils?

Do you have an example of the error?

__
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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Matthew Thode]

Sphinx has breaking changes (yet again) and we need to figure out how to
deal with it.  I think the fix will be simple for affected projects, but
we should probably move forward on this.  The error people are getting
seems to be 'Field list ends without a blank line; unexpected unindent.'

I'd like to keep on 1.7.4 and have the affected projects fix the error
so we can move on, but the revert has been proposed (and approved to get
gate unbroken for them).  https://review.openstack.org/568248  Any
advice from the community is welcome.

-- 
Matthew Thode (prometheanfire)


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] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

[Jeremy Stanley]

On 2018-05-16 17:42:09 + (+), Jeremy Stanley wrote:
[...]
> Unfortunately, I'm unable to find any follow-up summary on the
> mailing list from the aforementioned session, but recollection from
> those who were present (I had a schedule conflict at that time) was
> that a Castellan-compatible key store would at least be a candidate
> for inclusion in our base services list
[...]

As Jim Rollenhagen pointed out in #openstack-tc, I was probably
thinking of the earlier Pike PTG session the Architecture WG held,
summarized at:

http://lists.openstack.org/pipermail/openstack-dev/2017-February/113016.html

Ensuing discussion yielded that there was no good reason to rename a
library even if the Oslo team was going to officially adopt it
(which for castellan they subsequently did in March 2017).
-- 
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

[openstack-dev] [octavia] Weekly IRC meeting cancelled May 23rd

[Michael Johnson]

Some of the team will be attending the OpenStack summit in Vancouver,
so I am cancelling the weekly IRC meeting for the 23rd.

We will resume our normal schedule on the 30th.

Michael

__
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] Cancel IRC meeting for May 22, 2018

[Emilien Macchi]

On Wed, May 16, 2018 at 1:07 PM, Alex Schultz  wrote:

> Since the summit is coming up, there will likely be very low
> attendance. We'll carry any open items until the following week.
>

No Weekly Owl as well, but be patient for the next Edition special Summit.
-- 
Emilien Macchi
__
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] [tripleo] Cancel IRC meeting for May 22, 2018

[Alex Schultz]

Since the summit is coming up, there will likely be very low
attendance. We'll carry any open items until the following week.

Thanks,
-Alex

__
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] [docs] Automating documentation the tripleo way?

[Harry Rybacki]

On Wed, May 16, 2018 at 2:51 PM, Wesley Hayutin  wrote:
>
>
> On Wed, May 16, 2018 at 2:41 PM Doug Hellmann  wrote:
>>
>> Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
>> > Hi all,
>> >
>> > In the past few years, we've seen several efforts aimed at automating
>> > procedural documentation, mostly centered around the OpenStack
>> > installation guide. This idea to automatically produce and verify
>> > installation steps or similar procedures was mentioned again at the last
>> > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
>> >
>> > It was brought to my attention that the tripleo team has been working on
>> > automating some of the tripleo deployment procedures, using a Bash
>> > script
>> > with included comment lines to supply some RST-formatted narrative, for
>> > example:
>> >
>> >
>> > https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
>> >
>> > The Bash script can then be converted to RST, e.g.:
>> >
>> >
>> > https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
>> >
>> > Source Code:
>> >
>> >
>> > https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
>> >
>> > I really liked this approach and while I don't want to sound like
>> > selling
>> > other people's work, I'm wondering if there is still an interest among
>> > the
>> > broader OpenStack community in automating documentation like this?
>> >
>> > Thanks,
>> > pk
>> >
>>
>> Weren't the folks doing the training-labs or training-guides taking a
>> similar approach? IIRC, they ended up implementing what amounted to
>> their own installer for OpenStack, and then ended up with all of the
>> associated upgrade and testing burden.
>>
>> I like the idea of trying to use some automation from this, but I wonder
>> if we'd be better off extracting data from other tools, rather than
>> building a new one.
>>
>> Doug
>
>
> So there really isn't anything new to create, the work is done and executed
> on every tripleo change that runs in rdo-cloud.
>
> Instead of dismissing the idea upfront I'm more inclined to set an
> achievable small step to see how well it works.  My thought would be to
> focus on the upcoming all-in-one installer and the automated doc generated
> with that workflow.  I'd like to target publishing the all-in-one tripleo
> installer doc to [1] for Stein and of course a section of tripleo.org.
>
> What do you think?
>
Interesting idea -- discussing this a bit at Summit (for those who
will be in attendance) seems like a good place to start.

> [1] https://docs.openstack.org/queens/deploy/
>
>
>>
>>
>> __
>> 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] [docs] Automating documentation the tripleo way?

[Alex Schultz]

On Wed, May 16, 2018 at 1:04 PM, Doug Hellmann  wrote:
> Excerpts from Wesley Hayutin's message of 2018-05-16 12:51:25 -0600:
>> On Wed, May 16, 2018 at 2:41 PM Doug Hellmann  wrote:
>>
>> > Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
>> > > Hi all,
>> > >
>> > > In the past few years, we've seen several efforts aimed at automating
>> > > procedural documentation, mostly centered around the OpenStack
>> > > installation guide. This idea to automatically produce and verify
>> > > installation steps or similar procedures was mentioned again at the last
>> > > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
>> > >
>> > > It was brought to my attention that the tripleo team has been working on
>> > > automating some of the tripleo deployment procedures, using a Bash script
>> > > with included comment lines to supply some RST-formatted narrative, for
>> > > example:
>> > >
>> > >
>> > https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
>> > >
>> > > The Bash script can then be converted to RST, e.g.:
>> > >
>> > >
>> > https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
>> > >
>> > > Source Code:
>> > >
>> > >
>> > https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
>> > >
>> > > I really liked this approach and while I don't want to sound like selling
>> > > other people's work, I'm wondering if there is still an interest among
>> > the
>> > > broader OpenStack community in automating documentation like this?
>> > >
>> > > Thanks,
>> > > pk
>> > >
>> >
>> > Weren't the folks doing the training-labs or training-guides taking a
>> > similar approach? IIRC, they ended up implementing what amounted to
>> > their own installer for OpenStack, and then ended up with all of the
>> > associated upgrade and testing burden.
>> >
>> > I like the idea of trying to use some automation from this, but I wonder
>> > if we'd be better off extracting data from other tools, rather than
>> > building a new one.
>> >
>> > Doug
>> >
>>
>> So there really isn't anything new to create, the work is done and executed
>> on every tripleo change that runs in rdo-cloud.
>
> It wasn't clear what Petr was hoping to get. Deploying with TripleO is
> only one way to deploy, so we wouldn't be able to replace the current
> installation guides with the results of this work. It sounds like that's
> not the goal, though.
>
>>
>> Instead of dismissing the idea upfront I'm more inclined to set an
>> achievable small step to see how well it works.  My thought would be to
>> focus on the upcoming all-in-one installer and the automated doc generated
>> with that workflow.  I'd like to target publishing the all-in-one tripleo
>> installer doc to [1] for Stein and of course a section of tripleo.org.
>
> As an official project, why is TripleO still publishing docs to its own
> site? That's not something we generally encourage.
>

We publish on docs.o.o. It's the same docs, just different theme.

https://docs.openstack.org/tripleo-docs/latest/install/index.html
https://docs.openstack.org/tripleo-docs/latest/contributor/index.html

I guess we could just change the tripleo.org to redirect to the
docs.o.o stuff. I'm not sure the history behind this.  I would say
that you can't really find them from the main docs.o.o page unless you
search so maybe that's part of it? I'm assuming this is likely because
we don't version our docs in the past so they don't show up.  Is there
a better way to ensure visibility of docs?

Thanks,
-Alex

> That said, publishing a new deployment guide based on this technique
> makes sense in general. What about Ben's comments elsewhere in the
> thread?
>
> Doug
>
>>
>> What do you think?
>>
>> [1] https://docs.openstack.org/queens/deploy/
>>
>> >
>> > __
>> > 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] [docs] Automating documentation the tripleo way?

[Wesley Hayutin]

On Wed, May 16, 2018 at 3:05 PM Doug Hellmann  wrote:

> Excerpts from Wesley Hayutin's message of 2018-05-16 12:51:25 -0600:
> > On Wed, May 16, 2018 at 2:41 PM Doug Hellmann 
> wrote:
> >
> > > Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
> > > > Hi all,
> > > >
> > > > In the past few years, we've seen several efforts aimed at automating
> > > > procedural documentation, mostly centered around the OpenStack
> > > > installation guide. This idea to automatically produce and verify
> > > > installation steps or similar procedures was mentioned again at the
> last
> > > > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
> > > >
> > > > It was brought to my attention that the tripleo team has been
> working on
> > > > automating some of the tripleo deployment procedures, using a Bash
> script
> > > > with included comment lines to supply some RST-formatted narrative,
> for
> > > > example:
> > > >
> > > >
> > >
> https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
> > > >
> > > > The Bash script can then be converted to RST, e.g.:
> > > >
> > > >
> > >
> https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
> > > >
> > > > Source Code:
> > > >
> > > >
> > >
> https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
> > > >
> > > > I really liked this approach and while I don't want to sound like
> selling
> > > > other people's work, I'm wondering if there is still an interest
> among
> > > the
> > > > broader OpenStack community in automating documentation like this?
> > > >
> > > > Thanks,
> > > > pk
> > > >
> > >
> > > Weren't the folks doing the training-labs or training-guides taking a
> > > similar approach? IIRC, they ended up implementing what amounted to
> > > their own installer for OpenStack, and then ended up with all of the
> > > associated upgrade and testing burden.
> > >
> > > I like the idea of trying to use some automation from this, but I
> wonder
> > > if we'd be better off extracting data from other tools, rather than
> > > building a new one.
> > >
> > > Doug
> > >
> >
> > So there really isn't anything new to create, the work is done and
> executed
> > on every tripleo change that runs in rdo-cloud.
>
> It wasn't clear what Petr was hoping to get. Deploying with TripleO is
> only one way to deploy, so we wouldn't be able to replace the current
> installation guides with the results of this work. It sounds like that's
> not the goal, though.
>
> >
> > Instead of dismissing the idea upfront I'm more inclined to set an
> > achievable small step to see how well it works.  My thought would be to
> > focus on the upcoming all-in-one installer and the automated doc
> generated
> > with that workflow.  I'd like to target publishing the all-in-one tripleo
> > installer doc to [1] for Stein and of course a section of tripleo.org.
>
> As an official project, why is TripleO still publishing docs to its own
> site? That's not something we generally encourage.
>
> That said, publishing a new deployment guide based on this technique
> makes sense in general. What about Ben's comments elsewhere in the
> thread?
>

I think Ben is referring to an older implementation and a slightly
different design but still has some points that we would want to be mindful
of.   I think this is a worthy effort to take another pass at this
regarless to be honest as we've found a good combination of interested
folks and sometimes the right people make all the difference.

My personal opinion is that I'm not expecting the automated doc generation
to be upload ready to a doc server after each run.  I do expect it to do
95% of the work, and to help keep the doc up to date with what is executed
in the latest releases of TripleO.  Also noting the doc used is a mixture
of static and generated documentation which I think worked out quite well
in order to not soley rely on what is executed in ci.

So again, my thought is to create a small achievable goal and see where the
collaboration takes us.

Thanks


>
> Doug
>
> >
> > What do you think?
> >
> > [1] https://docs.openstack.org/queens/deploy/
> >
> > >
> > >
> __
> > > 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] [cyborg] [nova] Cyborg quotas

[Matt Riedemann]

On 5/16/2018 12:24 PM, Jay Pipes wrote:
Quota checks happen before Nova's scheduler gets involved, so having a 
scheduler filter handle quota usage checking is pretty much a non-starter.


For server resources yeah, for things like instances quota, CPU and RAM, 
etc.


Nova does an up-front quota check for ports when creating servers (from 
nova-api) based on the number of servers requested vs whether or not 
pre-created ports were provided in the server create request.


Nova does *not* do the same up-front quota check for volumes when 
booting from volume and nova creates the volume in the nova-compute 
service, which could lead to an OverQuota error from Cinder and then we 
abort the build [1].


So what nova does probably depends on what the API interaction is when 
creating a server. As far as I know, nova isn't getting passed explicit 
cyborg-controlled resources like neutron ports or cinder volumes, right? 
I thought the interaction was that the flavor would have required 
resource amounts for cyborg resources which the nova-scheduler will 
allocate for the instance, and then some magic happens in nova-compute 
to hook those things up (like os-brick/os-vif type stuff).


Is nova going to be creating resources in cyborg like it creates ports 
in neutron or volumes in cinder? If not, then I don't see why nova would 
have anything to do with quota checks on these types of resources.


Also, you should totally start with modeling your limits in keystone 
since that's the direction all projects should be going. I believe the 
usages are tracked per-project but the limits are meant to be unified in 
keystone for all projects.


[1] https://bugs.launchpad.net/nova/+bug/1742102

--

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

Re: [openstack-dev] [docs] Automating documentation the tripleo way?

[Doug Hellmann]

Excerpts from Wesley Hayutin's message of 2018-05-16 12:51:25 -0600:
> On Wed, May 16, 2018 at 2:41 PM Doug Hellmann  wrote:
> 
> > Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
> > > Hi all,
> > >
> > > In the past few years, we've seen several efforts aimed at automating
> > > procedural documentation, mostly centered around the OpenStack
> > > installation guide. This idea to automatically produce and verify
> > > installation steps or similar procedures was mentioned again at the last
> > > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
> > >
> > > It was brought to my attention that the tripleo team has been working on
> > > automating some of the tripleo deployment procedures, using a Bash script
> > > with included comment lines to supply some RST-formatted narrative, for
> > > example:
> > >
> > >
> > https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
> > >
> > > The Bash script can then be converted to RST, e.g.:
> > >
> > >
> > https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
> > >
> > > Source Code:
> > >
> > >
> > https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
> > >
> > > I really liked this approach and while I don't want to sound like selling
> > > other people's work, I'm wondering if there is still an interest among
> > the
> > > broader OpenStack community in automating documentation like this?
> > >
> > > Thanks,
> > > pk
> > >
> >
> > Weren't the folks doing the training-labs or training-guides taking a
> > similar approach? IIRC, they ended up implementing what amounted to
> > their own installer for OpenStack, and then ended up with all of the
> > associated upgrade and testing burden.
> >
> > I like the idea of trying to use some automation from this, but I wonder
> > if we'd be better off extracting data from other tools, rather than
> > building a new one.
> >
> > Doug
> >
> 
> So there really isn't anything new to create, the work is done and executed
> on every tripleo change that runs in rdo-cloud.

It wasn't clear what Petr was hoping to get. Deploying with TripleO is
only one way to deploy, so we wouldn't be able to replace the current
installation guides with the results of this work. It sounds like that's
not the goal, though.

> 
> Instead of dismissing the idea upfront I'm more inclined to set an
> achievable small step to see how well it works.  My thought would be to
> focus on the upcoming all-in-one installer and the automated doc generated
> with that workflow.  I'd like to target publishing the all-in-one tripleo
> installer doc to [1] for Stein and of course a section of tripleo.org.

As an official project, why is TripleO still publishing docs to its own
site? That's not something we generally encourage.

That said, publishing a new deployment guide based on this technique
makes sense in general. What about Ben's comments elsewhere in the
thread?

Doug

> 
> What do you think?
> 
> [1] https://docs.openstack.org/queens/deploy/
> 
> >
> > __
> > 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] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-05-16 17:42:09 +:
> On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote:
> > On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote:
> > > As part of the work from the Security Squad, we added the
> > > ability for the containerized undercloud to encrypt the
> > > overcloud plans. This is done by enabling Swift's encrypted
> > > volumes, which require barbican. Right now it's turned off, but
> > > I would like to enable it by default [1]. What do you folks
> > > think?
> > 
> > I like the idea, but I'm a bit skeptical about adding a new
> > service to already quite bloated undercloud. Why is barbican a
> > hard requirement here?
> [...]
> 
> This exchange has given me pause to reflect on discussions we were
> having one year ago (leading up to and at the Forum in Boston).
> 
> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18736/key-management-developeroperatorcommunity-coordination
> 
> https://etherpad.openstack.org/p/BOS-forum-key-management
> 
> As a community, we're likely to continue to make imbalanced
> trade-offs against relevant security features if we don't move
> forward and declare that some sort of standardized key storage
> solution is a fundamental component on which OpenStack services can
> rely. Being able to just assume that you can encrypt volumes in
> Swift, even as a means to further secure a TripleO undercloud, would
> be a step in the right direction for security-minded deployments.
> 
> Unfortunately, I'm unable to find any follow-up summary on the
> mailing list from the aforementioned session, but recollection from
> those who were present (I had a schedule conflict at that time) was
> that a Castellan-compatible key store would at least be a candidate
> for inclusion in our base services list:
> 
> https://governance.openstack.org/tc/reference/base-services.html
> 
> So a year has passed... where are we with this? Is it still
> something we want to do (I think so, do others)? What are the next
> steps so this doesn't come up again and again?

It seems like we should add "some form of key manager" to the base
service lists, shouldn't we? And then we would encourage projects to use
castellan to talk to it. Unless we want to try to pick a single key
manager, which feels like a much longer sort of conversation.

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] [neutron] Team dinner in Vancouver, Tuesday 22nd 7pm

[Miguel Lavalle]

Hi Dear Neutron Team,

Our team dinner will take place at Al Porto Ristorante, which is located
half a mile from the Summit venue:

321 Water St, Vancouver, BC V6B 1B8
Phone: +1 604-683-8376
http://www.alporto.ca
https://goo.gl/8q5Qy2

Our reservation is at 7pm, under mi name: "Miguel Lavalle"

Looking forward to see you all there!

Best regards

MIguel
__
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] [docs] Automating documentation the tripleo way?

[Wesley Hayutin]

On Wed, May 16, 2018 at 2:41 PM Doug Hellmann  wrote:

> Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
> > Hi all,
> >
> > In the past few years, we've seen several efforts aimed at automating
> > procedural documentation, mostly centered around the OpenStack
> > installation guide. This idea to automatically produce and verify
> > installation steps or similar procedures was mentioned again at the last
> > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
> >
> > It was brought to my attention that the tripleo team has been working on
> > automating some of the tripleo deployment procedures, using a Bash script
> > with included comment lines to supply some RST-formatted narrative, for
> > example:
> >
> >
> https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
> >
> > The Bash script can then be converted to RST, e.g.:
> >
> >
> https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
> >
> > Source Code:
> >
> >
> https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
> >
> > I really liked this approach and while I don't want to sound like selling
> > other people's work, I'm wondering if there is still an interest among
> the
> > broader OpenStack community in automating documentation like this?
> >
> > Thanks,
> > pk
> >
>
> Weren't the folks doing the training-labs or training-guides taking a
> similar approach? IIRC, they ended up implementing what amounted to
> their own installer for OpenStack, and then ended up with all of the
> associated upgrade and testing burden.
>
> I like the idea of trying to use some automation from this, but I wonder
> if we'd be better off extracting data from other tools, rather than
> building a new one.
>
> Doug
>

So there really isn't anything new to create, the work is done and executed
on every tripleo change that runs in rdo-cloud.

Instead of dismissing the idea upfront I'm more inclined to set an
achievable small step to see how well it works.  My thought would be to
focus on the upcoming all-in-one installer and the automated doc generated
with that workflow.  I'd like to target publishing the all-in-one tripleo
installer doc to [1] for Stein and of course a section of tripleo.org.

What do you think?

[1] https://docs.openstack.org/queens/deploy/



>
> __
> 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] [docs] Automating documentation the tripleo way?

[Doug Hellmann]

Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
> Hi all,
> 
> In the past few years, we've seen several efforts aimed at automating
> procedural documentation, mostly centered around the OpenStack
> installation guide. This idea to automatically produce and verify
> installation steps or similar procedures was mentioned again at the last
> Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
> 
> It was brought to my attention that the tripleo team has been working on
> automating some of the tripleo deployment procedures, using a Bash script
> with included comment lines to supply some RST-formatted narrative, for
> example:
> 
> https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
> 
> The Bash script can then be converted to RST, e.g.:
> 
> https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
> 
> Source Code:
> 
> https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
> 
> I really liked this approach and while I don't want to sound like selling
> other people's work, I'm wondering if there is still an interest among the
> broader OpenStack community in automating documentation like this?
> 
> Thanks,
> pk
> 

Weren't the folks doing the training-labs or training-guides taking a
similar approach? IIRC, they ended up implementing what amounted to
their own installer for OpenStack, and then ended up with all of the
associated upgrade and testing burden.

I like the idea of trying to use some automation from this, but I wonder
if we'd be better off extracting data from other tools, rather than
building a new one.

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] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

[Jeremy Stanley]

On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote:
> On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote:
> > As part of the work from the Security Squad, we added the
> > ability for the containerized undercloud to encrypt the
> > overcloud plans. This is done by enabling Swift's encrypted
> > volumes, which require barbican. Right now it's turned off, but
> > I would like to enable it by default [1]. What do you folks
> > think?
> 
> I like the idea, but I'm a bit skeptical about adding a new
> service to already quite bloated undercloud. Why is barbican a
> hard requirement here?
[...]

This exchange has given me pause to reflect on discussions we were
having one year ago (leading up to and at the Forum in Boston).

https://www.openstack.org/summit/boston-2017/summit-schedule/events/18736/key-management-developeroperatorcommunity-coordination

https://etherpad.openstack.org/p/BOS-forum-key-management

As a community, we're likely to continue to make imbalanced
trade-offs against relevant security features if we don't move
forward and declare that some sort of standardized key storage
solution is a fundamental component on which OpenStack services can
rely. Being able to just assume that you can encrypt volumes in
Swift, even as a means to further secure a TripleO undercloud, would
be a step in the right direction for security-minded deployments.

Unfortunately, I'm unable to find any follow-up summary on the
mailing list from the aforementioned session, but recollection from
those who were present (I had a schedule conflict at that time) was
that a Castellan-compatible key store would at least be a candidate
for inclusion in our base services list:

https://governance.openstack.org/tc/reference/base-services.html

So a year has passed... where are we with this? Is it still
something we want to do (I think so, do others)? What are the next
steps so this doesn't come up again and again?
-- 
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] [cyborg] [nova] Cyborg quotas

[Jay Pipes]

On 05/16/2018 01:01 PM, Nadathur, Sundar wrote:

Hi,
    The Cyborg quota spec [1] proposes to implement a quota (maximum 
usage) for accelerators on a per-project basis, to prevent one project 
(tenant) from over-using some resources and starving other tenants. 
There are separate resource classes for different accelerator types 
(GPUs, FPGAs, etc.), and so we can do quotas per RC.


The current proposal [2] is to track the usage in Cyborg agent/driver. I 
am not sure that scheme will work, as I have indicated in the comments 
on [1]. Here is another possible way.


  * The operator configures the oslo.limit in keystone per-project
per-resource-class (GPU, FPGA, ...).
  o Until this gets into Keystone, Cyborg may define its own quota
table, as defined in [1].
  * Cyborg implements a table to track per-project usage, as defined in [1].


Placement already stores usage information for all allocations of 
resources. There is already even a /usages API endpoint that you can 
specify a project and/or user:


https://developer.openstack.org/api-ref/placement/#list-usages

I see no reason not to use it.

There is already actually a spec to use placement for quota usage checks 
in Nova here:


https://review.openstack.org/#/c/509042/

Probably best to have a look at that and see if it will end up meeting 
your needs.



  * Cyborg provides a filter for the Nova scheduler, which checks
whether the project making the request has exceeded its own quota.


Quota checks happen before Nova's scheduler gets involved, so having a 
scheduler filter handle quota usage checking is pretty much a non-starter.


I'll have a look at the patches you've proposed and comment there.

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] [docs] Automating documentation the tripleo way?

[Ben Nemec]

On 05/16/2018 10:39 AM, Petr Kovar wrote:

Hi all,

In the past few years, we've seen several efforts aimed at automating
procedural documentation, mostly centered around the OpenStack
installation guide. This idea to automatically produce and verify
installation steps or similar procedures was mentioned again at the last
Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).

It was brought to my attention that the tripleo team has been working on
automating some of the tripleo deployment procedures, using a Bash script
with included comment lines to supply some RST-formatted narrative, for
example:

https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2

The Bash script can then be converted to RST, e.g.:

https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/

Source Code:

https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs

I really liked this approach and while I don't want to sound like selling
other people's work, I'm wondering if there is still an interest among the
broader OpenStack community in automating documentation like this?


I think it's worth noting that TripleO doesn't even use the generated 
docs.  The main reason is that we tried this back in the 
tripleo-incubator days and it was not the silver bullet for good docs 
that it appears to be on the surface.  As the deployment scripts grow 
features and more complicated logic it becomes increasingly difficult to 
write inline documentation that is readable.  In the end, the 
tripleo-incubator docs had a number of large bash snippets that referred 
to internal variables and such.  It wasn't actually good documentation.


When we moved to instack-undercloud to drive TripleO deployments we also 
moved to a more traditional hand-written docs repo.  Both options have 
their benefits and drawbacks, but neither absolves the development team 
of their responsibility to curate the docs.  IME the inline method 
actually makes it harder to do this because it tightly couples your code 
and docs in a very inflexible way.


/2 cents

-Ben

__
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] [docs] Style guide for OpenStack documentation

[Jeremy Stanley]

On 2018-05-16 18:24:45 +0200 (+0200), Petr Kovar wrote:
[...]
> I'd like to propose replacing the reference to the IBM Style Guide
> with a reference to the developerWorks editorial style guide
> (https://www.ibm.com/developerworks/library/styleguidelines/).
> This lightweight version comes from the same company and is based
> on the same guidelines, but most importantly, it is available for
> free.
[...]

I suppose replacing a style guide nobody can access with one
everyone can (modulo legal concerns) is a step up. Still, are there
no style guides published under an actual free/open license? If
https://www.ibm.com/developerworks/community/terms/use/ is correct
then even accidental creation of a derivative work might be
prosecuted as copyright infringement.

http://www.writethedocs.org/guide/writing/style-guides/#selecting-a-good-style-guide-for-you
mentions some more aligned with our community's open ideals, such as
the 18F Content Guide (public domain), SUSE Documentation Style
Guide (GFDL), GNOME Documentation Style Guide (GFDL), and the
Writing Style Guide and Preferred Usage for DOD Issuances (public
domain). Granted adopting one of those might lead to a need to
overhaul some aspects of style in existing documents, so I can
understand it's not a choice to be made lightly. Still, we should
always consider embracing open process, and that includes using
guidelines which we can freely derive and republish as needed.
-- 
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

[openstack-dev] [cyborg] [nova] Cyborg quotas

[Nadathur, Sundar]

Hi,
   The Cyborg quota spec [1] proposes to implement a quota (maximum 
usage) for accelerators on a per-project basis, to prevent one project 
(tenant) from over-using some resources and starving other tenants. 
There are separate resource classes for different accelerator types 
(GPUs, FPGAs, etc.), and so we can do quotas per RC.


The current proposal [2] is to track the usage in Cyborg agent/driver. I 
am not sure that scheme will work, as I have indicated in the comments 
on [1]. Here is another possible way.


 * The operator configures the oslo.limit in keystone per-project
   per-resource-class (GPU, FPGA, ...).
 o Until this gets into Keystone, Cyborg may define its own quota
   table, as defined in [1].
 * Cyborg implements a table to track per-project usage, as defined in [1].
 * Cyborg provides a filter for the Nova scheduler, which checks
   whether the project making the request has exceeded its own quota.
 o If so, it removes all candidates, thus failing the request.
 o If not, it updates the per-project usage in its own DB. Since
   this is an out-of-tree filter, at least to start with, it should
   be ok to directly update the db without making REST API calls.

IOW, the resource usage tracking and enforcement are done as part of the 
request scheduling, rather than done at the compute node.


If there are better ways, or ways to avoid a filter, please LMK.

[1] https://review.openstack.org/#/c/560285/
[2] https://review.openstack.org/#/c/564968/

Thanks.

Regards,
Sundar

__
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] [docs] Style guide for OpenStack documentation

[Petr Kovar]

Hi all,

For OpenStack documentation contributors, we provide a basic style guide
that describes most important guidelines for writing, user interface
guidelines, and RST conventions:

https://docs.openstack.org/doc-contrib-guide/writing-style.html
https://docs.openstack.org/doc-contrib-guide/user-guidelines.html
https://docs.openstack.org/doc-contrib-guide/rst-conv.html

In these documents, we also refer to the printed IBM Style Guide for more
information. While this is a standard resource used by many technical
writers, we no longer have a group of dedicated writers working on our docs.
Also, the IBM Style Guide is not available online for free, making it
inaccessible to many in the community.

I'd like to propose replacing the reference to the IBM Style Guide with a
reference to the developerWorks editorial style guide
(https://www.ibm.com/developerworks/library/styleguidelines/). This
lightweight version comes from the same company and is based on the same
guidelines, but most importantly, it is available for free.

Any objections to this?

A related change:

https://review.openstack.org/#/c/562310/

I hope this change will make it much easier for our docs contributors to
consult style guidelines.

Thanks,
pk

__
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] [Zun] Team meeting canceled on 2018-05-22

[Hongbin Lu]

 Hi all,

Due to OpenStack Vancouver Summit, we canceled the weekly team meeting
at 2018-05-22. Updated Meeting schedule can be found at
https://wiki.openstack.org/wiki/Zun#Meetings .

Best regards,
Hongbin
__
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] [docs] Automating documentation the tripleo way?

[Petr Kovar]

Hi all,

In the past few years, we've seen several efforts aimed at automating
procedural documentation, mostly centered around the OpenStack
installation guide. This idea to automatically produce and verify
installation steps or similar procedures was mentioned again at the last
Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).

It was brought to my attention that the tripleo team has been working on
automating some of the tripleo deployment procedures, using a Bash script
with included comment lines to supply some RST-formatted narrative, for
example:

https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2

The Bash script can then be converted to RST, e.g.:

https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/

Source Code:

https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs

I really liked this approach and while I don't want to sound like selling
other people's work, I'm wondering if there is still an interest among the
broader OpenStack community in automating documentation like this?

Thanks,
pk

__
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] [nova] Can we remove the monkey_patch_modules config option?

[Matt Riedemann]

On 8/31/2017 2:14 PM, Matt Riedemann wrote:


The change to deprecate the monkey_patch and monkey_patch_modules option 
was deprecated in Queens, so they wouldn't be removed until the Rocky 
release at the earliest. We don't backport changes which deprecate things.


My recommendation to you is upstream your changes. If it's a new 
feature, propose a blueprint [1].


Chances are someone else needs or wants the same thing, or is already 
doing something similar but without the monkey patch config options.


[1] https://docs.openstack.org/nova/latest/contributor/blueprints.html


Following up on this, I have submitted a patch to remove the deprecated 
monkey_patch-related config options:


https://review.openstack.org/#/c/568880/

--

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

Re: [openstack-dev] [requirements][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate

[Ade Lee]

Thanks for the reminder.  We replaced the pycrypto code in Barbican but
 forgot to remove the dependency in requirements.txt.  A review has
been added to do this.

https://review.openstack.org/568879

On Sun, 2018-05-13 at 12:22 -0500, Matthew Thode wrote:
> This is a reminder to the projects called out that they are using
> old,
> unmaintained and probably insecure libraries (it's been dead since
> 2014).  Please migrate off to use the cryptography library.  We'd
> like
> to drop pycrypto from requirements for rocky.
> 
> See also, the bug, which has most of you cc'd already.
> 
> https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> 
> ++---
> --+--+---
> +
> > Repository |
> > Filename   
> >  | Line | Text  |
> 
> ++---
> --+--+---
> +
> > barbican   |
> > requirements.txt   
> >  |   25 | pycrypto>=2.6 # Public Domain |
> > daisycloud-core|
> > code/daisy/requirements.txt
> >  |   17 | pycrypto>=2.6 # Public Domain |
> > freezer|
> > requirements.txt   
> >  |   21 | pycrypto>=2.6 # Public Domain |
> > fuel-web   |
> > nailgun/requirements.txt   
> >  |   24 | pycrypto>=2.6.1   |
> > heat-cfnclient |
> > requirements.txt   
> >  |2 | PyCrypto>=2.1.0   |
> > pyghmi |
> > requirements.txt   
> >  |1 | pycrypto>=2.6 |
> > rpm-packaging  |
> > requirements.txt   
> >  |  189 | pycrypto>=2.6  # Public Domain|
> > solum  |
> > requirements.txt   
> >  |   24 | pycrypto>=2.6 # Public Domain |
> > tatu   |
> > requirements.txt   
> >  |7 | pycrypto>=2.6.1   |
> > tatu   | test-
> > requirements.txt   |   
> >  7 | pycrypto>=2.6.1   |
> > trove  |
> > integration/scripts/files/requirements/fedora-
> > requirements.txt  |   30 | pycrypto>=2.6  # Public
> > Domain|
> > trove  |
> > integration/scripts/files/requirements/ubuntu-
> > requirements.txt  |   29 | pycrypto>=2.6  # Public
> > Domain|
> > trove  |
> > requirements.txt   
> >  |   47 | pycrypto>=2.6 # Public Domain |
> 
> ++---
> --+--+---
> +
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [neutron] Neutron L3 sub-team meeting canceled on May 24th

[Miguel Lavalle]

Hi Dear Neutron Team,

Due to the OpenStack Summit in Vancouver next week, we will cancel the
drivers meeting scheduled on May 24th at 1500UTC. We will resume our
meetings on May 31st at 1500UTC

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

[openstack-dev] [neutron] Neutron drivers meeting canceled on May 25th

[Miguel Lavalle]

Hi Dear Neutron Team,

Due to the OpenStack Summit in Vancouver next week, we will cancel the
drivers meeting scheduled on May 25th at 1400UTC. We will resume our
meetings on June 1st at 1400UTC

Best regards

Miguel
__
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] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[Jeremy Stanley]

On 2018-05-16 15:17:52 +0200 (+0200), Bogdan Dobrelya wrote:
[...]
> My understanding, I may be totally wrong, is that unlike to
> packages and repos (do not count OSTree [0]), containers use
> layers and can be exported into tarballs with built-in
> de-duplication. This makes idea of tossing those tarballs around
> much more attractive, than doing something similar to repositories
> with packages.
[...]

Projects which utilize service VMs (e.g. Trove) were asking to do
precisely the same things and had nothing to do with containers. The
idea that you might build a VM image up from proposed source in one
job and then fire several other jobs which used that proposed image
well-predates similar requests from container-oriented projects.
-- 
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

[openstack-dev] [neutron] Neutron weekly meeting canceled on May 22nd

[Miguel Lavalle]

Hi Dear Neutron Team,

Due to the OpenStack Summit in Vancouver next week, we will cancel the team
meeting scheduled on May 22nd at 1400UTC. We will resume our meetings on
May 28th at 2100UTC

Best regards

Miguel
__
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] [SIG][Edge-computing][FEMDC] Wed. 16 May - FEMDC IRC Meeting 15:00 UTC

[lebre . adrien]

s/#edge-computing-irc/#edge-computing-group

Sorry for the typo. 
The meeting starts now. 

ad_ri3n_
- Mail original -
> De: "Dimitri Pertin" 
> À: openstack-dev@lists.openstack.org
> Cc: openstack-s...@lists.openstack.org, edge-comput...@lists.openstack.org
> Envoyé: Mardi 15 Mai 2018 17:16:22
> Objet: [Openstack-sigs] [SIG][Edge-computing][openstack-dev][FEMDC] Wed. 16 
> May - FEMDC IRC Meeting 15:00 UTC
> 
> Dear all,
> 
> Here is a gentle reminder regarding the FEMDC meeting that was
> postponed
> from last week to tomorrow: May, the 16th at 15:00 UTC.
> 
> As a consequence, the meeting will be held on #edge-computing-irc
> 
> This meeting will focus on the preparation of the Vancouver summit
> (presentations, F2F sessions, ...). You can already check and fill
> this
> pad with you wishes/ideas:
> https://etherpad.openstack.org/p/FEMDC_Vancouver
> 
> As usually, a draft of the agenda is available at line 550 and you
> are
> very welcome to add any item:
> https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018
> 
> Best regards,
> 
> Dimitri
> 
> 
> 
>  Forwarded Message 
> Subject: [Edge-computing] [FEMDC] IRC meeting postponed to next
> Wednesday
> Date: Wed, 9 May 2018 15:50:45 +0200 (CEST)
> From: lebre.adr...@free.fr
> To: OpenStack Development Mailing List (not for usage questions)
> ,
> openstack-s...@lists.openstack.org,
> edge-comput...@lists.openstack.org
> 
> Dear all,
> Neither Paul-Andre nor me can chair the meeting today so we propose
> to
> postpone it for one week. The agenda will be delivered soon but you
> can
> consider that next meeting will focus on the preparation of the
> Vancouver summit (presentations, F2F meetings...).
> Best regards, ad_ri3n_
> 
> ___
> Edge-computing mailing list
> edge-comput...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 

__
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] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jim Rollenhagen]

On Wed, May 16, 2018 at 9:55 AM, Doug Hellmann 
wrote:

> Excerpts from Lingxian Kong's message of 2018-05-16 11:12:01 +1200:
> > Hi,
> >
> > Maybe I missed the original discussion, I found the 'mutable'
> configuration
> > implementation relies on oslo.service, but is there any guide for the
> > projects using cotyledon instead?
>
> oslo.service implements the signal handler natively, but the feature
> does not rely on oslo.service. The method in oslo.config that does the
> work makes no assumptions about what triggers it. We did this on purpose
> to support projects that do not use oslo.service.
>
> I don't know enough about cotyledon to tell you how to do it, but you
> need to set up a signal handler so that SIGHUP invokes the
> mutate_config_files() method of the ConfigOpts instance being used by
> the application.
>

This was asked in another thread, see my reply :)
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html

// 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] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

Excerpts from Lingxian Kong's message of 2018-05-16 11:12:01 +1200:
> Hi,
> 
> Maybe I missed the original discussion, I found the 'mutable' configuration
> implementation relies on oslo.service, but is there any guide for the
> projects using cotyledon instead?

oslo.service implements the signal handler natively, but the feature
does not rely on oslo.service. The method in oslo.config that does the
work makes no assumptions about what triggers it. We did this on purpose
to support projects that do not use oslo.service.

I don't know enough about cotyledon to tell you how to do it, but you
need to set up a signal handler so that SIGHUP invokes the
mutate_config_files() method of the ConfigOpts instance being used by
the application.

Doug

> 
> Cheers,
> Lingxian Kong
> 
> On Wed, May 16, 2018 at 2:46 AM Doug Hellmann  wrote:
> 
> > Excerpts from Lance Bragstad's message of 2018-05-14 18:45:49 -0500:
> > >
> > > On 05/14/2018 05:46 PM, Doug Hellmann wrote:
> > > > Excerpts from Lance Bragstad's message of 2018-05-14 15:20:42 -0500:
> > > >> On 05/14/2018 02:24 PM, Doug Hellmann wrote:
> > > >>> Excerpts from Lance Bragstad's message of 2018-05-14 13:13:51 -0500:
> > >  On 03/19/2018 09:22 AM, Jim Rollenhagen wrote:
> > > > On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann <
> > d...@doughellmann.com
> > > > > wrote:
> > > >
> > > > Both of those are good ideas.
> > > >
> > > >
> > > > Agree. I like the socket idea a bit more as I can imagine some
> > > > operators don't want config file changes automatically applied. Do
> > we
> > > > want to choose one to standardize on or allow each project (or
> > > > operators, via config) the choice?
> > >  Just to recap, keystone would be listening for when it's
> > configuration
> > >  file changes, and reinitialize the logger if the logging settings
> > >  changed, correct?
> > > >>> Sort of.
> > > >>>
> > > >>> Keystone would need to do something to tell oslo.config to re-load
> > the
> > > >>> config files. In services that rely on oslo.service, this is handled
> > > >>> with a SIGHUP handler that calls ConfigOpts.mutate_config_files(), so
> > > >>> for Keystone you would want to do something similar.
> > > >>>
> > > >>> That is, you want to wait for an explicit notification from the
> > operator
> > > >>> that you should reload the config, and not just watch for the file to
> > > >>> change. We could talk about using file modification as a trigger, but
> > > >>> reloading is something that may need to be staged across several
> > > >>> services in order so we chose for the first version to make the
> > trigger
> > > >>> explicit. Relying on watching files will also fail when the modified
> > > >>> data is not in a file (which will be possible when we finish the
> > driver
> > > >>> work described in
> > > >>>
> > http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
> > ).
> > > >> Hmm, these are good points. I wonder if just converting to use
> > > >> oslo.service would be a lower bar then?
> > > > I thought keystone had moved away from that direction toward deploying
> > > > only within Apache? I may be out of touch, or have misunderstood
> > > > something, though.
> > >
> > > Oh - never mind... For some reason I was thinking there was a way to use
> > > oslo.service and Apache.
> > >
> > > Either way, I'll do some more digging before tomorrow. I have this as a
> > > topic on keystone's meeting agenda to go through our options [0]. If we
> > > do come up with something that doesn't involve intercepting signals
> > > (specifically for the reason noted by Kristi and Jim in the mod_wsgi
> > > documentation), should the community goal be updated to include that
> > > option? Just thinking that we can't be the only service in this position.
> >
> > I think we've left the implementation details up to the project
> > teams, for just that reason. That said, it would be good to document
> > how you do it (either formally or with a mailing list thread).
> >
> > And FWIW, if what you choose to do is monitor a file, that's fine
> > as a trigger. I suggest not using the configuration file itself,
> > though, for the reasons mentioned earlier.
> >
> > Doug
> >
> > PS - I wonder how Apache deals with reloading its own configuration
> > file. Is there some sort of hook you could use?
> >
> > >
> > > [0] https://etherpad.openstack.org/p/keystone-weekly-meeting
> > >
> > > >
> > > > 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 

Re: [openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[Bogdan Dobrelya]

On 5/16/18 2:17 PM, Jeremy Stanley wrote:

On 2018-05-16 11:31:30 +0200 (+0200), Bogdan Dobrelya wrote:
[...]

I'm pretty sure though with broader containers adoption, openstack
infra will catch up eventually, so we all could benefit our
upstream CI jobs with affinity based and co-located data available
around for consequent build steps.


I still don't see what it has to do with containers. We've known


My understanding, I may be totally wrong, is that unlike to packages and 
repos (do not count OSTree [0]), containers use layers and can be 
exported into tarballs with built-in de-duplication. This makes idea of 
tossing those tarballs around much more attractive, than doing something 
similar to repositories with packages. Of course container images can be 
pre-built into nodepool images, just like packages, so CI users can 
rebuild on top with less changes brought into new layers, which is 
another nice to have option by the way.


[0] https://rpm-ostree.readthedocs.io/en/latest/


these were potentially useful features long before
container-oriented projects came into the picture. We simply focused
on implementing other, even more generally-applicable features
first.


Right, I think this only confirms that it *does* have something to 
containers, and priorities for containerized use cases will follow 
containers adoption trends. If everyone one day suddenly ask for 
nodepool images containing latest kolla containers injected, for example.





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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [docs] Documentation meeting today

[Petr Kovar]

Hi all,

The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] [ptg] Early bird pricing ends EOD tomorrow, act now

[Thierry Carrez]

Friendly reminder that the "early bird" pricing for the next PTG in 
Denver in September is ending at 6:59 UTC Friday (which translates to 
Thursday, 23:59 Pacific time).


If you are concerned with pricing increase and want to snatch the $199 
ticket deal before the price jumps to $399, act now !


More details:
https://www.eventbrite.com/e/project-teams-gathering-denver-2018-tickets-45296703660

--
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] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[Jeremy Stanley]

On 2018-05-16 11:31:30 +0200 (+0200), Bogdan Dobrelya wrote:
[...]
> I'm pretty sure though with broader containers adoption, openstack
> infra will catch up eventually, so we all could benefit our
> upstream CI jobs with affinity based and co-located data available
> around for consequent build steps.

I still don't see what it has to do with containers. We've known
these were potentially useful features long before
container-oriented projects came into the picture. We simply focused
on implementing other, even more generally-applicable features
first.
-- 
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] [tripleo] Encrypted swift volumes by default in the undercloud

[Dmitry Tantsur]

Hi,

On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote:

Hello!

As part of the work from the Security Squad, we added the ability for the 
containerized undercloud to encrypt the overcloud plans. This is done by 
enabling Swift's encrypted volumes, which require barbican. Right now it's 
turned off, but I would like to enable it by default [1]. What do you folks think?


I like the idea, but I'm a bit skeptical about adding a new service to already 
quite bloated undercloud. Why is barbican a hard requirement here?




[1] https://review.openstack.org/#/c/567200/

BR

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



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




__
OpenStack 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] [I18n] [Docs] Forum session Vancouver

[Frank Kloeker]

Good morning,

just a quick note when packing the suitcase: We have a Docs/I18n Forum 
session on Monday 21th, 13:30, direct after lunch [1]. Take the chance 
to discuss topics about project onboarding with translation or 
documentation, usage of translated documents or tools. Or just come to 
say Hello :-)

Looking forward to see you there!

kind regards

Frank (PTL I18n)


[1] 
https://etherpad.openstack.org/p/docs-i18n-project-onboarding-vancouver


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

[openstack-dev] [neutron] Next Neutron QoS meeting cancelled

[Slawomir Kaplonski]

Hi,

As there is summit in next week, neutron QoS meeting from 22.05 is cancelled. 
Next meeting will be normally on 05.06.2018

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

[openstack-dev] [neutron] Next Neutron CI meeting canceled

[Slawomir Kaplonski]

Hi,

As there is summit in next week, neutron CI meeting from 22.05 is cancelled. 
Next meeting will be normally on 29.05

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [Designate] Plan for OSM

[super user]

I thought it is Open Source MANO.

On Thu, May 3, 2018, 4:45 PM duon...@vn.fujitsu.com 
wrote:

> Hi Ben,
>
> >>On 04/25/2018 11:31 PM, daidv at vn.fujitsu.com wrote:
> >> Hi forks,
> >>
> >> We tested and completed our process with OVO migration in Queens cycle.
> >> Now, we can continue with OSM implementation for Designate.
> >> Actually, we have pushed some patches related to OSM[1] and it's ready
> to review.
>
> > Out of curiosity, what does OSM stand for?  Based on the patches it
> > seems related to rolling upgrades, but a quick glance at them doesn't
> > make it obvious to me what's going on.  Thanks.
>
> OSM stands for Online Schema Migration, which means that we can migrate
> database schema without
> downtime for service.
>
> > -Ben
>
> Best regards,
>
> Ha Quang Duong (Mr.)
> PODC - Fujitsu Vietnam Ltd.
>
>
> __
> 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] [cyborg]Weekly Team Meeting 2018.05.16

[Zhipeng Huang]

Hi team,

As usual we will have our weekly meeting starting UTC1400 at
#openstack-cyborg, initial agenda as follows:

1. summit prep
2. sub team report
3. critical rocky spec review
4. open patches

-- 
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] [requirements][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate

[Javier Pena]

- Original Message -
> This is a reminder to the projects called out that they are using old,
> unmaintained and probably insecure libraries (it's been dead since
> 2014).  Please migrate off to use the cryptography library.  We'd like
> to drop pycrypto from requirements for rocky.
> 
> See also, the bug, which has most of you cc'd already.
> 
> https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> 

In the rpm-packaging case, the requirements.txt file is not actually a list of 
requirements for the project, but a copy of the requirements project 
upper-constraints.txt file (a bit outdated now).

Regards,
Javier


> ++-+--+---+
> | Repository | Filename
> | | Line | Text
> | |
> ++-+--+---+
> | barbican   | requirements.txt
> | |   25 | pycrypto>=2.6
> | # Public Domain |
> | daisycloud-core| code/daisy/requirements.txt
> | |   17 | pycrypto>=2.6 # Public
> | Domain |
> | freezer| requirements.txt
> | |   21 | pycrypto>=2.6
> | # Public Domain |
> | fuel-web   | nailgun/requirements.txt
> | |   24 | pycrypto>=2.6.1
> | |
> | heat-cfnclient | requirements.txt
> | |2 |
> | PyCrypto>=2.1.0   |
> | pyghmi | requirements.txt
> | |1 | pycrypto>=2.6
> | |
> | rpm-packaging  | requirements.txt
> | |  189 | pycrypto>=2.6
> | # Public Domain|
> | solum  | requirements.txt
> | |   24 | pycrypto>=2.6
> | # Public Domain |
> | tatu   | requirements.txt
> | |7 |
> | pycrypto>=2.6.1   |
> | tatu   | test-requirements.txt
> | |7 | pycrypto>=2.6.1
> | |
> | trove  |
> | integration/scripts/files/requirements/fedora-requirements.txt  |   30
> | | pycrypto>=2.6  # Public Domain|
> | trove  |
> | integration/scripts/files/requirements/ubuntu-requirements.txt  |   29
> | | pycrypto>=2.6  # Public Domain|
> | trove  | requirements.txt
> | |   47 | pycrypto>=2.6
> | # Public Domain |
> ++-+--+---+
> 
> --
> Matthew Thode (prometheanfire)
> 
> __
> 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] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal

[Bogdan Dobrelya]

On 5/15/18 10:31 PM, Wesley Hayutin wrote:



On Tue, May 15, 2018 at 1:29 PM James E. Blair > wrote:


Jeremy Stanley > writes:

 > On 2018-05-15 09:40:28 -0700 (-0700), James E. Blair wrote:
 > [...]
 >> We're also talking about making a new kind of job which can
continue to
 >> run after it's "finished" so that you could use it to do
something like
 >> host a container registry that's used by other jobs running on the
 >> change.  We don't have that feature yet, but if we did, would
you prefer
 >> to use that instead of the intermediate swift storage?
 >
 > If the subsequent jobs depending on that one get nodes allocated
 > from the same provider, that could solve a lot of the potential
 > network performance risks as well.

That's... tricky.  We're *also* looking at affinity for buildsets, and
I'm optimistic we'll end up with something there eventually, but that's
likely to be a more substantive change and probably won't happen as
soon.  I do agree it will be nice, especially for use cases like this.

-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


There is a lot here to unpack and discuss, but I really like the ideas 
I'm seeing.
Nice work Bogdan!  I've added it the tripleo meeting agenda for next 
week so we can continue socializing the idea and get feedback.


Thanks!

https://etherpad.openstack.org/p/tripleo-meeting-items


Thank you for feedback, folks. There is a lot of technical caveats, 
right. I'm pretty sure though with broader containers adoption, 
openstack infra will catch up eventually, so we all could benefit our 
upstream CI jobs with affinity based and co-located data available 
around for consequent build steps.




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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [tc] [all] TC Report 18-20

[Thierry Carrez]

Graham Hayes wrote:

Any additional background on why we allowed LCOO to operate like this
would help a lot.


We can't prevent any group of organizations to work in any way they 
prefer -- we can, however, deny them the right to be called an OpenStack 
workgroup if they fail at openly collaborating. We can raise the topic, 
but in the end it is a User Committee decision though, since the LCOO is 
a User Committee-blessed working group.


Source: https://governance.openstack.org/uc/

--
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] [zVMCloudConnector][python-zvm-sdk][requirements] Unblock webob-1.8.1

[Chen CH Ji]

Thanks for the reminder

we updated the code to 1.1.1 , and current info can be found
https://pypi.org/project/zVMCloudConnector/#description

detailed code can be found here , you can see no block for webob anymore
https://github.com/mfcloud/python-zvm-sdk/blob/master/requirements.txt#L7

please share what's additional work need to be done, thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matthew Thode 
To: openstack-dev@lists.openstack.org
Date:   05/16/2018 01:01 AM
Subject:[openstack-dev]
[zVMCloudConnector][python-zvm-sdk][requirements]   Unblock
webob-1.8.1



Please unblock webob-1.8.1, you are the only library holding it back at
this point.  I don't see a way to submit code to the project so I cc'd
the project in launchpad.

https://bugs.launchpad.net/openstack-requirements/+bug/1765748

--
Matthew Thode (prometheanfire)
[attachment "signature.asc" deleted by Chen CH Ji/China/IBM]
__
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][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Bump the last time

Hi all,
As we keep adding more info to the migration guideline [1], you might like
to take a look again.
And do hope it will make things easier for you. If not, please find me in
irc or mail.

[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info


2018-05-10 18:42 GMT+08:00 Rico Lin :

> Hi all,
> As we keep adding more info to the migration guideline [1], you might like
> to take a look again.
> And do hope it will make things easier for you. If not, please find me in
> irc or mail.
>
> [1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>
> Here's the quick hint for you, your bug id is exactly your story id.
>
> 2018-05-07 18:27 GMT+08:00 Rico Lin :
>
>> Hi all,
>>
>> I updated more information to this guideline in [1].
>> Please must take a view on [1] to see what's been updated.
>> will likely to keep update on that etherpad if new Q or issue found.
>>
>> Will keep trying to make this process as painless for you as possible,
>> so please endure with us for now, and sorry for any inconvenience
>>
>> *[1] https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
>> *
>>
>> 2018-05-05 12:15 GMT+08:00 Rico Lin :
>>
>>> looping heat-dashboard team
>>>
>>> 2018-05-05 12:02 GMT+08:00 Rico Lin :
>>>
 Dear all Heat members and friends

 As you might award, OpenStack projects are scheduled to migrating ([5])
 from Launchpad to StoryBoard [1].
 For whom who like to know where to file a bug/blueprint, here are some
 heads up for you.

 *What's StoryBoard?*
 StoryBoard is a cross-project task-tracker, contains numbers of
 ``project``, each project contains numbers of ``story`` which you can think
 it as an issue or blueprint. Within each story, contains one or multiple
 ``task`` (task separate stories into the tasks to resolve/implement). To
 learn more about StoryBoard or how to make a good story, you can reference
 [6].

 *How to file a bug?*
 This is actually simple, use your current ubuntu-one id to access to
 storyboard. Then find the corresponding project in [2] and create a story
 to it with a description of your issue. We should try to create tasks which
 to reference with patches in Gerrit.

 *How to work on a spec (blueprint)?*
 File a story like you used to file a Blueprint. Create tasks for your
 plan. Also you might want to create a task for adding spec( in heat-spec
 repo) if your blueprint needs documents to explain.
 I still leave current blueprint page open, so if you like to create a
 story from BP, you can still get information. Right now we will start work
 as task-driven workflow, so BPs should act no big difference with a bug in
 StoryBoard (which is a story with many tasks).

 *Where should I put my story?*
 We migrate all heat sub-projects to StoryBoard to try to keep the
 impact to whatever you're doing as small as possible. However, if you plan
 to create a new story, *please create it under heat project [4]* and
 tag it with what it might affect with (like python-heatclint,
 heat-dashboard, heat-agents). We do hope to let users focus their stories
 in one place so all stories will get better attention and project
 maintainers don't need to go around separate places to find it.

 *How to connect from Gerrit to StoryBoard?*
 We usually use following key to reference Launchpad
 Closes-Bug: ###
 Partial-Bug: ###
 Related-Bug: ###

 Now in StoryBoard, you can use following key.
 Task: ##
 Story: ##
 you can find more info in [3].

 *What I need to do for my exists bug/bps?*
 Your bug is automatically migrated to StoryBoard, however, the
 reference in your patches ware not, so you need to change your commit
 message to replace the old link to launchpad to new links to StoryBoard.

 *Do we still need Launchpad after all this migration are done?*
 As the plan, we won't need Launchpad for heat anymore once we have done
 with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
 provide new information as many as possible. Hopefully, we can make
 everyone happy. For those newly created bugs during/after migration, don't
 worry we will disallow further create new bugs/bps and do a second migrate
 so we won't missed yours.

 [1] https://storyboard.openstack.org/
 [2] https://storyboard.openstack.org/#!/project_group/82
 [3] https://docs.openstack.org/infra/manual/developers.html#
 development-workflow
 [4] https://storyboard.openstack.org/#!/project/989
 [5] https://docs.openstack.org/infra/storyboard/migration.html
 [6]