[openstack-dev] [nova][cinder] Questions about truncked disk serial number

[Zhenyu Zheng]

Hi,

I meet a problem like this recently:

When attaching a volume to an instance, in the xml, the disk is described
as:

[image: Inline image 1]
where the serial number here is the volume uuid in Cinder. While inside the
vm:
in /dev/disk/by-id, there is a link for /vdb with the name of
"virtio"+truncated serial number:

[image: Inline image 2]

and according to
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/ch16s03.html

it seems that we will use this mount the volume.

The truncate seems to be happen in here [1][2] which is 20 digits.

*My question here is: *if two volume have the identical first 20 digits in
their uuids, it seems that the latter attached one will overwrite the first
one's link:
[image: Inline image 3]
(the above graph is snapshot for an volume backed instance, the
virtio-15ex was point to vda before, the by-path seems correct though)

It is rare to have the identical first 20 digits of two uuids, but
possible, so what was the consideration of truncate only 20 digits of the
volume uuid instead of use full 32?

BR,

Kevin Zheng
__
OpenStack Development Mailing 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][cinder] Questions about truncked disk serial number

[Zhenyu Zheng]

Ops, forgot references:
[1]
https://github.com/torvalds/linux/blob/1cc15701cd89b0ce695bbc5cff3a2bf3e2efd25f/include/uapi/linux/virtio_blk.h#L54
[2]
https://github.com/torvalds/linux/blob/1cc15701cd89b0ce695bbc5cff3a2bf3e2efd25f/drivers/block/virtio_blk.c#L363

On Tue, Jan 16, 2018 at 2:35 PM, Zhenyu Zheng 
wrote:

> Hi,
>
> I meet a problem like this recently:
>
> When attaching a volume to an instance, in the xml, the disk is described
> as:
>
> [image: Inline image 1]
> where the serial number here is the volume uuid in Cinder. While inside
> the vm:
> in /dev/disk/by-id, there is a link for /vdb with the name of
> "virtio"+truncated serial number:
>
> [image: Inline image 2]
>
> and according to https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux_OpenStack_Platform/2/html/Getting_
> Started_Guide/ch16s03.html
>
> it seems that we will use this mount the volume.
>
> The truncate seems to be happen in here [1][2] which is 20 digits.
>
> *My question here is: *if two volume have the identical first 20 digits
> in their uuids, it seems that the latter attached one will overwrite the
> first one's link:
> [image: Inline image 3]
> (the above graph is snapshot for an volume backed instance, the
> virtio-15ex was point to vda before, the by-path seems correct though)
>
> It is rare to have the identical first 20 digits of two uuids, but
> possible, so what was the consideration of truncate only 20 digits of the
> volume uuid instead of use full 32?
>
> BR,
>
> Kevin Zheng
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Adding Adriano Petrich to the core team

[Renat Akhmerov]

Adriano, you now have +2 vote and can approve patches :) Welcome!

Thanks

Renat Akhmerov
@Nokia

On 16 Jan 2018, 05:03 +0700, Lingxian Kong , wrote:
> welcome to the team, Adriano!
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> > On Mon, Jan 15, 2018 at 10:11 PM, Renat Akhmerov  
> > wrote:
> > > Hi,
> > >
> > > I’d like to promote Adriano Petrich to the Mistral core team. Adriano has 
> > > shown the good review rate and quality at least over the last two cycles 
> > > and implemented several important features (including new useful 
> > > YAQL/JINJA functions).
> > >
> > > Please vote whether you agree to add Adriano to the core team.
> > >
> > > Adriano’s statistics: 
> > > http://stackalytics.com/?module=mistral-group&release=queens&user_id=apetrich
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > >
> > > __
> > > OpenStack Development Mailing 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] [mistral] Adding Adriano Petrich to the core team

[Lingxian Kong]

welcome to the team, Adriano!


Cheers,
Lingxian Kong (Larry)

On Mon, Jan 15, 2018 at 10:11 PM, Renat Akhmerov 
wrote:

> Hi,
>
> I’d like to promote Adriano Petrich to the Mistral core team. Adriano has
> shown the good review rate and quality at least over the last two cycles
> and implemented several important features (including new useful YAQL/JINJA
> functions).
>
> Please vote whether you agree to add Adriano to the core team.
>
> Adriano’s statistics: http://stackalytics.com/?module=
> mistral-group&release=queens&user_id=apetrich
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing 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] Stepping down from Keystone core

[Lance Bragstad]

Boris,

Thank you for all the contributions you've made to the project. I always
found your reviews extremely thorough and they certainly improved the
quality of our code. I'm sad to see you go, but I'm relieved to know
that you're not completely leaving us :)

This goes without being said, but should you find yourself looking to
get involved in keystone again, we can certainly expedite your path to core.

Thanks again, Boris


On 01/15/2018 02:47 PM, Boris Bobrov wrote:
> Hey!
>
> I don't work on Keystone as much as I used to any more, so i'm
> stepping down from core reviewers.
>
> Don't expect to get rid of me though. I still work on OpenStack-related
> stuff and i will annoy you all in #openstack-keystone and in other IRC
> channels.
>
> __
> OpenStack Development Mailing 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] [keystone] Stepping down from Keystone core

[Boris Bobrov]

Hey!

I don't work on Keystone as much as I used to any more, so i'm
stepping down from core reviewers.

Don't expect to get rid of me though. I still work on OpenStack-related
stuff and i will annoy you all in #openstack-keystone and in other IRC
channels.

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

Re: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks kuryr-kubernetes

[mdulko]

On Mon, 2018-01-15 at 17:21 +, Mooney, Sean K wrote:
> > -Original Message-
> > From: mdu...@redhat.com [mailto:mdu...@redhat.com]
> > Sent: Monday, January 15, 2018 4:46 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks
> > kuryr-kubernetes
> > 
> > Hi,
> > 
> > os-vif commit [1] introduced a non-backward compatible change to the
> > Subnet object - removal of ips field. Turns out kuryr-kubernetes were
> > depending on that e.g. here [1] and we're now broken with os-vif 1.8.0.
> > 
> > kuryr-kubernetes is saving the VIF objects into the K8s resources
> > annotations, so to keep backwards compatibility we need
> > VIFBase.obj_make_compatible able to backport the data back into the
> > Subnet object. Or be able to load the older data to the newer object.
> > Anyone have an advice how we should proceed with that issue?
> 
> [Mooney, Sean K] I belive obj_make_compatible methods were in the original
> Patch but they were removed as we did not know of any user of this field.
> The IPs field in the subnet object Was a legacy hold over from when the
> object was ported from nova-networks.
> it is never used by nova when calling os-vif today hence the
> change to align the data structure more closely with neutrons
> where the fixed ips are an attribute of the port.
> The change was made to to ensure no future users of os-vif consumed
> the fixed ips from the subnet object but I guess kuryr-kubernetes had already 
> done so.
> 
> Ideally we would migrate kuryr-kubernetes to consume fixed_ips form The vif 
> object instead of the subnet
> but if we can introduce a patch to os-vif to provide backwards compatibly
> before the non-client lib freeze on thrusday we can include that in queens.

I prefer Jay's proposed solution of simply doing a revert of the patch,
though this would work as well, at least as short-term remediation.

> > 
> > It would also be nice to setup a kuryr-kubernetes gate on the os-vif
> > repo. If there are no objections to that I'd volunteer to submit a
> > commit that adds it.
> 
> [Mooney, Sean K] I would be happy to see gate form all consumer of os-vif so 
> go for it.

Will do!

> Related to this https://review.openstack.org/#/c/509107/4 is currently 
> abandoned but I would
> Also like revivew this change in Rocky. Neutron has supported multiple dhcp 
> servers for
> some time, Nova-networks only supported one hench why the dhcp_server field 
> is currently singular.
> Will this effect kuryr-kubernetes?
> Are ye currently working around this issue in some other way? 

Looks like kuryr-kubernetes doesn't depend on dhcp_server field, though
I believe we should work out a way of doing such changes that's safe
for everyone. Making guesses on projects depending on certain fields is
dangerous.

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

