Re: [openstack-dev] [all] Python 3.6 testing is available on Fedora 26 nodes

[ChangBo Guo]

Thanks for the follow up, it's really helpful for us to support Python 3.6
smoothly in the future.

2017-08-25 12:29 GMT+08:00 Ian Wienand :

> Hello,
>
> In a recent discussion [1] I mentioned we could, in theory, use Fedora
> 26 for Python 3.6 testing (3.6.2, to be exact).  After a few offline
> queries we have put theory into practice, sorted out remaining issues
> and things are working.
>
> For unit testing (tox), you can use the
> 'gate-{name}-python36-{node}-nv' job template with fedora-26 nodes.
> For an example, see [2] (which, I'm happy to report, found a real
> issue [3] :).  You may need to modify your bindep.txt files to install
> correct build pacakges for RPM platforms; in terms of general
> portability this is probably not a bad thing anyway.
>
> I have an up/down devstack test working with a minor change [4].  I
> will work on getting this more stable and more complete, but if this
> is of interest, reach out.  In general, I track the centos & fedora
> jobs fairly closely at [5] to try and keep up with any systemic
> issues.
>
> Although it is not exactly trivial, there is fairly complete
> instructions within [6] to help build a Fedora image that looks like
> the infra ones for testing purposes.  You can also reach out and we
> can do things like place failed nodes on hold if there are hard to
> debug issues.
>
> Thanks,
>
> -i
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120888.html
> [2] https://git.openstack.org/cgit/openstack-infra/project-
> config/commit/?id=5fe3ba95616136709a319ae1cd3beda38a299a13
> [3] https://review.openstack.org/496054
> [4] https://review.openstack.org/496098
> [5] http://people.redhat.com/~iwienand/devstack-status/
> [6] https://git.openstack.org/cgit/openstack-infra/project-
> config/tree/tools/build-image.sh
>
> __
> 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
>



-- 
ChangBo Guo(gcb)
__
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] Python 3.6 testing is available on Fedora 26 nodes

[Ian Wienand]

Hello,

In a recent discussion [1] I mentioned we could, in theory, use Fedora
26 for Python 3.6 testing (3.6.2, to be exact).  After a few offline
queries we have put theory into practice, sorted out remaining issues
and things are working.

For unit testing (tox), you can use the
'gate-{name}-python36-{node}-nv' job template with fedora-26 nodes.
For an example, see [2] (which, I'm happy to report, found a real
issue [3] :).  You may need to modify your bindep.txt files to install
correct build pacakges for RPM platforms; in terms of general
portability this is probably not a bad thing anyway.

I have an up/down devstack test working with a minor change [4].  I
will work on getting this more stable and more complete, but if this
is of interest, reach out.  In general, I track the centos & fedora
jobs fairly closely at [5] to try and keep up with any systemic
issues.

Although it is not exactly trivial, there is fairly complete
instructions within [6] to help build a Fedora image that looks like
the infra ones for testing purposes.  You can also reach out and we
can do things like place failed nodes on hold if there are hard to
debug issues.

Thanks,

-i

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120888.html
[2] 
https://git.openstack.org/cgit/openstack-infra/project-config/commit/?id=5fe3ba95616136709a319ae1cd3beda38a299a13
[3] https://review.openstack.org/496054
[4] https://review.openstack.org/496098
[5] http://people.redhat.com/~iwienand/devstack-status/
[6] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh

__
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] nova 16.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for nova for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/pike

Release notes for nova can be found at:

http://docs.openstack.org/releasenotes/nova/




__
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] [ironic]clean failed after I finished

[王俊]

Hi,Richard:
Thanks for your response,after I set the auto_clean=false,It’s OK now.I think 
it’ll be much better if drac driver have more detail in official docs

Date: Wed, 23 Aug 2017 20:11:02 +
From: >
To: 
>
Subject: Re: [openstack-dev] [ironic]clean failed after I finished
clean-step
Message-ID:
>
Content-Type: text/plain; charset="gb2312"

Greetings,

Thank you for your question.  Hopefully, I can help you move beyond the node 
cleaning issue you encountered.

To begin, I have a couple of observations.


1.   It seems that automated cleaning was attempted.  Please note that the 
DRAC driver does not implement any automated cleaning steps.  The RAID cleaning 
steps it offers can be used by manual cleaning.

2.   The iDRAC driver code that detected an issue with the clean step(s) 
configured on the node has been removed on master and in the forthcoming 9.1.0 
(Pike) release of ironic.  That was done to fix the bug “double manage/provide 
cycle cause trace for pxe_drac” 
(https://bugs.launchpad.net/ironic/+bug/1676387).  That bug is not related to 
your issue.

Beyond that, to further assist you, I need the following information.


1.   Which distribution of ironic are you using?

2.   What is ironic’s version?

3.   Please describe how the clean steps were set to configure RAID.  I am 
looking for the API requests or CLI commands that were issued.

4.  What was the state of the ironic node before it was provided?  That can be 
retrieved by either of the following CLI commands, depending on the version of 
the ironic client you are using.

ironic node-show 
openstack baremetal node show 

Thank you, and regards,
Rick

From: 王俊 [mailto:wang...@yovole.com]
Sent: Wednesday, August 23, 2017 3:52 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ironic]clean failed after I finished clean-step

