Re: [openstack-dev] [Networking-OVN] Unable to run OVN functional tests

[Trinath Somanchi]

I’m not running functional tests as root.

Also, from [1] , The following errors fails most for the cases.

Captured pythonlogging:
~~~
   ERROR [neutron.agent.linux.utils] Exit code: 1; Stdin: ; Stdout: ; 
Stderr: 2017-08-19T19:16:26Z|1|unixctl|WARN|failed to connect to 
/tmp/tmpNpVzUM/tmpxaCA5
ovs-appctl: cannot connect to "/tmp/tmpNpVzUM/tmpxaCA5m/ovnnb_db.ctl" (No 
such file or directory)

   ERROR [neutron.agent.linux.utils] Exit code: 1; Stdin: ; Stdout: ; 
Stderr: 2017-08-19T19:16:26Z|1|unixctl|WARN|failed to connect to 
/tmp/tmpNpVzUM/tmpxaCA5
ovs-appctl: cannot connect to "/tmp/tmpNpVzUM/tmpxaCA5m/ovnsb_db.ctl" (No 
such file or directory)

why the test case is searching ovnnb_db.ctl at some other location?

[1] http://paste.openstack.org/show/618837/

Best Regards,
Trinath Somanchi | NXP | HSDC, INDIA

From: Numan Siddique [mailto:nusid...@redhat.com]
Sent: Wednesday, August 23, 2017 10:25 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Networking-OVN] Unable to run OVN functional tests



On Wed, Aug 23, 2017 at 12:03 AM, Assaf Muller 
> wrote:


On Sat, Aug 19, 2017 at 3:02 PM, Trinath Somanchi 
> wrote:
Hi-

Using [1] I have enabled devstack setup.

Now that when I try dvsm-functional tests, I get all tests failed.

Please find the error log [2]  help me resolve this issue.

Looking into the logs, I am pretty sure there is some problem in finding  
'ovsdb-server' binary in the path.
May be you need to verify if you have installed the ovs properly in your 
system. I would suggest you clone ovs repository, compile it and run "sudo make 
install".

Since you have mentioned that you have deployed devstack, devstack ovn script 
should have compiled ovs and installed.
What I suggest you to do is verify again if you have installed ovs properly. 
Run "which ovsdb-server" and see if it returns "/usr/local/sbin/ovsdb-server".

If you see the code here - 
https://github.com/openstack/networking-ovn/blob/master/networking_ovn/tests/functional/resources/process.py#L91,
 it uses spawn.find_executable('ovsdb-server'). May be you can run 
"spawn.find_executable('ovsdb-server') this out in a python shell.

I hope you are not running functional tests as "sudo". When you run as sudo it 
may be possible that /usr/local/bin or /usr/local/sbin might not be in the PATH 
environment.

Thanks
Numan


Also, were there any tempests tests possible for OVN?

The networking-ovn repo doesn't add new Tempest tests, but the Tempest 
networking tests, as well as the Tempest tests in the Neutron tree can be run 
against a cloud using OVN.


[1] https://docs.openstack.org/networking-ovn/latest/contributor/testing.html
[2] http://paste.openstack.org/show/618837/


Best Regards,
/ Trinath Somanchi.

Trinath Somanchi.
Hyderabad Software Development Center (HSDC), GSD , DN,
NXP India Pvt Limited, 1st Floor, Block 3, DLF Cyber City, Gachibowli,
Hyderabad, Telangana, 500032, India

Email: trinath.soman...@nxp.com  | Mobile: +91 
9866235130 | Off: +91 
4033504051
[cid:image002.png@01D28854.B7934C80]





__
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] [Networking-OVN] Unable to run OVN functional tests

[Numan Siddique]

On Wed, Aug 23, 2017 at 12:03 AM, Assaf Muller  wrote:

>
>
> On Sat, Aug 19, 2017 at 3:02 PM, Trinath Somanchi <
> trinath.soman...@nxp.com> wrote:
>
>> Hi-
>>
>>
>>
>> Using [1] I have enabled devstack setup.
>>
>>
>>
>> Now that when I try dvsm-functional tests, I get all tests failed.
>>
>>
>>
>> Please find the error log [2]  help me resolve this issue.
>>
>
Looking into the logs, I am pretty sure there is some problem in finding
 'ovsdb-server' binary in the path.
May be you need to verify if you have installed the ovs properly in your
system. I would suggest you clone ovs repository, compile it and run "sudo
make install".

Since you have mentioned that you have deployed devstack, devstack ovn
script should have compiled ovs and installed.
What I suggest you to do is verify again if you have installed ovs
properly. Run "which ovsdb-server" and see if it returns
"/usr/local/sbin/ovsdb-server".

If you see the code here -
https://github.com/openstack/networking-ovn/blob/master/networking_ovn/tests/functional/resources/process.py#L91,
it uses spawn.find_executable('ovsdb-server'). May be you can run
"spawn.find_executable('ovsdb-server') this out in a python shell.

I hope you are not running functional tests as "sudo". When you run as sudo
it may be possible that /usr/local/bin or /usr/local/sbin might not be in
the PATH environment.

Thanks
Numan


>>
>> Also, were there any tempests tests possible for OVN?
>>
>
> The networking-ovn repo doesn't add new Tempest tests, but the Tempest
> networking tests, as well as the Tempest tests in the Neutron tree can be
> run against a cloud using OVN.
>
>
>>
>>
>> [1] https://docs.openstack.org/networking-ovn/latest/contributor
>> /testing.html
>>
>> [2] http://paste.openstack.org/show/618837/
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> */ Trinath Somanchi.*
>>
>> [image: cid:image001.png@01D28854.B7934C80]
>>
>> *Trinath Somanchi.*
>>
>> Hyderabad Software Development Center (HSDC), GSD , DN,
>>
>> NXP India Pvt Limited, 1st Floor, Block 3, DLF Cyber City, Gachibowli,
>>
>> Hyderabad, Telangana, 500032, India
>>
>>
>>
>> Email: *trinath.soman...@nxp.com *  | Mobile: +91
>> 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
>> <+91%2040%203350%204051>
>>
>> [image: cid:image002.png@01D28854.B7934C80]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> __
>> 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

[openstack-dev] [wiki] How to delete an unused page in OpenStack wiki?

[Chen Ying]

hi,

Does anyone know how to delete an unused page in OpenStack wiki?
This page[1] is needless. But I can not find an option to delete it.



   [1]   https://wiki.openstack.org/wiki/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

[openstack-dev] [glance] priorities for Wednesday, August 23

[Brian Rosmaita]

Hello Glancers,

Two new bugs.

1) https://launchpad.net/bugs/1712462  is release-critical; I have a patch
up for it:
https://review.openstack.org/#/c/496477/  .  Erno and anyone else
knowledgeable about taskflow please look it over.

2) https://bugs.launchpad.net/glance/+bug/1712463 is confirmed, but I'm not
sure whether it's a simple configuration fix or something more sinister.
Matt and anyone else knowledgeable about the running-glance-as-a-wsgi-app
work please take a look.

Please keep an eye on the etherpad in case anything else pops up:
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] [nova] Proposing Balazs Gibizer for nova-core

[Alex Xu]

Yay!

2017-08-23 9:18 GMT+08:00 Matt Riedemann :

> I'm proposing that we add gibi to the nova core team. He's been around for
> awhile now and has shown persistence and leadership in the multi-release
> versioned notifications effort, which also included helping new
> contributors to Nova get involved which helps grow our contributor base.
>
> Beyond that though, gibi has a good understanding of several areas of
> Nova, gives thoughtful reviews and feedback, which includes -1s on changes
> to get them in shape before a core reviewer gets to them, something I
> really value and look for in people doing reviews who aren't yet on the
> core team. He's also really helpful with not only reporting and triaging
> bugs, but writing tests to recreate bugs so we know when they are fixed,
> and also works on fixing them - something I expect from a core maintainer
> of the project.
>
> So to the existing core team members, please respond with a yay/nay and
> after about a week or so we should have a decision (knowing a few cores are
> on vacation right now).
>
> --
>
> 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] [nova] Proposing Balazs Gibizer for nova-core

[Matt Riedemann]

I'm proposing that we add gibi to the nova core team. He's been around 
for awhile now and has shown persistence and leadership in the 
multi-release versioned notifications effort, which also included 
helping new contributors to Nova get involved which helps grow our 
contributor base.


Beyond that though, gibi has a good understanding of several areas of 
Nova, gives thoughtful reviews and feedback, which includes -1s on 
changes to get them in shape before a core reviewer gets to them, 
something I really value and look for in people doing reviews who aren't 
yet on the core team. He's also really helpful with not only reporting 
and triaging bugs, but writing tests to recreate bugs so we know when 
they are fixed, and also works on fixing them - something I expect from 
a core maintainer of the project.


So to the existing core team members, please respond with a yay/nay and 
after about a week or so we should have a decision (knowing a few cores 
are on vacation right now).


--

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-dev] [keystone] office hours report 2017-08-22

[Lance Bragstad]

Today we realized we're going to need to cut a new release candidate due
to some confusion around release notes. Particularly the ones for Pike.
We spent the majority of office hours fixing and reviewing those
patches. Full logs from office hours can be found here [0]. Thanks for
all the quick responses in review today, it really helped get things
squared away for the next release candidate!