Re: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks kuryr-kubernetes

[mdulko]

On Mon, 2018-01-15 at 12:30 -0500, Jay Pipes wrote:
> On 01/15/2018 11:45 AM, mdu...@redhat.com wrote:
> > Hi,
> > 
> > os-vif commit [1] introduced a non-backward compatible change to the
> > Subnet object - removal of ips field. Turns out kuryr-kubernetes were
> > depending on that e.g. here [1] and we're now broken with os-vif 1.8.0.
> > 
> > kuryr-kubernetes is saving the VIF objects into the K8s resources
> > annotations, so to keep backwards compatibility we need
> > VIFBase.obj_make_compatible able to backport the data back into the
> > Subnet object. Or be able to load the older data to the newer object.
> > Anyone have an advice how we should proceed with that issue?
> 
> It would have been great to know kuryr-kubernetes was saving/using these 
> objects :) as mentioned on the original os-vif code review, the 
> versioned objects in os-vif have yet to be used in over-the-wire 
> communication nor have they been saved to a backing data store by Nova 
> or Neutron. Thus, we haven't bothered with the obj_make_compatible() 
> stuff yet.
> 
> If we had known there was a non-Nova non-Neutron client of os-vif, of 
> course we would have been tracking changes using obj_make_compatible().

Sure thing, I've already learned that without CI breaking things is
expected. :)

> That said, even if we *were* using obj_make_compatible() and allowing 
> for the backversioning of object formats, that would not have magically 
> enabled kuryr-kubernetes to work with our objects without modification. 
> kuryr-kubernetes would still need to do the dance of telling os-vif 
> somehow what version of the objects that it expects to be given. This is 
> what all the infrastructure in oslo.versionedobject's client-server 
> negotiation does and it's non-trivial.

Agreed, though now the only solution is either to implement backporting
on kuryr-kubernetes side or drop backward compatibility with already
existing deployments.

> Bottom line, we can straight revert the os-vif patch in question 
> (because it's really just a cleanup), release os-vif 1.8.1 by the cutoff 
> on Thursday and "fix" kuryr-kubernetes. However, we will want to have a 
> call with you guys to tell you exactly how to do the versioning 
> negotiation that you will now need to do since you're storing these 
> objects somewhere.

If that change isn't critical to anyone, I'd prefer to do the revert
now and discuss how to do such changes correctly in the future. 

Implementing obj_make_compatible would help us, but I'm not sure it's a
good long-term solution, because it would require kuryr-kubernetes to
*always* specify the version of all the o.vo it uses, which may lead to
locking it to the lowest version that's available. In case of o.vo used
for DB & RPC communication that's solved by online data migrations. We
don't have such framework now and I simply don't know if we should copy
the same approach.

> Best,
> -jay
> 
> > It would also be nice to setup a kuryr-kubernetes gate on the os-vif
> > repo. If there are no objections to that I'd volunteer to submit a
> > commit that adds it.
> > 
> > Thanks,
> > Michal
> > 
> > [1] https://review.openstack.org/#/c/508498
> > [2] 
> > https://github.com/openstack/kuryr-kubernetes/blob/18db6499432e6cab61059eb5abeeaad3ea40b6e4/kuryr_kubernetes/cni/binding/base.py#L64-L66
> > 
> > __
> > OpenStack Development Mailing 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] [all][tc] Clarifying testing recommendation for interop programs

[Doug Hellmann]

Excerpts from Erno Kuvaja's message of 2018-01-15 12:59:44 +:

> I think the worst case scenario is that we scrape together what ever
> we can just to have something to say that we test it and not have
> consistency nor clear responsibility of who, what and how.
> (Unfortunately I think this is the current situation and I'm super
> happy to hear that this is being discussed and the decision is not
> made lightly.)

That seems very far from the current situation to me.

We have a large integration test suite written primarily by
contributors to the projects it tests. A subset of that is used for
the trademark tests. That same subset is in 1 repo, managed by the
QA team, who apply the extra review criteria needed for the trademark
program to be stable.

The fact that so many people seem uninformed about how all of this
works is exactly why I think it's a mistake to spread the tests out
and have a bunch of different teams applying different review
criteria to them.

Doug

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

Re: [openstack-dev] [masakari] problems starting up masakari instance monitoring in devstack @ master

[Kwan, Louie]

Hi Dinesh,

Thanks for the info.

'recovery_method' (choose from 'auto', 'reserved_host', 'auto_priority', 
'rh_priority')

What should be put for 

Same as the segment host

What should be put as   , it seems it 
accepts any arbitrary values.

Any more pointers. Much appreciated.

Thank you.
Louie Kwan 

From: Bhor, Dinesh [dinesh.b...@nttdata.com]
Sent: Wednesday, December 13, 2017 11:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master

Hi Greg,


Looks like you don’t have “devstack-masakari” host registered in Masakari 
database.


Currently operator have to add all the hosts from failover-segment manually to 
Masakari database.


You can use below command:


Register failover-segment to Masakari database:

openstack segment create   


Register hosts under the created segment to Masakari database:

openstack segment host create



There is a work in progress on auto compute node registration.

Please refer: 
https://blueprints.launchpad.net/masakari-monitors/+spec/auto-compute-node-registration



Thank you,

Dinesh Bhor


From: Waines, Greg 
Sent: 13 December 2017 19:26:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master


ok ... i changed all the domain related attributes in 
/etc/masakarimonitors/masakarimonitors.conf to be set to ‘default’ .

I seemed to get further,

but now get the following error when instancemonitor tries to send a 
notification:

  Bad Request (HTTP 400) (Request-ID: 
req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name devstack-masakari 
could not be found.

however:

- devstack-masakari is in the /etc/hosts

- nova hypervisor-list shows devstack-masakari as a hypervisor hostname

- i am running both hostmonitor, processmonitor and instancemonitor



any ideas ?

see details below,

Greg.



2017-12-13 13:50:34.353 7637 INFO 
masakarimonitors.instancemonitor.libvirt_handler.callback [-] Libvirt Event: 
type=VM, hostname=devstack-masakari, uuid=6ae0b09b-3e93-4f0c-b81b-fa140636f267, 
time=2017-12-13 13:50:34.353037, event_id=LIFECYCLE, detail=STOPPED_DESTROYED)

2017-12-13 13:50:34.353 7637 INFO masakarimonitors.ha.masakari [-] Send a 
notification. {'notification': {'hostname': 'devstack-masakari', 'type': 'VM', 
'payload': {'instance_uuid': '6ae0b09b-3e93-4f0c-b81b-fa140636f267', 
'vir_domain_event': 'STOPPED_DESTROYED', 'event': 'LIFECYCLE'}, 
'generated_time': datetime.datetime(2017, 12, 13, 13, 50, 34, 353037)}}

