Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Tony Breeds]

On Tue, Apr 03, 2018 at 02:05:35PM +0200, Elõd Illés wrote:
> Hi,
> 
> These patches probably solve the issue, if someone could review them:
> 
> https://review.openstack.org/#/c/557005/
> 
> and
> 
> https://review.openstack.org/#/c/557006/
> 
> Thanks,

Thanks for digging into that.  I've approved these even though they
don't have a +2 from the neutron stable team.  They look safe as the
only impact tests, unblock the gate and also have +1's from subject
matter experts.

Yours Tony.


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] [all][requirements] uncapping eventlet

[Tony Breeds]

On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:

> My understanding of our use of upper constraints was that this should
> (almost) always be the case for (almost) all dependencies.  We should
> rely on constraints instead of requirements caps. Capping libs like
> pbr or eventlet and any other that is in use globally is incredibly
> difficult to work with when you want to uncap it because you have to
> coordinate globally. Instead if using constraints you just bump the
> constraint and are done.

Part of the reason that we have the caps it to prevent the tools that
auto-generate the constraints syncs from considering these versions and
then depending on the requirements team to strip that from the bot
change before committing (assuming it passes CI).

Once the work Doug's doing is complete we could consider tweaking the
tools to use a different mechanism, but that's only part of the reason
for the caps in g-r.

Yours Tony.


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] [nova] [placement] placement update 18-14

[TETSURO NAKAMURA]

Hi Novaers,

On 2018/04/07 6:41, Eric Fried wrote:

Some negotiation happened with regard to when/if the fixes for
shared providers is going to happen. I'm not sure how that resolved,
if someone can follow up with that, that would be most excellent.


This is the subject of another thread [2] that's still "dangling".  We
discussed it in the sched meeting this week [3] and concluded [4] that
we shouldn't do it in Rocky.  BUT tetsuro later pointed out that part of
the series in question [5] is still needed to satisfy NRP-in-alloc-cands
(return the whole tree's providers in provider_summaries - even the ones
that aren't providing resource to the request).  That patch changes
behavior, so needs a microversion (mostly done already in that patch),
so needs a spec.  We haven't yet resolved whether this is truly needed,
so haven't assigned a body to the spec work.


Specs are where we discuss whether proposed functions are truly needed, 
so I've uploaded the spec[7] and put my thoughts there :)


[7] https://review.openstack.org/#/c/559466/

The implementation is in [8]. I've also submitted on it several patches 
for nested scenario.


[8] https://review.openstack.org/#/c/558045/



[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128944.html
[3]
http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-91
[4]
http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-137
[5] https://review.openstack.org/#/c/558045/
[6]
http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-04-02-14.00.log.html#l-104


P.S.
The hottest news in Japan this week is Shohei Otani's home runs @Los 
Angeles Angels. He started playing in MLB this year.

You should +2 on this without discussions.

Thanks!

--
Tetsuro Nakamura 
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan



__
OpenStack Development Mailing 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] [Vitrage] New proposal for analysis.

[MinWookKim]

Hello Ifat,

 

I'll update the BP soon. : )


Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Sunday, April 8, 2018 6:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Sounds like a good idea :)

 

Thanks,

Ifat

 

From: MinWookKim mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org> >
Date: Friday, 6 April 2018 at 12:07
To: "'OpenStack Development Mailing List (not for usage questions)'"
mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

If possible, could i write a blueprint based on what we discussed?
(architecture, specs)

 

After checking the blueprint, it would be better to proceed with specific
updates on the various issues.

what do you think?

 

Thanks.

 

Best regards,

Minwook.

From: MinWookKim [mailto:delightw...@ssu.ac.kr] 
Sent: Thursday, April 5, 2018 10:53 AM
To: 'OpenStack Development Mailing List (not for usage questions)'
Subject: RE: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for the good comments.

 

It was very helpful.

 

As you said, I tested for std.ssh, and I was able to get much better
results.

 

I am confident that this is what I want.

 

We can use std.ssh to provide convenience to users with a much more
efficient way to configure shell scripts / monitoring agent automation(for
Zabbix history,etc) / other commands.

 

