[openstack-dev] [openstack-ansible] restrictive umask / file permissions in target hosts

[Markus Zoeller]

How do you deal with hosts which have a restrictive umask of 077
*before* openstack-ansible starts the setup? Do you start with the
default umask of 022 and opt-in later to that security hardening[1]?

What's the development policy of openstack-ansible regarding setting
file or directory permissions in tasks?

* is a umask value of 022 assumed for tasks to work?
* should tasks always explicitly set the file/dir mode?
* other options I'm not aware of?

Background
--
The (internal) folks who gave me the target hosts for openstack-ansible
set the umask to 077 *before* I started the installation and I wasn't
aware of that setting. So I spent some time figuring out why the nginx
server in the repo container can't serve files like the requirements
file "requirements_absolute_requirements.txt"[2] because of file
permissions like this:

-rw--- 1 root root [...] requirements_absolute_requirements.txt

This also affects the nginx config files (which, for example, set the
'autoindex' behavior, which is needed to serve the python wheels):

cd /etc/nginx/sites-available/
ll openstack-slushee.vhost
-rw--- 1 root root [...] openstack-slushee.vhost

Not sure if that was also the root cause of [3].

References
--
[1]
https://github.com/openstack/openstack-ansible-security/blob/40c744c86dd7e5e53e88a5ddd7389333a26f92d2/defaults/main.yml#L340-L363
[2]
https://github.com/openstack/openstack-ansible-repo_build/blob/fe3ae20f74a912925d5c78040984957a6d55f9de/tasks/repo_post_build.yml#L43-L46
[3]
https://stackoverflow.com/questions/42286765/using-repo-other-then-pypi-with-pip

-- 
Regards, Markus Zoeller (markus_z)


__
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] [ceilometer]Understandig ceilometer

[Gyorgy Szombathelyi]

Hi!

I try to dig into the inner workings of ceilometer, and there are things I 
couldn't figure out:

- I understand that there is no collector service now. I know the old pipeline 
was: compute-agent->notification-agent->collector->storage(gnocchi).
Now I assumed it should be compute-agent->storage(gnocchi). 
However I found out it is a bit different: 
compute-agent->notification-agent->storage. Is it the intended behavior or just 
a configuration error on my side?

- I found no gnocchi at the publishers, but it is still there at the 
dispatchers. How is it used as a publisher? Just with some magic 
transformation, publishers: -gnocchi:// is
translated into using the direct publisher?

Br,
György

__
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][all][ptl] doc-migration status

[Alexandra Settle]

Just to add to this, today I have spent some time going through and abandoning 
patches that were against the master branch for openstack-manuals and I have 
backported those applicable to Ocata.

If anyone has patches against the master branch that are addressing a 
bug/fix/enhancement in the install, networking, config ref, CLI ref, or admin 
guides – please abandon and move to relevant repo.

Thanks everyone for all your hard work! This has been a massive success (so 
far) as a result of everyone pooling together (

On 7/3/17, 3:34 PM, "Doug Hellmann"  wrote:

After a busy week last week, we made some good progress with the
documentation migration project. We still have quite a few repositories
that haven't been started, though, so please keep working. If you
need assistance preparing or reviewing the patches, let us know
with a follow-up email to this thread or by asking in #openstack-docs.

Because we still have a lot of work to do in the openstack-manuals
repo, the documentation team has started landing patches to remove
the content that is being migrated into project repositories. If
you have not yet started your migration, check out the commit tagged
"before-migration" in openstack-manuals to find the content to be
migrated.

As part of this work today we have also prepared a patch to move
all remaining projects to the new documentation build jobs. This
will cause any content from doc/source to be published to
docs.o.o/$project/latest instead of docs.o.o/developer/$project.
Project teams still need to reorganize this content as described
in the spec to ensure the automatically generated landing pages
point to the correct URLs.

We need to complete this migration work before creating stable
branches, to avoid having to backport the documentation changes.

Over the course of last week, we had a few questions about the
directions and about reviews.

1. Please use the gerrit topic "doc-migration" for all of the patches
related to this work. We are monitoring the available changes by
using that topic in queries, and we won't see your patches to help
with reviews if you use another topic. Tying your patch to the
blueprint using "Blueprint: doc-migration" will set the topic of
the patch to "bp/doc-migration", and the patches will not appear
in the query results.

2. Please work on the steps in the order given. We have had quite
a few patches that only apply the new theme, without reorganizing
the content for the projects. These projects will not be linked
properly from the templated landing pages, so your users will have
trouble finding your documentation.

3. Only official OpenStack projects, under TC governance, should
use the openstackdocs theme. Projects publishing their documentation
to readthedocs.org or other sites should not use the theme, and do
not need to take any of the other migration steps.

4. Reviewers, please prioritize landing the intiial content import
and ask for follow-up patches to fix issues, unless the content is
just absolutely wrong. Whitespace issues, typos, etc. should all
be fixed after the initial import of the content created by the
documentation team is complete.

5. Projects with a "deployment guide" instead of "install guide"
need to make sure they are using the openstackdocs theme and to
update the organization of the rest of their content. The deployment
guide should stay where it is, for now.

6. We've had a couple of cases where multiple people did the same
work because neither put their name next to the repository in the
list on https://etherpad.openstack.org/p/doc-migration-tracking.
We have plenty of this work to go around! Please use the etherpad
to sign up for the repo you are going to work on *before* starting
to write patches, so that we can avoid duplicating effort!

If you run into trouble or have other questions, please follow-up
here or ping us in the #openstack-doc IRC channel on Freenode.

Doug

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


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

[openstack-dev] [OpenStack-Dev][OpenStackClient] - Running functional tests

[nidhi.h...@wipro.com]

Hello all,

I am running functional tests for openstackclient.
By using this command sudo tox -efunctional

It gives me this error

setUpClass 
(openstackclient.tests.functional.volume.v3.test_snapshot.VolumeSnapshotTests)
-

Captured traceback:
~~~
Traceback (most recent call last):
  File "openstackclient/tests/functional/volume/v3/test_snapshot.py", line 
22, in setUpClass
super(VolumeSnapshotTests, cls).setUpClass()
  File "openstackclient/tests/functional/volume/v2/test_snapshot.py", line 
31, in setUpClass
cls.VOLLY
  File "openstackclient/tests/functional/base.py", line 64, in openstack
return execute('openstack ' + cmd, fail_ok=fail_ok)
  File "openstackclient/tests/functional/base.py", line 41, in execute
result_err)
tempest.lib.exceptions.CommandFailed: Command 'openstack volume create -f 
json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned non-zero exit status 1.
stdout:

stderr:
Missing value auth-url required for auth plugin password


Can someone tell me where do I need to configure environment variables
So that functional tests run well?

Any doc /url also will be helpful.

Thanks
Nidhi

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] External GUI for Mistral is now at github

[Shaanan, Guy (Nokia - IL/Kfar Sava)]

Hi all,