[0]
http://eavesdrop.openstack.org/meetings/keystone_office_hours/2017/keystone_office_hours.2017-08-22-19.02.log.html



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

Re: [openstack-dev] [tripleo] mismatch of user/group id between ovs (baremetal) and libvirt (container)

[Oliver Walsh]

Hi,

>   sed -i 's/Group=qemu/Group=42427/'
> /usr/lib/systemd/system/ovs-vswitchd.service

Can't this be overridden via /etc/systemd/system/ovs-vswitchd.service?

> This change basically runs ovs with group id of kolla's qemu user
> (42427). For the solution, my opinion is that we don't require host's
> qemu (107) user in a containerized deployment. I am planning to ensure
> that kolla's user id (42427) is updated to the host via the host prep
> tasks. Let me know if there is any other aspects to be considered.
>

Might be worth considering overriding the qemu uid/gid to 107 in the
kolla config file instead.

Regards,
Ollie

__
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-ansible] group/host specific config file overrides: how-to?

[Jean-Philippe Evrard]

Hello,

The variables documented in each of the roles defaults/ are generally what
you can consider a user level interface (i.e.: what you can modify), while
the variables from vars/ are generally what's best to avoid overriding.

We've been slowly phasing out variables insides templates, to exclusively
rely on config_template overrides (See also: [1] and [2])
Please note that if a variable is deprecated, we are issuing a release note.

[1]: https://github.com/openstack/openstack-ansible-os_nova/blob/
4b9100a612ba0e9449d792b2783b9ec50a8fb28e/tasks/nova_post_install.yml#L40
[2]: https://docs.openstack.org/project-deploy-guide/
openstack-ansible/ocata/app-advanced-config-override.html

Best regards,
JP


On Tue, Aug 22, 2017 at 1:24 PM, Markus Zoeller  wrote:

> On 22.08.2017 09:46, Flávio Ramalho wrote:
> > Hi Markus,
> >
> > I think you can achieve what you want by simple overriding the host
> > variables, for example:
> >
> > In /etc/openstack_deploy/openstack_user_config.yml:
> > compute_hosts:
> >compute1:
> >  ip: 192.168.100.12
> >  host_vars:
> >nova_reserved_host_memory_mb: 256
> >compute2:
> >  ip: 192.168.100.10
> >
> > In this case you would have compute1 with reserved_host_memory_mb = 256
> and
> > compute2 with the default value set for nova_reserved_host_memory_mb.
> >
> >
> > Flávio
>
> Oh, I didn't see those variables, good hint! I'll give it a try, maybe
> that's good enough for me. Thanks a lot Flavio!
>
> http://git.openstack.org/cgit/openstack/openstack-ansible-os
> _nova/tree/templates/nova.conf.j2
>
> Despite that this will probably work, is that an "interface" I'm allowed
> to touch or is it considered an "internal/private" part of
> OpenStack-Ansible (and/or its roles)?
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> > On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller <
> mzoel...@linux.vnet.ibm.com>
> > wrote:
> >
> >> On 21.08.2017 16:40, Andy McCrae wrote:
> >>> Hey Markus,
> >>>
> >>>
>  I'm wondering which possibilities I have to do group/host specific
>  config file overrides. After reading [1], I'm still a little clueless.
>  To be specific, I have this setup (expressed as Ansible inventory
> file):
> 
>  [z_compute_nodes]
>  compute1
>  # more nodes
>  [x_compute_nodes]
>  compute2
>  # more nodes
>  [computes:children]
>  z_compute_nodes
>  x_compute_nodes
> 
>  As an example, I want to set Nova's config option
>  `reserved_host_memory_mb` of the `DEFAULT` config file section:
> 
>  ### nova.conf
>  [DEFAULT]
>  reserved_host_memory_mb=$VALUE
> 
>  My goal is this:
> 
>   | reserved_host_memory_mb
>  --
>  compute1 | 256
>  compute2 | 512
> 
>  I know there are overrides like `nova_nova_conf_overrides`.
>  So I tried to set a default override in `user_variables.yml`:
> 
>  ### /etc/openstack_deploy/user_variables.yml 
> 
>  nova_nova_conf_overrides:
>    DEFAULT:
>  reserved_host_memory_mb: 512
> 
>  But I wanted to override this depending on the host in
>  `openstack_user_config.yml`:
> 
>  ### /etc/openstack_deploy/openstack_user_config.yml 
>  # [...]
>  # nova hypervisors
>  compute_hosts:
>    compute1:
>  ip: 192.168.100.12
>  host_vars:
>    nova_nova_conf_overrides:
>  DEFAULT:
>    reserved_host_memory_mb: 256
>    compute2:
>  ip: 192.168.100.10
> 
> >>>
> >>> Try change "host_vars" to "container_vars".
> >>> If that doesn't work let me know, I'll spin up a test to recreate the
> >>> actual problem, but at a glance that looks correct otherwise.
> >>>
> >>
> >>
> >> Replacing `host_vars` with `container_vars` didn't have an effect:
> >>
> >> ### controller1: /etc/openstack_deploy/openstack_user_config.yml
> >> # nova hypervisors
> >> compute_hosts:
> >>   compute1:
> >> ip: 192.168.100.12
> >> container_vars:
> >>   nova_nova_conf_overrides:
> >> DEFAULT:
> >> reserved_host_memory_mb: 256
> >>   compute2:
> >> ip: 192.168.100.10
> >>
> >> Both compute nodes still have the same $VALUE, although `compute1`
> >> should have 256:
> >>
> >> ### compute1: /etc/nova/nova.conf
> >> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> >> reserved_host_memory_mb = 512
> >>
> >>
> >> ### compute2: /etc/nova/nova.conf
> >> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> >> reserved_host_memory_mb = 512
> >>
> >> I'd like to avoid to introduce some "clever" dict merging algorithm I
> >> won't understand anymore after a few weeks. :/
> >>

Re: [openstack-dev] [ironic] [nova] [tripleo] heads up: custom resource classes, bare metal scheduling and you

[Matt Riedemann]

On 8/22/2017 12:36 PM, Dmitry Tantsur wrote:
All operators running ironic will have to set the resource class field 
before upgrading to Pike and change their flavors before upgrading to 
Queens. See our upgrade notes [6] for details.


It might be worth mentioning that the ironic virt driver in nova is 
going to be automatically migrating the embedded flavor within existing 
instances in Pike as long as the associated node has a resource_class set:


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

Also worth mentioning that a periodic task in the nova-compute service 
will automatically create any custom resource class from an ironic node 
in the Placement service if it does not already exist so it can be used 
later for scheduling with flavors that have the resource class set.


--

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-dev] [api] microversion-parse growing, needs guidance

[Chris Dent]

In https://review.openstack.org/#/c/496212 I've started the process
of moving some of the generally useful microversion-related
functions out of the placement service and into the microversion-parse
library. This will help make the library more useful (see the
README.rst in the review for examples).

I have, however, thus far left out some of the serious microversion meat
that is still in use in placement:

* decorator for handling mulitple callables of the same name based
  on microversion
* utility method to raise a status code response based microversion
  match (things like: respond with a 404 if the microversion is less
  than (1, 1))
* middleware that extracts the microversion from headers (using
  microversion-parse), sticks it in the environment, and sends
  microversion headers on every response

The reason these are not included is because all of them use webob,
primarily in two different ways:

* raising webob exceptions within a webob.dec.wsgify context,
  causing well formed error responses
* using a json formatter to structure error responses according to
  api guidelines

I'm hesitant to add these because they would introduce a dependency
on webob and enforce some behaviors in the projects that use them.
The options seem to be:

* Don't worry, nobody but nova and placement is using
  microversion-parse and nobody else has plans to do so.
* Don't worry about it, everyone loves webob, include it.
* I _think_ I can keep the use of webob contained in a way that makes
  sure it doesn't impact the rest of the WSGI stack (less sure
  about the error formatter).
* With some more effort I could do raw WSGI handling, leaving out
  the use of webob stuff.

I'm kind of inclined towards the last option, but I'm not sure it is
worth it if there aren't any interested parties.

To be clear, if I move the missing parts mentioned above into
microversion-parse, what it could then become is a generic
microversion handling library, including WSGI middleware, satisfying
most common microversion needs. If I don't move them, it's still
useful, but projects would still need to write their own middleware.
Given the diversity of stacks we have in use, that might be how it
would have to work anyway.

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

[openstack-dev] [tc] [all] TC Report 34

[Chris Dent]

Once again, a slow week in the world of TC-related activity. Plenty
of people are on holiday or still engaged with release-related
activity.