Hi:
anybody saw this before?http://paste.openstack.org/show/619133/
I typed clean-step to config raid,after that,the node status was in 
manageable,then I made status to provide,the error appeared.
I don’t know how to fixed it

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
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] [neutron] [tests] [tempest] Neutron dvr tempest test problem

[Ihar Hrachyshka]

On Thu, Aug 24, 2017 at 5:13 AM, Luigi Toscano  wrote:
> On Thursday, 24 August 2017 12:51:05 CEST Ning Yao wrote:
>> Hi, all
>>
>> I encounter a problem about neutron tempest test. I run the tempest
>> neutron plugin test against my self-build OpenStack, and I find that
>> tempest will run the dvr test and report NotImplementedERROR. I dig
>> into the test code and find that even if I do not enable dvr router
>> for my OpenStack, the dvr test runs and does not automatically skip.
>> This is because it only skip this logic when
>> network-feature-enabled.api_extensions does not support dvr.
>
> I think that you hit this:
>
> https://bugs.launchpad.net/neutron/+bug/1450067
>
> which should be fixed from Pike.

Yes. Operator should also set enable_dvr = False for neutron-server so
that it doesn't advertise support for 'dvr' API extension.

Thanks,
Ihar

__
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] add mistral to the auto-update package list for TripleO CI

[Ben Nemec]

I think I'm +0 on this.  On the one hand we do have the gating job on 
Mistral, on the other hand our gate jobs don't exercise all of the 
functionality of some projects, especially Mistral.  I know in the past 
introspection has been broken by changes in Mistral, and that wouldn't 
be caught by gate jobs.  If we start using master all the time that 
becomes a blocker for TripleO since it will prevent our OVB jobs from 
passing.


So I can understand the desire to use master of a tightly coupled 
project like Mistral, but it does open a hole in our promotion pipeline 
which I don't feel great about.  If we had an OVB job running on every 
patch (and respected by the Mistral cores) I'd be +1 with no reservations.


On 08/24/2017 04:04 PM, Wesley Hayutin wrote:

Greetings,

I'd like to propose that the mistral project be added to the list of 
projects where in CI the very latest built packages are added to each CI 
run [1].


This will help get patches that depend on mistral patches to more 
quickly be tested and merged.  For example Honza's patch [2] depends on 
a merged mistral change.  The mistral change has not yet landed in a 
tripleo build and mistral is not on the auto-update list, so the patch 
fails.


Please respond if you would like to see mistral added or have any 
comments or concerns.


Note that we are able to consider mistral for auto-updates because the 
mistral project has a voting tripleo job [3] and the tripleo project can 
be assured that the latest mistral patches will not break tripleo-ci.


I would encourage other projects to consider adding tripleo jobs to 
their project to enable auto-updates as well [4] 


[1] 
https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70

[2] https://review.openstack.org/#/c/469608/
[3] 
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665
[4] 
https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html



__
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] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Sam Yaple]

I have been running api services behind uwsgi in http mode from Newton
forward. I recently switched to the uwsgi+nginx model with 2 containers
since I was having wierd issues with things that I couldn't track down.
Mainly after I started using keystone with ldap. There would be timeouts
and message-to-long type errors that all went away with nginx.

Additionally, running with HTTPS was measurably faster with nginx proxying
to a uwsgi socket.

This was just my experience with it, if you do want to switch to uwsgi+http
make sure you do thorough testing of all the components or you may be left
with a component that just won't work with your model.


On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
wrote:

> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
> wrote:
> > We are moving to deploy service via WSGI[0].
> >
> > There are two recommended ways.
> >
> > - apache + mod_wsgi
> > - nginx + uwsgi
> >
> > later one is more better.
> >
> > For traditional deployment, it is easy to implement. Use one
> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).
> > Then one nginx process to forward the http require into uwsgi server.
> >
> > But kolla is running one process in one container. If we use
> > the recommended solution, we have to use two container to run
> > nova-api container. and it will generate lots of containers.
> > like: nginx-nova-api, uwsig-nova-api.
> >
> > i propose use uwsgi native http mode[1]. Then one uwsgi
> > container is enough to run nova-api service. Base one the official
> > doc, if there is no static resource, uWSGI is recommended to use
> > as a real http server.
> >
> > So how about this?
>
> I think this is an interesting approach.  At the moment, the Puppet
> modules currently allow deploying for services using mod_wsgi.
> Personally, I don't think that relying on the HTTP support of uWSGI is
> very favorable.   It is quite difficult to configure and 'get right'
> and it leaves a lot to be desired (for example, federated auth relies
> on Apache modules which would make this nearly impossible).
>
> Given that the current OpenStack testing infrastructure proxies to
> UWSGI, I think it would be best if that approach is taken.  This way,
> a container (or whatever service) would expose a UWSGI API, which you
> can connect whichever web server that you need.
>
> In the case of Kolla, the `httpd` container would be similar to what
> the `haproxy` is.  In the case of Puppet, I can imagine this being
> something to be managed by the user (with some helpers in there).  I
> think it would be interesting to add the tripleo folks on their
> opinion here as consumers of the Puppet modules.
>
> >
> >
> > [0] https://governance.openstack.org/tc/goals/pike/deploy-api-
> in-wsgi.html
> > [1]
> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-
> use-uwsgi-s-http-capabilities-in-production
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > ___
> > OpenStack-operators mailing list
> > openstack-operat...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] tripleo-image-elements 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-image-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-image-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-image-elements/log/?h=stable/pike

Release notes for tripleo-image-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-image-elements/




__
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] tripleo-puppet-elements 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-puppet-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-puppet-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/pike

Release notes for tripleo-puppet-elements can be found at:

http://docs.openstack.org/releasenotes/tripleo-puppet-elements/




__
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] tripleo-heat-templates 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for tripleo-heat-templates for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-heat-templates/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/pike

Release notes for tripleo-heat-templates can be found at:

http://docs.openstack.org/releasenotes/tripleo-heat-templates/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/tripleo

and tag it *pike-rc-potential* to bring it to the tripleo-heat-templates
release crew's attention.


__
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] add mistral to the auto-update package list for TripleO CI

[Wesley Hayutin]

Greetings,

I'd like to propose that the mistral project be added to the list of
projects where in CI the very latest built packages are added to each CI
run [1].

This will help get patches that depend on mistral patches to more quickly
be tested and merged.  For example Honza's patch [2] depends on a merged
mistral change.  The mistral change has not yet landed in a tripleo build
and mistral is not on the auto-update list, so the patch fails.

Please respond if you would like to see mistral added or have any comments
or concerns.

Note that we are able to consider mistral for auto-updates because the
mistral project has a voting tripleo job [3] and the tripleo project can be
assured that the latest mistral patches will not break tripleo-ci.

I would encourage other projects to consider adding tripleo jobs to their
project to enable auto-updates as well [4] 

[1]
https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70
[2] https://review.openstack.org/#/c/469608/
[3]
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665
[4]
https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html
__
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] [keystone] [nova] [neutron] [cinder] [ironic] [glance] [swift] Baremetal/VM SIG PTG Schedule/Etherpad

[Lance Bragstad]

Hi all,

Keystone has a few cross-project topics we'd like to share with a wider
group, like the Baremetal/VM SIG. As a result, I attempted to dust off
some of the Baremetal/VM sessions [0][1] from Boston and port the
popular topics over to the etherpad for the PTG [2]. Maybe it will kick
start some discussions before we get there?

John has more insight into this than I do, but I'm curious if we plan to
have a rough schedule for Monday and Tuesday? I'm happy to help
coordinate or shuffle bits for the baremetal/VM group if ideas come up here.


[0] https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal
[1] https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
[2] https://etherpad.openstack.org/p/queens-PTG-vmbm



signature.asc
Description: OpenPGP digital 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] [sahara] sahara-image-elements 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara-image-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara-image-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/sahara-image-elements/log/?h=stable/pike

Release notes for sahara-image-elements can be found at:

http://docs.openstack.org/releasenotes/sahara-image-elements/




__
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] [sahara] sahara 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/sahara/log/?h=stable/pike

Release notes for sahara can be found at:

http://docs.openstack.org/releasenotes/sahara/




__
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] [sahara] sahara-dashboard 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/sahara-dashboard/log/?h=stable/pike

Release notes for sahara-dashboard can be found at:

http://docs.openstack.org/releasenotes/sahara-dashboard/




__
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] [sahara] sahara-extra 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara-extra for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara-extra/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/sahara-extra/log/?h=stable/pike

Release notes for sahara-extra can be found at:

http://docs.openstack.org/releasenotes/sahara-extra/




__
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] [keystone] Queens PTG Planning

[Lance Bragstad]

I've worked the topics into a schedule [0]. Monday and Tuesday are
pretty general, but contain topics we need to discuss with other
projects. I've left these time slots flexible for now and I'll start
another thread to include other projects. Wednesday and Thursday are
mostly project-specific keystone topics we can hash out in our room. The
last day is pretty open, but I expect to push topics to Friday
throughout the week if they need more discussion. After all that we do
have a couple time slots open on Wednesday and Thursday if we missed
something.