We are happy to announce "CloudFlow"- a Mistral Workflow Execution 
Visualization tool, to help you debug and monitor in real time the progress of 
executions.

CloudFlow offers web based GUI and relies on Mistral REST API.

CloudFlow source code is publicly available on github[1].

With this move we can now leverage the project management options in Github, 
like:
* Projects[2] - managing the backlog, todos and in-progress tasks.
* Issues[3] - for opening bugs and feature requests.

Contributions should be made via a PR and code review, after an appropriate 
task has been added to Projects or a bug has been opened.

Currently the building and publishing of new versions is done manually and will 
be automated in the future.


[1] https://github.com/nokia/CloudFlow
[2] https://github.com/nokia/CloudFlow/projects/1
[3] https://github.com/nokia/CloudFlow/issues

Thanks,

-
Guy Shaanan
CI & Internal Tools
Application & Analytics, Nokia
16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
T: +972 9 793 3013
M: +972 52 536 2986
guy.shaa...@nokia.com

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

[openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Daniel Mellado]

Hi Team,

I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
great help from start both contributing and reviewing.

Please voice your support or concerns if any

Best!

Daniel

__
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] The definition of 'Optional' parameter in API reference

[Ghanshyam Mann]

On Mon, Jul 3, 2017 at 1:38 PM, Takashi Natsume
 wrote:
> Hi, all.
>
> In Nova API reference, there is inconsistency in
> whether to define parameters added in new microversion as 'optional' or not.

Those should be defined based on how they are defined in respective
microversion. If they are 'optional' in that microversion they should
be mentioned as 'optional' and vice versa. Any parameter added in
microversion is mentioned as 'New in version 2.xy' which shows the non
availability of that parameter in earlier versions. Same case for
removal of parameter also.

But if any microversion change parameter from option param to required
or vice versa then it is tricky but IMO documenting the latest
behavior is right thing but with clear notes.
For example, microversion 2.37,   where 'network' in request made as
required from optional. In this cases, api-ref have the latest
behavior of that param which is 'required' and a clear notes about
till when it was optional and from when it is mandatory.

In all cases, doc should reflect the latest behavior of param with
notes(manual or auto generated with min_version & max_version)

>
> In the case that the parameter is always included in the response after a
> certain microversion,
> some parameters(e.g. 'type' [1]) are defined as 'required', but some
> parameters (e.g. 'project_id', 'user_id'[2])
> are defined as 'optional'.
>
> [1] List Keypairs in Keypairs (keypairs)
> https://developer.openstack.org/api-ref/compute/?expanded=list-keypairs-detail#list-keypairs
>
> [2] List Server Groups in Server groups (os-server-groups)
> https://developer.openstack.org/api-ref/compute/?expanded=list-server-groups-detail#list-server-groups

'project_id', 'user_id' are introduced as 'required' from version 2.13
[2] and should be added as 'required' in api doc also. i reported bug
on this - https://bugs.launchpad.net/nova/+bug/1702238


>
> In the case that the parameter is always included in the response after a
> certain microversion,
> should it be defined as 'required' instead of 'optional'?
>
> Regards,
> Takashi Natsume
> NTT Software Innovation Center
> E-mail: natsume.taka...@lab.ntt.co.jp
>

..1 
https://developer.openstack.org/api-ref/compute/?expanded=create-server-detail#create-server
..2 
https://github.com/openstack/nova/blob/038619cce803c3522701886aa59c0c2750532b3a/nova/api/openstack/compute/server_groups.py#L104-L106

-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 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] no QoS meeting tomorrow

[Alonso Hernandez, Rodolfo]

Hello everyone:

Sorry for the late heads up. Today won't be Neutron QoS meeting because of the 
lack of quorum (4th of July).

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

Re: [openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Gal Sagie]

+1

On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado 
wrote:

> Hi Team,
>
> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
> great help from start both contributing and reviewing.
>
> Please voice your support or concerns if any
>
> Best!
>
> Daniel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

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

Re: [openstack-dev] [nova] The definition of 'Optional' parameter in API reference

[Alex Xu]

2017-07-04 15:40 GMT+08:00 Ghanshyam Mann :

> On Mon, Jul 3, 2017 at 1:38 PM, Takashi Natsume
>  wrote:
> > Hi, all.
> >
> > In Nova API reference, there is inconsistency in
> > whether to define parameters added in new microversion as 'optional' or
> not.
>
> Those should be defined based on how they are defined in respective
> microversion. If they are 'optional' in that microversion they should
> be mentioned as 'optional' and vice versa. Any parameter added in
> microversion is mentioned as 'New in version 2.xy' which shows the non
> availability of that parameter in earlier versions. Same case for
> removal of parameter also.
>
> But if any microversion change parameter from option param to required
> or vice versa then it is tricky but IMO documenting the latest
> behavior is right thing but with clear notes.
> For example, microversion 2.37,   where 'network' in request made as
> required from optional. In this cases, api-ref have the latest
> behavior of that param which is 'required' and a clear notes about
> till when it was optional and from when it is mandatory.
>
> In all cases, doc should reflect the latest behavior of param with
> notes(manual or auto generated with min_version & max_version)
>

++


>
> >
> > In the case that the parameter is always included in the response after a
> > certain microversion,
> > some parameters(e.g. 'type' [1]) are defined as 'required', but some
> > parameters (e.g. 'project_id', 'user_id'[2])
> > are defined as 'optional'.
> >
> > [1] List Keypairs in Keypairs (keypairs)
> > https://developer.openstack.org/api-ref/compute/?expanded=
> list-keypairs-detail#list-keypairs


'keypairs_links' in the response should be the required parameter. Because
it always show up after 2.35.


>
> >
> > [2] List Server Groups in Server groups (os-server-groups)
> > https://developer.openstack.org/api-ref/compute/?expanded=
> list-server-groups-detail#list-server-groups
>
> 'project_id', 'user_id' are introduced as 'required' from version 2.13
> [2] and should be added as 'required' in api doc also. i reported bug
> on this - https://bugs.launchpad.net/nova/+bug/1702238
>
>
> >
> > In the case that the parameter is always included in the response after a
> > certain microversion,
> > should it be defined as 'required' instead of 'optional'?
> >
> > Regards,
> > Takashi Natsume
> > NTT Software Innovation Center
> > E-mail: natsume.taka...@lab.ntt.co.jp
> >
>
> ..1 https://developer.openstack.org/api-ref/compute/?expanded=
> create-server-detail#create-server
> ..2 https://github.com/openstack/nova/blob/038619cce803c3522701886aa59c0c
> 2750532b3a/nova/api/openstack/compute/server_groups.py#L104-L106
>
> -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 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] (no subject)

[Lawrence J. Albinson]

Dear Colleagues,

Before I go problem hunting, has anyone seen openstack-ansible builds failing 
at release 15.1.5 at the following point:

TASK [lxc_container_create : Create localhost config] **

with the error 'lxc-attach: command not found'?

The self-same environment is working fine at 15.1.3.