So really the only thing to talk about is that everyone who will be
attending the [PTG](https://www.openstack.org/ptg) or who has concerns
they wish to see addressed there should be aware of the [canonical
list of PTG
etherpads](https://wiki.openstack.org/wiki/PTG/Queens/Etherpads).
Those are used by the various projects, working groups, SIGs, and
committees to build agendas and prepare. If you have concerns, add
them. The TC will be sharing a room on Monday and Tuesday with the
Stewardship Working Group. There may be topics of interest on [that
etherpad](https://etherpad.openstack.org/p/queens-PTG-TC-SWG).

There's also a handy set of [PTG quick
links](http://ptg.openstack.org/).

--
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] [Networking-OVN] Unable to run OVN functional tests

[Assaf Muller]

On Sat, Aug 19, 2017 at 3:02 PM, Trinath Somanchi 
wrote:

> Hi-
>
>
>
> Using [1] I have enabled devstack setup.
>
>
>
> Now that when I try dvsm-functional tests, I get all tests failed.
>
>
>
> Please find the error log [2]  help me resolve this issue.
>
>
>
> Also, were there any tempests tests possible for OVN?
>

The networking-ovn repo doesn't add new Tempest tests, but the Tempest
networking tests, as well as the Tempest tests in the Neutron tree can be
run against a cloud using OVN.


>
>
> [1] https://docs.openstack.org/networking-ovn/latest/
> contributor/testing.html
>
> [2] http://paste.openstack.org/show/618837/
>
>
>
>
>
> Best Regards,
>
> */ Trinath Somanchi.*
>
> [image: cid:image001.png@01D28854.B7934C80]
>
> *Trinath Somanchi.*
>
> Hyderabad Software Development Center (HSDC), GSD , DN,
>
> NXP India Pvt Limited, 1st Floor, Block 3, DLF Cyber City, Gachibowli,
>
> Hyderabad, Telangana, 500032, India
>
>
>
> Email: *trinath.soman...@nxp.com *  | Mobile: +91
> 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image002.png@01D28854.B7934C80]
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] How to report tripleo-quickstart results to DLRN API

[David Moreau Simard]

> Idea #3: Use "post-build scripts" in the promotion jobs. We can pattern match 
> for failed/passed jobs and report the result accordingly. The problem with 
> this is that it's environment dependent. While we can certainly do this with 
> post-build scripts in Jenkins Job Builder on CentOS CI, it's not clear how to 
> solve this in Zuul queues. Probably we just need to make the shell scripts of 
> the jobs more involved (not fail on quickstart.sh's nonzero exit). Besides 
> these complications, it also means that we have to keep the reporting method 
> in sync across multiple environments.

So what you are talking about is basically the "postbuildscript" [1]
publisher from Jenkins.
It's how we are currently reporting both successes and failures with
WeIRDO out of ci.centos.org jobs right now [2][3].

Interestingly enough, it so happens that I've asked #openstack-infra
about "postbuildscript" recently, but for other purposes [4].
You're correct in saying that there's no such thing in the current
Zuul implementation, however, it will be easy to accomplish in Zuul v3
which is planned to be deployed right before the PTG in less than a
month.

As far as how to do the implementation in TripleO Quickstart, I don't
feel adding "DLRN API reporting" to tripleo-quickstart is a good fit.
It has nothing to do with TripleO or TripleO Quickstart, it's just
tooling that helps RDO keep track of what is working and what isn't.

The logic to report to DLRN API should be deferred to a job or a
separate playbook without "deep" integration with tripleo-quickstart
IMO.

That said, Zuul v3 is still a bit away so if we want to get started
now, let's compromise on not reporting failures for the time being and
revisit this after the PTG.

[1]: 
https://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.postbuildscript
[2]: 
https://github.com/rdo-infra/ci-config/blob/bcd70953fd69a2d375f81c301b6eca8b796becda/jenkins/jobs/weirdo-defaults.yml#L92
[3]: 
https://github.com/rdo-infra/weirdo/blob/master/playbooks/dlrn-api-report.yml
[4]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-08-08.log.html#t2017-08-08T18:58:54

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Tue, Aug 22, 2017 at 11:22 AM, Attila Darazs  wrote:
> Hi folks,
>
> I'm trying to come up with a good design for $subject, and there are several
> different methods with pros and cons. I'd like to get your opinion about
> them.
>
> For a bit of context, DLRN API[1] is a new extension of DLRN, our package
> and repo building solution for RDO. It's designed to be a central point of
> information about jobs that ran on certain hashes in various stages of
> testing and handle "promotions", which are really just symlinks to certain
> hashes.
>
> We want to report back job results on multiple levels (upstream, RDO CI
> phase1 & phase2) and then use the information to promote new hashes at every
> stage.
>
> If we would only be interested in reporting successful runs, the solution is
> fairly simple: add a reporting step to the quickstart-extras.yml[2] playbook
> at the end if a "report" variable is set.
>
> However it would be probably useful in the long term to also report back
> failures (for statistics) and that's where things get complicated.
>
> It would be great if we could report the failed status within the same
> quickstart.sh run instead of having a second run, because this way we don't
> have to touch the shell scripts in multiple places (upstream, phase1,
> phase2), just get the reporting done with config file changes.
>
> This is not simple, because the Ansible play can exit at any failed task. We
> would need to wrap each task in rescue blocks[3] to avoid skipping the
> failure.
>
> Idea #1: Create a "run successful" marker file at the reporting step, and
> report failure in case the file is not found (also making sure the file does
> not exist at the start of the run). This would still require multiple run of
> ansible-playbook, but we could integrate the functionality into
> quickstart.sh by creating a --report option, making it available at every
> environment at the same time.
>
> Idea #2: Don't fail on *any* step, just register variables and check for
> success. An example where we already do this is the overcloud-deploy role.
> We don't fail on errors[4], but write out a file with the result and fail
> later[5]. We would need to do this at almost all shell parts to be
> reasonably certain we won't miss any failure. This requires a lot of
> alterations to playbooks and it seems a bit forced on Ansible without the
> usage of the rescue block, which we can't put in every single task.
>
> Idea #3: Use "post-build scripts" in the promotion jobs. We can pattern
> match for failed/passed jobs and report the result accordingly. The problem
> with this is that it's environment dependent. While we can certainly do this
> with post-build 

[openstack-dev] [ironic] [nova] [tripleo] heads up: custom resource classes, bare metal scheduling and you

[Dmitry Tantsur]

Hi all!

There have been some talks about $subj recently, but I've just realized that not 
everyone is still aware of it. So, this is a heads up about recent changes in 
nova scheduling of bare metal instances. If you only use standalone deployments, 
you can ignore it. If you run a 3rd party CI, please read carefully though.


In the Pike release, that will happen really soon, nova will feature a new way 
of scheduling bare metals. It will be based on custom resource classes [1] 
instead of CPU count, memory and disk size. The old way is thus deprecated [2] 
and will be unavailable in Queens. For those chasing master Queens is *already 
happening*.


The reason behind the change is that properties-based scheduling for bare metals 
does not really match properties-based scheduling for VMs. If I have a VM with 
16 GiB of RAM, I can put there 3-4 instances that require 4 GiB of RAM. If I 
have a BM with 16 GiB of RAM, I can only put one instance there, no matter how 
much RAM it needs. This situation required ugly hacks in the ironic virt driver 
to avoid excessive scheduling retries.


The new approach is to make bare metal nodes expose exactly one unit of some 
custom resource class. Such class is set on the node.resource_class field, and 
is requested by a flavor as described in our docs [3]. The standard properties 
will stop being exposed from ironic nodes to nova in Queens. We have already 
removed some hacks from the ironic virt driver, which may make a deployment 
without resource classes less stable [4].


We have switched [5] the ironic CI to using resource classes by default. This is 
something the 3rd party CI will have to follow for Pike and Queens as soon as 
possible, otherwise they may get broken. Make sure you do *not* set 
IRONIC_USE_RESOURCE_CLASSES to False in your configuration, then our devstack 
plugin will handle setting resource classes and configuring flavors for you.


All operators running ironic will have to set the resource class field before 
upgrading to Pike and change their flavors before upgrading to Queens. See our 
upgrade notes [6] for details.


As an example, I have updated TripleO undercloud to always set the same constant 
resource class [7] on nodes and request it in flavors [8]. This is, of course, 
the simplest way to use custom resource classes. I went down this path, because 
TripleO extensively uses capabilities for precise scheduling anyway. A more 
sophisticated bare metal cloud may use many more custom resource classes.


Please let us know if you have any questions.

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html

[2] https://docs.openstack.org/releasenotes/nova/pike.html#deprecation-notes
[3] 
https://docs.openstack.org/ironic/latest/install/configure-nova-flavors.html#scheduling-based-on-resource-classes

[4] https://docs.openstack.org/releasenotes/nova/pike.html#known-issues
[5] https://review.openstack.org/#/c/494850/
[6] https://docs.openstack.org/releasenotes/ironic/pike.html#id7
[7] https://review.openstack.org/493943
[8] https://review.openstack.org/490851

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

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/horizon/

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/horizon/log/?h=stable/pike

Release notes for horizon can be found at:

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




__
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] Updating the docs team mission statement

[Jay S Bryant]

On 8/22/2017 11:33 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2017-08-22 11:06:37 -0500:

On 8/22/2017 7:30 AM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:

Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:

Petr Kovar wrote:

Hi all,

With the core docs suite moving from openstack-manuals to individual
project repos as per
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
it's also time to update the docs team mission statement from
https://governance.openstack.org/tc/reference/projects/documentation.html.

What are everybody's thoughts on what should the new mission statement
say now that most OpenStack docs maintenance is in the hands of project
teams?

One idea is for the docs team to act as a focused group of editors and
maintain a common set of guidelines, recommended practices (style
guidelines come to mind, for instance), and requirements (such as a common
docs and publishing structure shared across projects).

I would say something like:

The docs team provides guidance, assistance, tooling, and style guides
enabling OpenStack project teams to produce consistent, accurate, and
high-quality documentation.


Thanks for starting this thread, Petr.

To make it easier to compare, here's the current mission statement:

Provide documentation for core OpenStack projects to promote
OpenStack.  Develop and maintain tools and processes to ensure
quality, accurate documentation. Treat documentation like OpenStack
code.

Thierry's suggestion highlights some of the changes I see coming
for the docs team. I would like to hear from some of the other team
members about what they think about that.

Doug

This thread died out, but I think it's important that we make some
progress on the discussion before the PTG because the outcome is
going to influence the work we do there.

One way we could approach it is to make a list of all of the things
that the team is currently doing (or has been doing, up to Pike)
and then review that list to consider which of those things, if the
team was not already doing them, you would be willing to start doing
today.  That should establish a pattern for the types of tasks and
initiatives the team thinks it can manage, and help us focus the
mission statement.

So, what does the docs team "do" or "make" today?

Doug

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

Doug,

I think this is a good idea.  Rather than writing a mission statement
and try to get what we do to fit it, we should look at what everyone is
doing and can do and then work to craft the statement from that.

One important part in the process, however, would be to look at how that
compares to what was previously being done and make sure that there
aren't gaps.  It is an opportunity to make sure we don't let anything
slip through the cracks.

Jay


It's also an opportunity to identify things that should be dropped, or
moved to another team. But yes, let's start by understanding what's
actually happening today.

Doug

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

Doug,

Good point.  There are also things that can be dropped and will have to 
be dropped given the changes in resources.  It will need to be a 
thoughtful look at all the pieces.


It will also be important as we look at what needs to be dropped from 
the core team that it is communicated to the project teams what they are 
expected to pick up.  I have been figuring that out as I have been going 
and can try to help there but I am not sure that all the projects have 
been as active there.


Jay


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

Re: [openstack-dev] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2017-08-22 11:06:37 -0500:
> 
> On 8/22/2017 7:30 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> >> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> >>> Petr Kovar wrote:
>  Hi all,
> 
>  With the core docs suite moving from openstack-manuals to individual
>  project repos as per
>  http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
>  it's also time to update the docs team mission statement from
>  https://governance.openstack.org/tc/reference/projects/documentation.html.
> 
>  What are everybody's thoughts on what should the new mission statement
>  say now that most OpenStack docs maintenance is in the hands of project
>  teams?
> 
>  One idea is for the docs team to act as a focused group of editors and
>  maintain a common set of guidelines, recommended practices (style
>  guidelines come to mind, for instance), and requirements (such as a 
>  common
>  docs and publishing structure shared across projects).
> >>> I would say something like:
> >>>
> >>> The docs team provides guidance, assistance, tooling, and style guides
> >>> enabling OpenStack project teams to produce consistent, accurate, and
> >>> high-quality documentation.
> >>>
> >> Thanks for starting this thread, Petr.
> >>
> >> To make it easier to compare, here's the current mission statement:
> >>
> >>Provide documentation for core OpenStack projects to promote
> >>OpenStack.  Develop and maintain tools and processes to ensure
> >>quality, accurate documentation. Treat documentation like OpenStack
> >>code.
> >>
> >> Thierry's suggestion highlights some of the changes I see coming
> >> for the docs team. I would like to hear from some of the other team
> >> members about what they think about that.
> >>
> >> Doug
> > This thread died out, but I think it's important that we make some
> > progress on the discussion before the PTG because the outcome is
> > going to influence the work we do there.
> >
> > One way we could approach it is to make a list of all of the things
> > that the team is currently doing (or has been doing, up to Pike)
> > and then review that list to consider which of those things, if the
> > team was not already doing them, you would be willing to start doing
> > today.  That should establish a pattern for the types of tasks and
> > initiatives the team thinks it can manage, and help us focus the
> > mission statement.
> >
> > So, what does the docs team "do" or "make" today?
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Doug,
> 
> I think this is a good idea.  Rather than writing a mission statement 
> and try to get what we do to fit it, we should look at what everyone is 
> doing and can do and then work to craft the statement from that.
> 
> One important part in the process, however, would be to look at how that 
> compares to what was previously being done and make sure that there 
> aren't gaps.  It is an opportunity to make sure we don't let anything 
> slip through the cracks.
> 
> Jay
> 

It's also an opportunity to identify things that should be dropped, or
moved to another team. But yes, let's start by understanding what's
actually happening today.

Doug

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

Re: [openstack-dev] [docs] Updating the docs team mission statement

[Jay S Bryant]

On 8/22/2017 7:30 AM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:

Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:

Petr Kovar wrote:

Hi all,

With the core docs suite moving from openstack-manuals to individual
project repos as per
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
it's also time to update the docs team mission statement from
https://governance.openstack.org/tc/reference/projects/documentation.html.

What are everybody's thoughts on what should the new mission statement
say now that most OpenStack docs maintenance is in the hands of project
teams?

One idea is for the docs team to act as a focused group of editors and
maintain a common set of guidelines, recommended practices (style
guidelines come to mind, for instance), and requirements (such as a common
docs and publishing structure shared across projects).

I would say something like:

The docs team provides guidance, assistance, tooling, and style guides
enabling OpenStack project teams to produce consistent, accurate, and
high-quality documentation.


Thanks for starting this thread, Petr.

To make it easier to compare, here's the current mission statement:

   Provide documentation for core OpenStack projects to promote
   OpenStack.  Develop and maintain tools and processes to ensure
   quality, accurate documentation. Treat documentation like OpenStack
   code.

Thierry's suggestion highlights some of the changes I see coming
for the docs team. I would like to hear from some of the other team
members about what they think about that.

Doug

This thread died out, but I think it's important that we make some
progress on the discussion before the PTG because the outcome is
going to influence the work we do there.

One way we could approach it is to make a list of all of the things
that the team is currently doing (or has been doing, up to Pike)
and then review that list to consider which of those things, if the
team was not already doing them, you would be willing to start doing
today.  That should establish a pattern for the types of tasks and
initiatives the team thinks it can manage, and help us focus the
mission statement.

So, what does the docs team "do" or "make" today?

Doug

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

Doug,

I think this is a good idea.  Rather than writing a mission statement 
and try to get what we do to fit it, we should look at what everyone is 
doing and can do and then work to craft the statement from that.


One important part in the process, however, would be to look at how that 
compares to what was previously being done and make sure that there 
aren't gaps.  It is an opportunity to make sure we don't let anything 
slip through the cracks.


Jay


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

Re: [openstack-dev] [ironic] ironic-staging-drivers core cleanup and additions

[Loo, Ruby]

I agree whether I have a vote or not ;)

Thanks Dmitry!

--ruby

From: Dmitry Tantsur 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, August 22, 2017 at 5:24 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: Lucas Alvares Gomes 
Subject: [openstack-dev] [ironic] ironic-staging-drivers core cleanup and 
additions

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 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] [magnum] Weekly meetings

[Spyros Trigazis]

Hello,

Recently we decided to have bi-weekly meetings. Starting from today we will
have weekly meetings again.

From now on, we will have our meeting every Tuesday at 1600 UTC
in #openstack-meeting-alt . For today, that is in 13 minutes.

Cheers,
Spyros

__
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] [Monasca] GridDB repository support

[Akira Yoshiyama]

Hi Witek,

Thank you for your interest.

2017-08-22 21:25 GMT+09:00 witold.be...@est.fujitsu.com
:
> Hi Akira,
>
> thank you for your contribution. We indeed urgently need a scalable open 
> source TSDB.

I see. Kawabata-san from NEC was my co-worker and he told me about the
problem. So, I've been interested in open source TSDBs and found
GridDB at an open source event in Tokyo last fall. But there was no
python binding at the time, so I had waited for it.

> Do you use this database in your Monasca deployment? Have you made write/read 
> performance measurements when used with Monasca? I couldn't find much 
> information about this database apart from the references you have provided.

I have a small Monasca deployment on 2 VMs for development. Actually,
I've started building Monasca and GridDB environment on Aug. 11th and
then made the drivers in 5 days. So, I have no my own benchmark result
yet.

> In the recent weeks James Gu and his team have re-evaluated using Cassandra 
> as Monasca backend [1]. They have measured write throughput of 64 kmetrics/s 
> when storing 200 mil unique metric definitions and 50 bil measurements on the 
> two nodes cluster. It's way below what InfluxDB can on the single node, but 
> that's a number we can live with, I guess. Can GridDB perform better?

Some papers[1] (in english) are available and one of them is about
performance[2]. See page 24-25 of it, and you will find below:
---
   Throughput with Large Data Set (12M Records Per Node)
   Load / 1 node:
GridDB13,082 (ops/sec)
Cassandra 4,325 (ops/sec)

Latency with Large Data Set (12M Records Per Node) -- 1 Node
Load / Insert
GridDB  9.7 (ms)
Cassandra 7.0 (ms)
---

[1]https://griddb.net/en/downloads/
[2]https://griddb.net/en/docs/Fixstars_NoSQL_Benchmarks.pdf

> What do the others think? Should we experiment and add support for different 
> backend drivers or rather choose one or two and concentrate on these?
>
>
> Best greetings
> Witek

