Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Won]

Thank you for your reply Ifat.

The alertmanager.yml file already contains 'send_resolved:true'.
However, the alarm does not disappear from the alarm list and the entity
graph even if the alarm is resolved, the alarm manager makes a silence, or
removes the alarm rule from Prometheus.
The only way to remove alarms is to manually remove them from the db. Is
there any other way to remove the alarm?
Entities(vm) that run on multi nodes in the rocky version have similar
symptoms. There was a symptom that the Entities created on the multi-node
would not disappear from the Entity Graph even after deletion.
Is this a bug in rocky version?

Best Regards,
Won

2018년 10월 3일 (수) 오후 5:46, Ifat Afek 님이 작성:

> Hi,
>
> In the alertmanager.yml file you should have a receiver for Vitrage.
> Please verify that it includes "send_resolved: true". This is required for
> Prometheus to notify Vitrage when an alarm is resolved.
>
> The full Vitrage receiver definition should be:
>
> - name: **
>
>   webhook_configs:
>
>   - url: **  # example: 'http://127.0.0.1:8999/v1/event
> '
>
> send_resolved: true
>
> http_config:
>
>   basic_auth:
>
> username: **
>
> password: **
>
> Hope it helps,
> Ifat
>
>
> On Tue, Oct 2, 2018 at 7:51 AM Won  wrote:
>
>> I have some problems with Prometheus alarms in vitrage.
>> I receive a list of alarms from the Prometheus alarm manager well, but
>> the alarm does not disappear when the problem(alarm) is resolved. The alarm
>> that came once in both the alarm list and the entity graph does not
>> disappear in vitrage.  The alarm sent by zabbix disappears when alarm
>> solved, I wonder how to clear the Prometheus alarm from vitrage and how to
>> update the alarm automatically like zabbix.
>> thank you.
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing 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] [goal][python3] week 7 update

[Doug Hellmann]

Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> Doug Hellmann  writes:
>>
>>> == Things We Learned This Week ==
>>>
>>> When we updated the tox.ini settings for jobs like pep8 and release
>>> notes early in the Rocky session we only touched some of the official
>>> repositories. I'll be working on making a list of the ones we missed so
>>> we can update them by the end of Stein.
>>
>> I see quite a few repositories with tox settings out of date (about 350,
>> see below). Given the volume, I'm going to prepare the patches and
>> propose them a few at a time over the next couple of weeks.
>
> Zuul looked bored this morning so I went ahead and proposed a few of the
> larger batches of these changes for the Charms, OpenStack Ansible, and
> Horizon teams. TripleO also has quite a few, but since we know the gate
> is unstable I will hold off on those for now.
>
> There will be more patches when there is CI capacity again.
>
> Doug

All of these patches have now been proposed.

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] [nova][xenapi] can we deprecate the xenapi-specific 'nova-console' service?

[melanie witt]

Greetings Devs and Ops,

Today I noticed that our code does not handle the 'nova-console' service 
properly in a multi-cell deployment and given that no one has complained 
or reported bugs about it, we're wondering if anyone still uses the 
nova-console service. The documentation [1] says that the nova-console 
service is a "XenAPI-specific service that most recent VNC proxy 
architectures do not use."


Can anyone from xenapi land shed some light on whether the nova-console 
service is still useful in deployments using the xenapi driver, or is it 
an old relic that we should deprecate and remove?


Thanks for your help,
-melanie

[1] https://docs.openstack.org/nova/latest/admin/remote-console-access.html

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

Re: [openstack-dev] [goals][python3][heat][stable] how should we proceed with ocata branch

[Matt Riedemann]

On 10/3/2018 11:21 AM, Zane Bitter wrote:

That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?


I think we agreed on closing the branch, and Rico was looking into the 
procedure for how to actually do that.



Doug

[1]https://review.openstack.org/#/c/597272/


I'm assuming heat-agents is a service, not a library, since it doesn't 
show up in upper-constraints.


It's a guest agent, so neither :)

Based on that, does heat itself plan on putting its stable/ocata 
branch into extended maintenance mode and if 


Wearing my Red Hat hat, I would be happy to EOL it. But wearing my 
upstream hat, I'm happy to keep maintaining it, and I was not proposing 
that we EOL heat's stable/ocata as well.


so, does that mean EOLing the heat-agents stable/ocata branch could 
cause problems for the heat stable/ocata branch? In other words, will 
it be reasonable to run CI for stable/ocata heat changes against a 
heat-agents ocata-eol tag?


I don't think that's a problem. The guest agents rarely change, and I 
don't think there's ever been a patch backported by 4 releases.


OK, cool, sounds like killing the heat-agent ocata branch is the thing 
to do then.


--

Thanks,

Matt

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

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

[Matt Riedemann]

On 10/3/2018 9:45 AM, Jay S. Bryant wrote:

Team,

We had discussed the possibility of adding Gorka to the stable core team 
during the PTG.  He does review a number of our backport patches and is 
active in that area.


If there are no objections in the next week I will add him to the list.

Thanks!

Jay (jungleboyj)


+1 from me in the stable-maint-core peanut gallery.

--

Thanks,

Matt

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

[openstack-dev] [nova] team photos from the Stein PTG

[melanie witt]

Hey all,

Sorry for not posting this earlier but here's a direct link to our photo 
folder on dropbox for the Stein PTG team photos:


https://www.dropbox.com/sh/2pmvfkstudih2wf/AAB--3TRAFaU2qN7GKDj_eZha/Nova?dl=0_nav_tracking=1

You can view and download them from there ^. I think they came out 
really nice and the funny ones gave me a chuckle. :)


Cheers,
-melanie

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

[openstack-dev] [goals][python3][barbican][monasca][neutron][charms][ansible][telemetry][trove][stable] completing zuul settings migration

[Doug Hellmann]

We have 7 teams still working on the zuul setting migrations as part of
the python3-first goal [1]. 

Quite a few of the changes are on stable branches, so will need
attention from the stable teams for each project. If you need help
reviewing those stable branch patches, please speak up so we can find
some folks on the stable team to provide +2 votes.

Some of the patches are failing the test jobs, probably because of
bitrot on older stable branches. Those may need extra attention from
project team members to fix, depending on the nature of the problems.

I would like to have this portion of the work done by the first
milestone, and I think we're close enough to do it. Please look through
the list of patches for your project and ensure they are in your review
queues.

Thanks,
Doug

[1] 
https://review.openstack.org/#/q/topic:python3-first+is:open+message:%22import+zuul+job+settings+from+project-config%22

__
OpenStack Development Mailing 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] [manila] nominating Amit Oren for manila core

[Dustin Schoenbrun]

+1

---
Dustin Schoenbrun
Senior OpenStack Quality Engineer
Red Hat, Inc.
dscho...@redhat.com


On Wed, Oct 3, 2018 at 12:52 PM Goutham Pacha Ravi 
wrote:

> +1
>
> --
> Goutham Pacha Ravi
>
>
> On Tue, Oct 2, 2018 at 10:59 AM Tom Barron  wrote:
> >
> > Amit Oren has contributed high quality reviews in the last couple of
> > cycles so I would like to nominated him for manila core.
> >
> > Please respond with your +1 or -1 votes.  We'll hold voting open for 7
> > days.
> >
> > Thanks,
> >
> > -- Tom Barron (tbarron)
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Glance API Caching Enhancements for Edge Computing

[Waines, Greg]

Glance Team,

I am following up on discussions in the edge-computing PTG meetings.
There were discussions on potential enhancements to Glance API Caching for 
support of the proposed MVP Edge Architecture.
And I took the action to write up a blueprint and a specification for these 
enhancements ... and will follow up with implementation.

I thought I’d start the discussions on the mailing list ... and if everyone is 
still in agreement,
then I’ll move the high-level definition/requirements to Glance’s Launchpad (or 
Storyboard?) and
write up a Glance spec and review it in Gerrit.

THE PROPOSAL:

Enhance Glance API Caching such that

a)   It works between two Glance Services (i.e. Glance at a Central 
OpenStack Cloud and Glance at an Edge OpenStack Cloud)

· i.e. current Glance API Caching only works with external webservers

b)   Enable the Edge Cloud Glance API Caching to support the ability to 
locally use those cached images (e.g. nova boot ...)
even when network connectivity is lost to the Central Cloud Glance Service

· i.e. image meta-data is required in order to service a ‘nova boot 
...’, and
   today image meta-data is NOT cached by Glance API Caching.

The proposed solution should generically work between any two Glance Services.
e.g.

· in a Multi-Region Environment,

· in a StarlingX Distributed Cloud,

· etc.

The proposed solution need only deal with the Edge Cloud Glance talking to a 
single Central Cloud Glance.


Let me know if you have any a questions or comments,
Greg.



p.s.
Background:
More info on the edge-computing group’s MVP Edge Architecture can be found here:
 
https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0
and
 
https://docs.google.com/document/d/1Mq6bSm_lES56S4gygEuhmMbEeCI2nBFl_U5vl50wih8/edit?ts=5baa654e#heading=h.ncllqse6iw0u
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Tenks

[Julia Kreger]

On Wed, Oct 3, 2018 at 9:17 AM Mark Goddard  wrote:

>
>
> On Wed, 3 Oct 2018 at 17:10, James LaBarre  wrote:
>
>> On 10/2/18 10:37 AM, Mark Goddard wrote:
>>
>>
>>
>> On Tue, 2 Oct 2018 at 14:03, Jay Pipes  wrote:
>>
>>> On 10/02/2018 08:58 AM, Mark Goddard wrote:
>>> > Tenks is a project for managing 'virtual bare metal clusters'. It aims
>>> > to be a drop-in replacement for the various scripts and templates that
>>> > exist in the Ironic devstack plugin for creating VMs to act as bare
>>> > metal nodes in development and test environments. Similar code exists
>>> in
>>> > Bifrost and TripleO, and probably other places too. By focusing on one
>>> > project, we can ensure that it works well, and provides all the
>>> features
>>> > necessary as support for bare metal in the cloud evolves.
>>>
>>> How does Tenks relate to OVB?
>>>
>>>
>>> https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html
>>
>>
>> Good question. As far as I'm aware, OVB is a tool for using an OpenStack
>> cloud to host the virtual bare metal nodes, and is typically used for
>> testing TripleO. Tenks does not rule out supporting this use case in
>> future, but currently operates more like the Ironic devstack plugin, using
>> libvirt/KVM/QEMU as the virtualisation provider.
>>
>>
>> I'm presuming, as Tenks is supposed to support multiple hypervisors, that
>> a multi-arch environment would be supported (different node types on
>> different architectures).  Or does this even enter into the consideration?
>>
>
> I think that would be a good feature to consider in future, although it's
> not something that works currently.
>

I think it would be a very important thing to have as we branch out into
different architectures. I would personally love to see an ARM64 CI job. To
actually put that job in place would mean major changes to VM creation
which would be beneficial to put in one place. Long story short, I'm all
for additional spoons.

> __
>> OpenStack Development Mailing 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] [Release-job-failures][neutron] Release of openstack/networking-bigswitch failed

[Doug Hellmann]

AdityaVaja  writes:

> Hello Doug,
>
> I was going to send out an email or drop in on IRC to check how to fix that.
>
> We accidentally pushed 13.0.1 on stable/queens, instead of 12.0.5. (13.x.x
> is rocky and 12.x.x is queens)
> Tried reverting the situation by pushing 12.0.5 for the same commit hash on
> queens, but that didn't work. Releases with commit hash can be compared
> here [1].
>
> Deleting the release from PYPI can be done, but deleting a tag from gerrit
> is not possible without allowing forcePush from project-config - afaik. But
> that seems like an extreme step.
> Not sure how to fix the situation, so I thought checking with
> openstack-release to get an idea.
>
> If your original suggestion of pushing 12.0.6 still stands, I can go ahead
> and do that.

I think that pushing 12.0.6 to a point on that branch after the
12.0.5/13.0.1 commit will produce a new release with version 12.0.6 that
works correctly.

Unfortunately, you're right that we don't have a good way to remove the
old 13.0.1 release and tag. In the past we have just ignored that and
moved on, although I think in some cases we did remove the package from
PyPI to avoid having it installed accidentally. I don't know how many of
your users are using pip to install the packages you build, so I don't
know how important it will be for you to do that.

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] [manila] nominating Amit Oren for manila core

[Goutham Pacha Ravi]

+1

--
Goutham Pacha Ravi


On Tue, Oct 2, 2018 at 10:59 AM Tom Barron  wrote:
>
> Amit Oren has contributed high quality reviews in the last couple of
> cycles so I would like to nominated him for manila core.
>
> Please respond with your +1 or -1 votes.  We'll hold voting open for 7
> days.
>
> Thanks,
>
> -- Tom Barron (tbarron)
>
>
> __
> OpenStack Development Mailing 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] [neutron] Please opt-in for neutron-lib patches

[Boden Russell]

On 10/3/18 10:16 AM, Eric Fried wrote:
> We would like networking-powervm to be included, and have proposed [5],
> but are wondering why we weren't picked up in [6]. Your email [1] says
>
> "If your project isn't in [3][4],
> but you think it should be; it maybe missing a recent neutron-lib
> version in your requirements.txt."
>
> What's "recent"? I see the latest (per the requirements project) is
> 1.19.0 and we have 1.18.0. Should we bump?
I must've accidentally missed powervm; thanks for following up.
The fact that you're not using neutron-lib 1.19.0 has nothing to do with it;
this was a user error.

It's probably a good idea to move up to 1.19.0 once neutron does [1].
Typically I will propose the bump for all such projects, but I was waiting
for the list of opt-in consumers before doing so.

[1] https://review.openstack.org/#/c/605690


__
OpenStack Development Mailing 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] Zuul job backlog

[Doug Hellmann]

Wesley Hayutin  writes:

[snip]

> The TripleO project has created a single node container based composable
> OpenStack deployment [2]. It is the projects intention to replace most of
> the TripleO upstream jobs with the Standalone deployment.  We would like to
> reduce our multi-node usage to a total of two or three multinode jobs to
> handle a basic overcloud deployment, updates and upgrades[a]. Currently in
> master we are relying on multiple multi-node scenario jobs to test many of
> the OpenStack services in a single job. Our intention is to move these
> multinode scenario jobs to single node job(s) that tests a smaller subset
> of services. The goal of this would be target the specific areas of the
> TripleO code base that affect these services and only run those there. This
> would replace the existing 2-3 hour two node job(s) with single node job(s)
> for specific services that completes in about half the time.  This
> unfortunately will reduce the overall coverage upstream but still allows us
> a basic smoke test of the supported OpenStack services and their deployment
> upstream.
>
> Ideally projects other than TripleO would make use of the Standalone
> deployment to test their particular service with containers, upgrades or
> for various other reasons.  Additional projects using this deployment would
> help ensure bugs are found quickly and resolved providing additional
> resilience to the upstream gate jobs. The TripleO team will begin review to
> scope out and create estimates for the above work starting on October 18
> 2018.  One should expect to see updates on our progress posted to the
> list.  Below are some details on the proposed changes.

[snip]

Thanks for all of the details, Wes. I know the current situation has
been hurting the TripleO team as well, so I'm glad to see a good plan in
place to address it. I look forward to seeing updates about the
progress.

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] [manila] nominating Amit Oren for manila core

[Ben Swartzlander]

On 10/02/2018 01:58 PM, Tom Barron wrote:
Amit Oren has contributed high quality reviews in the last couple of 
cycles so I would like to nominated him for manila core.


Please respond with your +1 or -1 votes.  We'll hold voting open for 7 
days.


+1


Thanks,