I've turned up nothing with searches. Any help greatly appreciated.

Kind regards, Lawrence

Lawrence J Albinson

__
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] [mistral] External GUI for Mistral is now at github

[Lingxian Kong]

That's awesome! It'd be better if there is a demo for introduction :-)


Cheers,
Lingxian Kong (Larry)

On Tue, Jul 4, 2017 at 9:48 PM, Shaanan, Guy (Nokia - IL/Kfar Sava) <
guy.shaa...@nokia.com> wrote:

> Hi all,
>
>
>
> We are happy to announce “CloudFlow”- a Mistral Workflow Execution
> Visualization tool, to help you debug and monitor in real time the progress
> of executions.
>
>
>
> CloudFlow offers web based GUI and relies on Mistral REST API.
>
>
>
> CloudFlow source code is publicly available on github[1].
>
>
>
> With this move we can now leverage the project management options in
> Github, like:
>
> * Projects[2] - managing the backlog, todos and in-progress tasks.
>
> * Issues[3] - for opening bugs and feature requests.
>
>
>
> Contributions should be made via a PR and code review, after an
> appropriate task has been added to Projects or a bug has been opened.
>
>
>
> Currently the building and publishing of new versions is done manually and
> will be automated in the future.
>
>
>
>
>
> [1] https://github.com/nokia/CloudFlow
>
> [2] https://github.com/nokia/CloudFlow/projects/1
>
> [3] https://github.com/nokia/CloudFlow/issues
>
>
>
> Thanks,
>
>
>
> *-*
>
> *Guy Shaanan*
>
> CI & Internal Tools
>
> Application & Analytics, Nokia
>
> 16 Atir Yeda St. Kfar-Saba 44643, ISRAEL
>
> T: +972 9 793 3013
>
> M: +972 52 536 2986 <+972%2052-536-2986>
>
> guy.shaa...@nokia.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] How to specify gic version in openstack

[Vishnu Pajjuri]

Hi,

I am trying to run Openstack on ARM64 architecture. ARM64 architecture with
KVM hypervisor needs GIC version(generic interrupt controller) as a
property for the image when we are creating/uploading an image. I would
like to include this property in the glance code. I am new to glance, Can
someone suggest me how to approach for this.

Thanks in advance

-Vishnu
__
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] [FEMDC] IRC Meeting tomorrow 15:00 UTC

[lebre . adrien]

Dear all, 

A gentle reminder for our meeting tomorrow. 
As usual, the agenda is available at: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
860)
Please feel free to add items.

Best,
Adrien
PS: note that due to the vacation period, I don't know how many persons will be 
present. 

__
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-Dev][OpenStackClient] - Running functional tests

[Steve Martinelli]

Looks like running tox will pass along any environment variables with the
prefix "OS_" from the shell to tox, see
https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L55

So as long as you've sourced or exported a bunch of env. variables, you
should be ready to run tests. You don't and shouldn't run it with sudo
either.

On Tue, Jul 4, 2017 at 2:25 AM, nidhi.h...@wipro.com 
wrote:

> Hello all,
>
>
>
> I am running functional tests for openstackclient.
>
> By using this command sudo tox -efunctional
>
>
>
> *It gives me this error *
>
>
>
> setUpClass (openstackclient.tests.functional.volume.v3.test_
> snapshot.VolumeSnapshotTests)
>
> 
> -
>
>
>
> Captured traceback:
>
> ~~~
>
> Traceback (most recent call last):
>
>   File "openstackclient/tests/functional/volume/v3/test_snapshot.py",
> line 22, in setUpClass
>
> super(VolumeSnapshotTests, cls).setUpClass()
>
>   File "openstackclient/tests/functional/volume/v2/test_snapshot.py",
> line 31, in setUpClass
>
> cls.VOLLY
>
>   File "openstackclient/tests/functional/base.py", line 64, in
> openstack
>
> return execute('openstack ' + cmd, fail_ok=fail_ok)
>
>   File "openstackclient/tests/functional/base.py", line 41, in execute
>
> result_err)
>
> tempest.lib.exceptions.CommandFailed: Command 'openstack volume
> create -f json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned
> non-zero exit status 1.
>
> stdout:
>
>
>
> stderr:
>
> *Missing value auth-url required for auth plugin password*
>
>
>
>
>
> *Can someone tell me where do I need to configure environment variables*
>
> *So that functional tests run well?*
>
>
>
> *Any doc /url also will be helpful.*
>
>
>
> *Thanks*
>
> *Nidhi*
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.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] [congress] Using congress to improve the consistency of configuration files.

[valentin.matton]

We would like to use congress to check the consistency of the 
configuration files used by the various Openstack services on different 
nodes.


Although installers do a great job for ensuring that the initial 
definition of those files are correct, it may be necessary to tweak 
those files on running instances
or to use templates that are out of the bounds of the pre-configured 
use-cases. Then the administrator must modify the configuration without 
any safety net.


Congress is such a safety net but it ensures policies on live resources 
deployed in the cloud, not on how the cloud is configured but we think 
that it could be extended

to perform such verification with the adequate datasource.
So we propose a new datasource that will query each node to fetch its 
configuration files as long as they follow oslo.config requirements and 
structure.
As a first step we propose to use agents deployed on the different nodes 
explicitly configured with the list of configuration files that push 
those files to the central
congress service. Later on, oslo.config could be modified to provide a 
hook used to push config files directly from running services.


The new datasource displays not only the option values, the file, host 
where they are defined but also the associated metadata so that generic 
rules can be defined.

It is then possible to define rules:
- that constrain the value of options between different nodes
- that constrain the values between different services or different 
service plugins.
- it is even possible to use the knowledge of those configuration 
options to check policies on live resources (for example when there is a 
limitation or a bug in a given

driver).

We have a working prototype and the corresponding specification along 
those principles that we would like to share. An initial blueprint has 
been submitted here:

Please feel free to react

V. Matton

_

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

Re: [openstack-dev] [OpenStack-Dev][OpenStackClient] - Running functional tests

[Akihiro Motoki]

As Steve mentioned, you need to import OS_* envvars.
A user with admin role is required to pass all functional tests.
What I usually do is "export OS_CLOUD=devstack-admin" (if you use DevStack).