2017-12-13 13:50:34.461 7637 WARNING masakarimonitors.ha.masakari [-] Retry 
sending a notification. (HttpException: Bad Request (HTTP 400) (Request-ID: 
req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name devstack-masakari 
could not be found.): HttpException: HttpException: Bad Request (HTTP 400) 
(Request-ID: req-556c6c4d-0e12-414e-ac8c-8ef3a61d4864), Host with name 
devstack-masakari could not be found.

^C2017-12-13 13:50:42.462 7637 INFO oslo_service.service [-] Caught SIGINT 
signal, instantaneous exiting

root@devstack-masakari:~#

root@devstack-masakari:~# ping devstack-masakari

PING localhost (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms

64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.022 ms

^C

--- localhost ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.022/0.035/0.049/0.014 ms

root@devstack-masakari:~#



stack@devstack-masakari:~$ nova hypervisor-list

+--+-+---+-+

| ID   | Hypervisor hostname | State | Status  |

+--+-+---+-+

| 5fb1b09b-e5f5-465a-828a-2101135ff700 | devstack-masakari   | up| enabled |

+--+-+---+-+

stack@devstack-masakari:~$













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

Date: Wednesday, December 13, 2017 at 8:17 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master



So i believe the error is:

HttpException: HttpException: Expecting to find domain in project.



I have attached the /etc/masakarimonitors/masakarimonitors.conf file and the 
/etc/masakari/masakari.conf file .



See the domain related attributes in each file below.



Is the Default vs default causing this problem ?

Are there other domain related attributes that should be set to default ?



stack@devstack-masakari:~$ fgrep -i domain /etc/masakari/masakari.conf

project_domain_name = Default

user_domain_name = Defa

Re: [openstack-dev] [pbr] support v_version

[Doug Hellmann]

Excerpts from Gaetan's message of 2018-01-15 19:29:01 +0100:
> >
> >
> > > I guess it somehow didn't used my build of the pbr package when
> > > running in gitlab pipeline.
> >
> > It sounds like the CE pipeline is not building packages in the same way?
> > Or is using an old version of pbr?
> >
> > I guess it was the pbr version from pypi.python.org, not my customized
> build
> published on our internal pypi
> https://books.sonatype.com/nexus-book/3.0/reference/pypi.html
> 
> > > Do you plan on releasing PBR soon on pypi?
> > > I have to build myself and push it on our internal nexus pypi, but I
> > think
> > > the
> > > safest way is to wait for an official pbr release on pypi.python.org :)
> >
> > Unfortunately we're approaching a significant set of feature freeze
> > deadlines for this OpenStack development cycle. Because it is very
> > difficult to "pin" a library like pbr that appears in the setup_requires
> > list for projects in our CI pipelines, and this next release of pbr
> > would have quite a few changes, we have decided in our meeting today
> > to be cautious and delay the next release for a few weeks.
> >
> Have you ever considered using pipenv/pipfile ? I started using it a few
> months ago it helps a lot with dependency freezing

We have a system in place to constrain most of the libraries we use
(using pip's -c option) but pip does not pay attention to that list in
all code paths when installing things listed in setup_requires.

> > I have scheduled a reminder to tag the pbr release during the first
> > week of March, after the OpenStack release is safely completed.
> >
> > I'm sorry if this causes inconvenience. We're going to work on
> > ensuring we have more frequent releases so we reduce our chance of
> > ending up in a similar situation again in the future.
> >
> 
> That is not a problem by itself, I still have this self-hosted Pypi
> repository
> in the meantime.

OK, good.

> To react on the IRL log, indeed, the proposal I make in this thread is
> purely optional,
> for my need, gitlab handle correctly the protection against unwanted
> publication.
> Just hope it will be useful for other project, probably not for OpenStack
> itself.
> 
> Thanks a lot for supporting external projects :)
> 
> Gaetan

Thanks for working with us to improve pbr! :-)

Doug

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

Re: [openstack-dev] [pbr] support v_version

[Gaetan]

>
>
> > I guess it somehow didn't used my build of the pbr package when
> > running in gitlab pipeline.
>
> It sounds like the CE pipeline is not building packages in the same way?
> Or is using an old version of pbr?
>
> I guess it was the pbr version from pypi.python.org, not my customized
build
published on our internal pypi
https://books.sonatype.com/nexus-book/3.0/reference/pypi.html



> > Do you plan on releasing PBR soon on pypi?
> > I have to build myself and push it on our internal nexus pypi, but I
> think
> > the
> > safest way is to wait for an official pbr release on pypi.python.org :)
>
> Unfortunately we're approaching a significant set of feature freeze
> deadlines for this OpenStack development cycle. Because it is very
> difficult to "pin" a library like pbr that appears in the setup_requires
> list for projects in our CI pipelines, and this next release of pbr
> would have quite a few changes, we have decided in our meeting today
> to be cautious and delay the next release for a few weeks.
>
> Have you ever considered using pipenv/pipfile ? I started using it a few
months ago it helps a lot with dependency freezing

I have scheduled a reminder to tag the pbr release during the first
> week of March, after the OpenStack release is safely completed.
>
> I'm sorry if this causes inconvenience. We're going to work on
> ensuring we have more frequent releases so we reduce our chance of
> ending up in a similar situation again in the future.
>

That is not a problem by itself, I still have this self-hosted Pypi
repository
in the meantime.

To react on the IRL log, indeed, the proposal I make in this thread is
purely optional,
for my need, gitlab handle correctly the protection against unwanted
publication.
Just hope it will be useful for other project, probably not for OpenStack
itself.

Thanks a lot for supporting external projects :)

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

Re: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks kuryr-kubernetes

[Jay Pipes]

On 01/15/2018 11:45 AM, mdu...@redhat.com wrote:

Hi,

os-vif commit [1] introduced a non-backward compatible change to the
Subnet object - removal of ips field. Turns out kuryr-kubernetes were
depending on that e.g. here [1] and we're now broken with os-vif 1.8.0.

kuryr-kubernetes is saving the VIF objects into the K8s resources
annotations, so to keep backwards compatibility we need
VIFBase.obj_make_compatible able to backport the data back into the
Subnet object. Or be able to load the older data to the newer object.
Anyone have an advice how we should proceed with that issue?


It would have been great to know kuryr-kubernetes was saving/using these 
objects :) as mentioned on the original os-vif code review, the 
versioned objects in os-vif have yet to be used in over-the-wire 
communication nor have they been saved to a backing data store by Nova 
or Neutron. Thus, we haven't bothered with the obj_make_compatible() 
stuff yet.


If we had known there was a non-Nova non-Neutron client of os-vif, of 
course we would have been tracking changes using obj_make_compatible().


That said, even if we *were* using obj_make_compatible() and allowing 
for the backversioning of object formats, that would not have magically 
enabled kuryr-kubernetes to work with our objects without modification. 
kuryr-kubernetes would still need to do the dance of telling os-vif 
somehow what version of the objects that it expects to be given. This is 
what all the infrastructure in oslo.versionedobject's client-server 
negotiation does and it's non-trivial.


Bottom line, we can straight revert the os-vif patch in question 
(because it's really just a cleanup), release os-vif 1.8.1 by the cutoff 
on Thursday and "fix" kuryr-kubernetes. However, we will want to have a 
call with you guys to tell you exactly how to do the versioning 
negotiation that you will now need to do since you're storing these 
objects somewhere.


Best,
-jay


It would also be nice to setup a kuryr-kubernetes gate on the os-vif
repo. If there are no objections to that I'd volunteer to submit a
commit that adds it.

Thanks,
Michal

[1] https://review.openstack.org/#/c/508498
[2] 
https://github.com/openstack/kuryr-kubernetes/blob/18db6499432e6cab61059eb5abeeaad3ea40b6e4/kuryr_kubernetes/cni/binding/base.py#L64-L66

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



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

[openstack-dev] [Ironic] ironic tempest plugin code has been moved to openstack/ironic-tempest-plugin/

[John Villalovos]

The ironic tempest plugin code that was in openstack/ironic and
openstack/ironic-inspector has been moved to
openstack/ironic-tempest-plugin/

As of 10-Jan-2018 (Wednesday) the plugin code was deleted from
openstack/ironic and openstack/ironic-inspector. All users of the tempest
plugin code need to be using it from the openstack/ironic-tempest-plugin
repository now.

We believe that all of the 3rd Party CIs have already made this change.
Thanks to everyone working on this!

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

Re: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks kuryr-kubernetes

[Mooney, Sean K]

> -Original Message-
> From: mdu...@redhat.com [mailto:mdu...@redhat.com]
> Sent: Monday, January 15, 2018 4:46 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [kuryr][os-vif][nova] os-vif 1.8.0 breaks
> kuryr-kubernetes
> 
> Hi,
> 
> os-vif commit [1] introduced a non-backward compatible change to the
> Subnet object - removal of ips field. Turns out kuryr-kubernetes were
> depending on that e.g. here [1] and we're now broken with os-vif 1.8.0.
> 
> kuryr-kubernetes is saving the VIF objects into the K8s resources
> annotations, so to keep backwards compatibility we need
> VIFBase.obj_make_compatible able to backport the data back into the
> Subnet object. Or be able to load the older data to the newer object.
> Anyone have an advice how we should proceed with that issue?
[Mooney, Sean K] I belive obj_make_compatible methods were in the original
Patch but they were removed as we did not know of any user of this field.
The IPs field in the subnet object Was a legacy hold over from when the
object was ported from nova-networks.
it is never used by nova when calling os-vif today hence the
change to align the data structure more closely with neutrons
where the fixed ips are an attribute of the port.
The change was made to to ensure no future users of os-vif consumed
the fixed ips from the subnet object but I guess kuryr-kubernetes had already 
done so.

Ideally we would migrate kuryr-kubernetes to consume fixed_ips form The vif 
object instead of the subnet
but if we can introduce a patch to os-vif to provide backwards compatibly
before the non-client lib freeze on thrusday we can include that in queens.


> 
> It would also be nice to setup a kuryr-kubernetes gate on the os-vif
> repo. If there are no objections to that I'd volunteer to submit a
> commit that adds it.
[Mooney, Sean K] I would be happy to see gate form all consumer of os-vif so go 
for it.
Related to this https://review.openstack.org/#/c/509107/4 is currently 
abandoned but I would
Also like revivew this change in Rocky. Neutron has supported multiple dhcp 
servers for
some time, Nova-networks only supported one hench why the dhcp_server field is 
currently singular.
Will this effect kuryr-kubernetes?
Are ye currently working around this issue in some other way? 

> 
> Thanks,
> Michal
> 
> [1] https://review.openstack.org/#/c/508498
> [2] https://github.com/openstack/kuryr-
> kubernetes/blob/18db6499432e6cab61059eb5abeeaad3ea40b6e4/kuryr_kubernet
> es/cni/binding/base.py#L64-L66
> 
> ___
> ___
> OpenStack Development Mailing 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] PTL Election Season