-- Tom Barron (tbarron)


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


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

[openstack-dev] [nova] State of NUMA live migration

[Artom Lifshitz]

> Yes, this is still happening. Mea culpa for not carrying the ball and
> maintaining visibility. There's work in nova to actually get it
> working, and in intel-nfv-ci to lay down the groundwork for eventual
> CI.
>
> In nova, the spec has been re-proposed for Stein [1]. There are some
> differences from the Rocky version, but based on what I've heard was
> discussed at Denver, it shouldn't be too controversial. There's a
> couple of nova patches up as well [2], but that's still pretty WIP
> given the changes in the spec. A bunch of patches from Rocky were
> abandoned because they're no longer applicable.
>
> In intel-nfv-ci, there's a whole stack of changes [3] that are mostly
> about technical debt and laying the groundwork to support multinode
> test environments, but there's also a WIP patch in there [4] that'll
> eventually actually test live migration.
>
> For now we have no upstream/public environment to run that on, so
> anyone who's involved will need their own env if they want to run the
> tests and/or play with the feature. Longer-term, I would like to have
> some form of upstream CI testing this, be it in the vanilla nodepool
> with nested virt and "fake" NUMA topologies, or a 3rd party CI with
> resources provided by an interested stakeholder.

Forgot the nova tag :(

> [1] https://review.openstack.org/#/c/599587/
> [2] 
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/numa-aware-live-migration
> [3] https://review.openstack.org/#/c/576602/
> [4] https://review.openstack.org/#/c/574871/6



-- 
--
Artom Lifshitz
Software Engineer, OpenStack Compute DFG

__
OpenStack Development Mailing 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] State of NUMA live migration

[Artom Lifshitz]

Yes, this is still happening. Mea culpa for not carrying the ball and
maintaining visibility. There's work in nova to actually get it
working, and in intel-nfv-ci to lay down the groundwork for eventual
CI.

In nova, the spec has been re-proposed for Stein [1]. There are some
differences from the Rocky version, but based on what I've heard was
discussed at Denver, it shouldn't be too controversial. There's a
couple of nova patches up as well [2], but that's still pretty WIP
given the changes in the spec. A bunch of patches from Rocky were
abandoned because they're no longer applicable.

In intel-nfv-ci, there's a whole stack of changes [3] that are mostly
about technical debt and laying the groundwork to support multinode
test environments, but there's also a WIP patch in there [4] that'll
eventually actually test live migration.

For now we have no upstream/public environment to run that on, so
anyone who's involved will need their own env if they want to run the
tests and/or play with the feature. Longer-term, I would like to have
some form of upstream CI testing this, be it in the vanilla nodepool
with nested virt and "fake" NUMA topologies, or a 3rd party CI with
resources provided by an interested stakeholder.

[1] https://review.openstack.org/#/c/599587/
[2] 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/numa-aware-live-migration
[3] https://review.openstack.org/#/c/576602/
[4] https://review.openstack.org/#/c/574871/6

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

[openstack-dev] [nova] We should fail to boot a server if PF passthrough is requested and we don't honor it, right?

[Matt Riedemann]

I came across [1] today while triaging a bug [2]. Unless I'm mistaken, 
the user has requested SR-IOV PF passthrough for their server and for 
whatever reason we can't find the PCI device for the PF passthrough port 
so we don't reflect the actual device MAC address on the port. Is that 
worth stopping the server create? Or is logging an ERROR enough here?


The reason being we get an IndexError here [3]. Ultimately if we found a 
PCI device but it's not whitelisted, we'll raise an exception anyway 
when building the port binding profile [4].


So is it reasonable to just raise PciDeviceNotFound whenever we can't 
find a PCI device on a compute host given a pci_request_id? In other 
words, it seems something failed earlier during scheduling and/or the 
PCI device resource claim if we get this far and things are still messed up.


[1] 
https://github.com/openstack/nova/blob/237ced4737a28728408eb30c3d20c6b2c13b4a8d/nova/network/neutronv2/api.py#L1426

[2] https://bugs.launchpad.net/nova/+bug/1795064
[3] 
https://github.com/openstack/nova/blob/237ced4737a28728408eb30c3d20c6b2c13b4a8d/nova/network/neutronv2/api.py#L1404
[4] 
https://github.com/openstack/nova/blob/237ced4737a28728408eb30c3d20c6b2c13b4a8d/nova/network/neutronv2/api.py#L1393


--

Thanks,

Matt

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

Re: [openstack-dev] [goals][python3][heat][stable] how should we proceed with ocata branch

[Doug Hellmann]

Zane Bitter  writes:

> On 3/10/18 9:42 AM, Matt Riedemann wrote:
>> On 10/3/2018 7:58 AM, Doug Hellmann wrote:
>>> There is one more patch to import the zuul configuration for the
>>> heat-agents repository's stable/ocata branch. That branch is apparently
>>> broken, and Zane suggested on the review [1] that we abandon the patch
>>> and close the branch.
>>>
>>> That patch is the only thing blocking the cleanup patch in
>>> project-config, so I would like to get a definitive answer about what to
>>> do. Should we close the branch, or does someone want to try to fix
>>> things up?
>
> I think we agreed on closing the branch, and Rico was looking into the 
> procedure for how to actually do that.

OK. I am going to abandon the patch to import the zuul settings
then. Abandoning all open patches is one of the early steps anyway, and
doing that now for this 1 patch will allow us to proceed with the
cleanup.

Doug

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

Re: [openstack-dev] [all] Zuul job backlog

[Wesley Hayutin]

On Fri, Sep 28, 2018 at 3:02 PM Matt Riedemann  wrote:

> On 9/28/2018 3:12 PM, Clark Boylan wrote:
> > I was asked to write a followup to this as the long Zuul queues have
> persisted through this week. Largely because the situation from last week
> hasn't changed much. We were down the upgraded cloud region while we worked
> around a network configuration bug, then once that was addressed we ran
> into neutron port assignment and deletion issues. We think these are both
> fixed and we are running in this region again as of today.
> >
> > Other good news is our classification rate is up significantly. We can
> use that information to go through the top identified gate bugs:
> >
> > Network Connectivity issues to test nodes [2]. This is the current top
> of the list, but I think its impact is relatively small. What is happening
> here is jobs fail to connect to their test nodes early in the pre-run
> playbook and then fail. Zuul will rerun these jobs for us because they
> failed in the pre-run step. Prior to zuulv3 we had nodepool run a ready
> script before marking test nodes as ready, this script would've caught and
> filtered out these broken network nodes early. We now notice them late
> during the pre-run of a job.
> >
> > Pip fails to find distribution for package [3]. Earlier in the week we
> had the in region mirror fail in two different regions for unrelated
> errors. These mirrors were fixed and the only other hits for this bug come
> from Ara which tried to install the 'black' package on python3.5 but this
> package requires python>=3.6.
> >
> > yum, no more mirrors to try [4]. At first glance this appears to be an
> infrastructure issue because the mirror isn't serving content to yum. On
> further investigation it turned out to be a DNS resolution issue caused by
> the installation of designate in the tripleo jobs. Tripleo is aware of this
> issue and working to correct it.
> >
> > Stackviz failing on py3 [5]. This is a real bug in stackviz caused by
> subunit data being binary not utf8 encoded strings. I've written a fix for
> this problem athttps://review.openstack.org/606184, but in doing so found
> that this was a known issue back in March and there was already a proposed
> fix,https://review.openstack.org/#/c/555388/3. It would be helpful if the
> QA team could care for this project and get a fix in. Otherwise, we should
> consider disabling stackviz on our tempest jobs (though the output from
> stackviz is often useful).
> >
> > There are other bugs being tracked by e-r. Some are bugs in the
> openstack software and I'm sure some are also bugs in the infrastructure. I
> have not yet had the time to work through the others though. It would be
> helpful if project teams could prioritize the debugging and fixing of these
> issues though.
> >
> > [2]http://status.openstack.org/elastic-recheck/gate.html#1793370
> > [3]http://status.openstack.org/elastic-recheck/gate.html#1449136
> > [4]http://status.openstack.org/elastic-recheck/gate.html#1708704
> > [5]http://status.openstack.org/elastic-recheck/gate.html#1758054
>
> Thanks for the update Clark.
>
> Another thing this week is the logstash indexing is behind by at least
> half a day. That's because workers were hitting OOM errors due to giant
> screen log files that aren't formatted properly so that we only index
> INFO+ level logs, and were instead trying to index the entire file,
> which some of which are 33MB *compressed*. So indexing of those
> identified problematic screen logs has been disabled:
>
> https://review.openstack.org/#/c/606197/
>
> I've reported bugs against each related project.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Greetings Clark and all,
The TripleO team would like to announce a significant change to the
upstream CI the project has in place today.