2017-07-04 22:01 GMT+09:00 Steve Martinelli :
> Looks like running tox will pass along any environment variables with the
> prefix "OS_" from the shell to tox, see
> https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L55
>
> So as long as you've sourced or exported a bunch of env. variables, you
> should be ready to run tests. You don't and shouldn't run it with sudo
> either.
>
> On Tue, Jul 4, 2017 at 2:25 AM, nidhi.h...@wipro.com 
> wrote:
>>
>> Hello all,
>>
>>
>>
>> I am running functional tests for openstackclient.
>>
>> By using this command sudo tox -efunctional
>>
>>
>>
>> It gives me this error
>>
>>
>>
>> setUpClass
>> (openstackclient.tests.functional.volume.v3.test_snapshot.VolumeSnapshotTests)
>>
>>
>> -
>>
>>
>>
>> Captured traceback:
>>
>> ~~~
>>
>> Traceback (most recent call last):
>>
>>   File "openstackclient/tests/functional/volume/v3/test_snapshot.py",
>> line 22, in setUpClass
>>
>> super(VolumeSnapshotTests, cls).setUpClass()
>>
>>   File "openstackclient/tests/functional/volume/v2/test_snapshot.py",
>> line 31, in setUpClass
>>
>> cls.VOLLY
>>
>>   File "openstackclient/tests/functional/base.py", line 64, in
>> openstack
>>
>> return execute('openstack ' + cmd, fail_ok=fail_ok)
>>
>>   File "openstackclient/tests/functional/base.py", line 41, in execute
>>
>> result_err)
>>
>> tempest.lib.exceptions.CommandFailed: Command 'openstack volume create
>> -f json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned non-zero exit
>> status 1.
>>
>> stdout:
>>
>>
>>
>> stderr:
>>
>> Missing value auth-url required for auth plugin password
>>
>>
>>
>>
>>
>> Can someone tell me where do I need to configure environment variables
>>
>> So that functional tests run well?
>>
>>
>>
>> Any doc /url also will be helpful.
>>
>>
>>
>> Thanks
>>
>> Nidhi
>>
>>
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email. www.wipro.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 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] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Antoni Segura Puimedon]

On Tue, Jul 4, 2017 at 12:23 PM, Gal Sagie  wrote:
> +1
+1
>
> On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado 
> wrote:
>>
>> Hi Team,
>>
>> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
>> great help from start both contributing and reviewing.
>>
>> Please voice your support or concerns if any
>>
>> Best!
>>
>> Daniel
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
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] [congress] Using congress to improve the consistency of configuration files.

[Clint Byrum]

Excerpts from valentin.matton's message of 2017-07-04 15:29:25 +0200:
> We would like to use congress to check the consistency of the 
> configuration files used by the various Openstack services on different 
> nodes.
> 
> Although installers do a great job for ensuring that the initial 
> definition of those files are correct, it may be necessary to tweak 
> those files on running instances
> or to use templates that are out of the bounds of the pre-configured 
> use-cases. Then the administrator must modify the configuration without 
> any safety net.
> 

While I'm sure this does still happen, you'd have to be living under a
rock to think that this is the state of the art.

I'm certain _most_ OpenStack installs are using automated configuration
management to assert their config file content. And if they're
practicing safe deploys, they also have integration tests to make sure
those modifications work properly.

Now, if Congress does in fact want to compete with Puppet / Chef /
Ansible / Salt / etc., I suppose that's Congress's choice. But just to
be clear: very few operators are doing what you suggest as the reason
to make Congress do this.

__
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] [horizon] [horizon-plugin] Raising Django version cap

[Rob Cresswell]

Hi everyone,

I've put up a patch to global-requirements to raise the Django cap to "<1.11", 
with the upper-constraint at "1.10.7" 
(https://review.openstack.org/#/c/480215). Depending on the remaining time, I'd 
quite like to move us to "1.11.x" before Requirements Freeze, which will fall 
around the 27th of July.

Rob
__
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] [masakari][nova] Allow evacuation of instances in resized state

[Kekane, Abhishek]

Hi operators,

I want to know how evacuation of resized instances is handled in real 
environment.
For example if the vm is in resized state and if the compute host on which the 
vm is resized goes down, then how will operator evacuate the vm.

One possible way is to reset that vm state to error and then evacuate it to new 
compute host.
Please refer below scenario for reference:

Scenario:
=

Pre-conditions:

1. Config option allow_resize_to_same_host is False.
2. Instance path is not mounted on shared storage.
3. Three compute nodes: "compute node A", "compute node B" and "compute node C"

Steps:

1. Boot an instance on "compute node A".
2. User tries to resize the newly created instance and nova-scheduler selects 
"compute node B" as a destination node for resize.
   In this case nova creates a instance directory on destination "compute node 
B" and mark the instance directory which is present on the source "compute node 
A" as "*_resize".

Note that the resize operation is yet not confirmed and "compute node B" goes 
down.

3. Reset instance state to ERROR as nova allows evacuation only if instance 
state is 'ACTIVE', 'STOPPED' or 'ERROR'.
4. Evacuate the instance to "compute node C" using target_host option.
   As a result, instance files which were on "compute node B" will be cleaned 
up after compute service on it is up again, but instance files which were on 
"compute node A" marked as "*_resize" will never be cleaned up. As of now there 
is no periodic task in nova to perform cleanup of these kinds of scenarios.


Questions:
1. is this the only possible way of evacuating the resized instances in real 
world scenario?
2. If yes is there any way to cleanup unused (*_resize) instance files from the 
source compute node other than cleaning up it manually?
3. Should we add support of evacuating of resized instances in nova?

Please let me know your opinions about the same.


Thank you,

Abhishek Kekane



-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: Thursday, June 29, 2017 5:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

Hi Chris,

IMO we cannot perform auto-confirm as confirming or reverting is user's choice, 
whereas reverting is not possible as the node where the instance is resized is 
down.
As suggested by you allowing this in nova require additional work. It is 
possible if we take power-state into consideration for evacuation operation, 
i.e. while evacuation if instance vmstate is resized and power-state is shutoff 
then we can stop that instance after evacuation.

Thank you,

Abhishek Kekane 

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com]
Sent: Wednesday, June 28, 2017 8:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [masakari][nova] Allow evacuation of instances in 
resized state

On 06/28/2017 05:50 AM, Kekane, Abhishek wrote:

> In masakari, we are setting an instance to an error state if the 
> vmstate is resized before evacuating it to a new host.

Arguably the instance should be set to an error state as soon as you notice 
that the compute node is down.

> Once an instance (which was in
> resized state) is evacuated then it becomes active on the new host. 
> The main problem with this implementation from user’s point of view is 
> the instance goes into active state after evacuation, it should be in 
> stopped state if the prior action on the instance before resizing was 
> stop. In masakari, It’s possible to set the vm state to stopped state 
> after evacuation but for a short period the instance will go into the active 
> state which is unacceptable.

That's a valid point, I think.

> *Proposing changes to Nova:*
>
> In the current nova code, if the instance is in stopped state before 
> evacuation, then it remains in the stopped state after evacuation is 
> complete. On the similar lines, we are proposing nova should allow 
> instance to be evacuated in resized state and after evacuation the 
> instance should remain in stopped state if the prior action on the instance 
> is stopped before resizing.

The current nova code looks at the vm_state to decide whether or not it's 
allowable to evacuate, and while "stopped" is a valid state to evacuate from 
"resized" is not.  In your scenario it's both "stopped" *and* "resized" 
simultaneously, but there's no way to represent that in the vmstate so I think 
we'd have to check the power state, which would mean extending the
check_instance_state() routine since it doesn't currently handle the power 
state.