[Luke Hinds]

On Mon, Jan 15, 2018 at 5:04 PM, Kendall Nelson 
wrote:

> Election details: https://governance.openstack.org/election/
>
> Please read the stipulations and timelines for candidates and electorate
> contained in this governance documentation.
>
> Be aware, in the PTL elections if the program only has one candidate, that
> candidate is acclaimed and there will be no poll. There will only be a poll
> if there is more than one candidate stepping forward for a program's PTL
> position.
>
> There will be further announcements posted to the mailing list as action
> is required from the electorate or candidates. This email is for
> information purposes only.
>
> If you have any questions which you feel affect others please reply to
> this email thread.
>
> If you have any questions that you which to discuss in private please
> email any of the election judges[1] so that we may address your concerns.
>
>  Thank you,
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://governance.openstack.org/election/#election-officials
>

Keep in mind there will be no Security PTL election for rocky as we will be
changing to a SIG and will no longer be a project.
__
OpenStack Development Mailing 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] PTL Election Season

[Kendall Nelson]

Election details: https://governance.openstack.org/election/

Please read the stipulations and timelines for candidates and electorate
contained in this governance documentation.

Be aware, in the PTL elections if the program only has one candidate, that
candidate is acclaimed and there will be no poll. There will only be a poll
if there is more than one candidate stepping forward for a program's PTL
position.

There will be further announcements posted to the mailing list as action is
required from the electorate or candidates. This email is for information
purposes only.

If you have any questions which you feel affect others please reply to this
email thread.

If you have any questions that you which to discuss in private please email
any of the election judges[1] so that we may address your concerns.

 Thank you,

-Kendall Nelson (diablo_rojo)

[1] https://governance.openstack.org/election/#election-officials
__
OpenStack Development Mailing 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. 17 Jan - IRC Meeting 15:00 UTC

[avankemp]

Dear all, 

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

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

For the record, the 2017 agenda is still available here:
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 


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

Re: [openstack-dev] [pbr] support v_version

[Doug Hellmann]

Excerpts from Gaetan's message of 2018-01-15 17:29:01 +0100:
> First, thanks a lot for your support and your kindness ! Really appreciate
> that :)
> 
> > > Do you know where I need to hack PBR to fix it?
> >
> > So 'pbr' correctly parses the prefixed tags, but it's just the output
> > packages (sdists, wheels) that always unversioned? If so, this sounds
> > correct. Python packaging, as defined in PEP-440 [1], doesn't use the
> > 'v' prefixes, so it doesn't really make sense to stick them in here.
> > Out of curiosity, what's your rationale for modifying the package name?
> >
> 
> The package name is not changed actually. With the patch in PBR that has
> been merged, one could add a tag named "v1.0.0" on mypackage package,
> and the sdist will generate a distribution package
> 
> mypackage-0.0.4.tar.gz
> 
> 
> So I think (hope?) this is still PEP440 compliant.
> 
> I tried this feature on another software that also uses pbr and there is no
> problem: v version works great with sdist/bdist/wheel packages.
> 
> I use it inside a Gitlab CE pipeline on a tag pipeline (CI is triggered when
> a git tag that follows the "v*" regular expression), and instead of
> creating
> a package
> 
> mypackage-0.0.4-py2.py3-none-any.whl
> 
> it created
> 
> mypackage-0.0.3.dev3-py2.py3-none-any.whl.
> 
> 
> When I retried manually on my development environment, pbr works
> perfectly again on the same code.
> I guess it somehow didn't used my build of the pbr package when
> running in gitlab pipeline.

It sounds like the CE pipeline is not building packages in the same way?
Or is using an old version of pbr?

> 
> Do you plan on releasing PBR soon on pypi?
> I have to build myself and push it on our internal nexus pypi, but I think
> the
> safest way is to wait for an official pbr release on pypi.python.org :)

Unfortunately we're approaching a significant set of feature freeze
deadlines for this OpenStack development cycle. Because it is very
difficult to "pin" a library like pbr that appears in the setup_requires
list for projects in our CI pipelines, and this next release of pbr
would have quite a few changes, we have decided in our meeting today
to be cautious and delay the next release for a few weeks.

I have scheduled a reminder to tag the pbr release during the first
week of March, after the OpenStack release is safely completed.

I'm sorry if this causes inconvenience. We're going to work on
ensuring we have more frequent releases so we reduce our chance of
ending up in a similar situation again in the future.

Doug

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2018-01-15.log.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] [kuryr][os-vif][nova] os-vif 1.8.0 breaks kuryr-kubernetes

[mdulko]

Hi,

os-vif commit [1] introduced a non-backward compatible change to the
Subnet object - removal of ips field. Turns out kuryr-kubernetes were
depending on that e.g. here [1] and we're now broken with os-vif 1.8.0.

kuryr-kubernetes is saving the VIF objects into the K8s resources
annotations, so to keep backwards compatibility we need
VIFBase.obj_make_compatible able to backport the data back into the
Subnet object. Or be able to load the older data to the newer object.
Anyone have an advice how we should proceed with that issue?

It would also be nice to setup a kuryr-kubernetes gate on the os-vif
repo. If there are no objections to that I'd volunteer to submit a
commit that adds it.

Thanks,
Michal

[1] https://review.openstack.org/#/c/508498
[2] 
https://github.com/openstack/kuryr-kubernetes/blob/18db6499432e6cab61059eb5abeeaad3ea40b6e4/kuryr_kubernetes/cni/binding/base.py#L64-L66

__
OpenStack Development Mailing 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] [pbr] support v_version

[Gaetan]

First, thanks a lot for your support and your kindness ! Really appreciate
that :)


> > Do you know where I need to hack PBR to fix it?
>
> So 'pbr' correctly parses the prefixed tags, but it's just the output
> packages (sdists, wheels) that always unversioned? If so, this sounds
> correct. Python packaging, as defined in PEP-440 [1], doesn't use the
> 'v' prefixes, so it doesn't really make sense to stick them in here.
> Out of curiosity, what's your rationale for modifying the package name?
>

The package name is not changed actually. With the patch in PBR that has
been merged, one could add a tag named "v1.0.0" on mypackage package,
and the sdist will generate a distribution package

mypackage-0.0.4.tar.gz


So I think (hope?) this is still PEP440 compliant.

I tried this feature on another software that also uses pbr and there is no
problem: v version works great with sdist/bdist/wheel packages.

I use it inside a Gitlab CE pipeline on a tag pipeline (CI is triggered when
a git tag that follows the "v*" regular expression), and instead of
creating
a package