TripleO can at times consume a large share of the compute resources [1]
provided by the OpenStack upstream infrastructure team and OpenStack
providers.  The TripleO project has a large code base and high velocity of
change which alone can tax the upstream CI system [3]. Additionally like
other projects the issue is particularly acute when gate jobs are reset at
a high rate.  Unlike most other projects in OpenStack, TripleO uses
multiple nodepool nodes in each job to more closely emulate customer like
deployments.  While using multiple nodes per job helps to uncover bugs
that are not found in other projects, the resources used, the run time of
each job, and usability have proven to be challenging.  It has been a
challenge to maintain job run times, quality and usability for TripleO and
a challenge for the infra team to provide the required compute resources
for the project.

A simplification of our 

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

[Sean McGinnis]

On Wed, Oct 03, 2018 at 09:45:25AM -0500, Jay S. Bryant wrote:
> Team,
> 
> We had discussed the possibility of adding Gorka to the stable core team
> during the PTG.  He does review a number of our backport patches and is
> active in that area.
> 
> If there are no objections in the next week I will add him to the list.
> 
> Thanks!
> 
> Jay (jungleboyj)
> 

+1 from me. Gorka has shown to understand the stable policies and I think his
coming from a company that has a vested interest in stable backports would make
him a good candidate for stable core.


__
OpenStack Development Mailing 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] [goals][python3][heat][stable] how should we proceed with ocata branch

[Zane Bitter]

On 3/10/18 9:42 AM, Matt Riedemann wrote:

On 10/3/2018 7:58 AM, Doug Hellmann wrote:

There is one more patch to import the zuul configuration for the
heat-agents repository's stable/ocata branch. That branch is apparently
broken, and Zane suggested on the review [1] that we abandon the patch
and close the branch.

That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?


I think we agreed on closing the branch, and Rico was looking into the 
procedure for how to actually do that.



Doug

[1]https://review.openstack.org/#/c/597272/


I'm assuming heat-agents is a service, not a library, since it doesn't 
show up in upper-constraints.


It's a guest agent, so neither :)

Based on that, does heat itself plan on 
putting its stable/ocata branch into extended maintenance mode and if 


Wearing my Red Hat hat, I would be happy to EOL it. But wearing my 
upstream hat, I'm happy to keep maintaining it, and I was not proposing 
that we EOL heat's stable/ocata as well.


so, does that mean EOLing the heat-agents stable/ocata branch could 
cause problems for the heat stable/ocata branch? In other words, will it 
be reasonable to run CI for stable/ocata heat changes against a 
heat-agents ocata-eol tag?


I don't think that's a problem. The guest agents rarely change, and I 
don't think there's ever been a patch backported by 4 releases.


cheers,
Zane.

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

Re: [openstack-dev] [ironic] Tenks

[Mark Goddard]

On Wed, 3 Oct 2018 at 17:10, James LaBarre  wrote:

> On 10/2/18 10:37 AM, Mark Goddard wrote:
>
>
>
> On Tue, 2 Oct 2018 at 14:03, Jay Pipes  wrote:
>
>> On 10/02/2018 08:58 AM, Mark Goddard wrote:
>> > Tenks is a project for managing 'virtual bare metal clusters'. It aims
>> > to be a drop-in replacement for the various scripts and templates that
>> > exist in the Ironic devstack plugin for creating VMs to act as bare
>> > metal nodes in development and test environments. Similar code exists
>> in
>> > Bifrost and TripleO, and probably other places too. By focusing on one
>> > project, we can ensure that it works well, and provides all the
>> features
>> > necessary as support for bare metal in the cloud evolves.
>>
>> How does Tenks relate to OVB?
>>
>>
>> https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html
>
>
> Good question. As far as I'm aware, OVB is a tool for using an OpenStack
> cloud to host the virtual bare metal nodes, and is typically used for
> testing TripleO. Tenks does not rule out supporting this use case in
> future, but currently operates more like the Ironic devstack plugin, using
> libvirt/KVM/QEMU as the virtualisation provider.
>
>
> I'm presuming, as Tenks is supposed to support multiple hypervisors, that
> a multi-arch environment would be supported (different node types on
> different architectures).  Or does this even enter into the consideration?
>

I think that would be a good feature to consider in future, although it's
not something that works currently.

> __
> OpenStack Development Mailing 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] [neutron] Please opt-in for neutron-lib patches

[Eric Fried]

Hi Boden.

Love this initiative.

We would like networking-powervm to be included, and have proposed [5],
but are wondering why we weren't picked up in [6]. Your email [1] says

"If your project isn't in [3][4],
but you think it should be; it maybe missing a recent neutron-lib
version in your requirements.txt."

What's "recent"? I see the latest (per the requirements project) is
1.19.0 and we have 1.18.0. Should we bump?

Thanks,
efried

[5] https://review.openstack.org/#/c/607625/
[6] https://etherpad.openstack.org/p/neutron-sibling-setup

On 10/03/2018 10:43 AM, Boden Russell wrote:
> Just a friendly reminder that networking projects now need to opt-in for
> neutron-lib consumption patches [1].
> 
> Starting next week (September 8) I'd like to start basing consumption
> patches on those projects that have opted-in. If there are exceptions
> please let me know so we can track them accordingly.
> 
> Thanks
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/135063.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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Tenks

[James LaBarre]

On 10/2/18 10:37 AM, Mark Goddard wrote:



On Tue, 2 Oct 2018 at 14:03, Jay Pipes > wrote:


On 10/02/2018 08:58 AM, Mark Goddard wrote:
> Tenks is a project for managing 'virtual bare metal clusters'.
It aims
> to be a drop-in replacement for the various scripts and
templates that
> exist in the Ironic devstack plugin for creating VMs to act as bare
> metal nodes in development and test environments. Similar code
exists in
> Bifrost and TripleO, and probably other places too. By focusing
on one
> project, we can ensure that it works well, and provides all the
features
> necessary as support for bare metal in the cloud evolves.

How does Tenks relate to OVB?


https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html


Good question. As far as I'm aware, OVB is a tool for using an 
OpenStack cloud to host the virtual bare metal nodes, and is typically 
used for testing TripleO. Tenks does not rule out supporting this use 
case in future, but currently operates more like the Ironic devstack 
plugin, using libvirt/KVM/QEMU as the virtualisation provider.



I'm presuming, as Tenks is supposed to support multiple hypervisors, 
that a multi-arch environment would be supported (different node types 
on different architectures).  Or does this even enter into the 
consideration?


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

[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Markus Hentsch]

Hello Eric,

Eric Harney wrote:
>
> Are you aware of the existing Cinder support for similar functionality?
>
> When encrypted volumes are uploaded to Glance images from Cinder,
> encryption keys are cloned in Barbican and tied to Glance images as
> metadata.  Then, volumes created from those images can consume the
> Barbican key to use the volume.
>
> The keys I mention here are used for the LUKS encryption layer -- which
> is different from what you are proposing.  But I'd like to point it out
> to make sure that the interaction between the two different encryption
> methods is understood when designing this and considering use cases.
>
> (Note: there is still at least one big TODO pending around this
> functionality, namely that the Glance service doesn't know to remove a
> key from Barbican when the image is deleted from Glance.)
>