I've also bootstrapped Etherpads for all topics and linked to them from
the main etherpad. Each has some basic context, at least enough to kick
start a conversation. If I missed details for a specific topic, please
feel free to elaborate. If you see something you have an interest in, or
want to drive, please add your name to the top of the Etherpad as a
champion, moderator, or scribe (see definitions in the main schedule).

Let me know if you see any issues or conflicts.

Thanks,

Lance

[0] https://etherpad.openstack.org/p/keystone-queens-ptg


On 07/27/2017 12:21 PM, Lance Bragstad wrote:
> I've added a section to the etherpad [0] for attendees. We need to start
> getting an idea of how many people plan on attending the PTG (for
> scheduling purposes). Please add your name and IRC nick to the list.
>
> Thanks
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>
>
> On 07/05/2017 11:22 AM, Lance Bragstad wrote:
>> Hey all,
>>
>> I've started an etherpad [0] for us to collect topics and ideas for the
>> PTG in September. I hope to follow the same planning format as last
>> time. Everyone has the opportunity to add topics to the agenda and after
>> some time we'll group related topics and start building a formal schedule.
>>
>> The etherpad has two lists. One for project-specific topics and one for
>> cross-project topics. As soon as we firm up the things we need to
>> collaborate on with other projects, I'll start coordinating with other
>> teams. These were the sessions we had to work around last time due to
>> schedules. We can sprinkle the project related topics in to fill the gaps.
>>
>> Let me know if you have any questions.
>>
>> Thanks!
>>
>>
>> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>>
>>
>




signature.asc
Description: OpenPGP digital 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] [all][api] POST /api-sig/news

[Chris Dent]

Greetings OpenStack community,

Two main topics this week: Getting ready for the PTG and speculating about 
standards for representing singular resources in an HTTP response.

The API-SIG will have a room on Monday and Tuesday at the PTG. In addition to 
the guided review process [6] we've mentioned before, there's an etherpad [5] 
where an agenda of potential topics is being built. We'll likely be sharing 
some of the time with people interested in SDKs and other issues related to 
consuming APIs. If there are gaps we will strenuously but politely argue about 
strong types in HTTP APIs and the subtle nature of microversions.

The discussion about singular resources relates to a placeholder bug [7] for a 
guideline that we need to write. There are at least two different styles in use 
within OpenStack already, neither of which align with some emerging standards. 
The bug links to some of the discussion. Please feel free to provide your 
opinion if you have one.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* Explain, simply, why extensions are bad
  https://review.openstack.org/#/c/491611/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[5] https://etherpad.openstack.org/p/api-ptg-queens
[6] http://specs.openstack.org/openstack/api-wg/guidedreview.html
[7] https://bugs.launchpad.net/openstack-api-wg/+bug/1593310

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Mohammed Naser]

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang  wrote:
> We are moving to deploy service via WSGI[0].
>
> There are two recommended ways.
>
> - apache + mod_wsgi
> - nginx + uwsgi
>
> later one is more better.
>
> For traditional deployment, it is easy to implement. Use one
> uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).
> Then one nginx process to forward the http require into uwsgi server.
>
> But kolla is running one process in one container. If we use
> the recommended solution, we have to use two container to run
> nova-api container. and it will generate lots of containers.
> like: nginx-nova-api, uwsig-nova-api.
>
> i propose use uwsgi native http mode[1]. Then one uwsgi
> container is enough to run nova-api service. Base one the official
> doc, if there is no static resource, uWSGI is recommended to use
> as a real http server.
>
> So how about this?

I think this is an interesting approach.  At the moment, the Puppet
modules currently allow deploying for services using mod_wsgi.
Personally, I don't think that relying on the HTTP support of uWSGI is
very favorable.   It is quite difficult to configure and 'get right'
and it leaves a lot to be desired (for example, federated auth relies
on Apache modules which would make this nearly impossible).

Given that the current OpenStack testing infrastructure proxies to
UWSGI, I think it would be best if that approach is taken.  This way,
a container (or whatever service) would expose a UWSGI API, which you
can connect whichever web server that you need.

In the case of Kolla, the `httpd` container would be similar to what
the `haproxy` is.  In the case of Puppet, I can imagine this being
something to be managed by the user (with some helpers in there).  I
think it would be interesting to add the tripleo folks on their
opinion here as consumers of the Puppet modules.

>
>
> [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
> [1]
> http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

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

[openstack-dev] [glance] priorities for THURSDAY (24 aug) and FRIDAY (25 aug)

[Brian Rosmaita]

Glance Pike RC-2 is available.  Our current priorities are to test it
out and report any critical bugs immediately (use the RC etherpad).
We basically have Thursday and Friday to find, fix, and merge any
changes for Pike.

https://etherpad.openstack.org/p/glance-pike-RC-critical

cheers,
brian

__
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] [ironic][docs] I see, you see, we all see red*

