[openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Masahito MUROI]

Hi requirements team,

This is a FFE request for adding python-blazarclient to 
global-requirements.txt.  Blazar team had release problems for updating 
the blazarclient to pypo.


Luckily, the problems are fixed and the client is published at pypi this 
morning.


1. https://review.openstack.org/#/c/539126/

best regards,
Masahito


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

Re: [openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Thierry Carrez]

Masahito MUROI wrote:
> Hi requirements team,
> 
> This is a FFE request for adding python-blazarclient to
> global-requirements.txt.  Blazar team had release problems for updating
> the blazarclient to pypo.
> 
> Luckily, the problems are fixed and the client is published at pypi this
> morning.
> 
> 1. https://review.openstack.org/#/c/539126/

Looks like it only affects blazar-dashboard, so +1 from me

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [kolla] Policy regarding template customisation

[Paul Bourke]

So I think everyone is in agreement that it should be option 2. I'm 
leaning towards this also but I'm wondering how much of this makes 
things easier for us as developers rather than operators.


How committed this are we in practice? For example, if we take 
nova.conf[0], if we follow option 2, theoretically all alternate 
hypervisor options (vmware/xen/nova-fake) etc. should come out and be 
left to override files. As should options templating options such as 
metadata_workers, listen ports, etc. globals.yml could probably be half 
the size it currently is. But if we go this route how many operators 
will stick with kolla? Maybe it won't be a big deal, the issue currently 
is the line is blurred on what gets templated and what doesn't.


On 30/01/18 01:04, Michał Jastrzębski wrote:

Hey,

So I'm also for option 2. There was big discussion in Atlanta about
"how hard it is to keep configs up to date and remove deprecated
options". merge_config makes it easier for us to handle this. With
amount of services we support I don't think we have enough time to
keep tabs on every config change across OpenStack.

On 29 January 2018 at 08:03, Steven Dake (stdake)  wrote:

Agree, the “why” of this policy is stated here:

https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html



Paul, I think your corrective actions sound good.  Perhaps we should also
reword “essential” to some other word that is more lenient.



Cheers

-steve



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

Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation



Thank Paul for pointing this out.



for me, I prefer to consist with 2)



There are thousands of configuration in OpenStack, it is hard for Kolla to

add every key/value pair in playbooks. Currently, the merge_config is a more

better solutions.









On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke  wrote:

Hi all,

I'd like to revisit our policy of not templating everything in
kolla-ansible's template files. This is a policy that was set in place very
early on in kolla-ansible's development, but I'm concerned we haven't been
very consistent with it. This leads to confusion for contributors and
operators - "should I template this and submit a patch, or do I need to
start using my own config files?".

The docs[0] are currently clear:

"The Kolla upstream community does not want to place key/value pairs in the
Ansible playbook configuration options that are not essential to obtaining a
functional deployment."

In practice though our templates contain many options that are not
necessary, and plenty of patches have merged that while very useful to
operators, are not necessary to an 'out of the box' deployment.

So I'd like us to revisit the questions:

1) Is kolla-ansible attempting to be a 'batteries included' tool, which
caters to operators via key/value config options?

2) Or, is it to be a solid reference implementation, where any degree of
customisation implies a clear 'bring your own configs' type policy.

If 1), then we should potentially:

* Update ours docs to remove the referenced paragraph
* Look at reorganising files like globals.yml into something more
maintainable.

If 2),

* We should make it clear to reviewers that patches templating options that
are non essential should not be accepted.
* Encourage patches to strip down existing config files to an absolute
minimum.
* Make this policy more clear in docs / templates to avoid frustration on
the part of operators.

Thoughts?

Thanks,
-Paul

[0]
https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization

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





--

Regards,

Jeffrey Zhang

Blog: http://xcodest.me


__
OpenStack Development Mailing 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] [requirement][cyborg]FFE - pyspdk requirement dependency

[Thierry Carrez]

We We wrote:
> The pyspdk is a important tool library [1] which  supports Cyborg SPDK
> driver [2] to manage the backend SPDK-base app, so we need to upload
> pyspdk into the pypi [3]  and then append 'pyspdk>=0.0.1’ item into
> ‘OpenStack/Cyborg/requirements.txt’ , so that  SPDK driver can be built
> correctly when zuul runs. However, It's not what we thought it would be,
> if we want to  add the new requirements, we should get support from
> upstream OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item.

Before we talk FFE, pyspdk looks a bit far away from being something
OpenStack code can depend on. In particular:

- it's not clearly licensed under a supported license (no LICENSE file
in the source code)
- Missing metadata entries in setup.cfg means we are missing a lot of
context information about this library

Those need to be fixed before we can even consider adding this library
to global requirements...

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Swapnil Kulkarni]

On Tue, Jan 30, 2018 at 4:18 PM, Thierry Carrez 
wrote:

> Masahito MUROI wrote:
> > Hi requirements team,
> >
> > This is a FFE request for adding python-blazarclient to
> > global-requirements.txt.  Blazar team had release problems for updating
> > the blazarclient to pypo.
> >
> > Luckily, the problems are fixed and the client is published at pypi this
> > morning.
> >
> > 1. https://review.openstack.org/#/c/539126/
>
> Looks like it only affects blazar-dashboard, so +1 from me
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


Looks good to me as well. +1
__
OpenStack Development Mailing 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] [charms] Dublin PTG devroom

[James Page]

Hi Team

The Dublin PTG is not so far away now, so lets start on the agenda for our
Devroom:

  https://etherpad.openstack.org/p/DUB-charms-devroom

We had a fairly formal agenda of design related topics in Denver for the
first day, and spent most of the second day mini-sprinting on various
features/bugs/issues/niggles etc...

I think it worked well - what do others think?

Please add topics to the pad.

Cheers

James
__
OpenStack Development Mailing 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] [kolla] Policy regarding template customisation

[vladislav . belogrudov]

may be we could move those specific options / templates to sample 
overrides? Operators would move necessary pieces back to 
/etc/kolla/config . Just thinking of config plug-ins / third-party 
supported things.


Thanks,
Vlad

On 01/30/2018 01:46 PM, Paul Bourke wrote:
So I think everyone is in agreement that it should be option 2. I'm 
leaning towards this also but I'm wondering how much of this makes 
things easier for us as developers rather than operators.


How committed this are we in practice? For example, if we take 
nova.conf[0], if we follow option 2, theoretically all alternate 
hypervisor options (vmware/xen/nova-fake) etc. should come out and be 
left to override files. As should options templating options such as 
metadata_workers, listen ports, etc. globals.yml could probably be 
half the size it currently is. But if we go this route how many 
operators will stick with kolla? Maybe it won't be a big deal, the 
issue currently is the line is blurred on what gets templated and what 
doesn't.


On 30/01/18 01:04, Michał Jastrzębski wrote:

Hey,

So I'm also for option 2. There was big discussion in Atlanta about
"how hard it is to keep configs up to date and remove deprecated
options". merge_config makes it easier for us to handle this. With
amount of services we support I don't think we have enough time to
keep tabs on every config change across OpenStack.

On 29 January 2018 at 08:03, Steven Dake (stdake)  
wrote:

Agree, the “why” of this policy is stated here:

https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html 





Paul, I think your corrective actions sound good.  Perhaps we should 
also

reword “essential” to some other word that is more lenient.



Cheers

-steve



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


Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [kolla] Policy regarding template 
customisation




Thank Paul for pointing this out.



for me, I prefer to consist with 2)



There are thousands of configuration in OpenStack, it is hard for 
Kolla to


add every key/value pair in playbooks. Currently, the merge_config 
is a more


better solutions.









On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke 
 wrote:


Hi all,

I'd like to revisit our policy of not templating everything in
kolla-ansible's template files. This is a policy that was set in 
place very
early on in kolla-ansible's development, but I'm concerned we 
haven't been

very consistent with it. This leads to confusion for contributors and
operators - "should I template this and submit a patch, or do I need to
start using my own config files?".

The docs[0] are currently clear:

"The Kolla upstream community does not want to place key/value pairs 
in the
Ansible playbook configuration options that are not essential to 
obtaining a

functional deployment."

In practice though our templates contain many options that are not
necessary, and plenty of patches have merged that while very useful to
operators, are not necessary to an 'out of the box' deployment.

So I'd like us to revisit the questions:

1) Is kolla-ansible attempting to be a 'batteries included' tool, which
caters to operators via key/value config options?

2) Or, is it to be a solid reference implementation, where any 
degree of

customisation implies a clear 'bring your own configs' type policy.

If 1), then we should potentially:

* Update ours docs to remove the referenced paragraph
* Look at reorganising files like globals.yml into something more
maintainable.

If 2),

* We should make it clear to reviewers that patches templating 
options that

are non essential should not be accepted.
* Encourage patches to strip down existing config files to an absolute
minimum.
* Make this policy more clear in docs / templates to avoid 
frustration on

the part of operators.

Thoughts?

Thanks,
-Paul

[0]
https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization 



__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--

Regards,

Jeffrey Zhang

Blog: http://xcodest.me


__ 


OpenStack Development Mailing 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

Re: [openstack-dev] [masakari] BUG in Masakari Installation and Procedure and/or Documentation

[Waines, Greg]

Thanks Honjo,
I reported bug in masakari Launchpad.
https://bugs.launchpad.net/masakari/+bug/1746229

Greg.

From: Rikimaru Honjo 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Tuesday, January 30, 2018 at 1:49 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [masakari] BUG in Masakari Installation and 
Procedure and/or Documentation

Hello Greg,

Thank you for reporting & researching.

On 2018/01/27 5:59, Waines, Greg wrote:
Update on this.
It turned out that i had incorrectly set the ‘project_name’ and ‘username’ in  
/etc/masakarimonitors/masakarimonitors.conf
Setting both these attributes to ‘admin’ made it such that the 
instancemonitor’s notification to masakari-engine was successful.
e.g.
stack@devstack-masakari-louie:~/devstack$ masakari notification-list
+--++-+--+--+
| notification_uuid| generated_time | status  | 
source_host_uuid | type |
+--++-+--+--+
| b8c6c561-7a93-40a2-8d73-3783024865b4 | 2018-01-26T19:41:29.00 | running | 
51bc8b8b-324f-499a-9166-38c22b3842cd | VM   |
+--++-+--+--+
stack@devstack-masakari-louie:~/devstack$
However I now get the following error in masakari-engine, when the 
masakari-engine attempts to do the VM Recovery
Jan 26 19:41:28 devstack-masakari-louie masakari-engine[11795]: 2018-01-26 
19:41:28.968 TRACE masakari.engine.drivers.taskflow.driver EndpointNotFound: 
publicURL endpoint for compute service named Compute Service not found
Why is masakari-engine looking for a publicURL endpoint for 
service_type=’compute’ and service_name=’Compute Service’ ?
I think there is no reason.
This default value was added by the following patch.
https://review.openstack.org/#/c/388734/

I think this is a bug.
Could you report in Launchpad?