There are some other TSDBs like Gnocchi and Prometheus. I'll consider
making other drivers if GridDB isn't so good for Monasca.

Best,
Akira

> [1] https://etherpad.openstack.org/p/cassandra_monasca
>
>
>
>> -Original Message-
>> From: Akira Yoshiyama [mailto:akirayoshiy...@gmail.com]
>> Sent: Samstag, 19. August 2017 15:31
>> To: OpenStack Development Mailing List > d...@lists.openstack.org>
>> Subject: [openstack-dev] [Monasca] GridDB repository support
>>
>> Hi all,
>>
>> Toshiba GridDB[1][2] is a highly scalable distributed NoSQL database for IoT
>> and Big Data. It has very good scalability and performance[3].
>> It also has Community Edition licensed under GNU AGPL v3 and the source
>> code is available at Github[4][5][6].
>>
>> It looks suitable for Monasca repository, so I'm writing GridDB repository
>> drivers for monasca-api/-persister[7][8]. They work well but need unit tests.
>> Anyone interested?
>>
>> Thank you,
>> Akira Yoshiyama
>>
>> [1]http://solutions.toshiba.com/overview.html
>> [2]https://griddb.net/en/docs/documents/1-1_what-is-griddb.php
>> [3]https://griddb.net/ja/blog/griddb-and-cassandra-ycsb-benchmarks/
>> [4]https://github.com/griddb/griddb_nosql
>> [5]https://github.com/griddb/c_client
>> [6]https://github.com/griddb/griddb_client
>> [7]https://review.openstack.org/#/c/495504/
>> [8]https://review.openstack.org/#/c/495505/
>>
>> __
>> 
>> 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] [tripleo] How to report tripleo-quickstart results to DLRN API

[Attila Darazs]

Hi folks,

I'm trying to come up with a good design for $subject, and there are 
several different methods with pros and cons. I'd like to get your 
opinion about them.


For a bit of context, DLRN API[1] is a new extension of DLRN, our 
package and repo building solution for RDO. It's designed to be a 
central point of information about jobs that ran on certain hashes in 
various stages of testing and handle "promotions", which are really just 
symlinks to certain hashes.


We want to report back job results on multiple levels (upstream, RDO CI 
phase1 & phase2) and then use the information to promote new hashes at 
every stage.


If we would only be interested in reporting successful runs, the 
solution is fairly simple: add a reporting step to the 
quickstart-extras.yml[2] playbook at the end if a "report" variable is set.


However it would be probably useful in the long term to also report back 
failures (for statistics) and that's where things get complicated.


It would be great if we could report the failed status within the same 
quickstart.sh run instead of having a second run, because this way we 
don't have to touch the shell scripts in multiple places (upstream, 
phase1, phase2), just get the reporting done with config file changes.


This is not simple, because the Ansible play can exit at any failed 
task. We would need to wrap each task in rescue blocks[3] to avoid 
skipping the failure.


Idea #1: Create a "run successful" marker file at the reporting step, 
and report failure in case the file is not found (also making sure the 
file does not exist at the start of the run). This would still require 
multiple run of ansible-playbook, but we could integrate the 
functionality into quickstart.sh by creating a --report option, making 
it available at every environment at the same time.


Idea #2: Don't fail on *any* step, just register variables and check for 
success. An example where we already do this is the overcloud-deploy 
role. We don't fail on errors[4], but write out a file with the result 
and fail later[5]. We would need to do this at almost all shell parts to 
be reasonably certain we won't miss any failure. This requires a lot of 
alterations to playbooks and it seems a bit forced on Ansible without 
the usage of the rescue block, which we can't put in every single task.


Idea #3: Use "post-build scripts" in the promotion jobs. We can pattern 
match for failed/passed jobs and report the result accordingly. The 
problem with this is that it's environment dependent. While we can 
certainly do this with post-build scripts in Jenkins Job Builder on 
CentOS CI, it's not clear how to solve this in Zuul queues. Probably we 
just need to make the shell scripts of the jobs more involved (not fail 
on quickstart.sh's nonzero exit). Besides these complications, it also 
means that we have to keep the reporting method in sync across multiple 
environments.


Neither of these solutions are ideal, let me know if you have any better 
design idea. I personally think #1 might be the easiest and cleanest to 
implement, especially that I'm planning to introduce multiple 
ansible-playbook runs in quickstart.sh during the redesign of the devmode.


Best regards,
Attila

[1] https://github.com/javierpena/dlrnapi_client
[2] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/playbooks/quickstart-extras.yml
[3] 
http://docs.ansible.com/ansible/latest/playbooks_blocks.html#error-handling
[4] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-deploy/tasks/deploy-overcloud.yml#L6
[5] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/playbooks/quickstart-extras-overcloud.yml#L32-L44


__
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] docs: architecture or hw_architecture

[Markus Zoeller]

I'm wondering if there is an issue in the docs which describe the
possible image metadata properties:
https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#

This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
but the Nova scheduler image properties filter uses `hw_architecture`
(note the *hw_* prefix):
https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44

Is that simply a mistake in the Glance docs or do I miss some kind of
conversion between those metadata keys?

-- 
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] [tripleo][octavia] deploy overcloud with octavia container does not work after commit 0cb45d65c607cf4eb9a4096c7cc3f1c8a5ca58b4

[Or Idgar]

Hi all,
since commit 0cb45d65c607cf4eb9a4096c7cc3f1c8a5ca58b4 I cannot deploy
overcloud containerized with octavia service.

the command I'm running is:
openstack overcloud deploy --templates
/usr/share/openstack-tripleo-heat-templates/
-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e
/usr/share/openstack-tripleo-heat-templates/environments/docker-network.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/
docker-centos-tripleoupstream.yaml -e /usr/share/openstack-tripleo-
heat-templates/environments/low-memory-usage.yaml  -e
/usr/share/openstack-tripleo-heat-templates/environments/
services-docker/octavia.yaml

I've filed a bug in launchpad [1].
also, pastebin of stack failures list in [2].
gerrit patch in [3].

Please assist.

Thanks in advance!

[1] https://bugs.launchpad.net/tripleo/+bug/1712368
[2] https://paste.fedoraproject.org/paste/gir2bIpBm3lgJJuWnWYk6g
[3] https://review.openstack.org/#/c/481965/7

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

[openstack-dev] [PTG] Video interviews at PTG, now scheduling

[Rich Bowen]

Now that the PTG schedule is up, I'd like to invite you to sign up for
my video interview series. I'll be conducting interviews at the PTG,
with the goal of:

* Telling our users what's new in Pike, and what to expect in Queens
* Put a human face on the upstream developer community
* Show the awesome cooperation and collaboration between projects and
between companies

Sign up at:
https://docs.google.com/spreadsheets/d/1KNHuo9Yb5kbjZAYGQ_PAo-YFndD8QTdaKzaPoct_aaU/edit?usp=sharing

A few tips:

* Talk with your project about who should do the interview, and what you
want to highlight.
* Consider having several people sign up to do an interview (no more
than 3, please)
* Consider doing an interview that is cross-project, to talk about this
collaboration
* If you know of a user/customer who will be at the PTG who has a cool
use-case, encourage them to sign up
* Please read the notes on the "Planning for your interview" tab of the
spreadsheet.

If you'd like to see examples of what I'm going for, I did this on a
much smaller scale in Atlanta, with just Red Hat engineers. Please see:
https://www.youtube.com/watch?v=5kT-Sv3rkTw=PLOuHvpVx7kYksG0NFaCaQsSkrUlj3Oq4S

Thanks!

-- 
Rich Bowen - rbo...@redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity

__
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] [Monasca] GridDB repository support

[Julien Danjou]

On Tue, Aug 22 2017, witold.be...@est.fujitsu.com wrote:

Hi Witek,

> thank you for your contribution. We indeed urgently need a scalable open 
> source TSDB.

Did you look at Gnocchi? It's exactly that.

  http://gnocchi.xyz/

> In the recent weeks James Gu and his team have re-evaluated using Cassandra as
> Monasca backend [1]. They have measured write throughput of 64 kmetrics/s when
> storing 200 mil unique metric definitions and 50 bil measurements on the two
> nodes cluster. It's way below what InfluxDB can on the single node, but that's
> a number we can live with, I guess. Can GridDB perform better?
> 
> What do the others think? Should we experiment and add support for different
> backend drivers or rather choose one or two and concentrate on these?

We don't have any recent comparison with InfluxDB but last time we
tried, Gnocchi was already getting faster than it. And scalable
horizontally, so…

You might want to give it a try.

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

[openstack-dev] [tripleo] mismatch of user/group id between ovs (baremetal) and libvirt (container)

[Saravanan KR]

Hello,

I am working on to integrating DPDK with containerized environment.
Note that DPDK is not yet containerized in tripleo, but this exercise
is to deploy a DPDK workload with the containerized services. I just
want to provide an update regarding an issue.

Currently, OpenvSwitch is running as baremetal service where as
libvirt is containerized. When a VM is created with DPDK network, a
vhost-user socket file will be created by qemu in server mode and ovs
will connect to it as client mode. The socket file will be created on
the host at "/var/lib/vhost_sockets" by the libvrit container, which
is running with qemu user ids as 42427:42427 [1]. Where as
OpenvSwitch, running on baremetal, patched [2] to run with
"Group=qemu", will run with group id as 107.