[Ruby Loo]

Hi Alex,

Sorry, I don't know much about the docs stuff; Andreas' links were useful
for enlightening me.

Clearly, I'm biased and would prefer no difference in colour. What about
that (darker?) blue from [0], where it sez (I'm referring to the
upper-cased words here) 'Modern color theory uses either the ... RED-CYAN,
GREEN-MAGENTA, BLUE-YELLOW'. Would that blue clash with the blue you are
mentioning? (Well, maybe it is the bold + blue that I like, not just the
blue.)

I don't really think a complementary colour is good, orange is marginally
better than red. I'd like it to be highlighted but I guess I like subtle,
not strong.

Having said all that, I'm a reader/viewer of these documents and this is
*just* my opinion. It seems to me that there might be research into what
works best? Anyone know?

Thanks,
--ruby

On Thu, Aug 24, 2017 at 6:19 AM, Alexandra Settle 
wrote:

> Hey Ruby!
>
>
>
> Good point – thanks for bringing it up :)
>
>
>
> I was brought up to think that red was one of those colours that people
> had different (and sometimes really negative) associations with. When I
> look at our latest and greatest! ironic documentation (e.g. [1]), I see
> red. Not only do I see red, but the term has a different background colour
> and is bordered (or whatever it is called). Are we using the wrong .rst
> syntax, should we be highlighting terms differently? And/or is there some
> way to change the appearance of highlighted terms? I much prefer something
> simple, like bold black text in some uniform font. On the other hand,
> perhaps lots of others like this and I'm in the minority.
>
>
>
> Andreas is right – the red definitely correct, and this is how we have
> always done it in manuals. But that doesn’t mean we have to continue. We
> just need to come up with another strong, inoffensive colour that matches;
> I believe the red was chosen to simply contrast the blue. A compromise, and
> complementary colour[0], would be orange. How would you feel about this?
>
>
>
> I hesitated about sending this due to the wonderful bike shedding that
> could happen, don't disappoint me, cuz I'm sure we all have opinions about
> colour. :)
>
>
>
> Not going to lie, also afraid of all the bike shedding! But you bring up a
> good point – and I don’t want others to also feel negatively about our
> documentation. We should be as inclusive as we can.
>
>
>
> Also, this email thread isn't about discussing the green and orange
> colours used for the code blocks; feel free to start your own thread about
> that if you want!
>
>
>
> No thanks, if I can avoid it :P
>
>
>
> Cheers,
>
>
>
> Alex
>
>
>
> [0] https://en.wikipedia.org/wiki/Complementary_colors
>
> __
> 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] [neutron] neutron 11.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/pike

Release notes for neutron can be found at:

http://docs.openstack.org/releasenotes/neutron/




__
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] networking-midonet 5.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-midonet for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-midonet/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/networking-midonet/log/?h=stable/pike

Release notes for networking-midonet can be found at:

http://docs.openstack.org/releasenotes/networking-midonet/




__
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] networking-bgpvpn 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-bgpvpn for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-bgpvpn/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-bgpvpn/log/?h=stable/pike

Release notes for networking-bgpvpn can be found at:

http://docs.openstack.org/releasenotes/networking-bgpvpn/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/bgpvpn

and tag it *pike-rc-potential* to bring it to the networking-bgpvpn
release crew's attention.


__
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-dynamic-routing 11.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-dynamic-routing for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-dynamic-routing/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/neutron-dynamic-routing/log/?h=stable/pike

Release notes for neutron-dynamic-routing can be found at:

http://docs.openstack.org/releasenotes/neutron-dynamic-routing/




__
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] networking-ovn 3.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-ovn for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-ovn/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-ovn/log/?h=stable/pike

Release notes for networking-ovn can be found at:

http://docs.openstack.org/releasenotes/networking-ovn/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-ovn

and tag it *pike-rc-potential* to bring it to the networking-ovn
release crew's attention.


__
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] networking-sfc 5.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-sfc for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-sfc/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-sfc/log/?h=stable/pike

Release notes for networking-sfc can be found at:

http://docs.openstack.org/releasenotes/networking-sfc/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-sfc

and tag it *pike-rc-potential* to bring it to the networking-sfc
release crew's attention.


__
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-fwaas 11.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-fwaas for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-fwaas/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/pike

Release notes for neutron-fwaas can be found at:

http://docs.openstack.org/releasenotes/neutron-fwaas/




__
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] networking-bagpipe 7.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-bagpipe for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-bagpipe/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:


http://git.openstack.org/cgit/openstack/networking-bagpipe/log/?h=stable/pike

Release notes for networking-bagpipe can be found at:

http://docs.openstack.org/releasenotes/networking-bagpipe/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/networking-bagpipe