See below that the Service Name = ‘nova’ ... NOT ‘Compute Service’
stack@devstack-masakari-louie:~/devstack$ openstack endpoint list
+--+---+--++-+---+--+
| ID   | Region| Service Name | Service Type   
| Enabled | Interface | URL  |
+--+---+--++-+---+--+
| 0111643ef1584decb523524a3db5ce18 | RegionOne | nova_legacy  | compute_legacy 
| True| public| http://10.10.10.14/compute/v2/$(project_id)s |
| 01790448c22f49e69774adf290fba728 | RegionOne | gnocchi  | metric 
| True| internal  | http://10.10.10.14/metric|
| 0b31693c6650499a981d580721be9e48 | RegionOne | vitrage  | rca
| True| internal  | http://10.10.10.14:8999  |
| 40f66ed61b4e4310829aa69e11c75554 | RegionOne | neutron  | network
| True| public| http://10.10.10.14:9696/ |
| 47479cf64af944b996b1fbca42efd945 | RegionOne | nova | compute
| True| public| http://10.10.10.14/compute/v2.1  |
| 49dccfc61e8246a2a2c0b8d12b3db91a | RegionOne | vitrage  | rca
| True| admin | http://10.10.10.14:8999  |
| 5261ba0327de4c2d92842147636ee770 | RegionOne | masakari | ha 
| True| internal  | http://10.10.10.14:15868/v1/$(tenant_id)s|
| 5df28622c6f449ebad12d9b62110cd08 | RegionOne | gnocchi  | metric 
| True| admin | http://10.10.10.14/metric|
| 64f8f401431042a0ab1d053ca4f4df02 | RegionOne | glance   | image  
| True| public| http://10.10.10.14/image |
| 69ad6b9d0b0b4d0a8da6fa36af8289cb | RegionOne | masakari | ha 
| True| public| http://10.10.10.14:15868/v1/$(tenant_id)s|
| 7dd9d5396e9c49d4a41e2865b841f6a0 | RegionOne | masakari | ha 
| True| admin | http://10.10.10.14:15868/v1/$(tenant_id)s|
| 811fa7f4b3c14612b4aca354dc8ea77e | RegionOne | vitrage  | rca
| True| public| http://10.10.10.14:8999  |
| 8535da724c424363bffe1d033ee033e5 | RegionOne | cinder   | volume 
| True| public| http://10.10.10.14/volume/v1/$(project_id)s  |
| 853f1783f1014075a03c16f7c3a2568a | RegionOne | keystone | identity   
| True| admin | http://10.10.10.14/identity  |
| 9450f5611ca747f2a049f22ff0996dba | RegionOne | cinderv3 | volumev3   
| True| public| http://10.10.10.14/volume/v3/$(project_id)s  |
| 9a73696d88a9438cb0ab75a754a08

Re: [openstack-dev] [masakari] BUG in Masakari Installation and Procedure and/or Documentation

[Waines, Greg]

FYI ...

I tried updating /etc/masakari/masakari.conf with
[nova]
nova_catalog_admin_info = compute:nova:publicURL
and restarting masakari-engine and masakari-api ... but that didn’t work ... 
not sure why.

So I manually changed the default nova_catalog_admin_info to 
‘compute:nova:publicURL’ ... in masakari/masakari/conf/nova.py
and restarted masakari-engine ...

and YAY  ... my usecase demo of masakari non-intrusive instance monitoring 
worked .
i.e. masakari-instancemonitor detected and reported failed VM, masakari-engine 
recovered the VM automatically.

See below:

stack@devstack-masakari-louie:~$ nova list
+--+-+++-++
| ID   | Name| Status | Task State | 
Power State | Networks   |
+--+-+++-++
| 00f377e6-e21f-431a-aba9-31ce13fd974c | vm-1-cirros | ACTIVE | -  | 
Running | private=fd37:1afb:1393:0:f816:3eff:fec9:7f48, 10.0.0.7 |
+--+-+++-++
stack@devstack-masakari-louie:~$ masakari notification-list
+--++-+--+--+
| notification_uuid| generated_time | status  | 
source_host_uuid | type |
+--++-+--+--+
| 5b535d99-4e02-44a5-bd21-d131d14aaa36 | 2018-01-30T12:10:43.00 | running | 
51bc8b8b-324f-499a-9166-38c22b3842cd | VM   |
| b8c6c561-7a93-40a2-8d73-3783024865b4 | 2018-01-26T19:41:29.00 | running | 
51bc8b8b-324f-499a-9166-38c22b3842cd | VM   |
| ed6433c3-939d-4aa8-bf47-3ce8e8c78d45 | 2018-01-26T17:13:03.00 | running | 
51bc8b8b-324f-499a-9166-38c22b3842cd | VM   |
+--++-+--+--+
stack@devstack-masakari-louie:~$
stack@devstack-masakari-louie:~$ !ps
ps -ef | fgrep qemu
libvirt+  8113 1  2 12:12 ?00:00:14 /usr/bin/qemu-system-x86_64 
-name guest=instance-0004,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-instance-0004/master-key.aes
 -machine pc-i440fx-artful,accel=tcg,usb=off,dump-guest-core=off -m 512 
-realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
00f377e6-e21f-431a-aba9-31ce13fd974c -smbios type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=17.0.0,serial=dacbc8a8-47c5-4132-86e3-3c902df4cf15,uuid=00f377e6-e21f-431a-aba9-31ce13fd974c,family=Virtual
 Machine -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-instance-0004/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/opt/stack/data/nova/instances/00f377e6-e21f-431a-aba9-31ce13fd974c/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=80,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c9:7f:48,bus=pci.0,addr=0x3 
-add-fd set=1,fd=83 -chardev 
pty,id=charserial0,logfile=/dev/fdset/1,logappend=on -device 
isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -k en-us -device 
cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
stack 9195  5888  0 12:23 pts/000:00:00 grep -F --color=auto qemu
stack@devstack-masakari-louie:~$
stack@devstack-masakari-louie:~$ sudo kill -9 8113

... masakari detects and restarts VM 

stack@devstack-masakari-louie:~$ nova list
+--+-+++-++
| ID   | Name| Status | Task State | 
Power State | Networks   |
+--+-+++-++
| 00f377e6-e21f-431a-aba9-31ce13fd974c | vm-1-cirros | ACTIVE | -  | 
Running | private=fd37:1afb:1393:0:f816:3eff:fec9:7f48, 10.0.0.7 |
+--+-+++-++
stack@devstack-masakari-louie:~$ masakari notification-l

Re: [openstack-dev] [kolla] Policy regarding template customisation

[Simon Leinen]

Paul Bourke writes:
> So I think everyone is in agreement that it should be option 2. I'm
> leaning towards this also but I'm wondering how much of this makes
> things easier for us as developers rather than operators.

> How committed this are we in practice? For example, if we take
> nova.conf[0], if we follow option 2, theoretically all alternate
> hypervisor options (vmware/xen/nova-fake) etc. should come out and be
> left to override files. As should options templating options such as
> metadata_workers, listen ports, etc. globals.yml could probably be
> half the size it currently is. But if we go this route how many
> operators will stick with kolla? [...]

Operator here.  I've been following this discussion.  Background: We
have been using puppet-openstack combined with our own Puppet
"integration classes" for several years.  All configuration parameters
are neatly in Hiera.  So we're used to the "batteries-included" way that
Paul describes under (1).  For various reasons, we are also looking at
new ways of provisioning our control plane, including Kolla.

In hindsight, and in my personal opinion, while our previous approach
(1) has somehow felt like the proper way to do things, it hasn't really
paid off for us as an operator, and I would happily try approach (2).

The perceived downside of (2) - or a perceived advantage of (1) - is
that in an ideal world, (1) isolates us from the arcane configuration
file details that the crazy devs of individual services come up with.
In practice, it turns out that (a) those files aren't rocket science (b)
as an operator you need to understand them anyway, at the latest when
you need to debug stuff, and (c) the deployment tool can easily become a
bottlenecks for deploying new features.

This is why I'm happy to embrace the current Kolla philosophy (2).
Sorry if I'm just repeating arguments that led to its adoption in the
first place - I wasn't there when that happened.
-- 
Simon.

> Maybe it won't be a big deal, the issue currently is the line is
> blurred on what gets templated and what doesn't.

__
OpenStack Development Mailing 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] [magnum] [ironic] Why does magnum create instances with ports using 'fixed-ips' ?

[Waines, Greg]

Any thoughts on this ?
Greg.

From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Friday, January 19, 2018 at 3:10 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "Nasir, Shoaib" 
Subject: [openstack-dev] [magnum] [ironic] Why does magnum create instances 
with ports using 'fixed-ips' ?

Hey there,

We have just recently integrated MAGNUM into our OpenStack Distribution.

QUESTION:
When MAGNUM is creating the ‘instances’ for the COE master and minion nodes,
WHY does it create the instances with ports using ‘fixed-ips’ ?
- instead of just letting the instance’s port dhcp for its 
ip-address ?

I am asking this question because:

· we have also integrated IRONIC into our OpenStack Distribution, and

o   currently support the simple (somewhat non-multi-tenant) networking approach
i.e.

§  ironic-provisioning-net TENANT NETWORK,
used to  network boot the IRONIC Instances,
is owned by ADMIN but shared so TENANTS can create IRONIC instances,

§  AND,
we do NOT support the functionality to have IRONIC update the
adjacent switch configuration in order to move the IRONIC instance
on to a different (TENANT-owned) TENANT NETWORK after the instance
is created.

o   so it is SORT OF multi-tenant in the sense that any TENANT can create an 
IRONIC instance,
HOWEVER the IRONIC instances of all tenants are all on the same TENANT NETWORK



· In this environment,
When we use MAGNUM to create IRONIC COE Nodes

o   it ONLY works if the ADMIN creates the MAGNUM Cluster,

o   it does NOT work if a TENANT creates the MAGNUM Cluster,

§  because a TENANT can NOT create an instance port with ‘fixed-ips’ on a 
TENANT NETWORK
that is not owned by himself.

appreciate any info on this,
Greg.
__
OpenStack Development Mailing 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] [kolla] Policy regarding template customisation

[Paul Bourke]

On 30/01/18 12:54, Simon Leinen wrote:

The perceived downside of (2) - or a perceived advantage of (1) - is
that in an ideal world, (1) isolates us from the arcane configuration
file details that the crazy devs of individual services come up with.
In practice, it turns out that (a) those files aren't rocket science (b)
as an operator you need to understand them anyway,


Thanks very much for taking the time to provide input Simon, it's very 
valuable. I think you sum it up well, definitely approach (1) is easier 
to newcomers who want to get up and going quickly without having to read 
too much into the files they're customising. In reality anyone going 
beyond a demo environment will need to do so.


__
OpenStack Development Mailing 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][opendaylight puppet] failed to deploy odl master with latest opendaylight puppet

[Moshe Levi]

Hi all,