The trickier question is how to handle the "resized" state...after evacuating 
an instance in the "resized" state should you be able to revert the resize?  If 
so, how would that work in the case where the instance was resized on the same 
host originally and that host is no 

Re: [openstack-dev] [ceilometer]Understandig ceilometer

[gordon chung]

On 04/07/17 05:14 AM, Gyorgy Szombathelyi wrote:
> - I understand that there is no collector service now. I know the old 
> pipeline was: compute-agent->notification-agent->collector->storage(gnocchi).
> Now I assumed it should be compute-agent->storage(gnocchi).
> However I found out it is a bit different: 
> compute-agent->notification-agent->storage. Is it the intended behavior or 
> just a configuration error on my side?
>

there is no storage service now. ceilometer is just collection.

compute-agent->notification-agent->gnocchi is correct. there is no way 
to publish directly from polling agents to storage currently (not 
without hacking). i'm personally not against having polling agent push 
to gnocchi directory but it's just not there currently.

> - I found no gnocchi at the publishers, but it is still there at the 
> dispatchers. How is it used as a publisher? Just with some magic 
> transformation, publishers: -gnocchi:// is
> translated into using the direct publisher?
>

we haven't ported over gnocchi to publisher. it's still a dispatcher 
with a publisher alias. there is a work item for this and it's pretty 
simple, we just didn't do it (yet). i would think it will be done in 
Pike since we ideally want to remove all dispatchers in Queen.

cheers,

-- 
gord
__
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] CI Squad Meeting Summary (week 26) - job renaming discussion

[Emilien Macchi]

On Tue, Jul 4, 2017 at 3:49 PM, Sagi Shnaidman  wrote:
> Every job contains topology file too, like "1cont_1comp" for example. And
> generally could be different jobs that run the same featureset024 but with
> different topologies. So I think the topology part is necessary too.

In upstream CI we don't have complex topologies, our major ones are
ovb and multinodes. I don't have strong opinions and would be ok to
add topology in jobname, as long as we try to keep it stupid and
simple to keep debugging friendly.

>
>
> On Tue, Jul 4, 2017 at 8:45 PM, Emilien Macchi  wrote:
>>
>> On Fri, Jun 30, 2017 at 11:06 AM, Jiří Stránský  wrote:
>> > On 30.6.2017 15:04, Attila Darazs wrote:
>> >>
>> >> = Renaming the CI jobs =
>> >>
>> >> When we started the job transition to Quickstart, we introduced the
>> >> concept of featuresets[1] that define a certain combination of features
>> >> for each job.
>> >>
>> >> This seemed to be a sensible solution, as it's not practical to mention
>> >> all the individual features in the job name, and short names can be
>> >> misleading (for example ovb-ha job does so much more than tests HA).
>> >>
>> >> We decided to keep the original names for these jobs to simplify the
>> >> transition, but the plan is to rename them to something that will help
>> >> to reproduce the jobs locally with Quickstart.
>> >>
>> >> The proposed naming scheme will be the same as the one we're now using
>> >> for job type in project-config:
>> >>
>> >> gate-tripleo-ci-centos-7-{node-config}-{featureset-config}
>> >>
>> >> So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job
>> >> would look like
>> >> "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001"
>> >
>> >
>> > I'd prefer to keep the job names somewhat descriptive... If i had to
>> > pick
>> > one or the other, i'd rather stick with the current way, as at least for
>> > me
>> > it's higher priority to see descriptive names in CI results than saving
>> > time
>> > on finding featureset file mapping when needing to reproduce a job
>> > result.
>> > My eyes scan probably more than a hundred of individual CI job results
>> > daily, but i only need to reproduce 0 or 1 job failures locally usually.
>> >
>> > Alternatively, could we rename "featureset001.yaml" into
>> > "featureset-ovb-ha.yaml" and then have i guess something like
>> > "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-ovb-ha" for the job name?
>> > Maybe
>> > "ovb" would be there twice, in case it's needed both in node config and
>> > featureset parts of the job name...
>>
>> I'm in favor of keeping jobnames as simple as possible.
>> To me, we should use something like
>> gate-tripleo-ci-centos-7-ovb-featureset001
>>
>> So we know:
>>
>> - it's a tripleo gate job running on centos7
>> - it's OVB and not multinode
>> - it's deploying featureset001
>>
>> Please don't mention HA or ceph or other features in the name because
>> it would be too rigid in case of featureset would change the coverage.
>>
>> Note: if we go that way, we also might want to rename scenario jobs
>> and use featureset in the job name.
>> Note2: if we rename jobs, we need to keep doing good work on
>> documenting what featureset deploy and make
>>
>> https://github.com/openstack/tripleo-quickstart/blob/master/doc/source/feature-configuration.rst
>> more visible probably.
>>
>> My 2 cents.
>>
>> > Or we could pull the mapping between job name and job type in an
>> > automated
>> > way from project-config.
>> >
>> > (Will be on PTO for a week from now, apologies if i don't respond timely
>> > here.)
>> >
>> >
>> > Have a good day,
>> >
>> > Jirka
>> >
>> >>
>> >> The advantage of this will be that it will be easy to reproduce a gate
>> >> job on a local virthost by typing something like:
>> >>
>> >> ./quickstart.sh --release tripleo-ci/master \
>> >>   --nodes config/nodes/3ctlr_1comp.yml \
>> >>   --config config/general_config/featureset001.yml \
>> >>   
>> >>
>> >> Please let us know if this method sounds like a step forward.
>> >
>> >
>> >
>> > __
>> > 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
>>
>>
>>
>> --
>> 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
>
>
>
>
> --
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 26) - job renaming discussion

[Sagi Shnaidman]

Every job contains topology file too, like "1cont_1comp" for example. And
generally could be different jobs that run the same featureset024 but with
different topologies. So I think the topology part is necessary too.



On Tue, Jul 4, 2017 at 8:45 PM, Emilien Macchi  wrote:

> On Fri, Jun 30, 2017 at 11:06 AM, Jiří Stránský  wrote:
> > On 30.6.2017 15:04, Attila Darazs wrote:
> >>
> >> = Renaming the CI jobs =
> >>
> >> When we started the job transition to Quickstart, we introduced the
> >> concept of featuresets[1] that define a certain combination of features
> >> for each job.
> >>
> >> This seemed to be a sensible solution, as it's not practical to mention
> >> all the individual features in the job name, and short names can be
> >> misleading (for example ovb-ha job does so much more than tests HA).
> >>
> >> We decided to keep the original names for these jobs to simplify the
> >> transition, but the plan is to rename them to something that will help
> >> to reproduce the jobs locally with Quickstart.
> >>
> >> The proposed naming scheme will be the same as the one we're now using
> >> for job type in project-config:
> >>
> >> gate-tripleo-ci-centos-7-{node-config}-{featureset-config}
> >>
> >> So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job
> >> would look like "gate-tripleo-ci-centos-7-ovb-
> 3ctlr_1comp-featureset001"
> >
> >
> > I'd prefer to keep the job names somewhat descriptive... If i had to pick
> > one or the other, i'd rather stick with the current way, as at least for
> me
> > it's higher priority to see descriptive names in CI results than saving
> time
> > on finding featureset file mapping when needing to reproduce a job
> result.
> > My eyes scan probably more than a hundred of individual CI job results
> > daily, but i only need to reproduce 0 or 1 job failures locally usually.
> >
> > Alternatively, could we rename "featureset001.yaml" into
> > "featureset-ovb-ha.yaml" and then have i guess something like
> > "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-ovb-ha" for the job name?
> Maybe
> > "ovb" would be there twice, in case it's needed both in node config and
> > featureset parts of the job name...
>
> I'm in favor of keeping jobnames as simple as possible.
> To me, we should use something like gate-tripleo-ci-centos-7-ovb-
> featureset001
>
> So we know:
>
> - it's a tripleo gate job running on centos7
> - it's OVB and not multinode
> - it's deploying featureset001
>
> Please don't mention HA or ceph or other features in the name because
> it would be too rigid in case of featureset would change the coverage.
>
> Note: if we go that way, we also might want to rename scenario jobs
> and use featureset in the job name.
> Note2: if we rename jobs, we need to keep doing good work on
> documenting what featureset deploy and make
> https://github.com/openstack/tripleo-quickstart/blob/
> master/doc/source/feature-configuration.rst
> more visible probably.
>
> My 2 cents.
>
> > Or we could pull the mapping between job name and job type in an
> automated
> > way from project-config.
> >
> > (Will be on PTO for a week from now, apologies if i don't respond timely
> > here.)
> >
> >
> > Have a good day,
> >
> > Jirka
> >
> >>
> >> The advantage of this will be that it will be easy to reproduce a gate
> >> job on a local virthost by typing something like:
> >>
> >> ./quickstart.sh --release tripleo-ci/master \
> >>   --nodes config/nodes/3ctlr_1comp.yml \
> >>   --config config/general_config/featureset001.yml \
> >>   
> >>
> >> Please let us know if this method sounds like a step forward.
> >
> >
> > 
> __
> > 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
>
>
>
> --
> 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
>



-- 
Best regards
Sagi Shnaidman
__
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] (no subject)

[Andy McCrae]

Hi Lawrence,

On 4 July 2017 at 12:29, Lawrence J. Albinson 
wrote:

> Dear Colleagues,
>
> Before I go problem hunting, has anyone seen openstack-ansible builds
> failing at release 15.1.5 at the following point:
>
> TASK [lxc_container_create : Create localhost config]
> **
>
> with the error 'lxc-attach: command not found'?
>
> The self-same environment is working fine at 15.1.3.
>
> I've turned up nothing with searches. Any help greatly appreciated.
>

I know there were some issues created by changes to LXC and Ansible that
look related to what you're seeing.
Although, I believed those were resolved -
https://review.openstack.org/#/c/475438/
Looking at the patch that merged it seems this will only be in the latest
release (which just got released!)
Try updating to 15.1.6 . and see if that resolves it, if not let us know.

Kind Regards,
Andy
__
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] [ui] Integration testing in tripleo-ci

[Emilien Macchi]

On Fri, Jun 30, 2017 at 10:51 AM, Honza Pokorny  wrote:
> I'd like to write some integration tests for the TripleO UI.  Simple
> configuration checks, workflow tests, websocket tests, etc.
>
> I had a quick look at the tripleo-ci [1] repository, and it wasn't
> immediately obvious to me how to extend the existing infrastructure to
> add something like this.  It seems to me that the current way is just
> "stick some shell script here and here".  The tripleo.sh script is about
> 1,600 LOC and it look rather intimidating.
>
> I'm looking for help or pointers on how to do this.  Is there a standard
> way of accomplishing this?  Are there any helpers I should be aware of?
> Is there any documentation beyond what is in the git tree?
>
> Any help would be appreciated

I think we have 2 options here (which could also be mixed):