There is a permission mismatch between the kolla's qemu user id
(42427) and the host machines qemu user id (107), because of which
vhost-use socket creation fails. Till we get ovs containerized,
probably we need to patch ovs to run under kolla's qemu group id
(42427).

With following changes, I am able to get it working.
  chown 42427:42427 /var/lib/vhost_sockets
  sed -i 's/Group=qemu/Group=42427/'
/usr/lib/systemd/system/ovs-vswitchd.service
  systemctl daemon-reload
  systemctl restart openvswitch

This change basically runs ovs with group id of kolla's qemu user
(42427). For the solution, my opinion is that we don't require host's
qemu (107) user in a containerized deployment. I am planning to ensure
that kolla's user id (42427) is updated to the host via the host prep
tasks. Let me know if there is any other aspects to be considered.

Regards,
Saravanan KR

[1] 
https://github.com/openstack/kolla/blob/187b1f08f586327e5c47a0bed3760a575daa1287/kolla/common/config.py#L750
[2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/extraconfig/pre_network/host_config_and_reboot.yaml#L227

__
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][oslo][all] Clean up oslo deprecated stuff !

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-22 20:44:18 +0800:
> 2017-08-22 20:37 GMT+08:00 Doug Hellmann :
> 
> > Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> > > Hi ALL,
> > >
> > > We discussed a little about how to avoid breaking consuming projects'
> > gate
> > > in oslo weekly meeting last week.  The easy improvement is that clean up
> > > deprecated stuff in oslo at the beginning of Queens.  I collected
> > > deprecated stuff  in [1].  This need Oslo team and other team work
> > > toghether. I think we can start the work when cycle Queens is open. I
> > also
> > > reserved a room in PTG
> > > for 2 hours to do hacking.[2]
> > >
> > >
> > > [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> > > [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> > >
> >
> > Cleaning up some of this technical debt is a great idea for Queens!
> >
> > What do you think about using a common gerrit topic to make those
> > reviews easy to find across the repository?
> >
>   yeah, that's helpful to track the reviews,  what about the topic 
> 'oslo-debt-cleanup'?

That works great. I can add the query for that topic to my regular
review routine.

Doug

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

[openstack-dev] [neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

It will be a short update about the code and PTG.

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_22_August_2017

Best regards,
Igor D.C.

__
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][oslo][all] Clean up oslo deprecated stuff !

[ChangBo Guo]

2017-08-22 20:37 GMT+08:00 Doug Hellmann :

> Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> > Hi ALL,
> >
> > We discussed a little about how to avoid breaking consuming projects'
> gate
> > in oslo weekly meeting last week.  The easy improvement is that clean up
> > deprecated stuff in oslo at the beginning of Queens.  I collected
> > deprecated stuff  in [1].  This need Oslo team and other team work
> > toghether. I think we can start the work when cycle Queens is open. I
> also
> > reserved a room in PTG
> > for 2 hours to do hacking.[2]
> >
> >
> > [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> > [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> >
>
> Cleaning up some of this technical debt is a great idea for Queens!
>
> What do you think about using a common gerrit topic to make those
> reviews easy to find across the repository?
>
>   yeah, that's helpful to track the reviews,  what about the topic 
> 'oslo-debt-cleanup'
?

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



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

Re: [openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> Hi ALL,
> 
> We discussed a little about how to avoid breaking consuming projects' gate
> in oslo weekly meeting last week.  The easy improvement is that clean up
> deprecated stuff in oslo at the beginning of Queens.  I collected
> deprecated stuff  in [1].  This need Oslo team and other team work
> toghether. I think we can start the work when cycle Queens is open. I also
> reserved a room in PTG
> for 2 hours to do hacking.[2]
> 
> 
> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> 

Cleaning up some of this technical debt is a great idea for Queens!

What do you think about using a common gerrit topic to make those
reviews easy to find across the repository?

Doug

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

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2017-08-22 11:38:10 +0200:
> On 08/22/2017 11:34 AM, Dmitry Tantsur wrote:
> > On 08/21/2017 09:15 PM, Doug Hellmann wrote:
> >> Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:
> >>> Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:
>  On 08/08/2017 03:30 PM, Doug Hellmann wrote:
> > We realized recently that we haven't publicized some of the tools
> > in the releases repository very well. One tool that will be useful
> > this week as you prepare your release candidates is the 'new-release'
> > command, which edits a deliverable file to add a new release from
> > HEAD of the given branch, automatically computing the next verison
> > number based on the inputs.
> >
> > Use the ``venv`` tox environment to run the tool, like this:
> >
> >  $ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> >
> > The SERIES value should be the release series, such as "pike".
> >
> > The DELIVERABLE value should be the deliverable name, such as
> > "oslo.config" or "cinder".
> >
> > The TYPE value should be one of "bugfix", "feature", "major",
> > "milestone", or "rc".
> >
> > If the most recent release of cinder during the pike series is
> > 11.0.0.0b3 then running:
> >
> >  $ tox -e venv -- new-release pike cinder rc
> 
>  On systems with Python 3 by default this fails on installing 
>  lazr.restfulclient.
>  I think we should add
> 
> basepython = python2
> 
>  for now.
> >>
> >> I wonder if you have an old copy of the releases repo. In master we
> >> explicitly set basepython to python3 and lazr.restfulclient is no longer
> >> a dependency.
> > 
> > Updated to latest HEAD, removed *.pyc files and .tox. Still getting:
> > 
> > Obtaining file:///home/dtantsur/Projects/releases
> > Requirement already up-to-date: pbr>=1.6 in 
> > ./.tox/list-changes/lib/python3.6/site-packages (from 
> > releases==0.0.1.dev3083)
> > Collecting lazr.restfulclient==0.13.1 (from releases==0.0.1.dev3083)
> >Using cached lazr.restfulclient-0.13.1.tar.gz
> >  Complete output from command python setup.py egg_info:
> >  Traceback (most recent call last):
> >File "", line 1, in 
> >File "/tmp/pip-build-hhi229rh/lazr.restfulclient/setup.py", line 19, 
> > in 
> > 
> >  import ez_setup
> >File "/tmp/pip-build-hhi229rh/lazr.restfulclient/ez_setup.py", line 
> > 98
> >  except pkg_resources.VersionConflict, e:
> >  ^
> >  SyntaxError: invalid syntax
> > 
> > I cannot find where this dependency comes from, still investigating.
> 
> And here is what helped: rm -rf *.egg-info/
> 
> I suspect it was coming from stale directory releases.egg-info (currently we 
> have openstack_releases.egg-info instead). I'm not sure why it was picked..

Yes, that's odd, but I'm glad you found the problem.

I see you're running with python 3.6. I've only tested with 3.5 so far,
so I would appreciate bug reports or patches if you find issues.

Doug

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

Re: [openstack-dev] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> > Petr Kovar wrote:
> > > Hi all,
> > > 
> > > With the core docs suite moving from openstack-manuals to individual
> > > project repos as per
> > > http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> > > it's also time to update the docs team mission statement from
> > > https://governance.openstack.org/tc/reference/projects/documentation.html.
> > > 
> > > What are everybody's thoughts on what should the new mission statement
> > > say now that most OpenStack docs maintenance is in the hands of project
> > > teams?
> > > 
> > > One idea is for the docs team to act as a focused group of editors and
> > > maintain a common set of guidelines, recommended practices (style
> > > guidelines come to mind, for instance), and requirements (such as a common
> > > docs and publishing structure shared across projects).
> > 
> > I would say something like:
> > 
> > The docs team provides guidance, assistance, tooling, and style guides
> > enabling OpenStack project teams to produce consistent, accurate, and
> > high-quality documentation.
> > 
> 
> Thanks for starting this thread, Petr.
> 
> To make it easier to compare, here's the current mission statement:
> 
>   Provide documentation for core OpenStack projects to promote
>   OpenStack.  Develop and maintain tools and processes to ensure
>   quality, accurate documentation. Treat documentation like OpenStack
>   code.
> 
> Thierry's suggestion highlights some of the changes I see coming
> for the docs team. I would like to hear from some of the other team
> members about what they think about that.
> 
> Doug

This thread died out, but I think it's important that we make some
progress on the discussion before the PTG because the outcome is
going to influence the work we do there.

One way we could approach it is to make a list of all of the things
that the team is currently doing (or has been doing, up to Pike)
and then review that list to consider which of those things, if the
team was not already doing them, you would be willing to start doing
today.  That should establish a pattern for the types of tasks and
initiatives the team thinks it can manage, and help us focus the
mission statement.

So, what does the docs team "do" or "make" today?

Doug

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

Re: [openstack-dev] [Monasca] GridDB repository support

[witold.be...@est.fujitsu.com]

Hi Akira,

thank you for your contribution. We indeed urgently need a scalable open source 
TSDB.

Do you use this database in your Monasca deployment? Have you made write/read 
performance measurements when used with Monasca? I couldn't find much 
information about this database apart from the references you have provided.

In the recent weeks James Gu and his team have re-evaluated using Cassandra as 
Monasca backend [1]. They have measured write throughput of 64 kmetrics/s when 
storing 200 mil unique metric definitions and 50 bil measurements on the two 
nodes cluster. It's way below what InfluxDB can on the single node, but that's 
a number we can live with, I guess. Can GridDB perform better?

What do the others think? Should we experiment and add support for different 
backend drivers or rather choose one or two and concentrate on these?


Best greetings
Witek



[1] https://etherpad.openstack.org/p/cassandra_monasca



> -Original Message-
> From: Akira Yoshiyama [mailto:akirayoshiy...@gmail.com]
> Sent: Samstag, 19. August 2017 15:31
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] [Monasca] GridDB repository support
> 
> Hi all,
> 
> Toshiba GridDB[1][2] is a highly scalable distributed NoSQL database for IoT
> and Big Data. It has very good scalability and performance[3].
> It also has Community Edition licensed under GNU AGPL v3 and the source
> code is available at Github[4][5][6].
> 
> It looks suitable for Monasca repository, so I'm writing GridDB repository
> drivers for monasca-api/-persister[7][8]. They work well but need unit tests.
> Anyone interested?
> 
> Thank you,
> Akira Yoshiyama
> 
> [1]http://solutions.toshiba.com/overview.html
> [2]https://griddb.net/en/docs/documents/1-1_what-is-griddb.php
> [3]https://griddb.net/ja/blog/griddb-and-cassandra-ycsb-benchmarks/
> [4]https://github.com/griddb/griddb_nosql
> [5]https://github.com/griddb/c_client
> [6]https://github.com/griddb/griddb_client
> [7]https://review.openstack.org/#/c/495504/
> [8]https://review.openstack.org/#/c/495505/
> 
> __
> 
> 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-ansible] group/host specific config file overrides: how-to?

[Markus Zoeller]

On 22.08.2017 09:46, Flávio Ramalho wrote:
> Hi Markus,
> 
> I think you can achieve what you want by simple overriding the host
> variables, for example:
> 
> In /etc/openstack_deploy/openstack_user_config.yml:
> compute_hosts:
>compute1:
>  ip: 192.168.100.12
>  host_vars:
>nova_reserved_host_memory_mb: 256
>compute2:
>  ip: 192.168.100.10
> 
> In this case you would have compute1 with reserved_host_memory_mb = 256 and
> compute2 with the default value set for nova_reserved_host_memory_mb.
> 
> 
> Flávio

Oh, I didn't see those variables, good hint! I'll give it a try, maybe
that's good enough for me. Thanks a lot Flavio!

http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova/tree/templates/nova.conf.j2

Despite that this will probably work, is that an "interface" I'm allowed
to touch or is it considered an "internal/private" part of
OpenStack-Ansible (and/or its roles)?

-- 
Regards, Markus Zoeller (markus_z)


> On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller 
> wrote:
> 
>> On 21.08.2017 16:40, Andy McCrae wrote:
>>> Hey Markus,
>>>
>>>
 I'm wondering which possibilities I have to do group/host specific
 config file overrides. After reading [1], I'm still a little clueless.
 To be specific, I have this setup (expressed as Ansible inventory file):

 [z_compute_nodes]
 compute1
 # more nodes
 [x_compute_nodes]
 compute2
 # more nodes
 [computes:children]
 z_compute_nodes
 x_compute_nodes

 As an example, I want to set Nova's config option
 `reserved_host_memory_mb` of the `DEFAULT` config file section:

 ### nova.conf
 [DEFAULT]
 reserved_host_memory_mb=$VALUE

 My goal is this:

  | reserved_host_memory_mb
 --
 compute1 | 256
 compute2 | 512

 I know there are overrides like `nova_nova_conf_overrides`.
 So I tried to set a default override in `user_variables.yml`:

 ### /etc/openstack_deploy/user_variables.yml 

 nova_nova_conf_overrides:
   DEFAULT:
 reserved_host_memory_mb: 512

 But I wanted to override this depending on the host in
 `openstack_user_config.yml`:

 ### /etc/openstack_deploy/openstack_user_config.yml 
 # [...]
 # nova hypervisors
 compute_hosts:
   compute1:
 ip: 192.168.100.12
 host_vars:
   nova_nova_conf_overrides:
 DEFAULT:
   reserved_host_memory_mb: 256
   compute2:
 ip: 192.168.100.10

>>>
>>> Try change "host_vars" to "container_vars".
>>> If that doesn't work let me know, I'll spin up a test to recreate the
>>> actual problem, but at a glance that looks correct otherwise.
>>>
>>
>>
>> Replacing `host_vars` with `container_vars` didn't have an effect:
>>
>> ### controller1: /etc/openstack_deploy/openstack_user_config.yml
>> # nova hypervisors
>> compute_hosts:
>>   compute1:
>> ip: 192.168.100.12
>> container_vars:
>>   nova_nova_conf_overrides:
>> DEFAULT:
>> reserved_host_memory_mb: 256
>>   compute2:
>> ip: 192.168.100.10
>>
>> Both compute nodes still have the same $VALUE, although `compute1`
>> should have 256:
>>
>> ### compute1: /etc/nova/nova.conf
>> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
>> reserved_host_memory_mb = 512
>>
>>
>> ### compute2: /etc/nova/nova.conf
>> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
>> reserved_host_memory_mb = 512
>>
>> I'd like to avoid to introduce some "clever" dict merging algorithm I
>> won't understand anymore after a few weeks. :/
>>
>> Any hint is appreciated!
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>

 After testing this locally, it turned out that *both* hosts will
 have 512 for $VALUE. which was not my intended configuration.

 Please note that I only used 2 hosts here as an example but I'm looking
 for a solution which scales with much more hosts. I'm also applying
 those settings in a templated way like this:

 ### /etc/openstack_deploy/openstack_user_config.yml 
 # [...]
 # nova hypervisors
 compute_hosts:
 {% for host in groups['computes'] %}
   {{ hostvars[host]['inventory_hostname'] }}:
 ip: {{ hostvars[host]['ansible_host'] }}
 {% endfor %}

 The reason is, that I use the same steps for different environments
 (dev, test, prod) with a different amount of nodes.

 Any tips how to do this properly?


>>> Andy
>>>
>>>


__
OpenStack Development 

Re: [openstack-dev] [ironic] ironic-staging-drivers core cleanup and additions

[milanisko k]

makes sense, +1

Cheers,
milan

út 22. 8. 2017 v 11:38 odesílatel Vladyslav Drok 
napsal:

> Hey Dmitry,
>
> On Tue, Aug 22, 2017 at 12:24 PM, 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.
>>
>
> ++ to all of the changes.
>
>
>> 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [doc][cinder] Missing config-reference folder in openstack-manuals repository

[Sandanaraj, William Durairaj]

Thanks Andreas -- I'm able to find here 
http://git.openstack.org/cgit/openstack/cinder/tree/doc/source/configuration/block-storage/drivers
 

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com] 
Sent: Tuesday, August 22, 2017 4:56 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Sandanaraj, William Durairaj 

Cc: Shatwara, Sumit 
Subject: Re: [openstack-dev][doc][cinder] Missing config-reference folder in 
openstack-manuals repository

On 2017-08-22 12:57,  Sandanaraj, William Durairaj  wrote:
> Hi,
> 
>  
> 
> In ocata branch , I do see this config-reference folder -- 
> https://github.com/openstack/openstack-manuals/tree/stable/ocata/doc/c
> onfig-reference/source/block-storage/drivers
> 
> 
>  
> 
> But as of master branch, I don't see this folder -- 
> https://github.com/openstack/openstack-manuals/tree/master/doc/config-
> reference/source/block-storage/drivers
> 
> 
>  
> 
> Was there is any change in which we update the config-reference page 
> in Openstack Manuals repository ?

All the content has moved to the project repos as part of a larger doc reorg. 
Check cinder repo - directory doc/source/configuration,

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


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

Re: [openstack-dev] [doc][cinder] Missing config-reference folder in openstack-manuals repository

[Andreas Jaeger]

On 2017-08-22 12:57,  Sandanaraj, William Durairaj  wrote:
> Hi,
> 
>  
> 
> In ocata branch , I do see this config-reference folder --
> https://github.com/openstack/openstack-manuals/tree/stable/ocata/doc/config-reference/source/block-storage/drivers
> 
> 
>  
> 
> But as of master branch, I don’t see this folder --
> https://github.com/openstack/openstack-manuals/tree/master/doc/config-reference/source/block-storage/drivers
> 
> 
>  
> 
> Was there is any change in which we update the config-reference page in
> Openstack Manuals repository ?

All the content has moved to the project repos as part of a larger doc
reorg. Check cinder repo - directory doc/source/configuration,

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


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

[openstack-dev] Missing config-reference folder in openstack-manuals repository

[Sandanaraj, William Durairaj]

Hi,

In ocata branch , I do see this config-reference folder -- 
https://github.com/openstack/openstack-manuals/tree/stable/ocata/doc/config-reference/source/block-storage/drivers

But as of master branch, I don't see this folder -- 
https://github.com/openstack/openstack-manuals/tree/master/doc/config-reference/source/block-storage/drivers

Was there is any change in which we update the config-reference page in 
Openstack Manuals repository ?


Thanks & Regards,
William

__
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-fwaas]Why fwaas v1 plugin automatically inserts a rule to the head of a policy if people haven't set its position manually?

[Akihiro Motoki]

See the Networking API definition
https://developer.openstack.org/api-ref/networking/v2/index.html?expanded=insert-rule-into-a-firewall-policy-detail#insert-rule-into-a-firewall-policy
It says "If both insert_before and insert_after are not set, the new
firewall_rule_id is inserted at the top of the policy."
I think this is the intended behavior.

2017-08-22 18:50 GMT+09:00 田明明 :
> Has this referenced any firewall production or it is a bug because it will 
> cause original rules re-ordered every time?
>
> 发自我的 iPhone
>
>
> __
> 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-fwaas]Why fwaas v1 plugin automatically inserts a rule to the head of a policy if people haven't set its position manually?