In addition, std_actions.py contained a number of features that could be
used for this proposal (such as HTTP).

 

So if we actively use and utilize the actions in std_actions.py, we might
be able to construct neat code without the duplicate functionality that you
worried about.

 

It has been a great help.

 

In addition, I also agree that Vitrage action is required for Mistral.

 

If possible, I might be able to do that in the future.(ASAP)

 

Thank you.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Wednesday, April 4, 2018 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

I discussed this issue with a Mistral contributor. 

Mistral has a long list of actions that can be used. Specifically, you can
use the std.ssh action to execute shell scripts.

 

Some useful commands:

 

mistral action-list

mistral action-get 

 

I’m not sure about the output of the std.ssh, and whether you can get it
from the action. I suggest you try it and see how it works.

The action is implemented here:
https://github.com/openstack/mistral/blob/master/mistral/actions/std_actions
.py 

 

If std.ssh does not suit your needs, you also have an option to implement
and run your own action in Mistral (either as an ssh action or as a python
code). 

And BTW, it is not related to your current use case, but we can also add
Vitrage actions to Mistral, so the user can access Vitrage information (get
topology, get alarms) from Mistral workflows. 

 

Best regards,

Ifat

 

 

From: MinWookKim mailto:delightw...@ssu.ac.kr> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org> >
Date: Tuesday, 3 April 2018 at 15:19
To: "'OpenStack Development Mailing List (not for usage questions)'"
mailto:openstack-dev@lists.openstack.org> >
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hello Ifat,

 

Thanks for your reply.

 

Your comments have been a great help to the proposal.  (sorry, I did not
think we could use Mistral).

 

If we use the Mistral workflow for the proposal, we can get better results
(we can get good results on performance and code conciseness).

 

Also, if we use the Mistral workflow, we do not need to write any
unnecessary code.

 

Since I don't know about mistral yet, I think it would be better to do the
most efficient design including mistral after grasping it.

 

If we run a check through a Mistral workflow, how about providing users
with a choice of tools that have the capability to perform checks?

 

We can get the results of the check through the Mistral and tools, but I
think we need the least functionality to manage them. What do you think?

 

I attached a picture of the actual UI that I simply implemented. I hope it
helps you understand. (The parameter and content have no meaning and are a
simple example.) : )

 

Thanks.

 

Best regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 3, 2018 8:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] New proposal for analysis.

 

Hi Minwook,

 

Thanks for the 

[openstack-dev] [horizon][xstatic]How to handle xstatic if upstream files are modified

[Xinni Ge]

Hello, team.

Sorry for talking about xstatic repo for so many times.

I didn't realize xstatic repositories should be provided with exactly the
same file as upstream, and should have talked about it at very first.

I modified several upstream files because some of them files couldn't be
used directly under my expectation.

For example,  {{ }} are used in some original files as template tags, but
Horizon adopts {$ $} in angular module, so I modified them to be recognized
properly.

Another major modification is that css files are converted into scss files
to solve some css import issue previously.
Besides, after collecting statics, some png file paths in css cannot be
referenced properly and shown as 404 errors, I also modified css itself to
handle this issues.

I will recheck all the un-matched xstatic repositories and try to replace
with upstream  files as much as I can.
But I if I really have to modify some original files, is it acceptable to
still use it as embedded files with license info appeared at the top?


Best Regards,
Xinni Ge
__
OpenStack Development Mailing 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] [infra][qa][requirements] Pip 10 is on the way

[Paul Belanger]

On Sat, Apr 07, 2018 at 12:56:31AM -0700, Arun SAG wrote:
> Hello,
> 
> On Thu, Apr 5, 2018 at 5:39 PM, Paul Belanger  wrote:
> 
> > Yah, I agree your approach is the better, i just wanted to toggle what was
> > supported by default. However, it is pretty broken today.  I can't imagine
> > anybody actually using it, if so they must be carrying downstream patches.
> >
> > If we think USE_VENV is valid use case, for per project VENV, I suggest we
> > continue to fix it and update neutron to support it.  Otherwise, we maybe 
> > should
> > rip and replace it.
> 
> I work for Yahoo (Oath). We use USE_VENV a lot in our CI. We use VENVs
> to deploy software to
> production as well. we have some downstream patches to devstack to fix
> some issues with
> USE_VENV feature, i would be happy to upstream them. Please do not rip
> this out. Thanks.
> 
Yes, please upstream them if at all possible. I've been tracking all the fixes
so far at https://review.openstack.org/552939/ but still having an issue with
rootwrap.  I think clarkb managed to fix this in his patchset.

Paul

__
OpenStack Development Mailing 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] [OVN] Tempest API / Scenario tests and OVN metadata

[Gary Kotton]

Hi,
There are some tempest tests that check realization of resources on the 
networking platform and connectivity. Here things are challenging as each 
networking platform may be more restrictive than the upstream ML2 plugin. My 
thinking here is that we should leverage the tempest plugins for each 
networking platform and they can overwrite the problematic tests and address 
them as suitable for the specific plugin.
Thanks
Gary

From: Miguel Angel Ajo Pelayo 
Reply-To: OpenStack List 
Date: Saturday, April 7, 2018 at 8:56 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] [OVN] Tempest API / Scenario tests and 
OVN metadata

this issue isn't only for networking ovn, please note that it happens with a 
flew other vendor plugins (like nsx), at least this is something we have found 
in downstream certifications.

Cheers,
On Sat, Apr 7, 2018, 12:36 AM Daniel Alvarez 
mailto:dalva...@redhat.com>> wrote:


> On 6 Apr 2018, at 19:04, Sławek Kapłoński 
> mailto:sla...@kaplonski.pl>> wrote:
>
> Hi,
>
> Another idea is to modify test that it will:
> 1. Check how many ports are in tenant,
> 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it is 
> now,
> 3. Try to add 2 ports - exactly as it is now,
>
Cool, I like this one :-)
Good idea.

> I think that this should be still backend agnostic and should fix this 
> problem.
>
>> Wiadomość napisana przez Sławek Kapłoński 
>> mailto:sla...@kaplonski.pl>> w dniu 06.04.2018, o godz. 
>> 17:08:
>>
>> Hi,
>>
>> I don’t know how networking-ovn is working but I have one question.
>>
>>
>>> Wiadomość napisana przez Daniel Alvarez Sanchez 
>>> mailto:dalva...@redhat.com>> w dniu 06.04.2018, o 
>>> godz. 15:30:
>>>
>>> Hi,
>>>
>>> Thanks Lucas for writing this down.
>>>
>>> On Thu, Apr 5, 2018 at 11:35 AM, Lucas Alvares Gomes 
>>> mailto:lucasago...@gmail.com>> wrote:
>>> Hi,
>>>
>>> The tests below are failing in the tempest API / Scenario job that
>>> runs in the networking-ovn gate (non-voting):
>>>
>>> neutron_tempest_plugin.api.admin.test_quotas_negative.QuotasAdminNegativeTestJSON.test_create_port_when_quotas_is_full
>>> neutron_tempest_plugin.api.test_routers.RoutersIpV6Test.test_router_interface_status
>>> neutron_tempest_plugin.api.test_routers.RoutersTest.test_router_interface_status
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_prefixlen
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_quota
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_subnet_cidr
>>>
>>> Digging a bit into it I noticed that with the exception of the two
>>> "test_router_interface_status" (ipv6 and ipv4) all other tests are
>>> failing because the way metadata works in networking-ovn.
>>>
>>> Taking the "test_create_port_when_quotas_is_full" as an example. The
>>> reason why it fails is because when the OVN metadata is enabled,
>>> networking-ovn will metadata port at the moment a network is created
>>> [0] and that will already fulfill the quota limit set by that test
>>> [1].
>>>
>>> That port will also allocate an IP from the subnet which will cause
>>> the rest of the tests to fail with a "No more IP addresses available
>>> on network ..." error.
>>>
>>> With ML2/OVS we would run into the same Quota problem if DHCP would be
>>> enabled for the created subnets. This means that if we modify the current 
>>> tests
>>> to enable DHCP on them and we account this extra port it would be valid for
>>> all networking-ovn as well. Does it sound good or we still want to isolate 
>>> quotas?
>>
>> If DHCP will be enabled for networking-ovn, will it use one more port also 
>> or not? If so then You will still have the same problem with DHCP as in 
>> ML2/OVS You will have one port created and for networking-ovn it will be 2 
>> ports.
>> If it’s not like that then I think that this solution, with some comment in 
>> test code why DHCP is enabled should be good IMO.
>>
>>>
>>> This is not very trivial to fix because:
>>>
>>> 1. Tempest should be backend agnostic. So, adding a conditional in the
>>> tempest test to check whether OVN is being used or not doesn't sound
>>> correct.
>>>
>>> 2. Creating a port to be used by the metadata agent is a core part of
>>> the design implementation for the metadata functionality [2]
>>>
>>> So, I'm sending this email to try to figure out what would be the best
>>> approach to deal with this problem and start working towards having
>>> that job to be voting in our gate. Here are some ideas:
>>>
>>> 1. Simple disable the tests that are affected by the metadata approach.
>>>
>>> 2. Disable metadata for the tempest API / Scenario tests (here's a
>>> test patch doing it [3])
>>>
>>> IMHO, we don't want to do this as metadata is likely to be enabled in all 
>>> the
>>> clouds either using ML2/OVS or OVN so it's good to keep exercising
>>> this part.
>>>
>>>
>>> 3. Same as 1. but also create similar 

Re: [openstack-dev] [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

[resending to include OSP devs ]

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Wed, Apr 4, 2018 at 7:23 PM, Yaniv Lavi  wrote:

> [resending to include KubeVirt devs ]
>
> YANIV LAVI
>
> SENIOR TECHNICAL PRODUCT MANAGER
>
> Red Hat Israel Ltd. 
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
> ylavi
>   TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat 
>    Red Hat 
> 
>
>
> On Wed, Apr 4, 2018 at 7:07 PM, Yaniv Lavi  wrote:
>
>> Hi,
>> I'd like to go one step back and discuss why we should try to do this on
>> the high level.
>>
>> For the last 5-10 years of KVM development, we are pragmatically
>> providing the Linux host level APIs via project specific host
>> agents/integration code (Nova agent, oVirt host agent, virt-manager).
>> In recent time we see new projects that have similar requirements
>> (Cockpit, different automation tool, KubeVirt), this means that all of the
>> Linux virt stack consumers are reinventing the wheel and using very
>> different paths to consume the partial solutions that are provided today.
>>
>> The use of the Linux virt stack is well defined by the existing projects
>> scope and it makes a lot of sense to try to provide the common patterns via
>> the virt stack directly as a host level API that different client or
>> management consume.
>> The main goal is to improve the developer experience for virtualization
>> management applications with an API set that is useful to the entire set of
>> tools (OSP, oVirt, KubeVirt, Cockpit and so on).
>>
>> The Linux virt developer community currently is not able to provide best
>> practices and optimizations from single node knowledge. This means that all
>> of that smarts is locked to the specific project integration in the good
>> case or not provided at all and the projects as a whole lose from that.
>> When testing the Linux virt stack itself and since each project has
>> different usage pattern, we lose the ability to test abilities on the lower
>> level making the entire stack less stable and complete for new features.
>>
>> This also limits the different projects ability to contribute back to the
>> Linux stack based on their user and market experience for others in open
>> source to gain.
>>
>> I understand this shift is technically challenging for existing projects,
>> but I do see value in doing this even for new implementation like Cockpit
>> and KubeVirt.
>> I also believe that the end result could be appealing enough to cause
>> project like OSP, virt-manager and oVirt to consider to reduce the existing
>> capabilities of their host side integrations/agents to shims on the host
>> level and reuse the common/better-tested pattern as clients that was
>> developed against the experience of the different projects.
>>
>> I call us all to collaborate and try to converge on a solution that will
>> help all in the long term in the value you get from the common base.
>>
>>
>> Thanks,
>>
>> YANIV LAVI
>>
>> SENIOR TECHNICAL PRODUCT MANAGER
>>
>> Red Hat Israel Ltd. 
>>
>> 34 Jerusalem Road, Building A, 1st floor
>>
>> Ra'anana, Israel 4350109
>>
>> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
>> ylavi
>>   TRIED. TESTED. TRUSTED. 
>> @redhatnews    Red Hat 
>>    Red Hat 
>> 
>>
>>
>> On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
>> wrote:
>>
>>> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
>>> > >
>>> > > > One more thing could be automatically figuring out best values
>>> based on
>>> > > > libosinfo-provided data.
>>> > > >
>>> > > > 2) Policies
>>> > > >
>>> > > > Lot of the time there are parts of the domain definition that need
>>> to be
>>> > > > added, but nobody really cares about them.  Sometimes it's enough
>>> to
>>> > > > have few templates, another time you might want to have a policy
>>> > > > per-scenario and want to combine them in various ways.  For
>>> example with
>>> > > > the data provided by point 1).
>>> > > >
>>> > > > For example if you want PCI-Express, you need the q35 machine
>>> type, but
>>> > > > you don't really want to care about the machine type.  Or you want
>>

[openstack-dev] PBR and Pipfile

[Gaetan]

Hello OpenStack dev community,

I am currently working on the support of Pipfile for PBR ([1]), and I also
follow actively the work on pipenv, which is now in officially supported by
PyPA.

There have been recently an intense discussion on the difficulties about
Python libraries development, and how to spread good practices [2] on the
pipenv community and enhance its documentation.

As a user of PBR, and big fan of it, I try to bridge the link between pbr
and pipenv (with [1]) but I am interested in getting the feedback of Python
developers of OpenStack that may have much more experience using PBR and
more generally packaging python libraries than me.

The main point is that packaging an application is quite easy or at least
understandable by newcomers, using `requirements.txt` or `Pipfile`+
`Pipfile.lock` with pipenv. At least it is easily "teachable".

Packaging a library is harder, and require to explain why by default
`requirements.txt`(or `Pipfile`) does not work. Some "advanced"
documentation exists but it still hard to understand why Python ended up
with something complex for libraries ([3]).
One needs to ensure `install_requires`declares the dependencies to that pip
can find them during transitive dependencies installation (that is,
installing the dependencies of a given dependency). PBR helps on this point
but some does not want its other features.

There is also works on PEP around pyproject.toml ([4]), which looks quite
similar to PBR's setup.cfg. What do you think about it?

My opinion is this difference in behaviour between lib and app has
technical reasons, but as a community we would gain a lot of unifying both
workflows. I am using PBR + a few hacks [5], and I am pretty satisfied with
the overall result.

So, in short, I simply start a general thread here to retrieve your general
feedback around these points.

Thanks for your feedbacks

Gaetan

[1]: https://review.openstack.org/#/c/524436/
[2]: https://github.com/pypa/pipenv/issues/1911
[3]: https://docs.pipenv.org/advanced/#pipfile-vs-setup-py
[4]: https://www.python.org/dev/peps/pep-0518/
[5]: library:
  - pipenv to maintain Pipfile and Pipfile.lock
  - Pipfile.lock not tracked  (local reproductivity),
  - pipenv-to-requirements [6] to generate a `requirements.txt` without
version freeze, also tracked
applications:
  - pipenv to maintain Pipfile and Pipfile.lock
  - Pipfile.lock not tracked (global reproductivity),
  - pipenv-to-requirements [6] to generate a `requirements.txt` and
`requirements-dev.txt` with version freeze, both tracked
The development done with [1] should allow to get rid of [6].

[6] https://github.com/gsemet/pipenv-to-requirements
-
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

[openstack-dev] Patches on PBR

[Gaetan]

Hello,

I have started a few patch on PBR which fail, but I am not sure the reason,
they seem related to something external of my changes:

- https://review.openstack.org/#/c/559484/6: 'pbr boostrap' command. Error
seems:"testtools.matchers._impl.MismatchError: b'STARTING test server
pbr_testpackage.wsgi' not in b''"
- https://review.openstack.org/#/c/558181/: proposal for update of sem-ver
3 doc
- https://review.openstack.org/#/c/524436/: Pipfile support (still WIP)

Can you review them?
Thanks,

-
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