- Using tripleo-validatons and make sure we run it in CI.
- Write a tempest plugin for tripleo-ui (like Horizon has one:
https://github.com/openstack/tempest-horizon) (it could be
openstack/tempest-triploe-ui) for example. We could run the tempest
tests in the CI jobs (we're working on running Tempest on scenario
jobs, see efforts made in
https://trello.com/c/Z8jIillp/252-spec-out-the-work-required-to-run-tempest-on-the-tripleo-gating-jobs).

Please do not implement tests in tripleo-ci or quickstart, I think we
need a way to test it outside CI and include it directly in the
product.

Thanks,

> Thanks!
>
> Honza Pokorny
>
> [1]: https://github.com/openstack-infra/tripleo-ci
>
> __
> 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



-- 
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

Re: [openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback

[Emilien Macchi]

On Wed, Jun 28, 2017 at 3:47 PM, Lance Bragstad  wrote:
>
>
> On 06/28/2017 02:29 PM, Fox, Kevin M wrote:
>> I think everyone would benefit from a read-only role for keystone out of the 
>> box. Can we get this into keystone rather then in the various distro's?
> Yeah - I think that would be an awesome idea. John Garbutt had some good
> work on this earlier in the cycle. Most of it was documented in specs
> [0] [1]. FWIW - this will be another policy change that is going to have
> cross-project effects. It's implementation or impact won't be isolated
> to keystone if we want read-only roles out-of-the-box.

I just wanted to complete what Lance said with the ongoing
cross-project effort: we're close to approve
https://review.openstack.org/#/c/469954/ for Queens cycle, which means
projects would make some efforts on moving default policies into code
and documenting them.
I also think it would be great to solve this issue into projects
themselves and provide the option for operators.

The way it was done in TripleO (manage policy.json files with Puppet)
was temporary I guess, until we can use what will be done by projects.
Any feedback to make it better in the meanwhile is very welcome.

> [0] https://review.openstack.org/#/c/427872/19
> [1] https://review.openstack.org/#/c/428454/
>>
>> Thanks,
>> Kevin
>> 
>> From: Ben Nemec [openst...@nemebean.com]
>> Sent: Wednesday, June 28, 2017 12:06 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback
>>
>> A few weeks later than I had planned, but here's the other half of the
>> field feedback I mentioned in my previous email:
>>
>> * They very emphatically want in-place upgrades to work when moving from
>> non-containerized to containerized.  I think this is already the plan,
>> but I told them I'd make sure development was aware of the desire.
>>
>> * There was also great interest in contributing back some of the custom
>> templates that they've had to write to get advanced features working in
>> the field.  Here again we recommended that they start with an RFE so
>> things could be triaged appropriately.  I'm hoping we can find some
>> developer time to help polish and shepherd these things through the
>> review process.
>>
>> * Policy configuration was discussed, and I pointed them at some recent
>> work we have done around that:
>> https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
>>   I'm not sure it fully addressed their issues, but I suggested they
>> take a closer look and provide feedback on any ways it doesn't meet
>> their needs.
>>
>> The specific use case they were looking at right now was adding a
>> read-only role.  They did provide me with a repo containing their
>> initial work, but unfortunately it's private to Red Hat so I can't share
>> it here.
>>
>> * They wanted to be able to maintain separate role files instead of one
>> monolithic roles_data.yaml.  Apparently they have a pre-deploy script
>> now that essentially concatenates some individual files to get this
>> functionality.  I think this has already been addressed by
>> https://review.openstack.org/#/c/445687
>>
>> * They've also been looking at ways to reorganize the templates in a
>> more intuitive fashion.  At first glance the changes seemed reasonable,
>> but they were still just defining the layout.  I don't know that they've
>> actually tried to use the reorganized templates yet and given the number
>> of relative paths in tht I suspect it may be a bigger headache than they
>> expect, but I thought it was interesting.  There may at least be
>> elements of this work that we can use to make the templates easier to
>> understand for deployers.
>>
>> Thanks.
>>
>> -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
>>
>> __
>> 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
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo] OpenStack manuals project migration - Progress for TripleO

[Emilien Macchi]

On Wed, Jun 28, 2017 at 2:41 AM, Andreas Jaeger  wrote:
> On 2017-06-27 22:54, Emilien Macchi wrote:
>> Full background, context and details can be read here:
>> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
>>
>> TL;DR: there is a massive cross-project effort which aims to migrate
>> documentations out of a central repository and into project trees,
>> managed by project teams instead of OpenStack Manual team (who is
>> running with low number of contributors at this time). (Alex feel free
>> to correct me if I said something wrong).
>>
>> There is a list of things we need to do to achieve this goal, if
>> possible by the end of Pike:
>> https://etherpad.openstack.org/p/doc-migration-tracking
>>
>> Here's a first (basic) iteration:
>> Switch release notes to use openstacktheme:
>> https://review.openstack.org/#/q/topic:doc_migration+owner:%22Emilien+Macchi+%253Cemilien%2540redhat.com%253E%22
>> (for all TripleO projects).
>
> I commented on your first review with a -1 that probably applies to all
> of them.
>
> Please see https://docs.openstack.org/openstackdocstheme/latest/ how to
> setup openstackdocstheme 1.11 properly.
>
> Especially if you want to use the "Report a bug" feature, you need to
> add more variables,
>
> Andreas

Thanks Andreas for the feedback and reviews.

I'll work on the patches.
The next item we need to work on is tripleo-docs structure (see
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change
and ee the comment on line 10 here:
https://etherpad.openstack.org/p/doc-migration-tracking line 9). Any
help on this task is welcome. You can ping me on #openstack-doc or
#tripleo (and also ask asettle if support/review is needed).

Thanks,

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



-- 
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

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 26) - job renaming discussion

[Emilien Macchi]

On Fri, Jun 30, 2017 at 11:06 AM, Jiří Stránský  wrote:
> On 30.6.2017 15:04, Attila Darazs wrote:
>>
>> = Renaming the CI jobs =
>>
>> When we started the job transition to Quickstart, we introduced the
>> concept of featuresets[1] that define a certain combination of features
>> for each job.
>>
>> This seemed to be a sensible solution, as it's not practical to mention
>> all the individual features in the job name, and short names can be
>> misleading (for example ovb-ha job does so much more than tests HA).
>>
>> We decided to keep the original names for these jobs to simplify the
>> transition, but the plan is to rename them to something that will help
>> to reproduce the jobs locally with Quickstart.
>>
>> The proposed naming scheme will be the same as the one we're now using
>> for job type in project-config:
>>
>> gate-tripleo-ci-centos-7-{node-config}-{featureset-config}
>>
>> So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job
>> would look like "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001"
>
>
> I'd prefer to keep the job names somewhat descriptive... If i had to pick
> one or the other, i'd rather stick with the current way, as at least for me
> it's higher priority to see descriptive names in CI results than saving time
> on finding featureset file mapping when needing to reproduce a job result.
> My eyes scan probably more than a hundred of individual CI job results
> daily, but i only need to reproduce 0 or 1 job failures locally usually.
>
> Alternatively, could we rename "featureset001.yaml" into
> "featureset-ovb-ha.yaml" and then have i guess something like
> "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-ovb-ha" for the job name? Maybe
> "ovb" would be there twice, in case it's needed both in node config and
> featureset parts of the job name...

I'm in favor of keeping jobnames as simple as possible.
To me, we should use something like gate-tripleo-ci-centos-7-ovb-featureset001

So we know:

- it's a tripleo gate job running on centos7
- it's OVB and not multinode
- it's deploying featureset001

Please don't mention HA or ceph or other features in the name because
it would be too rigid in case of featureset would change the coverage.

Note: if we go that way, we also might want to rename scenario jobs
and use featureset in the job name.
Note2: if we rename jobs, we need to keep doing good work on
documenting what featureset deploy and make
https://github.com/openstack/tripleo-quickstart/blob/master/doc/source/feature-configuration.rst
more visible probably.

My 2 cents.

> Or we could pull the mapping between job name and job type in an automated
> way from project-config.
>
> (Will be on PTO for a week from now, apologies if i don't respond timely
> here.)
>
>
> Have a good day,
>
> Jirka
>
>>
>> The advantage of this will be that it will be easy to reproduce a gate
>> job on a local virthost by typing something like:
>>
>> ./quickstart.sh --release tripleo-ci/master \
>>   --nodes config/nodes/3ctlr_1comp.yml \
>>   --config config/general_config/featureset001.yml \
>>   
>>
>> Please let us know if this method sounds like a step forward.
>
>
> __
> 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



-- 
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

Re: [openstack-dev] [tripleo] Queens PTG

[Emilien Macchi]

On Wed, Jun 28, 2017 at 9:37 PM, Giulio Fidente  wrote:
> On 06/28/2017 04:35 PM, Emilien Macchi wrote:
>> Hey folks,
>>
>> Let's start to prepare the next PTG in Denver.
>>
>> Here's the schedule draft:
>> https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true=gmail
>> We'll have a room Wednesday, Thursday and Friday. We'll probably
>> finish by end of Friday morning.
>>
>> Etherpad for the PTG:
>> https://etherpad.openstack.org/p/tripleo-ptg-queens
>
> thanks Emilien!
>
> I've added a session into the agenda about the integration of
> ceph-ansible as this brough in a generic functionality in Heat and
> TripleO which allows services to describe workflows to be executed
> during the overcloud deployment steps
>
> I think it'd be nice to review together what the submissions tracked by
> the two blueprints actually do [1] [2] and how!

Really cool. Indeed, a session for this topic would be awesome. Please
make sure we prepare the agenda (maybe prepare a TL;DR on the ML to
summarize what has been done and what remains).
So we prepare the session correctly and can directly start with
pro-active discussions.

Thanks,

> Flavio is using some of this code for Kubernetes integration as well
>
> 1.
> https://blueprints.launchpad.net/heat/+spec/mistral-new-resource-type-workflow-execution
>
> 2. https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ansible
>
> --
> Giulio Fidente
> GPG KEY: 08D733BA



-- 
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] [publiccloud-wg] Reminder meeting PublicCloudWorkingGroup