[田明明]

Has this referenced any firewall production or it is a bug because it will 
cause original rules re-ordered every time?

发自我的 iPhone


__
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

[Vladyslav Drok]

Hey Dmitry,

On Tue, Aug 22, 2017 at 12:24 PM, 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.
>

++ to all of the changes.


> 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Dmitry Tantsur]

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

On 08/21/2017 09:15 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:

Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:

On 08/08/2017 03:30 PM, Doug Hellmann wrote:

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

 $ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

 $ tox -e venv -- new-release pike cinder rc


On systems with Python 3 by default this fails on installing 
lazr.restfulclient.

I think we should add

   basepython = python2

for now.


I wonder if you have an old copy of the releases repo. In master we
explicitly set basepython to python3 and lazr.restfulclient is no longer
a dependency.


Updated to latest HEAD, removed *.pyc files and .tox. Still getting:

Obtaining file:///home/dtantsur/Projects/releases
Requirement already up-to-date: pbr>=1.6 in 
./.tox/list-changes/lib/python3.6/site-packages (from releases==0.0.1.dev3083)

Collecting lazr.restfulclient==0.13.1 (from releases==0.0.1.dev3083)
   Using cached lazr.restfulclient-0.13.1.tar.gz
 Complete output from command python setup.py egg_info:
 Traceback (most recent call last):
   File "", line 1, in 
   File "/tmp/pip-build-hhi229rh/lazr.restfulclient/setup.py", line 19, in 


 import ez_setup
   File "/tmp/pip-build-hhi229rh/lazr.restfulclient/ez_setup.py", line 98
 except pkg_resources.VersionConflict, e:
 ^
 SyntaxError: invalid syntax