mypackage-0.0.4-py2.py3-none-any.whl

it created

mypackage-0.0.3.dev3-py2.py3-none-any.whl.


When I retried manually on my development environment, pbr works
perfectly again on the same code.
I guess it somehow didn't used my build of the pbr package when
running in gitlab pipeline.

Do you plan on releasing PBR soon on pypi?
I have to build myself and push it on our internal nexus pypi, but I think
the
safest way is to wait for an official pbr release on pypi.python.org :)


> Second point, to go to the end of the logic of my change, I would
> > like to propose an optional way (in setup.cfg?) to **prevent** any
> > tag without the 'v' prefix, ie, where a bare version tag like `1.0.0`
> > is not to be considered as a valid version.
> > That way, on system such as gitlab or github:
> > - repository owners "protect" tags with pattern "v*", ie, all tags
> > for release such as "v1.0.0", ... cannot be pushed by anyone but the
> > owners/masters
> > - other developer can still push other tags for other purpose
>
> So this could be used to prevent pbr reading the tags, but it won't
> stop anyone from creating them in the first place (i.e. "protect"
> tags).


Yes, I agree this is not really mandatory. Gitlab tag protection should be
enough.

I am using a "protected environment variables" on gitlab, and indeed, the
credentials
to push on Pypi are only sent when the pipeline is triggered on such a
"protected"
branch or "protected tag".

So we "protect" only tags starting with a "v*" and only this triggered
pipeline
can publish to pypi (we use Nexus).

This allows other developers to add any tags not started with v (only
repository
owners can create tags starting with a "v*"). Note this "v*" regular
expression
is configurable and seem to default/good practice on GitLab CE/EE.


> We can do this but it would be a separate feature and, to be
> honest, I'd suggest using Git hooks or some form of access control as a
> better way to do this (Note: it seems GitLab already supports something
> similar [2]).
>

Yes this is what I actually use :) Thanks

In short: pbr v_version seems to work great, just hoping for the official
PBR
release on pypi.python.org :)

Thanks
Gaetan Semet
__
OpenStack Development Mailing 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] [glance][oslo][requirements] oslo.serialization fails with glance

[Matthew Thode]

On 18-01-13 00:41:28, Matthew Thode wrote:
> https://review.openstack.org/531788 is the review we are seeing it in,
> but 2.22.0 failed as well.
> 
> I'm guessing it was introduced in either
> 
> https://github.com/openstack/oslo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8
> or
> https://github.com/openstack/oslo.serialization/commit/cdb2f60d26e3b65b6370f87b2e9864045651c117

bamp

-- 
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] [neutron-dev] [neutron] Generalized issues in the unit testing of ML2 mechanism drivers

[Isaku Yamahata]

Hello. Any comments/thoughts?

This issue is generic to neutron. not specific to networking-odl.
So this should be addressed as Neutron wide, and neutron and sub-project should
be addressed uniformly.

Thanks,

On Mon, Dec 18, 2017 at 12:52:37PM +0200,
Mike Kolesnik  wrote:

> On Wed, Dec 13, 2017 at 2:30 PM, Michel Peterson  wrote:
> 
> > Through my work in networking-odl I've found what I believe is an issue
> > present in a majority of ML2 drivers. An issue I think needs awareness so
> > each project can decide a course of action.
> >
> > The issue stems from the adopted practice of importing
> > `neutron.tests.unit.plugins.ml2.test_plugin` and creating classes with
> > noop operation to "inherit" tests for free [1]. The idea behind is nice,
> > you inherit >600 tests that cover several scenarios.
> >
> > There are several issues of adopting this pattern, two of which are
> > paramount:
> >
> > 1. If the mechanism driver is not loaded correctly [2], the tests then
> > don't test the mechanism driver but still succeed and therefore there is no
> > indication that there is something wrong with the code. In the case of
> > networking-odl it wasn't discovered until last week, which means that for
> > >1 year it this was adding PASSed tests uselessly.
> >
> > 2. It gives a false sense of reassurance. If the code of those tests is
> > analyzed it's possible to see that the code itself is mostly centered
> > around testing the REST endpoint of neutron than actually testing that the
> > mechanism succeeds on the operation it was supposed to test. As a result of
> > this, there is marginally added value on having those tests. To be clear,
> > the hooks for the respective operations are called on the mechanism driver,
> > but the result of the operation is not asserted.
> >
> > I would love to hear more voices around this, so feel free to comment.
> >
> 
> ???i talked to a few guys from networking-ovn which are now processing this
> info so they could chime in, but from what I've understood the issue wasn't
> given much thought in networking-ovn (and I suspect other mechanism
> drivers).
> ???
> 
> >
> > Regarding networking-odl the solution I propose is the following:
> >   **First**, discard completely the change mentioned in the footnote #2.
> >   **Second**, create a patch that completely removes the tests that follow
> > this pattern.
> >   **Third**, incorporate the neutron tempest plugin into the CI and rely
> > on that for assuring coverage of the different scenarios.
> >
> 
> ???This sounds like a good plan to me.
> ???
> 
> >
> > Also to mention that when discovered this issue in networking-odl we took
> > a decision not to merge more patches until the PS of footnote #2 was
> > addressed. I think we can now decide to overrule that decision and proceed
> > as usual.
> >
> 
> ???Agreed.
> ???
> 
> >
> >
> >
> > [1]: http://codesearch.openstack.org/?q=class%20.*\(.*TestMl2
> > 
> > [2]: something that was happening in networking-odl and addressed by
> > https://review.openstack.org/#/c/523934
> >
> > ___
> > neutron-dev mailing list
> > neutron-...@lists.opendaylight.org
> > https://lists.opendaylight.org/mailman/listinfo/neutron-dev
> >
> >
> 
> 
> -- 
> Regards,
> Mike

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


-- 
Isaku Yamahata 

__
OpenStack Development Mailing 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] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Andreas Jaeger]

On 2018-01-15 16:11, Stephen Finucane wrote:
> On Thu, 2018-01-04 at 15:39 +, Stephen Finucane wrote:
>> I'm not sure what the procedure for this is but here goes.
>>
>> I've noticed that the 'os-api-ref' project seems to have its own group
>> of cores [1], many of whom are no longer working on OpenStack (at
>> least, not full-time), and has a handful of open patches against it
>> [2]. Since the doc team has recently changed its scope from writing
>> documentation to enabling individual projects to maintain their own
>> docs, we've become mainly responsible for projects like 'openstack-doc-
>> theme'. Given that the 'os-api-ref' project is a Sphinx thing required
>> for multiple OpenStack projects, it seems like something that
>> could/should fall into the doc team's remit.
>>
>> I'd like to move this project into the remit of the 'openstack-doc-
>> core' team, by way of removing the 'os-api-ref-core' group or adding
>> 'openstack-doc-core' to the list of included groups. In both cases,
>> existing active cores will be retained. Do any of the existing 'os-api-
>> ref' cores have any objections to this?
> 
> It's been two weeks with no -1s, so we've gone ahead and done this.
> Thanks, everyone.

Note that the ownership is already in government repo since May 2016
(https://review.openstack.org/317686),

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


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

Re: [openstack-dev] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Stephen Finucane]

On Thu, 2018-01-04 at 15:39 +, Stephen Finucane wrote:
> I'm not sure what the procedure for this is but here goes.
> 
> I've noticed that the 'os-api-ref' project seems to have its own group
> of cores [1], many of whom are no longer working on OpenStack (at
> least, not full-time), and has a handful of open patches against it
> [2]. Since the doc team has recently changed its scope from writing
> documentation to enabling individual projects to maintain their own
> docs, we've become mainly responsible for projects like 'openstack-doc-
> theme'. Given that the 'os-api-ref' project is a Sphinx thing required
> for multiple OpenStack projects, it seems like something that
> could/should fall into the doc team's remit.
> 
> I'd like to move this project into the remit of the 'openstack-doc-
> core' team, by way of removing the 'os-api-ref-core' group or adding
> 'openstack-doc-core' to the list of included groups. In both cases,
> existing active cores will be retained. Do any of the existing 'os-api-
> ref' cores have any objections to this?