We are trying to test solution of the odl hw offload in tripleo.
We have already merged the odl support for ovs hardware offload [1].
We are trying to test that everting is working with tripleo, but we get failure 
with jetty.xml.orig.
For some reason it get configure like [2] and causing opendaylight for failed 
to load http.
It seem that there is problem with opendaylight puppet that is misconfiguring 
jetty.xml.orig

Any help would be appreciated


[1] -  https://git.opendaylight.org/gerrit/#/c/67704/
[2] - http://paste.openstack.org/show/657899/
__
OpenStack Development Mailing 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] [kolla] Policy regarding template customisation

[Mark Goddard]

Sometimes there are features that require different containers to be
deployed, or different config files to be generated. These are things that
cannot be done simply through merging a fixed set of config files.
nova_compute_virt_type
is an example of such a variable - various non-config tasks depend upon it. I
guess the question is, for the supported values of kolla-ansible's
variables, should a minimal working deployment also be supported? Does this
logic inevitably lead to (1), or is it sustainable?

Mark

On 30 January 2018 at 12:54, Simon Leinen  wrote:

> Paul Bourke writes:
> > So I think everyone is in agreement that it should be option 2. I'm
> > leaning towards this also but I'm wondering how much of this makes
> > things easier for us as developers rather than operators.
>
> > How committed this are we in practice? For example, if we take
> > nova.conf[0], if we follow option 2, theoretically all alternate
> > hypervisor options (vmware/xen/nova-fake) etc. should come out and be
> > left to override files. As should options templating options such as
> > metadata_workers, listen ports, etc. globals.yml could probably be
> > half the size it currently is. But if we go this route how many
> > operators will stick with kolla? [...]
>
> Operator here.  I've been following this discussion.  Background: We
> have been using puppet-openstack combined with our own Puppet
> "integration classes" for several years.  All configuration parameters
> are neatly in Hiera.  So we're used to the "batteries-included" way that
> Paul describes under (1).  For various reasons, we are also looking at
> new ways of provisioning our control plane, including Kolla.
>
> In hindsight, and in my personal opinion, while our previous approach
> (1) has somehow felt like the proper way to do things, it hasn't really
> paid off for us as an operator, and I would happily try approach (2).
>
> The perceived downside of (2) - or a perceived advantage of (1) - is
> that in an ideal world, (1) isolates us from the arcane configuration
> file details that the crazy devs of individual services come up with.
> In practice, it turns out that (a) those files aren't rocket science (b)
> as an operator you need to understand them anyway, at the latest when
> you need to debug stuff, and (c) the deployment tool can easily become a
> bottlenecks for deploying new features.
>
> This is why I'm happy to embrace the current Kolla philosophy (2).
> Sorry if I'm just repeating arguments that led to its adoption in the
> first place - I wasn't there when that happened.
> --
> Simon.
>
> > Maybe it won't be a big deal, the issue currently is the line is
> > blurred on what gets templated and what doesn't.
>
> __
> OpenStack Development Mailing 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-job-failures][mistral][release][requirements] Pre-release of openstack/mistral-extra failed

[Brad P. Crochet]

On Mon, Jan 29, 2018 at 8:02 PM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2018-01-30 00:40:13 +:
>> Build failed.
>>
>> - release-openstack-python 
>> http://logs.openstack.org/53/533a5ee424ebf6937f03d3b1d9d5b52e8ecb/pre-release/release-openstack-python/44f2fd4/
>>  : FAILURE in 7m 58s
>> - announce-release announce-release : SKIPPED
>> - propose-update-constraints propose-update-constraints : SKIPPED
>>
>
> This release appears to have failed because tox.ini is set up to use the
> old style of constraints list management and mistral-extra appears in
> the constraints list.
>
> I don't know why the tox environment is being used to build the package;
> I thought we stopped doing that.
>
> One solution is to fix the tox.ini to put the constraints specification
> in the "deps" field. The patch [1] to oslo.config making a similar
> change should show you what is needed.
>
> Doug
>
> [1] https://review.openstack.org/#/c/524496/1/tox.ini
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hopefully https://review.openstack.org/539204 fixes it.

Brad

__
OpenStack Development Mailing 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] RHOSP 10 failed overcloud deployment

[Anda Nicolae]

Hello,

As previously stated in my previous mail on this list , I am trying to deploy 
OpenStack 10 using OpenStack Platform Director 10.
I am using a bare-metal server with RedHat 7.4, on which I have created 3 VMs: 
1st VM is the undercloud node, 2nd VM is the overcloud controller node and the 
3rd VM is the overcloud compute node.
The bare-metal server I am using is also my KVM hypervisor for the overcloud.

I managed to provision my overcloud nodes and now I am stuck at performing 
overcloud deployment.
The command I am running is:
openstack --debug overcloud deploy --templates ~/templates --control-scale 1 
--compute-scale 1 --control-flavor control --compute-flavor compute -e 
~/templates/environments/network-isolation.yaml -e 
~/templates/environments/network-environment.yaml --ntp-server pool.ntp.org 
--neutron-network-type vxlan --neutron-tunnel-types vxlan.

I connected via ssh with heat-admin user on my controller and compute nodes. 
I've run the following command to gather logs:
sudo journalctl -u os-collect-config

I think the problem is on my controller node, because I've noticed the 
following messages in the output of the above command:
os-collect-config[2996]: Source [ec2] Unavailable.
os-collect-config[2996]: /var/lib/os-collect-config/local-data not found. 
Skipping
os-collect-config[2996]: No local metadata found 
(['/var/lib/os-collect-config/local-data']

These messages repeat for various times in the output of the above command.

On my undercloud VM, I've noticed that overcloud deployment remains stuck when 
running wait_for_stack_ready function from 
/usr/lib/python2.7/site-packages/tripleoclient/utils.py.

I also intend to add some logs in 
/usr/lib/python2.7/site-packages/os_collect_config/collect.py to see what 
causes the error message: Source [ec2] Unavailable

I think I have an error in my templates, but I didn't figure out which yet. Do 
you happen to know what might have caused this?

Thanks,
Anda

__
OpenStack Development Mailing 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] bug deputy report (week of Jan 22)

[Akihiro Motoki]

Hi neutrinos,

Sorry for a bit late report of the bug deputy of last week.
I think there are several number of interesting bugs reported.



[Needs attention]

https://bugs.launchpad.net/neutron/+bug/1745642 SG hybrid iptables
driver and FWaaS OVS driver create overlapping conntrack zones

MTU topics on ovs-agent
https://bugs.launchpad.net/neutron/+bug/1744101 vxlan interfaces doesn't get MTU
https://bugs.launchpad.net/neutron/+bug/1745150 neutron doesn't set MTU on ovs
I am not sure it depends on deployments or not. We need to evaluate
these carefully, while the priority haven't been decided.

https://bugs.launchpad.net/neutron/+bug/1746000 dnsmasq does not
fallback on SERVFAIL
It is still Undecided status. The solution of dropping strict-order
option sounds reasonable to me, but I haven't understood why
strict-order of dnsmasq is required.

https://bugs.launchpad.net/neutron/+bug/1745468 Conntrack entry
removal can take a long time on large deployments
Brian is working on this, but it is worth attracted for the release.

https://bugs.launchpad.net/neutron/+bug/1745386 Update FloatingIP to
set QoS policy on it fails
It is medium priority, but it is worth fixed as this is one of new
features in queens. The fix is already proposed.

https://bugs.launchpad.net/neutron/+bug/1745443 cannot restrict
/var/lib/neutron permissions
I am not sure we can allow 'dnsmasq' user to access
/var/lib/neutron/dhcp instead of /var/lib/neutron.
More input on SElinux(?) would be appreciated.

[tricky bugs]

https://bugs.launchpad.net/neutron/+bug/1745412
test_l3_agent_scheduler intermittent failures when running locally

[Open question]

Neutron haproxy logs are not being collected
https://bugs.launchpad.net/devstack/+bug/1744359
-> Is there anything remaining? The merged fix looks complete to me.

[Closes Bug]

Many fullstack tests failing because of some error in L3 agent
https://bugs.launchpad.net/neutron/+bug/1745013
-> Nice finding, Slawek. It was eventlet bug.
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126580.html

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

[openstack-dev] [tripleo] Gate resets - do not recheck or approve any patch now

[Emilien Macchi]

Please do not recheck or approve any patch now, we're having some gate
issue, the team is working on it on #tripleo.

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

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[Thierry Carrez]

Thierry Carrez wrote:
> Here is the proposed pre-allocated track schedule for the Dublin PTG:
> 
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true

Following feedback I made small adjustments to Kuryr and
OpenStack-Charms allocations. The track schedule is about to be
published on the event website, so now is your last chance to signal
critical issues with it!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tripleo] CI'ing ceph-ansible against TripleO scenarios

[John Fulton]

On Fri, Jan 26, 2018 at 7:29 AM, Giulio Fidente  wrote:
> On 01/26/2018 01:49 AM, Paul Belanger wrote:
>> On Thu, Jan 25, 2018 at 04:22:56PM -0800, Emilien Macchi wrote:
>>> Is there any plans to run TripleO CI jobs in ceph-ansible?
>>> I know the project is on github but thanks to zuulv3 we can now easily
>>> configure ceph-ansible to run Ci jobs in OpenStack Infra.
>>>
>>> It would be really great to investigate that in the near future so we avoid
>>> eventual regressions.
>>> Sebastien, Giulio, John, thoughts?
>>> --
>>> Emilien Macchi
>>
>> Just a note, we haven't actually agree to enable CI for github projects just
>> yet.  While it is something zuul can do now, I believe we still need to 
>> decide
>> when / how to enable it.
>>
>> We are doing some initial testing with ansible/ansible however.
>
> but we like being on the front line! :D
>
> we discussed this same topic with Sebastien and John a few weeks back
> and agreed on having some gate job for ceph-ansible CI'ing against TripleO!
>
> how do we start? I think the candidate branch on ceph-ansible to gate is
> "beta-3.1" but there will be more ... I am just not sure we're stable
> enough to gate master yet ... but we might do it non-voting, it's up for
> debate
>
> on TripleO side we'd be looking at running scenarios 001 and 004 ...
> maybe initially 004 only is good enough as it covers (at least for ceph)
> most of what is in 001 as well
>
> can we continue on IRC? :D
>
> and thanks Emilien and Paul for starting the thread and helping

+1

We talked about this today and there's agreement from Seb to get a job
in place for this. I think we could start with the following plan:

- Simple extra job in ceph-ansible's CI on github which runs
ceph-ansible with the same params that TripleO uses
- ceph-ansible triggering zuul:
-- I'm hoping I can get a test in place in a test github area with the
help of pabelanger (do we have a living example on github of this?)
-- Then I can pursue making a real ceph-ansible CI job from the living example

Thoughts?

  John

__
OpenStack Development Mailing 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 Dublin - Price Increase this Thursday

[Kendall Waters]

Hi everyone,

We are four weeks out from the Dublin Project Teams Gathering (February 26 - 
March 2nd), and we are expecting the event to sell out! You have two more days 
to book your ticket at the normal price. We'll switch to last-minute price (USD 
$200) on Thursday, February 1st at 12 noon CT (18:00 UTC). So go and grab your 
ticket before the price increases! [1]