I cannot find where this dependency comes from, still investigating.


And here is what helped: rm -rf *.egg-info/

I suspect it was coming from stale directory releases.egg-info (currently we 
have openstack_releases.egg-info instead). I'm not sure why it was picked..






Doug

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






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

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Dmitry Tantsur]

On 08/21/2017 09:15 PM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:

Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:

On 08/08/2017 03:30 PM, Doug Hellmann wrote:

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

 $ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

 $ tox -e venv -- new-release pike cinder rc


On systems with Python 3 by default this fails on installing lazr.restfulclient.
I think we should add

   basepython = python2

for now.


I wonder if you have an old copy of the releases repo. In master we
explicitly set basepython to python3 and lazr.restfulclient is no longer
a dependency.


Updated to latest HEAD, removed *.pyc files and .tox. Still getting:

Obtaining file:///home/dtantsur/Projects/releases
Requirement already up-to-date: pbr>=1.6 in 
./.tox/list-changes/lib/python3.6/site-packages (from releases==0.0.1.dev3083)

Collecting lazr.restfulclient==0.13.1 (from releases==0.0.1.dev3083)
  Using cached lazr.restfulclient-0.13.1.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/pip-build-hhi229rh/lazr.restfulclient/setup.py", line 19, in 


import ez_setup
  File "/tmp/pip-build-hhi229rh/lazr.restfulclient/ez_setup.py", line 98
except pkg_resources.VersionConflict, e:
^
SyntaxError: invalid syntax

I cannot find where this dependency comes from, still investigating.



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

[Dmitry Tantsur]

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] [acceleration]Cyborg PTG planning etherpad

[Zhipeng Huang]

Hi Team,

I've put together an initial ptg planning at
https://etherpad.openstack.org/p/cyborg-queens-ptg , please feel free to
add your name if you plan to join and also write down any topic you want to
discuss.



-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [openstack-ansible] group/host specific config file overrides: how-to?

[Flávio Ramalho]

Hi Markus,

I think you can achieve what you want by simple overriding the host
variables, for example:

In /etc/openstack_deploy/openstack_user_config.yml:
compute_hosts:
   compute1:
 ip: 192.168.100.12
 host_vars:
   nova_reserved_host_memory_mb: 256
   compute2:
 ip: 192.168.100.10

In this case you would have compute1 with reserved_host_memory_mb = 256 and
compute2 with the default value set for nova_reserved_host_memory_mb.


Flávio

On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller 
wrote:

> On 21.08.2017 16:40, Andy McCrae wrote:
> > Hey Markus,
> >
> >
> >> I'm wondering which possibilities I have to do group/host specific
> >> config file overrides. After reading [1], I'm still a little clueless.
> >> To be specific, I have this setup (expressed as Ansible inventory file):
> >>
> >> [z_compute_nodes]
> >> compute1
> >> # more nodes
> >> [x_compute_nodes]
> >> compute2
> >> # more nodes
> >> [computes:children]
> >> z_compute_nodes
> >> x_compute_nodes
> >>
> >> As an example, I want to set Nova's config option
> >> `reserved_host_memory_mb` of the `DEFAULT` config file section:
> >>
> >> ### nova.conf
> >> [DEFAULT]
> >> reserved_host_memory_mb=$VALUE
> >>
> >> My goal is this:
> >>
> >>  | reserved_host_memory_mb
> >> --
> >> compute1 | 256
> >> compute2 | 512
> >>
> >> I know there are overrides like `nova_nova_conf_overrides`.
> >> So I tried to set a default override in `user_variables.yml`:
> >>
> >> ### /etc/openstack_deploy/user_variables.yml 
> >>
> >> nova_nova_conf_overrides:
> >>   DEFAULT:
> >> reserved_host_memory_mb: 512
> >>
> >> But I wanted to override this depending on the host in
> >> `openstack_user_config.yml`:
> >>
> >> ### /etc/openstack_deploy/openstack_user_config.yml 
> >> # [...]
> >> # nova hypervisors
> >> compute_hosts:
> >>   compute1:
> >> ip: 192.168.100.12
> >> host_vars:
> >>   nova_nova_conf_overrides:
> >> DEFAULT:
> >>   reserved_host_memory_mb: 256
> >>   compute2:
> >> ip: 192.168.100.10
> >>
> >
> > Try change "host_vars" to "container_vars".
> > If that doesn't work let me know, I'll spin up a test to recreate the
> > actual problem, but at a glance that looks correct otherwise.
> >
>
>
> Replacing `host_vars` with `container_vars` didn't have an effect:
>
> ### controller1: /etc/openstack_deploy/openstack_user_config.yml
> # nova hypervisors
> compute_hosts:
>   compute1:
> ip: 192.168.100.12
> container_vars:
>   nova_nova_conf_overrides:
> DEFAULT:
> reserved_host_memory_mb: 256
>   compute2:
> ip: 192.168.100.10
>
> Both compute nodes still have the same $VALUE, although `compute1`
> should have 256:
>
> ### compute1: /etc/nova/nova.conf
> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> reserved_host_memory_mb = 512
>
>
> ### compute2: /etc/nova/nova.conf
> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> reserved_host_memory_mb = 512
>
> I'd like to avoid to introduce some "clever" dict merging algorithm I
> won't understand anymore after a few weeks. :/
>
> Any hint is appreciated!
>
> --
> Regards, Markus Zoeller (markus_z)
>
> >>
> >> After testing this locally, it turned out that *both* hosts will
> >> have 512 for $VALUE. which was not my intended configuration.
> >>
> >> Please note that I only used 2 hosts here as an example but I'm looking
> >> for a solution which scales with much more hosts. I'm also applying
> >> those settings in a templated way like this:
> >>
> >> ### /etc/openstack_deploy/openstack_user_config.yml 
> >> # [...]
> >> # nova hypervisors
> >> compute_hosts:
> >> {% for host in groups['computes'] %}
> >>   {{ hostvars[host]['inventory_hostname'] }}:
> >> ip: {{ hostvars[host]['ansible_host'] }}
> >> {% endfor %}
> >>
> >> The reason is, that I use the same steps for different environments
> >> (dev, test, prod) with a different amount of nodes.
> >>
> >> Any tips how to do this properly?
> >>
> >>
> > 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
> >
>
>
>
>
> __
> 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] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi Training Team,

This is a friendly reminder that we are having our meeting in 90 minutes (0900 
UTC) on #openstack-meeting-3.

You can find the agenda here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you soon! :)

Thanks,
Ildikó
__
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][oslo][all] Clean up oslo deprecated stuff !

[ChangBo Guo]

Hi ALL,

We discussed a little about how to avoid breaking consuming projects' gate
in oslo weekly meeting last week.  The easy improvement is that clean up
deprecated stuff in oslo at the beginning of Queens.  I collected
deprecated stuff  in [1].  This need Oslo team and other team work
toghether. I think we can start the work when cycle Queens is open. I also
reserved a room in PTG
for 2 hours to do hacking.[2]


[1] https://etherpad.openstack.org/p/oslo-queens-tasks
[2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

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