and tag it *pike-rc-potential* to bring it to the networking-bagpipe
release crew's attention.


__
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] networking-odl 11.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-odl for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-odl/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/networking-odl/log/?h=stable/pike

Release notes for networking-odl can be found at:

http://docs.openstack.org/releasenotes/networking-odl/




__
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] [glance] glance 15.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for glance for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/glance/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/glance/log/?h=stable/pike

Release notes for glance can be found at:

http://docs.openstack.org/releasenotes/glance/




__
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] [ironic] ironic-staging-drivers core cleanup and additions

[Dmitry Tantsur]

We seem to be in agreement, so I'll apply these changes. Thanks all!

On 08/22/2017 11:24 AM, Dmitry Tantsur wrote:

Hi all!

This email concerns the ironic-staging-drivers project which is outside of the 
official Ironic governance. Please ignore it if you don't care about this project.


I've checked the core [1] and the release [2] teams for the project, and I think 
they need an update based (see [3]).


I suggest removing the following people:
* Dan Prince (due to inactivity)
* Lucas Alvares Gomes (due to priorities change)
* Imre Farkas (no longer works on OpenStack)

I suggest adding Pavlo Shchelokovskyy, who actively contributes to and reviews 
the project, to the core team.


I've cc'ed affected people as I was a bit too lazy to reach to them on IRC :) 
Please let me know your opinion.


[1] https://review.openstack.org/#/admin/groups/1258,members
[2] https://review.openstack.org/#/admin/groups/1259,members
[3] http://stackalytics.com/?module=ironic-staging-drivers=pike



__
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] [tc] [all] reducing code complexity as a top-5 goal

[Chris Dent]

In the rather long history of OpenStack there have been plenty of
discussions about how to make sure that architectural and code
complexity and various forms technical debt get the attention they
deserve. Lots of different approaches from different angles; some
more successful than others. One recent not-so-successful effort was
the architecture working group: it never got enough traction to make
any real change.

In TC office hours earlier this week

   
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-22.log.html#t2017-08-22T09:02:42

I introduced an idea for a different approach: attempt to reduce
some measure of complexity by prioritizing simple rules of thumb
about code complexity: "things like extracing methods, keeping
methods short, avoiding side effects, keeping modules short".

To make this discussion more concrete I've proposed that we "Add
Reduce Development Complexity" to the top-5 help wanted list:

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

(The top-5 list

https://governance.openstack.org/tc/reference/top-5-help-wanted.html

is a way to socialize and popularize areas where additional
contribution and attention is needed.)

This idea could just as easily be a community goal, or something we
take on simply because we are motivated folk. I'm simply using the
review as a way to get the conversation started and bound it a bit
so we don't fall in a hole. It may be that this goes nowhere, but
it's worth a try.

Different people have very different ideas on what complexity in
code means, and the relative important of maintainability and
readability. In the document under review I state some of the
reasons why these things might be important for than just personal
preference reasons. It also includes some complexity stats[1] for some
of the larger and older projects.

If you have thoughts on this idea, please comment here or on the
review, especially if you have some ideas on how to make issues like
this have traction.

Thanks.

[1] Note that such metrics are not substitute for human evaluation
of code. They simply provide a straightforward way of finding some
sore thumbs. We should neither trust nor rely on these metrics to
assert much of anything.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [tests] [tempest] Neutron dvr tempest test problem

[Luigi Toscano]

On Thursday, 24 August 2017 12:51:05 CEST Ning Yao wrote:
> Hi, all
> 
> I encounter a problem about neutron tempest test. I run the tempest
> neutron plugin test against my self-build OpenStack, and I find that
> tempest will run the dvr test and report NotImplementedERROR. I dig
> into the test code and find that even if I do not enable dvr router
> for my OpenStack, the dvr test runs and does not automatically skip.
> This is because it only skip this logic when
> network-feature-enabled.api_extensions does not support dvr.

I think that you hit this:

https://bugs.launchpad.net/neutron/+bug/1450067

which should be fixed from Pike.

Ciao
-- 
Luigi

__
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] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Raildo Mascena de Sousa Filho]

So, I didn't find that topic in the TripleO umbrella[1]. Emilien, can you
confirm that?
If not, I have a suggestion, we can schedule into the reservable rooms and
if we confirm that it will be able to do in the TripleO or any other team's
agenda, we can remove it.

What do you guys think?

[1] https://etherpad.openstack.org/p/tripleo-ptg-queens

On Mon, Aug 21, 2017 at 11:54 AM Doug Hellmann 
wrote:

> Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-17
> 12:16:15 +:
> > Hi all,
> >
> > Should we reserve a room in the extra session ethercalc [0
> > ] or we
> > already have a time slot scheduled for that discussion?
> >
> > [0] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>
> I think this topic was on Emilien's list for TripleO. Would the other
> groups mind if the TripleO team hosts the discussion in their room? That
> would save the more limited reserveable rooms for discussions that don't
> have an obvious host.
>
> 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
>
-- 

Raildo mascena

Software Engineer, Identity Managment

Red Hat



TRIED. TESTED. TRUSTED. 
__
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-neutron] [neutron dvr tempest test problem]

[Jakub Libosvar]

On 24/08/2017 12:47, Ning Yao wrote:
> Hi, all
> 
> I encounter a problem about neutron tempest test. I run the tempest
> neutron plugin test against my self-build OpenStack, and I find that
> tempest will run the dvr test and report NotImplementedERROR. I dig
> into the test code and find that even if I do not enable dvr router
> for my OpenStack, the dvr test runs and does not automatically skip.
> This is because it only skip this logic when
> network-feature-enabled.api_extensions does not support dvr.
> ```
> 
> class DvrRoutersTest(base_routers.BaseRouterTest):
> 
> 
> @classmethod
> 
> @test.requires_ext(extension="dvr", service="network")
> 
> def skip_checks(cls):
> 
> super(DvrRoutersTest, cls).skip_checks()
> 
> ```
> 
> Is any other way to skip the test?
> 
> I can manually delete the 'dvr' in tempest.conf
> network-feature-enabled.api_extensions, but it is not convenient for
> integrating test. while the value
> network-feature-enabled.api_extensions is automatically detected from
> neutron ext-list.
> 
> while neutron ext-list is describing whether the current version
> supports dvr,  dvr can be still disabled in neutron.conf for a certain
> openstack environment. So I think we need a method to find out whether
> this feature is enabled for the current OpenStack cluster and skip
> this test depending on this. Am I right or I still miss something.
> 
> 
> Regards
> Ning Yao

Hi Ning,

during the Pike cycle, there was a patch [1] merged for this specific
problem ops were facing. If your build contains this change, you can set
enable_dvr option to False in /etc/neutron/neutron.conf and then your
ext-list won't be propagating dvr.

I hope that helps.

Jakub

[1] https://review.openstack.org/#/c/454203/
> 
> __
> 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] [neutron] [tests] [tempest] Neutron dvr tempest test problem

[Ning Yao]

Hi, all

I encounter a problem about neutron tempest test. I run the tempest
neutron plugin test against my self-build OpenStack, and I find that
tempest will run the dvr test and report NotImplementedERROR. I dig
into the test code and find that even if I do not enable dvr router
for my OpenStack, the dvr test runs and does not automatically skip.
This is because it only skip this logic when
network-feature-enabled.api_extensions does not support dvr.
```

class DvrRoutersTest(base_routers.BaseRouterTest):


@classmethod

@test.requires_ext(extension="dvr", service="network")

def skip_checks(cls):

super(DvrRoutersTest, cls).skip_checks()

```

Is any other way to skip the test?

I can manually delete the 'dvr' in tempest.conf
network-feature-enabled.api_extensions, but it is not convenient for
integrating test. while the value
network-feature-enabled.api_extensions is automatically detected from
neutron ext-list.

while neutron ext-list is describing whether the current version
supports dvr,  dvr can be still disabled in neutron.conf for a certain
openstack environment. So I think we need a method to find out whether
this feature is enabled for the current OpenStack cluster and skip
this test depending on this. Am I right or I still miss something.


Regards
Ning Yao

__
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-neutron] [neutron dvr tempest test problem]

[Ning Yao]

Hi, all

I encounter a problem about neutron tempest test. I run the tempest
neutron plugin test against my self-build OpenStack, and I find that
tempest will run the dvr test and report NotImplementedERROR. I dig
into the test code and find that even if I do not enable dvr router
for my OpenStack, the dvr test runs and does not automatically skip.
This is because it only skip this logic when
network-feature-enabled.api_extensions does not support dvr.
```

class DvrRoutersTest(base_routers.BaseRouterTest):


@classmethod

@test.requires_ext(extension="dvr", service="network")

def skip_checks(cls):

super(DvrRoutersTest, cls).skip_checks()

```

Is any other way to skip the test?

I can manually delete the 'dvr' in tempest.conf
network-feature-enabled.api_extensions, but it is not convenient for
integrating test. while the value
network-feature-enabled.api_extensions is automatically detected from
neutron ext-list.

while neutron ext-list is describing whether the current version
supports dvr,  dvr can be still disabled in neutron.conf for a certain
openstack environment. So I think we need a method to find out whether
this feature is enabled for the current OpenStack cluster and skip
this test depending on this. Am I right or I still miss something.


Regards
Ning Yao

__
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] [ironic][docs] I see, you see, we all see red*

[Alexandra Settle]

Hey Ruby!

Good point – thanks for bringing it up :)

I was brought up to think that red was one of those colours that people had 
different (and sometimes really negative) associations with. When I look at our 
latest and greatest! ironic documentation (e.g. [1]), I see red. Not only do I 
see red, but the term has a different background colour and is bordered (or 
whatever it is called). Are we using the wrong .rst syntax, should we be 
highlighting terms differently? And/or is there some way to change the 
appearance of highlighted terms? I much prefer something simple, like bold 
black text in some uniform font. On the other hand, perhaps lots of others like 
this and I'm in the minority.

Andreas is right – the red definitely correct, and this is how we have always 
done it in manuals. But that doesn’t mean we have to continue. We just need to 
come up with another strong, inoffensive colour that matches; I believe the red 
was chosen to simply contrast the blue. A compromise, and complementary 
colour[0], would be orange. How would you feel about this?

I hesitated about sending this due to the wonderful bike shedding that could 
happen, don't disappoint me, cuz I'm sure we all have opinions about colour. :)

Not going to lie, also afraid of all the bike shedding! But you bring up a good 
point – and I don’t want others to also feel negatively about our 
documentation. We should be as inclusive as we can.

Also, this email thread isn't about discussing the green and orange colours 
used for the code blocks; feel free to start your own thread about that if you 
want!

No thanks, if I can avoid it :P

Cheers,

Alex

[0] https://en.wikipedia.org/wiki/Complementary_colors
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] About OpenStack's resource limit

[rk_1218_live]

Hi
I think of  starting to use OpenStack.
Because I want to monitor resource usage (CPU utilization, memory, 
...etc) with OpenStack!!

I have one question.
Can I restrict resource with OpenStack?

For example, is it possible to limit the CPU to 20 % for process that 
normally use 50% CPU?

If you have such a command, please let me know!

Thanks.

--
Name: Kurokawa Ryota
mail: rk_1218_l...@i.softbank.jp

__
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] [tricircle-Problem accessing the instance console]

[Vega Cai]

Hi Meher,

You can first check whether the nova-consoleauth and nova-novncproxy
services are correctly running. If you use DevStack, the window names for
these two services are n-cauth and n-novnc.

BR
Zhiyuan

On Wed, 23 Aug 2017 at 23:55  wrote:

> Hello to the Tricircle community,
>
>
>
> I am sending you this mail in order to ask for help concerning the launch
> of the console of the instances created in the different regions.
>
>
>
> I have two regions each with an active instance and its status is
> "running", for the first region, I can not open the console from the
> dashboard and for the second, the console is displayed but with an error of
> connection to the server.
>
> PS: access to both console worked without problems before I restarted my
> server.
>
>
>
> Thank you in advance for your help.
>
>
>
> Best regards,
>
>
>
> Meher
>
>
>
> (+33) 7 58 38 68 87 <+33%207%2058%2038%2068%2087>
>
>
>
> [image: Logo Orange] 
>
>
>
> *Meher Hihi *
> Intern
> ORANGE/IMT/OLN/WTC/CMA/MAX
>
> Fixe : +33 2 96 07 03 71
> 
> Mobile : +33 7 58 38 68 87
> 
> meher.h...@orange.com
>
>
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> 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
>
-- 
BR
Zhiyuan
__
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] Less than 24 hours to Pike RC2

[Alex Xu]

2017-08-24 11:34 GMT+08:00 Matt Riedemann :

> This is just a reminder that we're in the final stretch for Pike RC2 which
> happens tomorrow.
>
> There are a couple of fixes in flight yet for RC2 at the top of the
> etherpad:
>
> https://etherpad.openstack.org/p/nova-pike-release-candidate-todo
>
> And another bug that Alex pointed out tonight not yet reported in
> launchpad, but we don't cleanup allocations from the current node before
> doing a reschedule. If you have Ocata computes or are doing super-conductor
> mode tiered conductors for cells v2 then it's not an issue, but any
> installs that are doing single conductor relying on reschedules will have
> this issue, which I'd consider something we should fix for RC2 as it means
> we'll be reporting usage against compute nodes in Placement which isn't
> really there, thus potentially taking them out of scheduling decisions.
>

here is the bug https://bugs.launchpad.net/nova/+bug/1712718 and the fix
https://review.openstack.org/496995

>
> If you find anything else in the next few hours, please report a bug and
> tag it with pike-rc-potential.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra] Request to delete some unused pages from OpenStack wiki

[Chen Ying]

hi,
The name of the project data protection as a service has been
changed to Karbor for a long time.
The name smuag is no longer needed. So some pages about smaug could be
deleted from OpenStack wiki.
But I don't have permissions. Hope that these pages[1] could be deleted by
anyone who has the
administrator permissions to the wiki. Thanks.


[1] https://wiki.openstack.org/wiki/Smaug
 https://wiki.openstack.org/wiki/Smaug/Devstack
https://wiki.openstack.org/wiki/Meetings/smaug
Best regards.
Chen Ying
__
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