Cheers,
Kendall

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

Re: [openstack-dev] [tripleo][opendaylight puppet] failed to deploy odl master with latest opendaylight puppet

[Janki Chhatbar]

Hi Tim

Can this be because of version bump?
Moshe is using custom build ODL rpm based on master.

-- Forwarded message --
From: Moshe Levi 
Date: Tue, Jan 30, 2018 at 6:41 PM
Subject: [openstack-dev] [tripleo][opendaylight puppet] failed to deploy
odl master with latest opendaylight puppet
To: Janki Chhatbar , "OpenStack Development Mailing
List (not for usage questions)" , "
integration-...@lists.opendaylight.org" <
integration-...@lists.opendaylight.org>
Cc: Sulaiman Radwan , Hasan Qunoo <
has...@mellanox.com>


Hi all,



We are trying to test solution of the odl hw offload in tripleo.

We have already merged the odl support for ovs hardware offload [1].

We are trying to test that everting is working with tripleo, but we get
failure with jetty.xml.orig.

For some reason it get configure like [2] and causing opendaylight for
failed to load http.

It seem that there is problem with opendaylight puppet that is
misconfiguring jetty.xml.orig



Any help would be appreciated





[1] -  https://git.opendaylight.org/gerrit/#/c/67704/

[2] - http://paste.openstack.org/show/657899/



-- 
Thanking you

Janki Chhatbar
OpenStack | Docker | SDN
simplyexplainedblog.wordpress.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 22 January 2018

[Lance Bragstad]

On 01/27/2018 01:16 PM, Colleen Murphy wrote:
> # Keystone Team Update - Week of 22 January 2018
>
> ## News
>
> ### Feature freeze
>
> This week was feature freeze and client freeze. While we approved
> everything we cared about for this release on time, some CI issues
> (some unexpected and some predictable) delayed these features being
> merged. The release team has extended the freeze deadline to Monday,
> which should (hopefully) give us enough time for the last few changes
> to land before we release RC1.
>
> ### RC bugs
>
> We've started compiling a list of potential release-critical bugs[1].
> Please continue to report bugs as you find them in the RC, and also
> please focus your attention on fixing these bugs and reviewing
> bugfixes.
Looks like everything that is a possible RC bug is targeted accordingly.
Here is a LP link in case that's easier for some people to track [0].

[0] https://goo.gl/A5Wz4Z
>
> [1] https://etherpad.openstack.org/p/keystone-queens-bug-list
>
> ### API Discovery
>
> We had some interesting discussions this week about experimental APIs
> and API discovery[2][3]. This was partly in the context of our new
> "unified limits" API, which is step 1 in providing a cross-project
> service where quotas for projects could be set and retrieved by other
> OpenStack services. We're marking this API as "experimental" for the
> time being while we shake out some of the cross-project usage patterns
> we'll need to support, but this poses a discoverabiltiy problem. We
> already expose a "home document" which lists all of our API routes and
> their statuses, e.g. whether they're tagged as "experimental". While
> this seems like a really useful feature for API consumers as well as a
> great way to expose experimental features without committing to
> stability, it seems like the JSON-home standard never quite made it
> off the ground, so it's not a standard we can rely on API consumers
> supporting. However, we could certainly build off of what we already
> have to enhance our API discoverability
>
> [2] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-24.log.html#t2018-01-24T22:27:50
> [3] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-25.log.html#t2018-01-25T14:43:46
> [4] https://mnot.github.io/I-D/json-home/
>
> ### GSoC Projects
>
> OpenStack is applying to participate in the Google Summer of Code
> project[5]. We've started compiling a list of potential projects that
> a GSoC intern could work on[6]. Please help us add to the list! And if
> you're interested in being a mentor, please step up! We'll likely
> discuss this more at the next keystone meeting.
>
> [5] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-25.log.html#t2018-01-25T14:38:28
> [6] https://etherpad.openstack.org/p/keystone-internship-ideas
>
> ## Recently Merged Changes
>
> Search query: https://goo.gl/hdD9Kw
>
> We merged 49 changes this week, though we approved quite a few that
> are still making their way through the gate, including changes that
> are part of our main feature objectives.
>
> ## Changes that need Attention
>
> Search query: https://goo.gl/h9knRA
>
> There are 36 changes that are passing CI, not in merge conflict, have
> no negative reviews and aren't proposed by bots. Expect to see a lot
> more as we bugstomp over the next two weeks.
>
> ## Milestone Outlook
>
> https://releases.openstack.org/queens/schedule.html
>
> This week marked feature freeze and client freeze, but due to a number
> of CI problems the release team has extended the feature freeze till
> Monday and the client freeze until Tuesday[7]. This just means the
> approved changes that we still have moving through CI should hopefully
> have time to finish and be merged.
>
> [7] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126621.html
>
> ## Shout-outs
>
> Thanks to the whole team for working so hard this week!
>
> ## Help with this newsletter
>
> Help contribute to this newsletter by editing the etherpad:
> https://etherpad.openstack.org/p/keystone-team-newsletter
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [nova][ceilometer] versioned notifications coverage

[gordon chung]

hi,

we've had an open item to consume versioned notifications in ceilometer. 
the question that remains is: do all unversioned notifications have a 
versioned version or are there still some items missing?

the blocker for us is that we can't consume both as then we'd end up 
duplicating data but we also can't consume versioned notifications 
exclusively or we'll miss data.

apologies, if this is captured somewhere, just figured this is easier.

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

Re: [openstack-dev] [release][searchlight] problem with release job configurations

[McLellan, Steven]

Hi Doug,

Apologies, I was travelling all day yesterday. I've put up  
https://review.openstack.org/539231 to change the project config and made the 
release review (https://review.openstack.org/538321) depend on it.

Thanks for the detailed information!

Steve

On 1/29/18, 6:21 PM, "Doug Hellmann"  wrote:

Both searchlight-ui has a configuration issue that the release team
cannot fix by ourselves. We need input from the searchlight team about
how to resolve it.

As you'll see from [2] the release validation logic is categorizing
searchlight-ui as a horizon-plugin. It is then rejecting the release
request [1] because, according to the settings in project-config,
the repository is configured to use publish-to-pypi instead of the
expected publish-to-pypi-horizon.

The difference between the two jobs is the latter installs horizon
before trying to build the package. Many horizon plugins apparently
needed this. We don't know if searchlight does.

There are 2 possible ways to fix the issue:

1. Set release-type to "python-pypi" in [1] to tell the validation code
   that publish-to-pypi is the expected job.
2. Change the release job for the repository in project-config.

Please let us know which fix is correct by either updating [1] with the
release-type or a Depends-On link to the change in project-config to use
the correct release job.

Doug


[1] https://review.openstack.org/#/c/538321/
[2] 
http://logs.openstack.org/21/538321/1/check/openstack-tox-validate/3afbe28/tox/validate-request-results.log

__
OpenStack Development Mailing 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-job-failures][mistral][release][requirements] Pre-release of openstack/mistral-extra failed

[Doug Hellmann]

Excerpts from Brad P. Crochet's message of 2018-01-30 08:16:52 -0500:
> On Mon, Jan 29, 2018 at 8:02 PM, Doug Hellmann  wrote:
> > Excerpts from zuul's message of 2018-01-30 00:40:13 +:
> >> Build failed.
> >>
> >> - release-openstack-python 
> >> http://logs.openstack.org/53/533a5ee424ebf6937f03d3b1d9d5b52e8ecb/pre-release/release-openstack-python/44f2fd4/
> >>  : FAILURE in 7m 58s
> >> - announce-release announce-release : SKIPPED
> >> - propose-update-constraints propose-update-constraints : SKIPPED
> >>
> >
> > This release appears to have failed because tox.ini is set up to use the
> > old style of constraints list management and mistral-extra appears in
> > the constraints list.
> >
> > I don't know why the tox environment is being used to build the package;
> > I thought we stopped doing that.
> >
> > One solution is to fix the tox.ini to put the constraints specification
> > in the "deps" field. The patch [1] to oslo.config making a similar
> > change should show you what is needed.
> >
> > Doug
> >
> > [1] https://review.openstack.org/#/c/524496/1/tox.ini
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Hopefully https://review.openstack.org/539204 fixes it.
> 
> Brad
> 

Thanks!

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

Re: [openstack-dev] [release][searchlight] problem with release job configurations

[Doug Hellmann]

Excerpts from McLellan, Steven's message of 2018-01-30 15:03:59 +:
> Hi Doug,
> 
> Apologies, I was travelling all day yesterday. I've put up  
> https://review.openstack.org/539231 to change the project config and made the 
> release review (https://review.openstack.org/538321) depend on it.
> 
> Thanks for the detailed information!
> 
> Steve

Thanks for hopping on the fix so quickly, Steve.

> 
> On 1/29/18, 6:21 PM, "Doug Hellmann"  wrote:
> 
> Both searchlight-ui has a configuration issue that the release team
> cannot fix by ourselves. We need input from the searchlight team about
> how to resolve it.
> 
> As you'll see from [2] the release validation logic is categorizing
> searchlight-ui as a horizon-plugin. It is then rejecting the release
> request [1] because, according to the settings in project-config,
> the repository is configured to use publish-to-pypi instead of the
> expected publish-to-pypi-horizon.
> 
> The difference between the two jobs is the latter installs horizon
> before trying to build the package. Many horizon plugins apparently
> needed this. We don't know if searchlight does.
> 
> There are 2 possible ways to fix the issue:
> 
> 1. Set release-type to "python-pypi" in [1] to tell the validation code
>that publish-to-pypi is the expected job.
> 2. Change the release job for the repository in project-config.
> 
> Please let us know which fix is correct by either updating [1] with the
> release-type or a Depends-On link to the change in project-config to use
> the correct release job.
> 
> Doug
> 
> 
> [1] https://review.openstack.org/#/c/538321/
> [2] 
> http://logs.openstack.org/21/538321/1/check/openstack-tox-validate/3afbe28/tox/validate-request-results.log
> 

__
OpenStack Development Mailing 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][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

[Matt Riedemann]

The 10.0.0 release of python-novaclient dropped some deprecated CLIs and 
python API bindings for the server actions to add/remove fixed and 
floating IPs:


https://docs.openstack.org/releasenotes/python-novaclient/queens.html#id2

python-openstackclient was using some of those python API bindings from 
novaclient which now no longer work:


https://bugs.launchpad.net/python-openstackclient/+bug/1745795

I've at least identified where the broken code is:

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

The question I'm struggling with is how to resolve this in OSC. We can't 
just remove the CLIs without a deprecation period. I thought about doing 
something similar to the proxy orchestration that the compute API does 
for these actions, but that gets a bit complicated in OSC if we are 
going to make the CLI support both nova-network and neutron. 
Furthermore, if we did still support nova-network in those CLIs, the 
novaclient python API bindings are gone, so OSC would have to do 
something different - likely make it's own REST API calls to the compute 
API at a low enough microversion where those APIs still exist (<=2.43):


https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id39

So if we had to make a straight up REST API call to the compute endpoint 
anyway for the CLIs to still work, it seems easiest to just do that for 
now in both the nova-network and neutron cases. OSC CLI would make a 
request to the compute API on a microversion <= 2.43 and the compute 
service does the proxy work (albeit deprecated). In the OSC CLI, we 
could dump a deprecation warning if you're using these with nova-network 
since that is deprecated and the plan is in Rocky to drop support for 
nova-network altogether. Users of OSC could still be using newer 
versions of the client with older clouds that still run nova-network, 
but the deprecation timer would at least be set.


Are there other options here? Or some other precedent for a situation 
like this?


--

Thanks,

Matt

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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

[Matt Riedemann]

On 1/30/2018 9:01 AM, gordon chung wrote:

hi,

we've had an open item to consume versioned notifications in ceilometer.
the question that remains is: do all unversioned notifications have a
versioned version or are there still some items missing?

the blocker for us is that we can't consume both as then we'd end up
duplicating data but we also can't consume versioned notifications
exclusively or we'll miss data.

apologies, if this is captured somewhere, just figured this is easier.

cheers,



Gibi's burndown chart is here to see what's remaining:

http://burndown.peermore.com/nova-notification/

And this is the list of what's already done:

https://docs.openstack.org/nova/latest/reference/notifications.html#versioned-notification-samples

--

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][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Colleen Murphy]

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?