It's been two weeks with no -1s, so we've gone ahead and done this.
Thanks, everyone.

Stephen

> Stephen
> 
> PS: I'm not sure how this affects things from a release management
> perspective. Are there PTLs for these sorts of projects?

Turns out this project was already listed as a doc team deliverable.
Who knew?!

> [1] https://review.openstack.org/#/admin/groups/1391,members
> [2] https://review.openstack.org/#/q/project:openstack/os-api-ref+statu
> s:open

__
OpenStack Development Mailing 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] [pbr] support v_version

[Stephen Finucane]

On Tue, 2018-01-09 at 10:25 +0100, Gaetan wrote:
> Hello
> 
> I have submitted this patch ([1]) that add support for v_version in
> PBR. Basically I can tag v1.0.0 instead of 1.0.0 to release 1.0.0.
> 
> However, after rework it appears PBR does not behaves well, even if
> the unit tests pass:
> On tag for instance v1.0.0, the result packages in named
> `-1.0.0.dev1`.
> 
> Do you know where I need to hack PBR to fix it?

So 'pbr' correctly parses the prefixed tags, but it's just the output
packages (sdists, wheels) that always unversioned? If so, this sounds
correct. Python packaging, as defined in PEP-440 [1], doesn't use the
'v' prefixes, so it doesn't really make sense to stick them in here.
Out of curiosity, what's your rationale for modifying the package name?

> Second point, to go to the end of the logic of my change, I would
> like to propose an optional way (in setup.cfg?) to **prevent** any
> tag without the 'v' prefix, ie, where a bare version tag like `1.0.0`
> is not to be considered as a valid version.
> That way, on system such as gitlab or github:
> - repository owners "protect" tags with pattern "v*", ie, all tags
> for release such as "v1.0.0", ... cannot be pushed by anyone but the
> owners/masters
> - other developer can still push other tags for other purpose

So this could be used to prevent pbr reading the tags, but it won't
stop anyone from creating them in the first place (i.e. "protect"
tags). We can do this but it would be a separate feature and, to be
honest, I'd suggest using Git hooks or some form of access control as a
better way to do this (Note: it seems GitLab already supports something
similar [2]).

Stephen

[1] https://www.python.org/dev/peps/pep-0440/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/18471

__
OpenStack Development Mailing 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] [pbr] support v_version

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-01-15 14:40:14 +:
> On 2018-01-09 10:25:56 +0100 (+0100), Gaetan wrote:
> > I have submitted this patch ([1]) that add support for v_version
> > in PBR. Basically I can tag v1.0.0 instead of 1.0.0 to release
> > 1.0.0.
> [...]
> 
> Looks like the patch you linked has since merged. Any issues with it
> so far?
> 
> > Second point, to go to the end of the logic of my change, I would
> > like to propose an optional way (in setup.cfg?) to **prevent** any
> > tag without the 'v' prefix, ie, where a bare version tag like
> > `1.0.0` is not to be considered as a valid version.
> [...]
> 
> I'm not heavily involved in PBR maintenance so my ideas may be
> terrible, but have you considered just making it possible to set a
> version pattern option in setup.cfg so that this sort of filtering
> is more easily generalized?

That seems reasonable. It may even help solve the package filename
problem.

Doug

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

Re: [openstack-dev] [storyboard] need help figuring out how to use auth with storyboard client

[Doug Hellmann]

Excerpts from Adam Coldrick's message of 2018-01-15 11:26:14 +:
> On Fri, 2018-01-12 at 21:30 +, Jeremy Stanley wrote:
> > On 2018-01-12 15:57:44 -0500 (-0500), Doug Hellmann wrote:
> > > The storyboard client docs mention an "access token" [1] as
> > > something
> > > a client needs in order to create stories and make other sorts of
> > > changes.  They don't explain what that token is or how to get one,
> > > though.
> > > 
> > > Where do I get a token? How long does the token work? Can I safely
> > > put a token in a configuration file, or do I need to get a new one
> > > each time I want to do something with the client?
> > 
> > https://docs.openstack.org/infra/storyboard/webapi/v1.html#api
> > suggests that logging in and going to
> > https://storyboard.openstack.org/#!/profile/tokens will allow you to
> > issue one (with up to a 10-year expiration based on my modest
> > experimentation). I believe this to be the same solution we're using
> > to grant teh storyboard-its Gerrit plugin to update tasks/stories
> > from review.openstack.org.
> 
> This is likely the easiest solution. Some other options:
> 
> - Admin users can issue tokens for any users, so an automation user
>   could have a token granted by infra-root using the API directly (see
>   the API docs[0] for detail).

The script I'm thinking of would create the story, tasks, and board
associated with a community goal. So it could be run by a goal champion
on their local system, and wouldn't need a special user to own the
results.

> - Add some functionality in python-storyboardclient to handle
>   authenticating with the OpenID provider that the API sends a
>   redirect link for.

That would be useful, although having directions for getting a token
manually is probably fine, for this case.

> 
> [0]: https://docs.openstack.org/infra/storyboard/webapi/v1.html#post--v
> 1-users--user_id--tokens
> 

__
OpenStack Development Mailing 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] [pbr] support v_version

[Jeremy Stanley]

On 2018-01-09 10:25:56 +0100 (+0100), Gaetan wrote:
> I have submitted this patch ([1]) that add support for v_version
> in PBR. Basically I can tag v1.0.0 instead of 1.0.0 to release
> 1.0.0.
[...]

Looks like the patch you linked has since merged. Any issues with it
so far?

> Second point, to go to the end of the logic of my change, I would
> like to propose an optional way (in setup.cfg?) to **prevent** any
> tag without the 'v' prefix, ie, where a bare version tag like
> `1.0.0` is not to be considered as a valid version.
[...]

I'm not heavily involved in PBR maintenance so my ideas may be
terrible, but have you considered just making it possible to set a
version pattern option in setup.cfg so that this sort of filtering
is more easily generalized?
-- 
Jeremy Stanley


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

[openstack-dev] Notification update week 3

[Balázs Gibizer]

Hi,

Here is the status update / focus settings mail for 2018 w3.

Bugs

[High] 
https://bugs.launchpad.net/nova/+bug/1742935TestServiceUpdateNotificationSample 
fails intermittently: u'host2' != u'host1': path: 
root.payload.nova_object.data.host
The openstack-tox-functional (and functional-py35) test environment was 
totally broken during last Friday. Sorry for that. The patch that 
caused the break has been reverted 
https://review.openstack.org/#/c/533190/
A follow up bug has been opened (see next) to avoid similar break in 
the future.


[High] https://bugs.launchpad.net/nova/+bug/1742962 nova functional 
test does not triggered on notification sample only changes
During the zuul v3 migration the project-config generated based on the 
zuul v2 jobs. It contained a proper definition of when nova wants to 
trigger the functional job. Unfortunately this job definition does not 
override the openstack-tox-functional job definition from the 
openstack-zuul-jobs repo. This caused that the openstack-tox-functional 
(and functional-py35) jobs were not triggered for certain commits. The 
fix is to create a nova specific tox-functional job in tree. Patches 
has been proposed:
* https://review.openstack.org/#/c/533210/ Make sure that functional 
test triggered on sample changes
* https://review.openstack.org/#/c/533608/ Moving nova functional test 
def to in tree
In general we have to review all nova jobs in the project-config and 
move those in-tree that try to override parameters of the job 
definitions in openstack-zuul-jobs repo.


[High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when
sending notification during attach_interface
Fix merged to master. Backports have been proposed:
* Pike: https://review.openstack.org/#/c/531745/
* Queens: https://review.openstack.org/#/c/531746/

[High] https://bugs.launchpad.net/nova/+bug/1739325 Server operations
fail to complete with versioned notifications if payload contains unset
non-nullable fields
Patch has been proposed: https://review.openstack.org/#/c/529194/
Dan left feedback on it and I accept his comment that this is mostly 
papering over a problem that we don't fully understand how can happen 
in the first place. In the other hand I don't know how can we figure 
out what happend. So if somebody has an idea then don't hesistate to 
tell me.


[Low] https://bugs.launchpad.net/nova/+bug/1742688 
test_live_migration_actions notification sample test fails 
intermittently with 'notification 
instance.live_migration_rollback.start hasn't been received'
It seems that test execution in CI is a lot slower than before and it 
makes the 1 second timeout in the notification test too small. Fix is 
on the gate: https://review.openstack.org/#/c/532816


[Low] https://bugs.launchpad.net/nova/+bug/1487038
nova.exception._cleanse_dict should use
oslo_utils.strutils._SANITIZE_KEYS
Old abandoned patches exist but need somebody to pick them up:
* https://review.openstack.org/#/c/215308/
* https://review.openstack.org/#/c/388345/

Versioned notification transformation
-
Here are the patches ready to review:
* https://review.openstack.org/#/c/385644 Transform rescue/unrescue 
instance notifications

Needs only a second +2
* https://review.openstack.org/#/c/403660 Transform instance.exists 
notification
* https://review.openstack.org/#/c/410297 Transform missing delete 
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context 
manager


Introduce instance.lock and instance.unlock notifications
---
A specless bp has been proposed to the Rocky cycle
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
Some preliminary discussion happened in an earlier patch
https://review.openstack.org/#/c/526251/

Add the user id and project id of the user initiated the instance 
action to the notification


A new bp has been proposed 
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
As the user who initiates the instance action (e.g. reboot) could be 
different from the user owning the instance it would make sense to 
include the user_id and project_id of the action initiatior to the 
versioned instance action notifications as well.


Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
We have to be carefull to approve these type of commits until the 
solution for https://bugs.launchpad.net/nova/+bug/1742962 merged as 
functional tests could be broken silently.


Weekly meeting
--
There will not be a meeting this week. The next meeting will be held on 
23th of January.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180123T17

Cheers,
gibi


___

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-01-08 09:55:26 -0500:
> Stephen (sfinucan) has been working on pbr, oslo.config, and
> oslo.policy and reviewing several of the other Oslo libraries for
> a while now. His reviews are always helpful and I think he would
> make a good addition to the oslo-core team.
> 
> As per our usual practice, please reply here with a +1 or -1 and
> any reservations.
> 
> Doug

As we have gone a week with no objections, I added Stephen to the
oslo-core group this morning.

Stephen, welcome to the team!

Doug

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

[openstack-dev] [monasca] RE: alarm transition events are missing in kafka queue - mysql alarm state is updated properly

[Bedyk, Witold]

Hi Yuan,

please compare similar issue described in this bug report [1] and the 
corresponding fix [2].
As Craig explained in his comment to patch set 4, Kafka server closes idle 
connections after around 10 minutes, which causes first write to the topic fail.

I hope it helps.
Witek

[1] https://storyboard.openstack.org/#!/story/2001386
[2] https://review.openstack.org/525669


From: yuan@t-systems.com [mailto:yuan@t-systems.com]
Sent: Freitag, 12. Januar 2018 19:36
To: roland.hochm...@hpe.com
Cc: Bedyk, Witold ; mona...@lists.launchpad.net; 
Trebski, Tomasz ; bradley.kl...@charter.com
Subject: alarm transition events are missing in kafka queue - mysql alarm state 
is updated properly

Hi Roland,
This is Yuan Pen from Deutsche Telekom. I am sending this email to the monasca 
community asking for help on monasca threshold engine. We have found that when 
sometime alarm state transitions happened, the threshold engine updated mysql 
alarm state properly, but failed to put  state transition events  in kafka 
queue (alarm-state-transitions).  Does this ring a bell to anyone in the 
community? If this is a real problem, is there anything we can do to make sure 
the event in transition queue and state in mysql is synched? Any comments or 
help are greatly appreciated.
Best Regard,

Yuan Pen

571-594-6155

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

Re: [openstack-dev] [mistral] Adding Adriano Petrich to the core team

[Dougal Matthews]

+1!


On Mon, 15 Jan 2018 at 09:12, Renat Akhmerov 
wrote:

> Hi,
>
> I’d like to promote Adriano Petrich to the Mistral core team. Adriano has
> shown the good review rate and quality at least over the last two cycles
> and implemented several important features (including new useful YAQL/JINJA
> functions).
>
> Please vote whether you agree to add Adriano to the core team.
>
> Adriano’s statistics:
> http://stackalytics.com/?module=mistral-group&release=queens&user_id=apetrich
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Erno Kuvaja]

On Thu, Jan 11, 2018 at 4:36 PM, Colleen Murphy  wrote:
> Hi everyone,
>
> We have governance review under debate[1] that we need the community's help 
> on.
> The debate is over what recommendation the TC should make to the Interop team
> on where the tests it uses for the OpenStack trademark program should be
> located, specifically those for the new add-on program being introduced. Let 
> me
> badly summarize:
>
> A couple of years ago we issued a resolution[2] officially recommending that
> the Interop team use solely tempest as its source of tests for capability
> verification. The Interop team has always had the view that the developers,
> being the people closest to the project they're creating, are the best people
> to write tests verifying correct functionality, and so the Interop team 
> doesn't
> maintain its own test suite, instead selecting tests from those written in
> coordination between the QA team and the other project teams. These tests are
> used to validate clouds applying for the OpenStack Powered tag, and since all
> of the projects included in the OpenStack Powered program already had tests in
> tempest, this was a natural fit. When we consider adding new trademark 
> programs
> comprising of other projects, the test source is less obvious. Two examples 
> are
> designate, which has never had tests in the tempest repo, and heat, which
> recently had its tests removed from the tempest repo.
>
> So far the patch proposes three options:
>
> 1) All trademark-related tests should go in the tempest repo, in accordance
>with the original resolution. This would mean that even projects that have
>never had tests in tempest would now have to add at least some of their
>black-box tests to tempest.
>
> The value of this option is that centralizes tests used for the Interop 
> program
> in a location where interop-minded folks from the QA team can control them. 
> The
> downside is that projects that so far have avoided having a dependency on
> tempest will now lose some control over the black-box tests that they use for
> functional and integration that would now also be used for trademark
> certification.
> There's also concern for the review bandwidth of the QA team - we can't expect
> the QA team to be continually responsible for an ever-growing list of projects
> and their trademark tests.
>
> 2) All trademark-related tests for *add-on projects* should be sourced from
>plugins external to tempest.
>
> The value of this option is it allows project teams to retain control over
> these tests. The potential problem with it is that individual project teams 
> are
> not necessarily reviewing test changes with an eye for interop concerns and so
> could inadvertently change the behavior of the trademark-verification tools.
>
> 3) All trademark-related tests should go in a single separate tempest plugin.
>
> This has the value of giving the QA and Interop teams control over
> interop-related tests while also making clear the distinction between tests
> used for trademark verification and tests used for CI. Matt's argument against
> this is that there actually is very little distinction between those two 
> cases,
> and that a given test could have many different applications.
>
> Other ideas that have been thrown around are:
>
> * Maintaining a branch in the tempest repo that Interop tests are pulled from.
>
> * Tagging Interop-related tests with decorators to make it clear that they 
> need
>   to be handled carefully.
>
> At the heart of the issue is the perception that projects that keep their
> integration tests within the tempest tree are somehow blessed, maybe by the QA
> team or by the TC. It would be nice to try to clarify what technical
> and political
> reasons we have for why different projects have tests in different places -
> review bandwidth of the QA team, ownership/control by the project teams,
> technical interdependency between certain projects, or otherwise.
>
As someone who has been in middle of all that already once I'd like to
bring up bit more fundamental problem into this topic. I'm not able to
provide one size fits all solution but hopefully some insight that
would help the community to make the right decision.

I think the biggest problem is who's fox is let to guard the chicken coop.

By that I mean the basic problem of our testing still relies on what
is tested based on which assumptions and by whom. If the tests are
provided by the project teams, the test is more likely to cover the
intended usecase of the feature as it's implemented and if there is
bug found on that, the likelyhood that the test is altered is quite
high also the individual projects might not have the best idea what
might be the important things to the interoperability and trademark
purposes. Obviously when the test is written against intended behavior
it's less likely but also those changes might sneak in affecting the
interoprability. On the other hand if the test is written by
QA/inte