We are aware of this and plan to integrate this existing case with our
new approach. This would mean that the container_format property of such
image - which currently is simply 'bare' iirc - would be changed to the
new one for encrypted images and its metadata adjusted to contain
appropriate information about the encryption used. Such metadata would
indicate the Cinder-specific encryption in this case and differentiate
it from our general encryption mechanism.

Regarding the key deletion: that's an interesting point actually.
Although OpenStack does create and delete keys for encryption of volumes
or ephemeral storage itself automatically, we didn't plan to do that in
our current proposal for the image encryption. As our quoted use cases
describe, the user is to upload or order a key in Barbican beforehand
themselves. This means the key management (including deletion) for
encrypted images was meant to be in the hand of the user. I wonder,
would this be undesired from the OpenStack perspective?

Best regards,
Markus


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

[openstack-dev] [neutron] Please opt-in for neutron-lib patches

[Boden Russell]

Just a friendly reminder that networking projects now need to opt-in for
neutron-lib consumption patches [1].

Starting next week (September 8) I'd like to start basing consumption
patches on those projects that have opted-in. If there are exceptions
please let me know so we can track them accordingly.

Thanks

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135063.html

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

[openstack-dev] [TripleO] Promotion jobs migration to zuulv3-aware workflow

[Gabriele Cerami]

Hi,

as part of the process to migrate all the jobs to use a workflow that
takes advantage of zuulv3, we need to migrate the jobs that form the
promotion pipeline in rdo sf.
There are a total of 95 jobs that need migration in rdo sf. Of these, 55
are in the various promotion pipeline for all the branches.
We already tested part of them, sampling the various branch/topology
configuration, and we had good results.
We tried to plan a soft migration, but it would take ages to finish by
migrating job one at a time and be sure everything is working 100%
before moving to the next.
Since we are in a good spot with promotion (we just had promotion) our
next plan is to bulk migrate all the promotion jobs at the same time,
and spend a few days dealing with the consequences.

Tomorrow at 13 UTC, we'll pull the trigger on the migration. From that
moment, expect some delays in the promotions, as we'll try to fix
anything that we missed in our previous tests in the following days.

We don't expect the fixes to take more than one week, and we are ready
to revert to the previous configuration if need arises.

Thanks

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

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Eric Harney]

On 9/27/18 1:36 PM, Markus Hentsch wrote:

Dear OpenStack developers,

we would like to propose the introduction of an encrypted image format
in OpenStack. We already created a basic implementation involving Nova,
Cinder, OSC and Glance, which we'd like to contribute.

We originally created a full spec document but since the official
cross-project contribution workflow in OpenStack is a thing of the past,
we have no single repository to upload it to. Thus, the Glance team
advised us to post this on the mailing list [1].

Ironically, Glance is the least affected project since the image
transformation processes affected are taking place elsewhere (Nova and
Cinder mostly).

Below you'll find the most important parts of our spec that describe our
proposal - which our current implementation is based on. We'd love to
hear your feedback on the topic and would like to encourage all affected
projects to join the discussion.

Subsequently, we'd like to receive further instructions on how we may
contribute to all of the affected projects in the most effective and
collaborative way possible. The Glance team suggested starting with a
complete spec in the glance-specs repository, followed by individual
specs/blueprints for the remaining projects [1]. Would that be alright
for the other teams?

[1]
http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html

Best regards,
Markus Hentsch

(excerpts from our image encryption spec below)

Problem description
===

An image, when uploaded to Glance or being created through Nova from an
existing server (VM), may contain sensitive information. The already
provided signature functionality only protects images against
alteration. Images may be stored on several hosts over long periods of
time. First and foremost this includes the image storage hosts of Glance
itself. Furthermore it might also involve caches on systems like compute
hosts. In conclusion they are exposed to a multitude of potential
scenarios involving different hosts with different access patterns and
attack surfaces. The OpenStack components involved in those scenarios do
not protect the confidentiality of image data. That’s why we propose the
introduction of an encrypted image format.

Use Cases
-

* A user wants to upload an image, which includes sensitive information.
To ensure the integrity of the image, a signature can be generated and
used for verification. Additionally, the user wants to protect the
confidentiality of the image data through encryption. The user generates
or uploads a key in the key manager (e.g. Barbican) and uses it to
encrypt the image locally using the OpenStack client (osc) when
uploading it. Consequently, the image stored on the Glance host is
encrypted.

* A user wants to create an image from an existing server with ephemeral
storage. This server may contain sensitive user data. The corresponding
compute host then generates the image based on the data of the ephemeral
storage disk. To protect the confidentiality of the data within the
image, the user wants Nova to also encrypt the image using a key from
the key manager, specified by its secret ID. Consequently, the image
stored on the Glance host is encrypted.

* A user wants to create a new server or volume based on an encrypted
image created by any of the use cases described above. The corresponding
compute or volume host has to be able to decrypt the image using the
symmetric key stored in the key manager and transform it into the
requested resource (server disk or volume).




Although not required on a technical level, all of the use cases
described above assume the usage of encrypted volume types and encrypted
ephemeral storage as provided by OpenStack.


Proposed changes


* Glance: Adding a container type for encrypted images that supports
different mechanisms (format, cipher algorithms, secret ID) via a
metadata property. Whether introducing several container types or
outsourcing the mechanism definition into metadata properties may still
be up for discussion, although we do favor the latter.

* Nova: Adding support for decrypting an encrypted image when a servers
ephemeral disk is created. This includes direct decryption streaming for
encrypted disks. Nova should select a suitable mechanism according to
the image container type and metadata. The symmetric key will be
retrieved from the key manager (e.g. Barbican).

* Cinder: Adding support for decrypting an encrypted image when a volume
is created from it. Cinder should select a suitable mechanism according
to the image container type and metadata. The symmetric key will be
retrieved from the key manager (e.g. Barbican).


Are you aware of the existing Cinder support for similar functionality?

When encrypted volumes are uploaded to Glance images from Cinder, 
encryption keys are cloned in Barbican and tied to Glance images as 
metadata.  Then, volumes created from those images can consume the 
Barbican key to 

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...

[Ivan Kolodyazhny]

+1 from me to Gorka!



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Wed, Oct 3, 2018 at 5:47 PM Jay S. Bryant  wrote:

> Team,
>
> We had discussed the possibility of adding Gorka to the stable core team
> during the PTG.  He does review a number of our backport patches and is
> active in that area.
>
> If there are no objections in the next week I will add him to the list.
>
> Thanks!
>
> Jay (jungleboyj)
>
>
> __
> OpenStack Development Mailing 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] [cinder] Proposing Gorka Eguileor to Stable Core ...

[Jay S. Bryant]

Team,

We had discussed the possibility of adding Gorka to the stable core team 
during the PTG.  He does review a number of our backport patches and is 
active in that area.


If there are no objections in the next week I will add him to the list.

Thanks!

Jay (jungleboyj)


__
OpenStack Development Mailing 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] [cinder] Follow-up on core team changes ...

[Jay S. Bryant]

Team,

I wanted to follow up on the note I sent a week or so ago about changes 
to the Core team.  I talked to Winston-D (Huang Zhiteng) and it sounded 
like he would not be able to take a more active role.  There were no 
other objections so I am removing him from the Core list.


John Griffith indicated an interest in staying on and thinks that he 
will be able to get more time for Cinder.  As a result we have decided 
to keep him on.


This leaves Cinder with 9 people on the core team.

Thanks!

Jay (jungleboyj)


__
OpenStack Development Mailing 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][stadium][networking] Seeking proposals for non-voting Stadium projects in Neutron check queue

[Miguel Lavalle]

Thomas, Miguel,

Next step is just push a patch for review with the definition of your job.
We can discuss the details in Gerrit