From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1] 
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[4] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html

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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

[Mathieu Gagné]

On Tue, Jan 30, 2018 at 10:19 AM, Matt Riedemann  wrote:
>
> Gibi's burndown chart is here to see what's remaining:
>
> http://burndown.peermore.com/nova-notification/
>
> And this is the list of what's already done:
>
> https://docs.openstack.org/nova/latest/reference/notifications.html#versioned-notification-samples
>

So I just discovered this documentation. It's awesome! Great job to
all the ones involved!
Now I wish we had the same in all projects. =)

--
Mathieu

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

Re: [openstack-dev] [requirement][cyborg]FFE - pyspdk requirement dependency

[Matthew Thode]

On 18-01-30 11:58:17, Thierry Carrez wrote:
> We We wrote:
> > The pyspdk is a important tool library [1] which  supports Cyborg SPDK
> > driver [2] to manage the backend SPDK-base app, so we need to upload
> > pyspdk into the pypi [3]  and then append 'pyspdk>=0.0.1’ item into
> > ‘OpenStack/Cyborg/requirements.txt’ , so that  SPDK driver can be built
> > correctly when zuul runs. However, It's not what we thought it would be,
> > if we want to  add the new requirements, we should get support from
> > upstream OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item.
> 
> Before we talk FFE, pyspdk looks a bit far away from being something
> OpenStack code can depend on. In particular:
> 
> - it's not clearly licensed under a supported license (no LICENSE file
> in the source code)
> - Missing metadata entries in setup.cfg means we are missing a lot of
> context information about this library
> 
> Those need to be fixed before we can even consider adding this library
> to global requirements...
> 

I agree.  Also, there's no mention of python3 or testing in the repo.
The licence looks like gplv3, which is fine for non-openstack code.
There's also no commit since the initial commit.

Unless I'm looking at the wrong repo, I'm going to say no to this FFE.
https://github.com/lschw/pyspdf

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Matthew Thode]

On 18-01-30 17:03:58, Masahito MUROI wrote:
> Hi requirements team,
> 
> This is a FFE request for adding python-blazarclient to
> global-requirements.txt.  Blazar team had release problems for updating the
> blazarclient to pypo.
> 
> Luckily, the problems are fixed and the client is published at pypi this
> morning.
> 
> 1. https://review.openstack.org/#/c/539126/
> 

LGTM, +2

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [tc] Technical Committee Status update, January 26th

[Matt Riedemann]

On 1/26/2018 10:26 AM, Thierry Carrez wrote:

== Rocky goals ==

We are in the final steps of selecting a set of community goals for
Rocky. We need wide community input on which goals are doable and make
the most sense! Please see the list of proposed goals and associated
champions:

* Storyboard Migration [3] (diablo_rojo)
* Remove mox [4] (chandankumar)
* Ensure pagination links [5] (mordred)
* Add Cold upgrades capabilities [6] (masayuki)
* Enable mutable configuration [7] (gcb)

[3]https://review.openstack.org/513875
[4]https://review.openstack.org/532361
[5]https://review.openstack.org/532627
[6]https://review.openstack.org/#/c/533544/
[7]https://review.openstack.org/534605

NB: mriedem suggested on the ML that we wait until the PTG in Dublin to
make the final call. It gives more time to carefully consider the goals,
but delays the start of the work and makes planning pre-PTG a bit more
difficult.


I just threw "Use keystoneauth1 Adapter for consistent inter-service 
configuration" into the etherpad:


https://etherpad.openstack.org/p/community-goals

Eric didn't think he'd have the bandwidth to champion this goal right 
now, but if someone wanted to pick it up I think it would be pretty 
straight-forward.


--

Thanks,

Matt

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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Jim Rollenhagen]

On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy 
wrote:

> At the last PTG we had some time on Monday and Tuesday for
> cross-project discussions related to baremetal and VM management. We
> don't currently have that on the schedule for this PTG. There is still
> some free time available that we can ask for[1]. Should we try to
> schedule some time for this?
>

I'd attend for the topics you list below, FWIW.


>
> From a keystone perspective, some things we'd like to talk about with
> the BM/VM teams are:
>
> - Unified limits[2]: we now have a basic REST API for registering
> limits in keystone. Next steps are building out libraries that can
> consume this API and calculate quota usage and limit allocation, and
> developing models for quotas in project hierarchies. Input from other
> projects is essential here.
> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
> problem, and we'd like to guide other projects through the migration.
> - Application credentials[4]: this main part of this work is largely
> done, next steps are implementing better access control for it, which
> is largely just a keystone team problem but we could also use this
> time for feedback on the implementation so far
>
> There's likely some non-keystone-related things that might be at home
> in a dedicated BM/VM room too. Do we want to have a dedicated day or
> two for these projects? Or perhaps not dedicated days, but
> planned-in-advance meeting time? Or should we wait and schedule it
> ad-hoc if we feel like we need it?
>

There's always plenty to discuss between nova and ironic, but we usually
just schedule those topics somewhat ad-hoc. Never opposed to some
dedicated time if folks will show up, though. :)

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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

[gordon chung]

On 2018-01-30 10:19 AM, Matt Riedemann wrote:
> Gibi's burndown chart is here to see what's remaining:
> 
> http://burndown.peermore.com/nova-notification/

this answer far exceeded my expectations :)

thanks!

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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

[Matt Riedemann]

On 1/30/2018 9:37 AM, Mathieu Gagné wrote:

So I just discovered this documentation. It's awesome! Great job to
all the ones involved!
Now I wish we had the same in all projects. =)


Maybe it's worth putting something into the community goals etherpad:

https://etherpad.openstack.org/p/community-goals

At this point, I'd say it's probably premature to push across all 
projects since we don't have another service consuming nova's versioned 
notifications yet. Searchlight was working on it, but then I think that 
got stalled. Maybe after the Telemetry team starts looking at it to see 
how things work for them from a consumer / client standpoint.


--

Thanks,

Matt

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

Re: [openstack-dev] [kolla] Policy regarding template customisation

[Joshua Harlow]

I'm ok with #2,

Though I would like to show an alternative that we have been 
experimenting with that avoids the whole needs for a globals.yml and 
such files in the first place (and feels more naturally inline with how 
ansible works IMHO).


So short explanation first; we have this yaml format that describes all 
of our clouds and there settings and such (and which servers belong in 
which cloud and so on and so forth). We have then setup a REST server 
(small gunicorn based one) that renders/serves this format into other 
formats.


One of those other formats is one that is compatible with ansibles 
concept of dynamic inventory [1] and that is the one we are trying to 
send into kolla-ansible to get it to configure all the things (via 
typical mechanisms such as hostvars and groupvars).


An example of this rendering:

https://gist.github.com/harlowja/9d7b57571a2290c315fc9a4bf2957dac (this 
is dynamically generated from the other format, which is git version 
controlled...).


The goal here is that we can just render all the needed variables and 
such for kolla-ansible (at a per-host basis if we have to) and avoid the 
need for having a special globals.yml (per-cloud/environment) and 
per-host special files in the first place.


Was this kind of approach ever thought of?

Perhaps I can go into more detail if it seems like one others may want 
to follow


[1]: http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html

Paul Bourke wrote:

Hi all,

I'd like to revisit our policy of not templating everything in
kolla-ansible's template files. This is a policy that was set in place
very early on in kolla-ansible's development, but I'm concerned we
haven't been very consistent with it. This leads to confusion for
contributors and operators - "should I template this and submit a patch,
or do I need to start using my own config files?".

The docs[0] are currently clear:

"The Kolla upstream community does not want to place key/value pairs in
the Ansible playbook configuration options that are not essential to
obtaining a functional deployment."

In practice though our templates contain many options that are not
necessary, and plenty of patches have merged that while very useful to
operators, are not necessary to an 'out of the box' deployment.

So I'd like us to revisit the questions:

1) Is kolla-ansible attempting to be a 'batteries included' tool, which
caters to operators via key/value config options?

2) Or, is it to be a solid reference implementation, where any degree of
customisation implies a clear 'bring your own configs' type policy.

If 1), then we should potentially:

* Update ours docs to remove the referenced paragraph
* Look at reorganising files like globals.yml into something more
maintainable.

If 2),

* We should make it clear to reviewers that patches templating options
that are non essential should not be accepted.
* Encourage patches to strip down existing config files to an absolute
minimum.
* Make this policy more clear in docs / templates to avoid frustration
on the part of operators.

Thoughts?

Thanks,
-Paul

[0]
https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization


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


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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

[McLellan, Steven]

On 1/30/18, 11:17 AM, "Matt Riedemann"  wrote:

On 1/30/2018 9:37 AM, Mathieu Gagné wrote:
> So I just discovered this documentation. It's awesome! Great job to
> all the ones involved!
> Now I wish we had the same in all projects. =)

Maybe it's worth putting something into the community goals etherpad:

https://etherpad.openstack.org/p/community-goals

At this point, I'd say it's probably premature to push across all 
projects since we don't have another service consuming nova's versioned 
notifications yet. Searchlight was working on it, but then I think that 
got stalled. Maybe after the Telemetry team starts looking at it to see 
how things work for them from a consumer / client standpoint.

-- 

It did stall in searchlight (partly through lack of interest and partly because 
it was tracking a moving target), but it was/is very close and in general they 
work fine. We didn't get to the point of supporting lots of different versions, 
though, and I was a bit worried about branching hell if ever different versions 
introduced non-additive changes. Patch is 
https://review.openstack.org/#/c/453352/ if anyone's interested (it's a little 
complicated because it supports versioned and unversioned).

Steve

__
OpenStack Development Mailing 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][ceilometer] versioned notifications coverage