Re: [openstack-dev] Retirement of astara repos?

[Andreas Jaeger]

On 2018-01-11 22:55, Mark McClain wrote:
> Sean, Andreas-
> 
> Sorry I missed Andres’ message earlier in December about retiring astara. 
> Everyone is correct that development stopped a good while ago.  We attempted 
> in Barcelona to find others in the community to take over the day-to-day 
> management of the project. Unfortunately, nothing sustained resulted from 
> that session. 
> 
> I’ve intentionally delayed archiving the repos because of background 
> conversations around restarting active development for some pieces bubble up 
> from time-to-time.  I’ll contact those I know were interested and try for a 
> resolution to propose before the PTG.

Mark,

we can always unretire a repository - it's just a revert of the retire
patches...

So, if you don't hear anything by then, let's retire,

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


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

Re: [openstack-dev] [storyboard] need help figuring out how to use auth with storyboard client

[Adam Coldrick]

On Fri, 2018-01-12 at 21:30 +, Jeremy Stanley wrote:
> On 2018-01-12 15:57:44 -0500 (-0500), Doug Hellmann wrote:
> > The storyboard client docs mention an "access token" [1] as
> > something
> > a client needs in order to create stories and make other sorts of
> > changes.  They don't explain what that token is or how to get one,
> > though.
> > 
> > Where do I get a token? How long does the token work? Can I safely
> > put a token in a configuration file, or do I need to get a new one
> > each time I want to do something with the client?
> 
> https://docs.openstack.org/infra/storyboard/webapi/v1.html#api
> suggests that logging in and going to
> https://storyboard.openstack.org/#!/profile/tokens will allow you to
> issue one (with up to a 10-year expiration based on my modest
> experimentation). I believe this to be the same solution we're using
> to grant teh storyboard-its Gerrit plugin to update tasks/stories
> from review.openstack.org.

This is likely the easiest solution. Some other options:

- Admin users can issue tokens for any users, so an automation user
  could have a token granted by infra-root using the API directly (see
  the API docs[0] for detail).

- Add some functionality in python-storyboardclient to handle
  authenticating with the OpenID provider that the API sends a
  redirect link for.

[0]: https://docs.openstack.org/infra/storyboard/webapi/v1.html#post--v
1-users--user_id--tokens

__
OpenStack Development Mailing 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][ptl][goals][storyboard] tracking the rocky goals with storyboard

[Thierry Carrez]

Emilien Macchi wrote:
> On Fri, Jan 12, 2018 at 12:37 PM, Doug Hellmann  wrote:
>> [...]
>> How does this sound as an approach? Does anyone have any reservations
>> about using storyboard this way?
> 
> Sounds like a good idea, and will help to "Eat Our Own Dog Food" (if
> we want Storyboard adopted at some point).

+1!

-- 
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] quickstart with containers deployment failed

[Steven Hardy]

On Sun, Jan 14, 2018 at 7:46 AM, Moshe Levi  wrote:
> Hi,
>
>
>
> We are trying to add container support ovs hw offload.
>
> We were able to do the deployment  a few weeks ago, but now we getting an
> errors .
>
> Jan 14 07:14:32 localhost os-collect-config: "2018-01-14 07:14:28,568
> WARNING: 18476 -- retrying pulling image:
> 192.168.24.1:8787/tripleomaster/centos-binary-neutron-server:current-tripleo",
>
> Jan 14 07:14:32 localhost os-collect-config: "2018-01-14 07:14:31,587
> WARNING: 18476 -- docker pull failed: Get
>
> https://192.168.24.1:8787/v1/_ping: dial tcp 192.168.24.1:8787: getsockopt:
> connection refused",

Sounds like the docker registry is not running on the undercloud?

How does your environment compare to these outputs:

(undercloud) [stack@undercloud tripleo-heat-templates]$ sudo systemctl
status docker-distribution
● docker-distribution.service - v2 Registry server for Docker
   Loaded: loaded
(/usr/lib/systemd/system/docker-distribution.service; enabled; vendor
preset: disabled)
   Active: active (running) since Fri 2018-01-12 11:39:25 UTC; 2 days ago
 Main PID: 5859 (registry)
   CGroup: /system.slice/docker-distribution.service
   └─5859 /usr/bin/registry serve
/etc/docker-distribution/registry/config.yml


(undercloud) [stack@undercloud tripleo-heat-templates]$ sudo netstat
-taupen | grep registry
tcp0  0 192.168.24.1:8787   0.0.0.0:*
LISTEN  0  47530  5859/registry

(undercloud) [stack@undercloud tripleo-heat-templates]$ curl
http://192.168.24.1:8787/v2/_catalog
{"repositories":["tripleomaster/centos-binary-aodh-api","tripleomaster/centos-binary-aodh-evaluator","tripleomaster/centos-binary-aodh-listener","tripleomaster/centos-binary-aodh-notifier","tripleomaster/centos-binary-ceilometer-central","tripleomaster/centos-binary-ceilometer-compute","tripleomaster/centos-binary-ceilometer-notification","tripleomaster/centos-binary-cinder-api","tripleomaster/centos-binary-cinder-scheduler","tripleomaster/centos-binary-cinder-volume","tripleomaster/centos-binary-cron","tripleomaster/centos-binary-glance-api","tripleomaster/centos-binary-gnocchi-api","tripleomaster/centos-binary-gnocchi-metricd","tripleomaster/centos-binary-gnocchi-statsd","tripleomaster/centos-binary-haproxy","tripleomaster/centos-binary-heat-api","tripleomaster/centos-binary-heat-api-cfn","tripleomaster/centos-binary-heat-engine","tripleomaster/centos-binary-horizon","tripleomaster/centos-binary-iscsid","tripleomaster/centos-binary-keystone","tripleomaster/centos-binary-mariadb","tripleomaster/centos-binary-memcached","tripleomaster/centos-binary-neutron-dhcp-agent","tripleomaster/centos-binary-neutron-l3-agent","tripleomaster/centos-binary-neutron-metadata-agent","tripleomaster/centos-binary-neutron-openvswitch-agent","tripleomaster/centos-binary-neutron-server","tripleomaster/centos-binary-nova-api","tripleomaster/centos-binary-nova-compute","tripleomaster/centos-binary-nova-conductor","tripleomaster/centos-binary-nova-consoleauth","tripleomaster/centos-binary-nova-libvirt","tripleomaster/centos-binary-nova-novncproxy","tripleomaster/centos-binary-nova-placement-api","tripleomaster/centos-binary-nova-scheduler","tripleomaster/centos-binary-panko-api","tripleomaster/centos-binary-rabbitmq","tripleomaster/centos-binary-redis","tripleomaster/centos-binary-swift-account","tripleomaster/centos-binary-swift-container","tripleomaster/centos-binary-swift-object","tripleomaster/centos-binary-swift-proxy-server"]}
(undercloud) [stack@undercloud tripleo-heat-templates]$


> see log below [1].
>
> We tried to run
>
> openstack overcloud container image tag discover   --image
> trunk.registry.rdoproject.org/master/centos-binary-base:current-tripleo-rdo
> --tag-from-label rdo_version
>
>
>
> and we are getting the errors below [2]

Ok this looks like a different problem, does the quickstart generated
overcloud-prep-containers.sh script work?  What --release argument did
you give to quickstart?

This may be a docs issue or bug in the discover CLI as running with
the same image/tag also fails for me, but the
overcloud-prep-containers.sh script (which doesn't use the discover
CLI) works fine.

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

[openstack-dev] [mistral] Adding Adriano Petrich to the core team

[Renat Akhmerov]

Hi,

I’d like to promote Adriano Petrich to the Mistral core team. Adriano has shown 
the good review rate and quality at least over the last two cycles and 
implemented several important features (including new useful YAQL/JINJA 
functions).

Please vote whether you agree to add Adriano to the core team.

Adriano’s statistics: 
http://stackalytics.com/?module=mistral-group&release=queens&user_id=apetrich

Thanks

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