Cheers

On Wed, Oct 3, 2018 at 4:39 AM Miguel Angel Ajo Pelayo 
wrote:

> That's fantastic,
>
>I believe we could add some of the networking ovn jobs, we need to
> decide which one would be more beneficial.
>
> On Tue, Oct 2, 2018 at 10:02 AM  wrote:
>
>> Hi Miguel, all,
>>
>> The initiative is very welcome and will help make it more efficient to
>> develop in stadium projects.
>>
>> legacy-tempest-dsvm-networking-bgpvpn-bagpipe would be a candidate, for
>> networking-bgpvpn and networking-bagpipe (it covers API and scenario
>> tests for the BGPVPN API (networking-bgpvpn) and given that
>> networking-bagpipe is used as reference driver, it exercises a large
>> portion of networking-bagpipe as well).
>>
>> Having this one will help a lot.
>>
>> Thanks,
>>
>> -Thomas
>>
>>
>> On 9/30/18 2:42 AM, Miguel Lavalle wrote:
>> > Dear networking Stackers,
>> >
>> > During the recent PTG in Denver, we discussed measures to prevent
>> > patches merged in the Neutron repo breaking Stadium and related
>> > networking projects in general. We decided to implement the following:
>> >
>> > 1) For Stadium projects, we want to add non-voting jobs to the Neutron
>> > check queue
>> > 2) For non stadium projects, we are inviting them to add 3rd party CI
>> jobs
>> >
>> > The next step is for each project to propose the jobs that they want
>> > to run against Neutron patches.
>> >
>> > Best regards
>> >
>> > Miguel
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Miguel Ángel Ajo
> OSP / Networking DFG, OVN Squad Engineering
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][neutron] Release of openstack/networking-bigswitch failed

[AdityaVaja]

Hello Doug,

I was going to send out an email or drop in on IRC to check how to fix that.

We accidentally pushed 13.0.1 on stable/queens, instead of 12.0.5. (13.x.x
is rocky and 12.x.x is queens)
Tried reverting the situation by pushing 12.0.5 for the same commit hash on
queens, but that didn't work. Releases with commit hash can be compared
here [1].

Deleting the release from PYPI can be done, but deleting a tag from gerrit
is not possible without allowing forcePush from project-config - afaik. But
that seems like an extreme step.
Not sure how to fix the situation, so I thought checking with
openstack-release to get an idea.

If your original suggestion of pushing 12.0.6 still stands, I can go ahead
and do that.

Thanks!

[1] https://github.com/openstack/networking-bigswitch/releases

On Wed, Oct 3, 2018 at 9:47 PM Doug Hellmann  wrote:

> z...@openstack.org writes:
>
> > Build failed.
> >
> > - release-openstack-python
> http://logs.openstack.org/d1/d1df2f75e0e8259ddaaf5136f421567733ba7f5b/release/release-openstack-python/8a89663/
> : FAILURE in 6m 19s
> > - announce-release announce-release : SKIPPED
> > - propose-update-constraints propose-update-constraints : SKIPPED
>
> It looks like there's something wrong with the versioning in the
> stable/queens branch of the networking-bigswitch repository.
>
> The error I see when I run "python setup.py --name" locally is:
>
>   ValueError: git history requires a target version of
>   pbr.version.SemanticVersion(13.0.1), but target version is
>   pbr.version.SemanticVersion(12.0.5)
>
> This is being caused by re-tagging the 13.0.1 release as 12.0.5.
>
> I think if we tag a *newer* commit as 12.0.6 that will work (it seems to
> work locally).
>
> 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
>


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

Re: [openstack-dev] [Release-job-failures][neutron] Release of openstack/networking-bigswitch failed

[Doug Hellmann]

z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/d1/d1df2f75e0e8259ddaaf5136f421567733ba7f5b/release/release-openstack-python/8a89663/
>  : FAILURE in 6m 19s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED

It looks like there's something wrong with the versioning in the
stable/queens branch of the networking-bigswitch repository.

The error I see when I run "python setup.py --name" locally is:

  ValueError: git history requires a target version of
  pbr.version.SemanticVersion(13.0.1), but target version is
  pbr.version.SemanticVersion(12.0.5)

This is being caused by re-tagging the 13.0.1 release as 12.0.5.

I think if we tag a *newer* commit as 12.0.6 that will work (it seems to
work locally).

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] [goals][python3][heat][stable] how should we proceed with ocata branch

[Matt Riedemann]

On 10/3/2018 7:58 AM, Doug Hellmann wrote:

There is one more patch to import the zuul configuration for the
heat-agents repository's stable/ocata branch. That branch is apparently
broken, and Zane suggested on the review [1] that we abandon the patch
and close the branch.

That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?

Doug

[1]https://review.openstack.org/#/c/597272/


I'm assuming heat-agents is a service, not a library, since it doesn't 
show up in upper-constraints. Based on that, does heat itself plan on 
putting its stable/ocata branch into extended maintenance mode and if 
so, does that mean EOLing the heat-agents stable/ocata branch could 
cause problems for the heat stable/ocata branch? In other words, will it 
be reasonable to run CI for stable/ocata heat changes against a 
heat-agents ocata-eol tag?


--

Thanks,

Matt

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

Re: [openstack-dev] [neutron][stable] Stable Core Team Update

[Nate Johnston]

On Tue, Oct 02, 2018 at 10:41:58AM -0500, Miguel Lavalle wrote:
 
> I want to nominate Bernard Cafarrelli as a stable core reviewer for Neutron
> and related projects. Bernard has been increasing the number of stable
> reviews he is doing for the project [1]. Besides that, he is a stable
> maintainer downstream for his employer (Red Hat), so he can bring that
> valuable experience to the Neutron stable team.

I'm not on the stable team, but an enthusiastic +1 from me!

Nate

__
OpenStack Development Mailing 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] [placement] [infra] [qa] tuning some zuul jobs from "it works" to "proper"

[Chris Dent]

On Tue, 2 Oct 2018, Chris Dent wrote:


One of the comments in there is about the idea of making a zuul job
which is effectively "run the gabbits in these dirs" against a
tempest set up. Doing so will require some minor changes to the
tempest tox passenv settings but I think it ought to
straightforwardish.


I've made a first stab at this:

* Small number of changes to tempest:
  https://review.openstack.org/#/c/607507/
  (The important change here, the one that strictly required changes
  to tempest, is adjusting passenv in tox.ini)

* Much smaller job on the placement side:
  https://review.openstack.org/#/c/607508/

I'd really like to see this become a real thing, so if I could get
some help from tempest people on how to make it in line with
expectations that would be great.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

[Ivan Kolodyazhny]

Thanks for working on it, Shu.

Let's unblock gates and find a better long-term solution

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Mon, Oct 1, 2018 at 7:55 PM Duc Truong  wrote:

> Hi Shu,
>
> Thanks for proposing your fix.  It looks good to me.  I have submitted
> a similar patch for senlin-dashboard to unblock the broken gate test [1].
>
> [1] https://review.openstack.org/#/c/607003/
>
> Regards,
>
> Duc (dtruong)
> On Fri, Sep 28, 2018 at 2:24 AM Shu M.  wrote:
> >
> > Hi Ivan,
> >
> > Thank you for your help to our plugins and sorry for bothering you.
> > I found problem on installing horizon in "post-install", e.g. we should
> install horizon with upper-constraints.txt in "post-install".
> > I proposed patch[1] in zun-ui, please check it. If we can merge this, I
> will expand it the other remaining plugins.
> >
> > [1] https://review.openstack.org/#/c/606010/
> >
> > Thanks,
> > Shu Muto
> >
> > 2018年9月28日(金) 3:34 Ivan Kolodyazhny :
> >>
> >> Hi,
> >>
> >> Unfortunately, this issue affects some of the plugins too :(. At least
> gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken
> now. I'm working both with project teams to fix it asap. Let's wait if [5]
> helps for senlin-dashboard and fix all the rest of plugins.
> >>
> >>
> >> [5] https://review.openstack.org/#/c/605826/
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >>
> >> On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Patch [1]  is merged and our gates are un-blocked now. I went throw
> review list and post 'recheck' where it was needed.
> >>>
> >>> We need to cherry-pick this fix to stable releases too. I'll do it asap
> >>>
> >>> Regards,
> >>> Ivan Kolodyazhny,
> >>> http://blog.e0ne.info/
> >>>
> >>>
> >>> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny 
> wrote:
> 
>  Hi team,
> 
>  Unfortunately, horizon gates are broken now. We can't merge any patch
> due to the -1 from CI.
>  I don't want to disable tests now, that's why I proposed a fix [1].
> 
>  We'd got released some of XStatic-* packages last week. At least new
> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
> requirements repo [4] to prevent such issues in the future.
> 
>  Please, do not try 'recheck' until [1] will be merged.
> 
>  [1] https://review.openstack.org/#/c/604611/
>  [2] https://pypi.org/project/XStatic-jQuery/#history
>  [3] https://bugs.launchpad.net/horizon/+bug/1794028
>  [4] https://review.openstack.org/#/c/604613/
> 
>  Regards,
>  Ivan Kolodyazhny,
>  http://blog.e0ne.info/
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [goals][python3][heat][stable] how should we proceed with ocata branch

[Doug Hellmann]

There is one more patch to import the zuul configuration for the
heat-agents repository's stable/ocata branch. That branch is apparently
broken, and Zane suggested on the review [1] that we abandon the patch
and close the branch.

That patch is the only thing blocking the cleanup patch in
project-config, so I would like to get a definitive answer about what to
do. Should we close the branch, or does someone want to try to fix
things up?

Doug

[1] https://review.openstack.org/#/c/597272/

__
OpenStack Development Mailing 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] [cyborg]No irc meeting this week

[Li Liu]

Hi guys

I have to cancel the meeting this week as I realize all of the folks in
China are on their National day vacation. we will resume the meeting next
week.

Thank you
Regards
Li
__
OpenStack Development Mailing 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] [networking-ovn] No more overcloud_prep-containers.sh script

[Jiří Stránský]

Yes I know, but based on the deployment details we have for networking-ovn

it should be enough, we will have to update those documents with the new
changes anyway, because surprisingly this change has came for "Rocky" last
minute. Why did we have such last minute change? :-/

I understand the value of simplifying workflows to cloud operators, but
when we make workflow changes last minute we make others life harder (now I
need to rework something I want to be available in rocky, the migration
scripts/document).


Yea it's hard to strike a good balance there. It threw off updates and 
upgrades too. The upload is internally done via external_deploy_tasks 
which must not be run during `upgrade prepare` and `upgrade run` (or 
`update prepare` and `update run`). So likely Rocky updates/upgrades 
don't work as expected right now, and we'll need `external-upgrade run 
--tags image_prepare` inserted into the workflows. It's in my "queue of 
things to look into ASAP" ;D.


Jirka

__
OpenStack Development Mailing 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][stadium][networking] Seeking proposals for non-voting Stadium projects in Neutron check queue

[Miguel Angel Ajo Pelayo]

That's fantastic,

   I believe we could add some of the networking ovn jobs, we need to
decide which one would be more beneficial.

On Tue, Oct 2, 2018 at 10:02 AM  wrote:

> Hi Miguel, all,
>
> The initiative is very welcome and will help make it more efficient to
> develop in stadium projects.
>
> legacy-tempest-dsvm-networking-bgpvpn-bagpipe would be a candidate, for
> networking-bgpvpn and networking-bagpipe (it covers API and scenario
> tests for the BGPVPN API (networking-bgpvpn) and given that
> networking-bagpipe is used as reference driver, it exercises a large
> portion of networking-bagpipe as well).
>
> Having this one will help a lot.
>
> Thanks,
>
> -Thomas
>
>
> On 9/30/18 2:42 AM, Miguel Lavalle wrote:
> > Dear networking Stackers,
> >
> > During the recent PTG in Denver, we discussed measures to prevent
> > patches merged in the Neutron repo breaking Stadium and related
> > networking projects in general. We decided to implement the following:
> >
> > 1) For Stadium projects, we want to add non-voting jobs to the Neutron
> > check queue
> > 2) For non stadium projects, we are inviting them to add 3rd party CI
> jobs
> >
> > The next step is for each project to propose the jobs that they want
> > to run against Neutron patches.
> >
> > Best regards
> >
> > Miguel
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
__
OpenStack Development Mailing 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] [networking-ovn] No more overcloud_prep-containers.sh script

[Miguel Angel Ajo Pelayo]

Hi Jirka & Daniel, thanks for your answers... more inline.

On Wed, Oct 3, 2018 at 10:44 AM Jiří Stránský  wrote:

> On 03/10/2018 10:14, Miguel Angel Ajo Pelayo wrote:
> > Hi folks
> >
> >I was trying to deploy neutron with networking-ovn via
> tripleo-quickstart
> > scripts on master, and this config file [1]. It doesn't work, overcloud
> > deploy cries with:
> >
> > 1) trying to deploy ovn I end up with a 2018-10-02 17:48:12 | "2018-10-02
> > 17:47:51,864 DEBUG: 26691 -- Error: image
> > tripleomaster/centos-binary-ovn-controller:current-tripleo not found",
> >
> > it seems like the overcloud_prep-containers.sh is not there anymore (I
> > guess overcloud deploy handles it automatically now? but it fails to
> > generate the ovn containers for some reason)
> >
> > Also, if you look at [2] which are our ansible migration scripts to
> migrate
> > ml2/ovs to ml2/networking-ovn, you will see that we make use of
> > overcloud_prep-containers.sh , I guess that we will need to make sure [1]
> > works and we will get [2] for free.
>
> Hi Miguel,
>
> i'm not subject matter expert but here's some relevant info:
>
> * overcloud_prep-containers.sh is not a production thing, it's
> automation from TripleO Quickstart, which is not part of production
> deployments. We shouldn't depend on it in docs/automation for OVN
> migration.
>
> Yes I know, but based on the deployment details we have for networking-ovn
it should be enough, we will have to update those documents with the new
changes anyway, because surprisingly this change has came for "Rocky" last
minute. Why did we have such last minute change? :-/

I understand the value of simplifying workflows to cloud operators, but
when we make workflow changes last minute we make others life harder (now I
need to rework something I want to be available in rocky, the migration
scripts/document).


> * For production envs, the image preparation steps used to be documented
> and performed manually. This now is now changing in Rocky+, as Steve
> Baker integrated the image prep into the deployment itself. There are
> docs about the current method [3].
>

Oops, I see

openstack tripleo container image prepare default \
  --output-env-file containers-prepare-parameter.yaml

Always outputs neutron_driver: null


@Emilien Macchi, @Steve Baker   How can I make sure it
provides "ovn" for example?   ^

I know I could manually change the file, but then, how would I run... " --
local-push-destination" ?


>
>
> * I hit similar issues with incorrect Neutron images being uploaded to
> undercloud registry, you can try deploying with this patch [4] which
> aims to fix that problem (also the depends-on patch is necessary).
>

Thanks a lot!

>
> Jirka
>
> > [1]
> https://github.com/openstack/networking-ovn/blob/master/tripleo/ovn.yml
> > [2]
> https://docs.openstack.org/networking-ovn/latest/install/migration.html
>
> [3]
> http://tripleo.org/install/advanced_deployment/container_image_prepare.html
> [4] https://review.openstack.org/#/c/604953/
>
>

-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
__
OpenStack Development Mailing 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] ?==?utf-8?q? ?==?utf-8?q? [infra] Gerrit User Summit, November 2018

[jean-philippe]

On Tuesday, October 02, 2018 14:59 CEST, Adam Spiers  wrote: 
 
> Hi all,
> 
> The next forthcoming Gerrit User Summit 2018 will be Nov 15th-16th in
> Palo Alto, hosted by Cloudera.
> 
> See the Gerrit User Summit page at:
> 
> https://gerrit.googlesource.com/summit/2018/+/master/index.md
> 
> and the event registration at:
> 
> https://gus2018.eventbrite.com
> 
> Hopefully some members of the OpenStack community can attend the
> event, not just so we can keep up to date with Gerrit but also so that
> our interests can be represented!
> 
> Regards,
> Adam
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Good catch! 
When I read your email, I assume you won't be going? Palo Alto is indeed not 
very close to Europe and it's indeed a long trip for a two day effort. Maybe 
there is someone closer that can help there and attend this?

Regards,
Jean-Philippe Evrard (evrardjp)


__
OpenStack Development Mailing 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] ?==?utf-8?q? ?==?utf-8?q? [helm] multiple nova compute nodes

[jean-philippe]

> 
> The nova-compute pods are part of a daemonset which will automatically 
> create a nova-compute pod on each node that has the 
> "openstack-compute-node=enabled" label.
> 
 Hello,

Should we add this in the documentation, maybe with an architecture diagram?

Regards,
Jean-Philippe Evrard (evrardjp)


__
OpenStack Development Mailing 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] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

In the alertmanager.yml file you should have a receiver for Vitrage. Please
verify that it includes "send_resolved: true". This is required for
Prometheus to notify Vitrage when an alarm is resolved.

The full Vitrage receiver definition should be:

- name: **

  webhook_configs:

  - url: **  # example: 'http://127.0.0.1:8999/v1/event'

send_resolved: true

http_config:

  basic_auth:

username: **

password: **

Hope it helps,
Ifat


On Tue, Oct 2, 2018 at 7:51 AM Won  wrote:

> I have some problems with Prometheus alarms in vitrage.
> I receive a list of alarms from the Prometheus alarm manager well, but the
> alarm does not disappear when the problem(alarm) is resolved. The alarm
> that came once in both the alarm list and the entity graph does not
> disappear in vitrage.  The alarm sent by zabbix disappears when alarm
> solved, I wonder how to clear the Prometheus alarm from vitrage and how to
> update the alarm automatically like zabbix.
> thank you.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [networking-ovn] No more overcloud_prep-containers.sh script

[Jiří Stránský]

On 03/10/2018 10:14, Miguel Angel Ajo Pelayo wrote:

Hi folks

   I was trying to deploy neutron with networking-ovn via tripleo-quickstart
scripts on master, and this config file [1]. It doesn't work, overcloud
deploy cries with:

1) trying to deploy ovn I end up with a 2018-10-02 17:48:12 | "2018-10-02
17:47:51,864 DEBUG: 26691 -- Error: image
tripleomaster/centos-binary-ovn-controller:current-tripleo not found",

it seems like the overcloud_prep-containers.sh is not there anymore (I
guess overcloud deploy handles it automatically now? but it fails to
generate the ovn containers for some reason)

Also, if you look at [2] which are our ansible migration scripts to migrate
ml2/ovs to ml2/networking-ovn, you will see that we make use of
overcloud_prep-containers.sh , I guess that we will need to make sure [1]
works and we will get [2] for free.


Hi Miguel,

i'm not subject matter expert but here's some relevant info:

* overcloud_prep-containers.sh is not a production thing, it's 
automation from TripleO Quickstart, which is not part of production 
deployments. We shouldn't depend on it in docs/automation for OVN migration.


* For production envs, the image preparation steps used to be documented 
and performed manually. This now is now changing in Rocky+, as Steve 
Baker integrated the image prep into the deployment itself. There are 
docs about the current method [3].


* I hit similar issues with incorrect Neutron images being uploaded to 
undercloud registry, you can try deploying with this patch [4] which 
aims to fix that problem (also the depends-on patch is necessary).


Jirka


[1] https://github.com/openstack/networking-ovn/blob/master/tripleo/ovn.yml
[2] https://docs.openstack.org/networking-ovn/latest/install/migration.html


[3] 
http://tripleo.org/install/advanced_deployment/container_image_prepare.html

[4] https://review.openstack.org/#/c/604953/

__
OpenStack Development Mailing 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] [networking-ovn] No more overcloud_prep-containers.sh script

[Daniel Alvarez Sanchez]

Hi Miguel,

This patch should fix it [0]. I ran into same issues and had to manually
patch and/or generate the OVN containers myself.
Try it out and let me know if the problem persists.
To confirm that this is the same issue try to check which images you got in
your local registry (ODL images may be present while OVN ones are not).

[0] https://review.openstack.org/#/c/604953/5

Cheers,
Daniel



On Wed, Oct 3, 2018 at 10:15 AM Miguel Angel Ajo Pelayo 
wrote:

> Hi folks
>
>   I was trying to deploy neutron with networking-ovn via
> tripleo-quickstart scripts on master, and this config file [1]. It doesn't
> work, overcloud deploy cries with:
>
> 1) trying to deploy ovn I end up with a 2018-10-02 17:48:12 | "2018-10-02
> 17:47:51,864 DEBUG: 26691 -- Error: image
> tripleomaster/centos-binary-ovn-controller:current-tripleo not found",
>
> it seems like the overcloud_prep-containers.sh is not there anymore (I
> guess overcloud deploy handles it automatically now? but it fails to
> generate the ovn containers for some reason)
>
> Also, if you look at [2] which are our ansible migration scripts to
> migrate ml2/ovs to ml2/networking-ovn, you will see that we make use of
> overcloud_prep-containers.sh , I guess that we will need to make sure [1]
> works and we will get [2] for free.
>
>
>
> [1]
> https://github.com/openstack/networking-ovn/blob/master/tripleo/ovn.yml
> [2]
> https://docs.openstack.org/networking-ovn/latest/install/migration.html
> --
> Miguel Ángel Ajo
> OSP / Networking DFG, OVN Squad Engineering
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] [quickstart] [networking-ovn] No more overcloud_prep-containers.sh script

[Miguel Angel Ajo Pelayo]

Hi folks

  I was trying to deploy neutron with networking-ovn via tripleo-quickstart
scripts on master, and this config file [1]. It doesn't work, overcloud
deploy cries with:

1) trying to deploy ovn I end up with a 2018-10-02 17:48:12 | "2018-10-02
17:47:51,864 DEBUG: 26691 -- Error: image
tripleomaster/centos-binary-ovn-controller:current-tripleo not found",

it seems like the overcloud_prep-containers.sh is not there anymore (I
guess overcloud deploy handles it automatically now? but it fails to
generate the ovn containers for some reason)

Also, if you look at [2] which are our ansible migration scripts to migrate
ml2/ovs to ml2/networking-ovn, you will see that we make use of
overcloud_prep-containers.sh , I guess that we will need to make sure [1]
works and we will get [2] for free.



[1] https://github.com/openstack/networking-ovn/blob/master/tripleo/ovn.yml
[2] https://docs.openstack.org/networking-ovn/latest/install/migration.html
-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
__
OpenStack Development Mailing 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][stable] Stable Core Team Update

[Thomas Morin]

+1 !

-Thomas

On 10/2/18 5:41 PM, Miguel Lavalle wrote:

Hi Stable Team,

I want to nominate Bernard Cafarrelli as a stable core reviewer for 
Neutron and related projects. Bernard has been increasing the number 
of stable reviews he is doing for the project [1]. Besides that, he is 
a stable maintainer downstream for his employer (Red Hat), so he can 
bring that valuable experience to the Neutron stable team.


Thanks and regards

Miguel

[1] 
https://review.openstack.org/#/q/(project:openstack/neutron+OR+openstack/networking-sfc+OR+project:openstack/networking-ovn)++branch:%255Estable/.*+reviewedby:%22Bernard+Cafarelli+%253Cbcafarel%2540redhat.com%253E%22


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