[Matt Riedemann]

On 1/30/2018 11:17 AM, Matt Riedemann wrote:

Maybe it's worth putting something into the community goals etherpad:

https://etherpad.openstack.org/p/community-goals


I added the "Convert from legacy to versioned notifications" entry to 
keep the idea for the future.


--

Thanks,

Matt

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

Re: [openstack-dev] [requirement][cyborg]FFE - pyspdk requirement dependency

[We We]

> Hi,

> I have modified and resubmitted  pyspdk to the pypi. Please check it.

> Thx,

> Helloway

> 在 2018年1月30日，下午12:52，We We mailto:simple_...@163.com>> 
> 写道：
> 
> Hi,
> The pyspdk is a important tool library [1] which  supports Cyborg SPDK driver 
> [2] to manage the backend SPDK-base app, so we need to upload pyspdk into the 
> pypi [3]  and then append 'pyspdk>=0.0.1’ item into 
> ‘OpenStack/Cyborg/requirements.txt’ , so that  SPDK driver can be built 
> correctly when zuul runs. However, It's not what we thought it would be, if 
> we want to  add the new requirements, we should get support from upstream 
> OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item.
> 
> I'm sorry for propose the request so late. Please Please help.
> 
> 
> [1] https://review.gerrithub.io/#/c/379741/ 
> 
> [2] https://review.openstack.org/#/c/538164/11 
> 
> [3] https://pypi.python.org/pypi/pyspdk/0.0.1 
> 
> [4] https://github.com/openstack/requirements 
> 
> 
> 
> Regards,
> Helloway
> 

__
OpenStack Development Mailing 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 18-05

[Chris Dent]

Linkified: https://anticdent.org/tc-report-18-05.html

Your author has been rather ill, so this week's TC Report will be a
bit abridged and mostly links. I'll try to return with more robust
commentary next week.

## RDO Test Days

dmsimard showed up in `#openstack-tc` channel to [provide some
details](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-24.log.html#t2018-01-24T16:32:11)
on forthcoming RDO Test Days.

## More on the Goals

[Conversations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-25.log.html#t2018-01-25T15:48:50)
[continue](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:03:31)
about choosing OpenStack goals. One issue raised is whether we have
sufficient insight into how people are really using and deploying
OpenStack to be able to prioritize goals.

## Project Inception

smcginnis [pointed
out](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T17:25:25)
a governance discussion in the CNCF about [project
inception](https://github.com/cncf/toc/issues/85) that he thought
might be of interest to the TC. Discussion ensued around how the
OpenStack ecosystem differs from the CNCF and as a result the need, or
lack thereof, for help to bootstrap projects is different.

## PTG Scheduling

The PTG is coming and with it
[discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:22:44)
of how best to make room for all the conversations that need to
happen, including things that come up at the last minute. New this
time will be a more formal structuring of 
[post-lunch presentations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:38:17)

to do theme-setting and information sharing.

## Board Meeting at the PTG

Monday there was
[discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T16:06:18)
about the OpenStack Foundation [Board
Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/26Feb2018BoardMeeting)
overlapping with the first day of the PTG. This follows [discussion in
email](http://lists.openstack.org/pipermail/foundation/2018-January/002558.html).

## Today's Board Meeting

I attended [today's Board 
Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting)
but it seems that according to the [transparency
policy](http://www.openstack.org/legal/transparency-policy/) I can't
comment:


 No commenting on Board meeting contents and decisions until
 Executive Director publishes a meeting summary


That doesn't sound like transparency to me, but I assume there must be
reasons.

--
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] [kolla] Policy regarding template customisation

[Michał Jastrzębski]

On 30 January 2018 at 09:34, Joshua Harlow  wrote:
> I'm ok with #2,
>
> Though I would like to show an alternative that we have been experimenting
> with that avoids the whole needs for a globals.yml and such files in the
> first place (and feels more naturally inline with how ansible works IMHO).
>
> So short explanation first; we have this yaml format that describes all of
> our clouds and there settings and such (and which servers belong in which
> cloud and so on and so forth). We have then setup a REST server (small
> gunicorn based one) that renders/serves this format into other formats.
>
> One of those other formats is one that is compatible with ansibles concept
> of dynamic inventory [1] and that is the one we are trying to send into
> kolla-ansible to get it to configure all the things (via typical mechanisms
> such as hostvars and groupvars).
>
> An example of this rendering:
>
> https://gist.github.com/harlowja/9d7b57571a2290c315fc9a4bf2957dac (this is
> dynamically generated from the other format, which is git version
> controlled...).
>
> The goal here is that we can just render all the needed variables and such
> for kolla-ansible (at a per-host basis if we have to) and avoid the need for
> having a special globals.yml (per-cloud/environment) and per-host special
> files in the first place.
>
> Was this kind of approach ever thought of?

Well that totally works:)
I routinely use inventory to override parts of globals (different
iface per node). You could have [all:vars] section in inventory and
set every variable usually set in globals there. However I think issue
here is about files in /etc/kolla/config - so config overrides.

I think one potential solution would be to have some sort of ansible
task that would translate ansible vars to ini format and lay down
files in /etc/kolla/config, but I think that's beyond scope of
Kolla-Ansible.

>
> Perhaps I can go into more detail if it seems like one others may want to
> follow
>
> [1]: http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html
>
>
> Paul Bourke wrote:
>>
>> Hi all,
>>
>> I'd like to revisit our policy of not templating everything in
>> kolla-ansible's template files. This is a policy that was set in place
>> very early on in kolla-ansible's development, but I'm concerned we
>> haven't been very consistent with it. This leads to confusion for
>> contributors and operators - "should I template this and submit a patch,
>> or do I need to start using my own config files?".
>>
>> The docs[0] are currently clear:
>>
>> "The Kolla upstream community does not want to place key/value pairs in
>> the Ansible playbook configuration options that are not essential to
>> obtaining a functional deployment."
>>
>> In practice though our templates contain many options that are not
>> necessary, and plenty of patches have merged that while very useful to
>> operators, are not necessary to an 'out of the box' deployment.
>>
>> So I'd like us to revisit the questions:
>>
>> 1) Is kolla-ansible attempting to be a 'batteries included' tool, which
>> caters to operators via key/value config options?
>>
>> 2) Or, is it to be a solid reference implementation, where any degree of
>> customisation implies a clear 'bring your own configs' type policy.
>>
>> If 1), then we should potentially:
>>
>> * Update ours docs to remove the referenced paragraph
>> * Look at reorganising files like globals.yml into something more
>> maintainable.
>>
>> If 2),
>>
>> * We should make it clear to reviewers that patches templating options
>> that are non essential should not be accepted.
>> * Encourage patches to strip down existing config files to an absolute
>> minimum.
>> * Make this policy more clear in docs / templates to avoid frustration
>> on the part of operators.
>>
>> Thoughts?
>>
>> Thanks,
>> -Paul
>>
>> [0]
>>
>> https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization
>>
>>
>> __
>> OpenStack Development Mailing 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] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Pavlo Shchelokovskyy]

+1 to Jim,

I'm specifically interested in app creds and RBAC as I'd like to find a way
to pass some of API access creds to the ironic deploy ramdisk, and it seems
one of those could help. Let's discuss :)

Cheers,

On Tue, Jan 30, 2018 at 6:03 PM, Jim Rollenhagen 
wrote:

> On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy 
> wrote:
>
>> At the last PTG we had some time on Monday and Tuesday for
>> cross-project discussions related to baremetal and VM management. We
>> don't currently have that on the schedule for this PTG. There is still
>> some free time available that we can ask for[1]. Should we try to
>> schedule some time for this?
>>
>
> I'd attend for the topics you list below, FWIW.
>
>
>>
>> From a keystone perspective, some things we'd like to talk about with
>> the BM/VM teams are:
>>
>> - Unified limits[2]: we now have a basic REST API for registering
>> limits in keystone. Next steps are building out libraries that can
>> consume this API and calculate quota usage and limit allocation, and
>> developing models for quotas in project hierarchies. Input from other
>> projects is essential here.
>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>> problem, and we'd like to guide other projects through the migration.
>> - Application credentials[4]: this main part of this work is largely
>> done, next steps are implementing better access control for it, which
>> is largely just a keystone team problem but we could also use this
>> time for feedback on the implementation so far
>>
>> There's likely some non-keystone-related things that might be at home
>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>> two for these projects? Or perhaps not dedicated days, but
>> planned-in-advance meeting time? Or should we wait and schedule it
>> ad-hoc if we feel like we need it?
>>
>
> There's always plenty to discuss between nova and ironic, but we usually
> just schedule those topics somewhat ad-hoc. Never opposed to some
> dedicated time if folks will show up, though. :)
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirement][cyborg]FFE - pyspdk requirement dependency

[Doug Hellmann]

Excerpts from We We's message of 2018-01-31 01:54:04 +0800:
> > Hi,
> 
> > I have modified and resubmitted  pyspdk to the pypi. Please check it.
> 
> > Thx,
> 
> > Helloway

Is there a public source repository for the library somewhere?

> 
> > 在 2018年1月30日，下午12:52，We We mailto:simple_...@163.com>> 
> > 写道：
> > 
> > Hi,
> > The pyspdk is a important tool library [1] which  supports Cyborg SPDK 
> > driver [2] to manage the backend SPDK-base app, so we need to upload pyspdk 
> > into the pypi [3]  and then append 'pyspdk>=0.0.1’ item into 
> > ‘OpenStack/Cyborg/requirements.txt’ , so that  SPDK driver can be built 
> > correctly when zuul runs. However, It's not what we thought it would be, if 
> > we want to  add the new requirements, we should get support from upstream 
> > OpenStack/requirements [4] to append 'pyspdk>=0.0.1’ item.
> > 
> > I'm sorry for propose the request so late. Please Please help.
> > 
> > 
> > [1] https://review.gerrithub.io/#/c/379741/ 
> > 
> > [2] https://review.openstack.org/#/c/538164/11 
> > 
> > [3] https://pypi.python.org/pypi/pyspdk/0.0.1 
> > 
> > [4] https://github.com/openstack/requirements 
> > 
> > 
> > 
> > Regards,
> > Helloway
> > 

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

Re: [openstack-dev] [tc] [all] TC Report 18-05

[Graham Hayes]

On 30/01/18 18:34, Chris Dent wrote:

> 
> ## Today's Board Meeting
> 
> I attended [today's Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting)
> 
> but it seems that according to the [transparency
> policy](http://www.openstack.org/legal/transparency-policy/) I can't
> comment:
> 
>>  No commenting on Board meeting contents and decisions until
>>  Executive Director publishes a meeting summary
> 
> That doesn't sound like transparency to me, but I assume there must be
> reasons.

I was under the assumption that this only applied to board members, but
I am open to correction.

Can someone on legal-discuss clarify?

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



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

[Graham Hayes]

On 30/01/18 18:34, Chris Dent wrote:
> 
> Linkified: https://anticdent.org/tc-report-18-05.html
> 
> Your author has been rather ill, so this week's TC Report will be a
> bit abridged and mostly links. I'll try to return with more robust
> commentary next week.
> 
> ## RDO Test Days
> 
> dmsimard showed up in `#openstack-tc` channel to [provide some
> details](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-24.log.html#t2018-01-24T16:32:11)
> 
> on forthcoming RDO Test Days.
> 
> ## More on the Goals
> 
> [Conversations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-25.log.html#t2018-01-25T15:48:50)
> 
> [continue](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:03:31)
> 
> about choosing OpenStack goals. One issue raised is whether we have
> sufficient insight into how people are really using and deploying
> OpenStack to be able to prioritize goals.
> 
> ## Project Inception
> 
> smcginnis [pointed
> out](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T17:25:25)
> 
> a governance discussion in the CNCF about [project
> inception](https://github.com/cncf/toc/issues/85) that he thought
> might be of interest to the TC. Discussion ensued around how the
> OpenStack ecosystem differs from the CNCF and as a result the need, or
> lack thereof, for help to bootstrap projects is different.
> 
> ## PTG Scheduling
> 
> The PTG is coming and with it
> [discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:22:44)
> 
> of how best to make room for all the conversations that need to
> happen, including things that come up at the last minute. New this
> time will be a more formal structuring of [post-lunch
> presentations](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-30.log.html#t2018-01-30T09:38:17)
> 
> to do theme-setting and information sharing.
> 
> ## Board Meeting at the PTG
> 
> Monday there was
> [discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T16:06:18)
> 
> about the OpenStack Foundation [Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/26Feb2018BoardMeeting)
> 
> overlapping with the first day of the PTG. This follows [discussion in
> email](http://lists.openstack.org/pipermail/foundation/2018-January/002558.html).

There was also a suggestion [2] that the community / TC put an item on
the F2F meeting agenda, with an associated etherpad [2]:

1-
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-29.log.html#t2018-01-29T16:34:43
2 - https://etherpad.openstack.org/p/tc-message-to-board-dublin-2018

> 
> ## Today's Board Meeting
> 
> I attended [today's Board
> Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting)
> 
> but it seems that according to the [transparency
> policy](http://www.openstack.org/legal/transparency-policy/) I can't
> comment:
> 
>>  No commenting on Board meeting contents and decisions until
>>  Executive Director publishes a meeting summary
> 
> That doesn't sound like transparency to me, but I assume there must be
> reasons.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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] [nova][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

[Chris Friesen]

On 01/30/2018 09:15 AM, Matt Riedemann wrote:

The 10.0.0 release of python-novaclient dropped some deprecated CLIs and python
API bindings for the server actions to add/remove fixed and floating IPs:

https://docs.openstack.org/releasenotes/python-novaclient/queens.html#id2

python-openstackclient was using some of those python API bindings from
novaclient which now no longer work:

https://bugs.launchpad.net/python-openstackclient/+bug/1745795




Is there a plan going forward to ensure that python-novaclient and OSC are on 
the same page as far as deprecating CLIs and API bindings?


Chris

__
OpenStack Development Mailing 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] [legal-discuss] [tc] [all] TC Report 18-05

[Monty Taylor]

On 01/30/2018 01:05 PM, Monty Taylor wrote:

On 01/30/2018 12:53 PM, Graham Hayes wrote:

On 30/01/18 18:34, Chris Dent wrote:



## Today's Board Meeting

I attended [today's Board
Meeting](https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting) 



but it seems that according to the [transparency
policy](http://www.openstack.org/legal/transparency-policy/) I can't
comment:


  No commenting on Board meeting contents and decisions until
  Executive Director publishes a meeting summary


That doesn't sound like transparency to me, but I assume there must be
reasons.


I was under the assumption that this only applied to board members, but
I am open to correction.

Can someone on legal-discuss clarify?


That is correct. As officers information published from Board members 
could be construed as "official" communication. The approach we've taken 
on this topic is that Board members refrain from publishing their 
thoughts/feedback/take/opinion/summary of a meeting until after Jonathan 
has published an 'official' summary of the meeting, at which point, 
since there is an official document we're free to comment as we desire.


There is nothing preventing anyone who is not a board member from 
publishing a summary or thoughts or live-tweeting the whole thing.


markmc has historically written excellent summaries and has posted them 
as soon as Jonathan's have gone out.


Gah. Didn't reply originally to openstack-dev.

Monty

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

[openstack-dev] [I18n][PTL] PTL nomination for I18n

[Frank Kloeker]

This is my announcement for re-candidacy as I18n PTL in Rocky Cycle.

The time from the last cycle passed very fast. I had to manage all the
things that a PTL expects. But we documented everything very well and I
always had the full support of the team. I asked the team and it would
continue to support me, which is why I take the chance again.
This is the point to say thank you to all that we have achieved many
things and we are a great community!

Now it's time to finish things:

1. Zanata upgrade. We are in the middle of the upgrade process. The dev
server is sucessfull upgraded and the new Zanata versions fits all our
requirements to automate things more and more.
Now we are in the hot release phase and when it's over, the live
upgrade can start.

2. Translation check site. A little bit out of scope in Queens release
because of lack of resources. We'll try this again in Rocky.

3. Aquire more people to the team. That will be the main part of my work
as PTL in Rocky. We've won 3 new language teams in the last cycle and
can Openstack serve in Indian, Turkish and Esperanto. There is even more
potential for strengthening existing teams or creating new ones.
For this we have great OpenStack events in Europe this year, at least
the Fall Summit in Berlin. We plan workshops and presentations.

The work of the translation team is also becoming more colorful. We have
project documentation translation in the order books, translation user
survey and white papers for working groups.

We are well prepared, but we also look to the future, for example how
AI-programming can support us in the translation work.

If the plan suits you, I look forward to your vote.

Frank

Email: eu...@arcor.de
IRC: eumel8
Twitter: eumel_8

OpenStack Profile:
https://www.openstack.org/community/members/profile/45058/frank-kloeker

__
OpenStack Development Mailing 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] [kolla] Policy regarding template customisation

[Joshua Harlow]

Yup, I am hoping to avoid all of these kinds of customizations if 
possible... But if we have to we'll probably have to make something like 
that.


Or we'll just have to render out files for each host and serve it from 
the same REST endpoint, ya da ya da...


-Josh

Michał Jastrzębski wrote:

However I think issue
here is about files in /etc/kolla/config - so config overrides.

I think one potential solution would be to have some sort of ansible
task that would translate ansible vars to ini format and lay down
files in /etc/kolla/config, but I think that's beyond scope of
Kolla-Ansible.


__
OpenStack Development Mailing 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][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

[Matt Riedemann]

On 1/30/2018 1:04 PM, Chris Friesen wrote:
Is there a plan going forward to ensure that python-novaclient and OSC 
are on the same page as far as deprecating CLIs and API bindings?


There is no official plan, no. The 10.0.0 novaclient release came out 
late. If there was more lead time, or if I would have thought of it, we 
could have done an audit on what other things within OpenStack were 
using the deprecated CLIs/python API bindings and cleaned those up 
first. But that didn't happen.


At this point, novaclient 10.0.0 probably won't get into 
upper-constraints for Queens:


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

And I'm OK with that, nothing in Queens requires >=10.0.0. We can clean 
things up in Rocky.


--

Thanks,

Matt

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

Re: [openstack-dev] [legal-discuss] [tc] [all] TC Report 18-05

[Chris Dent]

On Tue, 30 Jan 2018, Monty Taylor wrote:

On 01/30/2018 01:05 PM, Monty Taylor wrote:
That is correct. As officers information published from Board members could 
be construed as "official" communication. The approach we've taken on this 
topic is that Board members refrain from publishing their 
thoughts/feedback/take/opinion/summary of a meeting until after Jonathan 
has published an 'official' summary of the meeting, at which point, since 
there is an official document we're free to comment as we desire.


Thanks, I assumed/hoped it was something like that but the blurb on
the wiki page[1] was ambiguous and I thought it better to point out the
ambiguity and see where that took us.

Somewhere good. So that's nice.

[1] https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2018BoardMeeting

--
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] [manila][ptl] Stepping down as Manila PTL

[Ben Swartzlander]

After leading the Manila project for 5 years, it's time for me to step 
down. I feel incredibly proud of the project and the team that's worked 
to bring Manila from an idea at the Folsom design summit to the 
successful project is it today.


Manila has reached a point of stability where I feel like it doesn't 
need me to spend all my time pushing it forward, and I can change my 
role to contributor and let someone else lead.


I'm thankful for all the support the project has received from 
contributors and from the larger OpenStack community.


-Ben Swartzlander

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

[openstack-dev] [FEMDC] Wed. 31 Jan - IRC Meeting 15:00 UTC

[avankemp]

Dear all, 

A gentle reminder for our tomorrow meeting at 15:00 UTC 

A draft of the agenda is available at line 141, you are very welcome to add any 
item.
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018 


Best,

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

[openstack-dev] [os-upstream-institute][ptg] Schedule Upstream Institute working sessions for the PTG

[Ildiko Vancsa]

Hi Training Team,

Good news, we are planning to have working sessions at the PTG! :)

The challenging part is that all of us are involved in several activities which 
makes it difficult to schedule these. We are looking into co-locating some 
parts of the discussions with related sessions, like First Contact SIG and 
Contributor Portal discussions.

On top of these we need to get rolling on re-designing the training including 
the flow and the exercises, which requires its own set of work sessions. In 
order to get most of the team in the same room I created a Doodle poll[1] 
capturing mornings and afternoons to find the best options. Please mark ALL the 
time intervals that might work for you!

We will also try to make it as a virtual working session with remote 
participation so please vote even if you cannot make it to the PTG in person.

Please let me know if you have any questions.

Thanks,
Ildikó
(IRC: ildikov)


[1] https://doodle.com/poll/y4cmhe2ur2vqkhae
__
OpenStack Development Mailing 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] [heat] [Release-job-failures] Tag of openstack/python-heatclient failed

[Sean McGinnis]

We had a release job failure for python-heatclient. See below for details.

This appears to be from the fact that this repo is configured with the
release-notes-job [1], and it does have a couple of notes, but the release note
infrastructure has not been set up for the repo.

This is safe to ignore - there just won't be any published release notes for
the project. But either the release note set up needs to be completed in the
repo, or the release-notes-jobs template needs to be removed for the repo so we
don't get errors going forward.

If set up is completed, the next release will get the release notes published.

[1] 
https://github.com/openstack-infra/project-config/blob/2c4c10e7f2c4b8fbef77b1859864c59f4909f0f2/zuul.d/projects.yaml#L13592

- Forwarded message from z...@openstack.org -

Date: Tue, 30 Jan 2018 22:29:48 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Tag of openstack/python-heatclient failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- publish-openstack-releasenotes 
http://logs.openstack.org/1b/1b86b91e2bc0e6dc3556ee7153e59e1a6ec6e655/tag/publish-openstack-releasenotes/606c36a/
 : FAILURE in 4m 22s

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

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

[openstack-dev] [blazar] [Release-job-failures] Release of openstack/blazar-nova failed

[Sean McGinnis]

There was a failure with releasing blazar-nova. It would appear this has a
dependency on nova, but nova is not in the required-projects. This will need to
be corrected before we can complete the blazar-nova release.

http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/job-output.txt.gz#_2018-01-30_22_06_50_103665

- Forwarded message from z...@openstack.org -

Date: Tue, 30 Jan 2018 22:11:42 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/blazar-nova failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- release-openstack-python 
http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/
 : FAILURE in 3m 45s
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

__
OpenStack Development Mailing 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] [heat] [Release-job-failures] Tag of openstack/heat-agents failed

[Sean McGinnis]

We have another failure. Looks to be the same as the last one, caused by the
release notes job being defined for the repo but the release note setup not
being complete.


- Forwarded message from z...@openstack.org -

Date: Tue, 30 Jan 2018 22:43:14 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Tag of openstack/heat-agents failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- publish-openstack-releasenotes 
http://logs.openstack.org/26/267694b7d3537942ab270bc7e91df58a7b7a1073/tag/publish-openstack-releasenotes/72ac779/
 : FAILURE in 5m 06s

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

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

Re: [openstack-dev] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Dirk Müller]

2018-01-30 16:53 GMT+01:00 Matthew Thode :

> LGTM, +2

+2

__
OpenStack Development Mailing 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] Race in FixedIP.associate_pool

[melanie witt]

> On Jan 29, 2018, at 16:45, Arun SAG  wrote:
> 
> If anyone is running into db race while running database in
> master-slave mode with async replication, The bug has been identified
> and getting fixed  here
> https://bugs.launchpad.net/oslo.db/+bug/1746116

Thanks for your persistence in tracking down the problem and raising the bug. 
If you get a chance, do please test the proposed patch in your environment to 
help ensure there aren’t any loose ends left.

Once the fix is merged, I think we should propose backports to stable/pike and 
stable/ocata, do .z releases for them, and bump oslo.db in 
upper-constraints.txt in the openstack/requirements repo for the stable/pike 
and stable/ocata branches. That way, operators running from stable can get the 
fix by upgrading their oslo.db packages to those .z releases.

-melanie
__
OpenStack Development Mailing 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] The Weekly Owl - 7th Edition