[Tobias Rydberg]

Hi everyone,

Don't forget todays meeting for the PublicCloudWorkingGroup.
1400 UTC in IRC channel #openstack-meeting-3

Etherpad: https://etherpad.openstack.org/p/publiccloud-wg

Goals: https://etherpad.openstack.org/p/SYDNEY_GOALS_publiccloud-wg

Talk to you this afternoon!

Tobias
tob...@citynetwork.se


smime.p7s
Description: S/MIME Cryptographic 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] [FEMDC] Use Cases

[Paul-Andre Raymond]

All,

I look forward to continue discussions on how to structure use cases during our 
FEMDC call today.

You will find some slides on google doc that describe my thinking.
https://docs.google.com/presentation/d/1sBczuC2Wu1d_misBmPahLPdvyhOI4QuVy129EHunuUM/edit#slide=id.g1f7f1a38ce_2_102


You will see in there that I feel a use case should include:


  1.  A Deployment Scenario (e.g. NFV or Edge or Federation)
  2.  A Service Use Case  (e.g. IOT, or Mobility or AR or …)
  3.  Openstack component distribution use case  (Regions or Cells or other)
  4.  User plane use case (e.g. Failure scenario)
  5.  Control Plane Use case (e.g. node commissioning or decommissioning)

Please let me know your comments.

Paul-Andre


__
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] [Blazar] Sydney CFP and Horizon plugin updates

[Hiroaki Kobayashi]

Hi Blazar folks,

Based on the discussion at the last meeting, I've created an etherpad  
page for Blazar Sydney CFP.

Please check and write your ideas here!

https://etherpad.openstack.org/p/blazar-cfp-sydney

And please also review the Blazar dashboard which I've pushed today:

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

Best regards,
Hiroaki


__
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] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Irena Berezovsky]

+1

On Wed, Jul 5, 2017 at 4:23 AM, Vikas Choudhary 
wrote:

> +1
>
> On Tue, Jul 4, 2017 at 7:59 PM, Antoni Segura Puimedon  > wrote:
>
>> On Tue, Jul 4, 2017 at 12:23 PM, Gal Sagie  wrote:
>> > +1
>> +1
>> >
>> > On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado <
>> daniel.mellado...@ieee.org>
>> > wrote:
>> >>
>> >> Hi Team,
>> >>
>> >> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been
>> a
>> >> great help from start both contributing and reviewing.
>> >>
>> >> Please voice your support or concerns if any
>> >>
>> >> Best!
>> >>
>> >> Daniel
>> >>
>> >> 
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards ,
>> >
>> > The G.
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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:unsubscrib
>> e
>> 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] [nova] The definition of 'Optional' parameter in API reference

[Takashi Natsume]

On 2017/07/04 21:12, Alex Xu wrote:

2017-07-04 15:40 GMT+08:00 Ghanshyam Mann :


On Mon, Jul 3, 2017 at 1:38 PM, Takashi Natsume
 wrote:

In Nova API reference, there is inconsistency in
whether to define parameters added in new microversion as 'optional' or

not.

Those should be defined based on how they are defined in respective
microversion. If they are 'optional' in that microversion they should
be mentioned as 'optional' and vice versa. Any parameter added in
microversion is mentioned as 'New in version 2.xy' which shows the non
availability of that parameter in earlier versions. Same case for
removal of parameter also.

But if any microversion change parameter from option param to required
or vice versa then it is tricky but IMO documenting the latest
behavior is right thing but with clear notes.
For example, microversion 2.37,   where 'network' in request made as
required from optional. In this cases, api-ref have the latest
behavior of that param which is 'required' and a clear notes about
till when it was optional and from when it is mandatory.

In all cases, doc should reflect the latest behavior of param with
notes(manual or auto generated with min_version & max_version)



++


Thank you for your replies and the fix in 
https://review.openstack.org/#/c/480162/ .



In the case that the parameter is always included in the response after a
certain microversion,
some parameters(e.g. 'type' [1]) are defined as 'required', but some
parameters (e.g. 'project_id', 'user_id'[2])
are defined as 'optional'.

[1] List Keypairs in Keypairs (keypairs)
https://developer.openstack.org/api-ref/compute/?expanded=

list-keypairs-detail#list-keypairs



'keypairs_links' in the response should be the required parameter. Because
it always show up after 2.35.


The 'keypairs_links' is an optional parameter.
When the 'get_links' method of the view builder for keypairs operations
returns an empty list, the 'keypairs_links' does not appear
in the response.

https://github.com/openstack/nova/blob/32e613b9cd499847b7a7dc49d43020523b96c1d1/nova/api/openstack/compute/keypairs.py#L286-L288

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.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] [horizon] [horizon-plugin] Raising Django version cap

[Adrian Turjak]

Great work!

Is there anything that can be done to help meet that July deadline and
get 1.11.x in? I'm more than happy to help with reviews or even fixes
for newer Django in Horizon, and we should try and get others involved
if it will help as I think this is a little urgent.

Running anything less than Django 1.11 leaves us in a weird spot because
of the point where support ends for any versions below it.

Looking at the release timelines, if we don't get 1.11 in for Pike,
we'll have released a version of Horizon that will be for an unsupported
version of Django in about 6 months time (8 if deployers stick with
django 1.8):
https://releases.openstack.org/pike/schedule.html
https://www.djangoproject.com/download/

It isn't as bad it could be, but it's an awkward situation to be in. 1.9
is no longer supported, 1.10 support stops at 2018, so realistically 1.8
is the only version to have Pike 'safe' until Queens thats not
particularly great either. Getting 1.11 support in would be ideal.


On 05/07/17 03:01, Rob Cresswell wrote:
> Hi everyone,
>
> I've put up a patch to global-requirements to raise the Django cap to
> "<1.11", with the upper-constraint at "1.10.7"
> (https://review.openstack.org/#/c/480215). Depending on the remaining
> time, I'd quite like to move us to "1.11.x" before Requirements
> Freeze, which will fall around the 27th of July.
>
> Rob
>
>
> __
> 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] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Vikas Choudhary]

+1

On Tue, Jul 4, 2017 at 7:59 PM, Antoni Segura Puimedon 
wrote:

> On Tue, Jul 4, 2017 at 12:23 PM, Gal Sagie  wrote:
> > +1
> +1
> >
> > On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado <
> daniel.mellado...@ieee.org>
> > wrote:
> >>
> >> Hi Team,
> >>
> >> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been a
> >> great help from start both contributing and reviewing.
> >>
> >> Please voice your support or concerns if any
> >>
> >> Best!
> >>
> >> Daniel
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Best Regards ,
> >
> > The G.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> 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