[Emilien Macchi]

Note: this is the seventh edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126509.html

+-+
| General announcements |
+-+

+--> Queens milestone 3 was released! We fixed more bugs than any other
milestone in the past!
+--> Next release will be Queens RC1, target is in ~1 month.
+--> Focus is on finishing the blueprints that have granted FFE;
High/Critical bugs; CI stabilization; Rocky planning.

+--+
| Continuous Integration |
+--+

+--> TripleO CI squad is proud to announce a new dashboard to track CI
metrics: https://review.rdoproject.org/grafana/dashboard/db/tripleo-ci
+--> Rover is John and ruck is Wes. Please let them know any new CI issue.
+--> Master promotion is 6 days, Pike is 24 days and Ocata is 2 days.
+--> Gate is currently in bad shape (a lot of resets), we're working on it.
Please help us by staying tuned in case we ask to not 'recheck'.
+--> We agreed that once OVB jobs running in RDO cloud become more stable,
they'll vote in check (as third party).
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and
https://goo.gl/D4WuBP

+-+
| Upgrades |
+-+

+--> New format for weekly meetings, checkout
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126611.html
!
+--> Reviews are still needed on FFU, Queens upgrade workflow and
undercloud backup.
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
and https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting

+---+
| Containers |
+---+

+--> Containerized undercloud: good discussions and progress on
https://review.openstack.org/#/c/517444/
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| Integration |
+--+

+--> The squad is planning Rocky and also talking about testing
ceph-ansible with tripleo!
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> CI jobs were optimized for stable branches
+--> Team is planning work in Rocky
+--> Good progress on Roles management
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> The squad needs review, please check the etherpad.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> Routed networks support still ongoing.
+--> Octavia work is mostly done, fixing a small issues for Queens.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+-+
| Owl facts |
+-+

The Minahassa Masked Owl is a medium-sized owl with short rounded wings and
no ear-tufts. It is also known as the Minahassa Barn Owl or the Sulawesi
Golden Owl.
Voice: A screech similar to other Barn and Masked Owls. (RHIIIK RHIIK -
does it sound real?)
(source: https://www.owlpages.com/owls/species.php?s=150)

Stay tuned!
--
Your fellow reporter, Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][ironic] Tagging newton EOL

[Tony Breeds]

Hi All,
When we tagged newton EOL in October there were in-flight reviews
for nova and ironic that needed to land before we could EOL them.  That
work completed but I dropped the ball.  So can we tag those last 2
repos?

As in October a member of the infra team needs to do this *or* I can
be added to Project Bootstrappers[1] for long enough to do this.

# EOL repos belonging to ironic
eol_branch.sh -- stable/newton newton-eol openstack/ironic
# EOL repos belonging to nova
eol_branch.sh -- stable/newton newton-eol openstack/nova

Yours Tony.

[1] https://review.openstack.org/#/admin/groups/26,members


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] [glance] Q-3 milestone released

[Brian Rosmaita]

Glance 16.0.0.0b3 was released today,  The tag was created at this commit:
http://git.openstack.org/cgit/openstack/glance/commit/?id=631add1ba849eac67ecb36ea4c90b57a300a96fa
which is dated Thu, 18 Jan 2018 12:09:11 +

As you'll notice, that was about 2 weeks ago.  Which prompts the
question, why did we wait so long to release it.

Q: Why that commit?
A: It's the last commit when the glance functional gates jobs were
still working.

Q: Why didn't we release it 2 weeks ago?
A: The Q-3 release marks the feature freeze.  Any code committed after
that point should be either a release-critical bug or something with a
Feature Freeze Exception.  So you really don't want to release Q-3
early.

Q: What's the deal with the glance functional gate jobs?
A: There are two patches fixing them, but they have to go through the
'integrated' queue before they can merge, and we've had some bad luck
over the past few days ... they've made it to the top of the queue to
be processed when something bad happened and they had to start over.
They're being processed again right now (keep your fingers crossed).

Q: What about my commits that show up after
631add1ba849eac67ecb36ea4c90b57a300a96fa?
A: I will be sending out FFEs or marking the bugs for RC1, as appropriate.

Glance cores, please do not merge any patches until after
https://review.openstack.org/#/c/536630/ has merged.


thanks,
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][ceilometer] versioned notifications coverage

[Hanxi Liu]

On Wed, Jan 31, 2018 at 1:17 AM, Matt Riedemann  wrote:

> On 1/30/2018 9:37 AM, Mathieu Gagné wrote:
>
>> So I just discovered this documentation. It's awesome! Great job to
>> all the ones involved!
>> Now I wish we had the same in all projects. =)
>>
>
> Maybe it's worth putting something into the community goals etherpad:
>
> https://etherpad.openstack.org/p/community-goals
>
> At this point, I'd say it's probably premature to push across all projects
> since we don't have another service consuming nova's versioned
> notifications yet. Searchlight was working on it, but then I think that got
> stalled. Maybe after the Telemetry team starts looking at it to see how
> things work for them from a consumer / client standpoint.


It's so glad that Ceilometer is the first consumer of versioned
notifications.  Can I understand it as a trend that versioned notifications
will replace unversioned notifications even though versioned notifications
may have the only consumer for long time?
You know Ceilometer consume unversioned notifications for now. So should we
replace unversioned with versioned one by one according to the link[1]
because we can't consume both as then we'd end up duplicating data? It may
result in data lost with thoroughly transformation.

[1]  http://burndown.peermore.com/nova-notification/


--

Cheers,

Hanxi Liu (IRC: lhx_)

__
> OpenStack Development Mailing 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] [all][Kingbird]Multi-Region Orchestrator

[Goutham Pratapa]

*Kingbird (The Multi Region orchestrator):*

We are proud to announce kingbird is not only a centralized quota and
resource-manager but also a  Multi-region Orchestrator.



*Use-cases covered:*- Admin can synchronize and periodically balance quotas
across regions and can have a global view of quotas of all the tenants
across regions.
- A user can sync a resource or a group of resources from one region to
other in a single go
 A user can sync multiple key-pairs, images, and flavors from one region to
other, ( Flavor can be synced only by admin)

- A user must have complete tempest test-coverage for all the
scenarios/services rendered by kingbird.

- Horizon plugin so that user can access/view global limits.

* Our Road-map:*

-- Automation scripts for kingbird in
-ansible,
-salt
-puppet.
-- Add SSL support to kingbird
-- Resource management in Kingbird-dashboard.
-- Kingbird in a docker
-- Add Kingbird into Kolla.

We are looking out for* contributors and ideas* which can enhance Kingbird
and make kingbird a one-stop solution for all multi-region problems




*Stable Branches :*


*Kingbird-server: https://github.com/openstack/kingbird/tree/stable/queens
*

*Python-Kingbird-client (0.2.1):
https://github.com/openstack/python-kingbirdclient/tree/0.2.1
*

I would like to Thank all the people who have helped us in achieving this
milestone and guided us all throughout this Journey :)

Thanks
Goutham Pratapa
PTL
OpenStack-Kingbird.
__
OpenStack Development Mailing 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] [I18n][PTL] PTL nomination for I18n

[Will Zhou]

+1

Frank Kloeker 于2018年1月31日周三 上午3:08写道：

> This is my announcement for re-candidacy as I18n PTL in Rocky Cycle.
>
> The time from the last cycle passed very fast. I had to manage all the
> things that a PTL expects. But we documented everything very well and I
> always had the full support of the team. I asked the team and it would
> continue to support me, which is why I take the chance again.
> This is the point to say thank you to all that we have achieved many
> things and we are a great community!
>
> Now it's time to finish things:
>
> 1. Zanata upgrade. We are in the middle of the upgrade process. The dev
> server is sucessfull upgraded and the new Zanata versions fits all our
> requirements to automate things more and more.
> Now we are in the hot release phase and when it's over, the live
> upgrade can start.
>
> 2. Translation check site. A little bit out of scope in Queens release
> because of lack of resources. We'll try this again in Rocky.
>
> 3. Aquire more people to the team. That will be the main part of my work
> as PTL in Rocky. We've won 3 new language teams in the last cycle and
> can Openstack serve in Indian, Turkish and Esperanto. There is even more
> potential for strengthening existing teams or creating new ones.
> For this we have great OpenStack events in Europe this year, at least
> the Fall Summit in Berlin. We plan workshops and presentations.
>
> The work of the translation team is also becoming more colorful. We have
> project documentation translation in the order books, translation user
> survey and white papers for working groups.
>
> We are well prepared, but we also look to the future, for example how
> AI-programming can support us in the translation work.
>
> If the plan suits you, I look forward to your vote.
>
> Frank
>
> Email: eu...@arcor.de
> IRC: eumel8
> Twitter: eumel_8
>
> OpenStack Profile:
> https://www.openstack.org/community/members/profile/45058/frank-kloeker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev