[openstack-dev] [tricircle]weekly meeting of Feb.22

[joehuang]

Hello, team,

Let's resume weekly meeting after Ocata 3.0.0 released.

Agenda of Feb. 22 weekly meeting:

  1.  Pike features development
  2.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.


Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] Atlanta PTG

[Carlos Camacho Gonzalez]

Thanks Emilien!

I think will be enough just by sharing a mic and the Etherpad notes.

Cheers,
Carlos.

On Wed, Feb 22, 2017 at 5:16 AM, Emilien Macchi  wrote:

> On Tue, Feb 21, 2017 at 11:46 AM, Sai Sindhur Malleni
>  wrote:
> > Is there a plan to have a google hangouts session or similar to attend
> > remotely?
>
> to be honest, mixing face 2 face & remote meetings is very challenging.
> But because people want it, we'll give a try on Friday morning during
> the CI sessions.
>
> If anyone at PTG volunteers to do the same for the other sessions on
> Wednesday or Thursday, feel free to do so.
>
> > On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge 
> wrote:
> >>
> >>
> >>
> >> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
> >> > Hi Emilien,
> >> >
> >> > while not a design session per se, I would love to propose a short
> slot
> >> > for TripleO CI Q&A, if we have some time left. In short, I'd like to
> be
> >> > more useful around CI failures, but I lack the understanding of a few
> >> > aspects of our current CI (promotion, when do images get built, etc.),
> >> > that would benefit quite a bit from a short session where we have a
> few
> >> > CI folks in the room that could answer questions or give some tips.
> >> > I know of quite few other people that are in the same boat and maybe
> >> > this will help a bit our current issue where only a few folks always
> >> > chase CI issues.
> >> >
> >> > If there is consensus (and some CI folks willing to attend ;) and time
> >> > for this, I'll be happy to organize this and prepare a bunch of
> >> > questions ideas beforehand.
> >> >
> >>
> >> Great idea. We have a room for three days, so it is not like summit
> >> where there is really limited time.
> >>
> >> > Thoughts?
> >> > Michele
> >> >
> >> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
> >> >> I would like to bring this topic up on your inbox, so we can continue
> >> >> to make progress on the agenda. Feel free to follow existing examples
> >> >> in the etherpad and propose a design dession.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi 
> >> >> wrote:
> >> >>> General infos about PTG: https://www.openstack.org/ptg/
> >> >>>
> >> >>> Some useful informations about PTG/TripleO:
> >> >>>
> >> >>> * When? We have a room between Wednesday and Friday included.
> >> >>> Important sessions will happen on Wednesday and Thursday. We'll
> >> >>> probably have sessions on Friday, but it might be more hands-on and
> >> >>> hackfest, where people can enjoy the day to work together.
> >> >>>
> >> >>> * Let's start to brainstorm our topics:
> >> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike
> >> >>>   Feel free to add any topic, as soon as you can. We need to know
> asap
> >> >>> which sessions will be share with other projects (eg:
> tripleo/mistral,
> >> >>> tripleo/ironic, tripleo/heat, etc).
> >> >>>
> >> >>>
> >> >>> Please let us know any question or feedback,
> >> >>> Looking forward to seeing you there!
> >> >>> --
> >> >>> Emilien Macchi
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Emilien Macchi
> >> >>
> >> >>
> >> >> 
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Sai Sindhur Malleni
> >
> > Red Hat Inc.
> > 100 East Davie Street
> > Raleigh, NC, USA
> > Work: (919) 754-4557 | Cell: (919) 985-1055
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Fedor Zhadaev]

+1

On Wed, Feb 22, 2017 at 12:36 AM Булат Гайфуллин 
wrote:

> +1
>
> 2017-02-21 17:01 GMT+03:00 Alexey Shtokolov :
>
> Hey fellow fuelers,
>
> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> He's doing thorough review [1], participate in feature developments
> (e.g. Config-DB enhancements, network-manager performance
> improvements) and made an outstanding contribution bug-fixing.
>
> Core reviewers, please reply back with +1/-1.
>
> Thanks,
> Ihor
>
> [1] http://stackalytics.com/?release=ocata&module=fuel-web
>
> __
> OpenStack Development Mailing 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
>
-- 
Fedor Zhadaev
email: fzhad...@mirantis.com
skype: zhadaevfm
IRC: fzhadaev
__
OpenStack Development Mailing 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] Atlanta PTG

[Marios Andreou]

On 22/02/17 10:25, Carlos Camacho Gonzalez wrote:
> Thanks Emilien!
> 
> I think will be enough just by sharing a mic and the Etherpad notes.

++ thanks very much Emilien - it can be very effective/useful as long as
people remember to use the mic (depending on room size, may be necessary
locally as well :) )... thanks in advance to anyone 'donating' their
laptop for the bluejeans session (extra bonus/cherry on top if you hit
'record' but I know I'm pushing it now ;) )

have a great day in Atlanta!

> 
> Cheers,
> Carlos.
> 
> On Wed, Feb 22, 2017 at 5:16 AM, Emilien Macchi  > wrote:
> 
> On Tue, Feb 21, 2017 at 11:46 AM, Sai Sindhur Malleni
> mailto:small...@redhat.com>> wrote:
> > Is there a plan to have a google hangouts session or similar to attend
> > remotely?
> 
> to be honest, mixing face 2 face & remote meetings is very challenging.
> But because people want it, we'll give a try on Friday morning during
> the CI sessions.
> 
> If anyone at PTG volunteers to do the same for the other sessions on
> Wednesday or Thursday, feel free to do so.
> 
> > On Mon, Jan 23, 2017 at 8:45 AM, John Trowbridge  > wrote:
> >>
> >>
> >>
> >> On 01/21/2017 05:37 AM, Michele Baldessari wrote:
> >> > Hi Emilien,
> >> >
> >> > while not a design session per se, I would love to propose a
> short slot
> >> > for TripleO CI Q&A, if we have some time left. In short, I'd
> like to be
> >> > more useful around CI failures, but I lack the understanding of
> a few
> >> > aspects of our current CI (promotion, when do images get built,
> etc.),
> >> > that would benefit quite a bit from a short session where we
> have a few
> >> > CI folks in the room that could answer questions or give some tips.
> >> > I know of quite few other people that are in the same boat and
> maybe
> >> > this will help a bit our current issue where only a few folks
> always
> >> > chase CI issues.
> >> >
> >> > If there is consensus (and some CI folks willing to attend ;)
> and time
> >> > for this, I'll be happy to organize this and prepare a bunch of
> >> > questions ideas beforehand.
> >> >
> >>
> >> Great idea. We have a room for three days, so it is not like summit
> >> where there is really limited time.
> >>
> >> > Thoughts?
> >> > Michele
> >> >
> >> > On Wed, Jan 04, 2017 at 07:26:52AM -0500, Emilien Macchi wrote:
> >> >> I would like to bring this topic up on your inbox, so we can
> continue
> >> >> to make progress on the agenda. Feel free to follow existing
> examples
> >> >> in the etherpad and propose a design dession.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> On Wed, Dec 21, 2016 at 9:06 AM, Emilien Macchi
> mailto:emil...@redhat.com>>
> >> >> wrote:
> >> >>> General infos about PTG: https://www.openstack.org/ptg/
> >> >>>
> >> >>> Some useful informations about PTG/TripleO:
> >> >>>
> >> >>> * When? We have a room between Wednesday and Friday included.
> >> >>> Important sessions will happen on Wednesday and Thursday. We'll
> >> >>> probably have sessions on Friday, but it might be more
> hands-on and
> >> >>> hackfest, where people can enjoy the day to work together.
> >> >>>
> >> >>> * Let's start to brainstorm our topics:
> >> >>> https://etherpad.openstack.org/p/tripleo-ptg-pike
> 
> >> >>>   Feel free to add any topic, as soon as you can. We need to
> know asap
> >> >>> which sessions will be share with other projects (eg:
> tripleo/mistral,
> >> >>> tripleo/ironic, tripleo/heat, etc).
> >> >>>
> >> >>>
> >> >>> Please let us know any question or feedback,
> >> >>> Looking forward to seeing you there!
> >> >>> --
> >> >>> Emilien Macchi
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Emilien Macchi
> >> >>
> >> >>
> >> >>
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> >> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >> >
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> >> http://lists.openstack.org/cgi-bin/ma

[openstack-dev] [nova]Placement api on https

[Gyorgy Szombathelyi]

Hi!

As the placement API is mandatory in Ocata, I found out that you cannot give a 
custom CA cert or skip the validation in its clients. That would be bad, as you 
can give a custom CA cert in the [keystone_authtoken] section, but not in the 
[placement] one, so if you're using this feature, you simply cannot use Nova. I 
made a simple patch, it would be nice if it could land in Ocata.

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

If it is accepted, I'll cherry-pick into stable/ocata.

Br,
György

__
OpenStack Development Mailing 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] The end of OpenStack packages in Debian?

[Thomas Goirand]

On 02/21/2017 12:19 PM, Clint Byrum wrote:
> We may have to agree to disagree on that. The libraries and clients
> should be an order of magnitude simpler than the services to maintain.

The problem isn't simplicity, but the amount of work. Once you've done
all the libraries, there's not much added work to be done to get all the
services uploaded, especially if the package only needs update.
Typically, I was needing 2 to 3 weeks (on each beta or RC) to get all
dependency into shape, and a few days for the services on top.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Matt Riedemann]

On 2/21/2017 10:38 AM, Prashant Shetty wrote:

Hi Mark,

Thanks for your reply.

I tried "nova-manage cell_v2 discover_hosts" and it returned nothing and
still I have same issue on the node.

Problem seems be the way devstack is getting configured,
As code suggest below we create cell0 on node where n-api and n-cpu
runs. In my case compute is running only n-cpu and controller is running
n-api service, due to this code there are no cell created in controller
or compute.


The nova_cell0 database is created here:

https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/nova#L680

That's the same place that the nova_api database is created.



We will not have this  problem in all-in-one-node setup.
--
# Do this late because it requires compute hosts to have started
if is_service_enabled n-api; then
if is_service_enabled n-cpu; then
create_cell
else
# Some CI systems like Hyper-V build the control plane on
# Linux, and join in non Linux Computes after setup. This
# allows them to delay the processing until after their whole
# environment is up.
echo_summary "SKIPPING Cell setup because n-cpu is not enabled.
You will have to do this manually before you have a working environment."
fi
fi


You're correct that when stacking the control node where n-api is 
running, you won't get to the create_cell call:


https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/stack.sh#L1371

The create_cell function is what creates the cell0 mapping in the 
nova_api database and runs the simple_cell_setup command:


https://github.com/openstack-dev/devstack/blob/7a30c7fcabac1cf28fd9baa39d05436680616aef/lib/nova#L943

You're running discover_hosts from the control node where the nova_api 
database lives, so that looks correct.


Can you run discover_hosts with the --verbose option to get some more 
details, i.e. how many cell mappings are there, how many host mappings 
and compute_nodes records are created?


I think the issue is that you haven't run map_cell0 and 
simple_cell_setup. In the gating multinode CI job, the create_cell 
function in devstack is called because that's a 2-node job where n-cpu 
is running on both nodes, but n-api is only running on the control 
(primary) node. In your case you don't have that so you're going to have 
to run these command manually.


The docs here explain how to set this up and the commands to run:

https://docs.openstack.org/developer/nova/cells.html#setup-of-cells-v2
https://docs.openstack.org/developer/nova/cells.html#fresh-install


---

vmware@cntr11:~$ nova-manage cell_v2 discover_hosts
vmware@cntr11:~$ nova service-list
++--+---+--+-+---++-+
| Id | Binary   | Host  | Zone | Status  | State |
Updated_at | Disabled Reason |
++--+---+--+-+---++-+
| 3  | nova-conductor   | cntr11| internal | enabled | up|
2017-02-21T15:34:13.00 | -   |
| 5  | nova-scheduler   | cntr11| internal | enabled | up|
2017-02-21T15:34:15.00 | -   |
| 6  | nova-consoleauth | cntr11| internal | enabled | up|
2017-02-21T15:34:11.00 | -   |
| 7  | nova-compute | esx-ubuntu-02 | nova | enabled | up|
2017-02-21T15:34:14.00 | -   |
| 8  | nova-compute | esx-ubuntu-03 | nova | enabled | up|
2017-02-21T15:34:16.00 | -   |
| 9  | nova-compute | kvm-3 | nova | enabled | up|
2017-02-21T15:34:07.00 | -   |
| 10 | nova-compute | kvm-2 | nova | enabled | up|
2017-02-21T15:34:13.00 | -   |
| 11 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
2017-02-21T15:34:14.00 | -   |
| 12 | nova-compute | kvm-1 | nova | enabled | up|
2017-02-21T15:34:09.00 | -   |
++--+---+--+-+---++-+
vmware@cntr11:~$
vmware@cntr11:~$ nova-manage cell_v2 list_cells
+--+--+
| Name | UUID |
+--+--+
+--+--+
vmware@cntr11:~$


Thanks,
Prashant



--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] End-of-Ocata core team updates

[Loo, Ruby]

Vasyl + Mario: definitely +2. Just like the rest of us, they aren't experts in 
everything, but we trust them and us to review and +2 based on our degree of 
confidence etc! Looking forward to them relieving the load :)

Devananda. Unfortunately, +2 but I'd rather do a -2. This makes me so sad. I am 
happy that Deva is on another journey but I wished it included ironic. I am so 
grateful for everything he has done for ironic, especially all the non-ironic 
parts of it :)

--ruby

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

Date: Friday, February 17, 2017 at 4:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] End-of-Ocata core team updates

Hi all!

I'd like to propose a few changes based on the recent contributor activity.

I have two candidates that look very good and pass the formal barrier of 3
reviews a day on average [1].

First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats [2] are
high, he's doing a lot of extremely useful work around networking and CI.

Second, Mario Villaplana (mariojv). His stats [3] are quite high too, he has
been doing some quality reviews for critical patches in the Ocata cycle.

Active cores and interested contributors, please respond with your +-1 to these
suggestions.

Unfortunately, there is one removal as well. Devananda, our team leader for
several cycles since the very beginning of the project, has not been active on
the project for some time [4]. I propose to (hopefully temporary) remove him
from the core team. Of course, when (look, I'm not even saying "if"!) he comes
back to active reviewing, I suggest we fast-forward him back. Thanks for
everything Deva, good luck with your current challenges!

Thanks,
Dmitry

[1] http://stackalytics.com/report/contribution/ironic-group/90
[2] http://stackalytics.com/?user_id=vsaienko&metric=marks
[3] http://stackalytics.com/?user_id=mario-villaplana-j&metric=marks
[4] http://stackalytics.com/?user_id=devananda&metric=marks

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

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

Re: [openstack-dev] [nova]Placement api on https

[Sylvain Bauza]

Le 22/02/2017 05:14, Gyorgy Szombathelyi a écrit :
> Hi!
> 
> As the placement API is mandatory in Ocata, I found out that you cannot give 
> a custom CA cert or skip the validation in its clients. That would be bad, as 
> you can give a custom CA cert in the [keystone_authtoken] section, but not in 
> the [placement] one, so if you're using this feature, you simply cannot use 
> Nova. I made a simple patch, it would be nice if it could land in Ocata.
> 
> https://review.openstack.org/#/c/436475/
> 
> If it is accepted, I'll cherry-pick into stable/ocata.
> 

Could you please open a bug for that so I would triage ?

Thanks,
-Sylvain

> Br,
> György
> 
> __
> OpenStack Development Mailing 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] Enable arp_responder without l2pop

[Thomas Morin]

Hi Anil,

Tue Feb 21 2017 22:47:46 GMT-0500 (EST), Anil Venkata:

Currently arp_resonder can enabled only if l2pop is enabled.

Can we have arp_responder feature enabled without l2pop(i.e Remove the 
dependency between arp_responder and l2_pop)?




I agree that it would be useful.
networking-bgpvpn ovs/bagpipe driver is relying on arp_responder, and 
hence currently draws this dependency on l2pop (not an issue I find, but 
still an artefact rather than a design decision).



Also setup arp_responder on OVS integration bridge(and not on br-tun)?



While relevant, I think this is not possible until br-int allows to 
match the network a packet belongs to (the ovsdb port tags don't let you 
do that until the packet leaves br-int with a NORMAL action).
Ajo has told me yesterday that the OVS firewall driver uses registers 
precisely to do that. Making this generic (and not specific to the OVS 
firewall driver) would be a prerequisite before you can add ARP 
responder rules in br-int.


I think this question (of where to put the ARP responder rules) also 
relates to https://review.openstack.org/#/c/320439/ .


-Thomas

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

[openstack-dev] [horizon] PTG Cross Project Sessions

[Rob Cresswell]

Hi everyone,

A reminder to those at the PTG about a couple of cross project sessions.

- Wednesday, 2:30 - 3:30, Horizon / Keystone in Savannah 3
- Thursday 3:00 - 4:00, Horizon / I18n in Savannah 3

These are also listed in our PTG etherpad: 
https://etherpad.openstack.org/p/horizon-ptg-pike

Rob
__
OpenStack Development Mailing 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] Call for upstream training liaison

[sfinucan]

On Tue, 2017-02-21 at 21:52 -0500, Sylvain Bauza wrote:
> Le 21 févr. 2017 14:48, "Matt Riedemann"  a
> écrit :
> 
> > If you haven't seen this yet [1] there is going to be an upstream
> > training meeting at the PTG on Wednesday 2/22 at 12ET to talk about
> > upstream training and what liaisons from each project can do to
> > help.
> > 
> > This email is a call for anyone that's working on Nova and is
> > interested in volunteering to be the team liaison for the upstream
> > training which happens the weekend before the Pike summit in
> > Boston.
> > 
> > At a high level, it's my understanding that this involves helping
> > some new contributors get comfortable with the various projects and
> > to associate a person with each project so when they show up in IRC
> > they know someone and can ask questions (similar to mentoring but I
> > believe less involved on an ongoing basis).
> > 
> > So if you're going to be at the Boston summit and this is something
> > you're interested in, please either speak with me, Ildiko, or show
> > up to the meeting to find out more.
> > 
> > [1] http://lists.openstack.org/pipermail/openstack-dev/2017-Februar
> > y/112270.html
> 
> I can help here even I'm not sure I'll be going to the Summit yet.

Likewise (with the same caveat).

Stephen

__
OpenStack Development Mailing 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] [watcher] Nominating Hidekazu Nakamura as Watcher Core

[Spencer, Christopher M]

+1

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

Date: Tuesday, February 21, 2017 at 4:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [watcher] Nominating Hidekazu Nakamura as Watcher 
Core

+1

Envoyé de mon iPhone

Le 21 févr. 2017 à 09:17, Чадин Александр 
mailto:a.cha...@servionica.ru>> a écrit :
+1

Best Regards,
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81

On 20 Feb 2017, at 11:25, Vincent FRANÇOISE 
mailto:vincent.franco...@b-com.com>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Team,

Hidekazu Nakamura has made many contributions[1] to Watcher since the
Barcelona summit when we first met. I would like to nominate him to be
part of the Watcher Core Team. I really think he will provide many
valuable contributions to the project and his inputs (such as [2])
will most certainly help us substantially improve Watcher as a whole.

It's now time to vote :)

[1] http://stackalytics.com/report/contribution/watcher/120
[2] https://wiki.openstack.org/wiki/Zone_migration
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYqqgNAAoJEEb+XENQ/jVSf+kH/1+BLL907SrocIM87AlOdMAn
IuB0Xk+y7fAijrs4X7FqknEb2f8Ns4EN3f97SQGFF6WUqSxTMoyMkCZNBEaTWi0P
0D+g2KLTgOhOG8UGdV26CQD0qj455Q+GsQztatcip3zBRalO3QYcF8WUNkCs3GY3
yMDoCnK9L3JE+aihGf93UklAeYij856LlY4zj1Nxnm5MCdUNLnYpz+VpyjOtpE2w
QX3AH0jPs6b2coYC7O0CggpbMF0xFJzpaLiiRaabSzvuLT8vh1ICaCyUpH9IgXIv
M8i1b7aIvLRyxo1ZylFdBNu3J74Ayv5BZKudEtA5yqGn0bExL+yPiSJgv20WcrY=
=4frW
-END PGP SIGNATURE-

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

__
OpenStack Development Mailing 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] [mistral][ptg] Mistral sessions started in Atlanta 4; Level 1

[Renat Akhmerov]

Hi,

We just started our Mistral sessions, everybody is welcome to participate!

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Prashant Shetty]

Thanks Matt.

Here are the steps I have performed, I dont see any error related to cell0
now but n-cond still not able to detect computes after discover as well :(.

Do we need any cell setting on nova-compute nodes as well?.

vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova service-list
++--+---+--+-+---++-+
| Id | Binary   | Host  | Zone | Status  | State |
Updated_at | Disabled Reason |
++--+---+--+-+---++-+
| 7  | nova-conductor   | cntr11| internal | enabled | up|
2017-02-22T14:23:34.00 | -   |
| 9  | nova-scheduler   | cntr11| internal | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 10 | nova-consoleauth | cntr11| internal | enabled | up|
2017-02-22T14:23:33.00 | -   |
| 11 | nova-compute | esx-ubuntu-02 | nova | enabled | up|
2017-02-22T14:23:35.00 | -   |
| 12 | nova-compute | esx-ubuntu-03 | nova | enabled | up|
2017-02-22T14:23:35.00 | -   |
| 13 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 14 | nova-compute | kvm-3 | nova | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 15 | nova-compute | kvm-1 | nova | enabled | up|
2017-02-22T14:23:32.00 | -   |
| 16 | nova-compute | kvm-2 | nova | enabled | up|
2017-02-22T14:23:32.00 | -   |
++--+---+--+-+---++-+
vmware@cntr11:~/nsbu_cqe_openstack/devstack$
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2 map_cell0
--database_connection mysql+pymysql://
root:vmware@127.0.0.1/nova?charset=utf8
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
simple_cell_setup --transport-url rabbit://
stackrabbit:vmware@60.0.24.49:5672/
Cell0 is already setup
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2 list_cells
+---+--+
|  Name | UUID |
+---+--+
|  None | ea6bec24-058a-4ba2-8d21-57d34c01802c |
| cell0 | ---- |
+---+--+
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
discover_hosts --verbose
Found 2 cell mappings.
Skipping cell0 since it does not contain hosts.
Getting compute nodes from cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
Found 6 computes in cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
Checking host mapping for compute host 'kvm-3':
a4b175d6-f5cc-45a8-9cf2-45726293b5c5
Checking host mapping for compute host 'esx-ubuntu-02':
70281329-590c-4cb7-8839-fd84160345b7
Checking host mapping for compute host 'esx-ubuntu-03':
04ea75a2-789e-483e-8d0e-4b0f79e012dc
Checking host mapping for compute host 'kvm-1':
dfabae3c-4ea9-4e8f-a496-8880dd9e89d9
Checking host mapping for compute host 'kvm-2':
d1cb30f5-822c-4c18-81fb-921ca676b834
Checking host mapping for compute host 'esx-ubuntu-01':
d00f8f16-af6b-437d-8136-bc744eb2472f
vmware@cntr11:~/nsbu_cqe_openstack/devstack$

​n-sch:
2017-02-22 14:26:51.467 INFO nova.scheduler.host_manager
[req-56d1cefb-1dfb-481d-aaff-b7b6e05f83f0 None None] Successfully synced
instances from host 'kvm-2'.
2017-02-22 14:26:51.608 INFO nova.scheduler.host_manager
[req-690b1a18-a709-49b2-bfad-2a6a75a3bee2 None None] Successfully synced
instances from host 'kvm-3'.
2017-02-22 14:27:23.366 INFO nova.filters
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filter
RetryFilter returned 0 hosts
2017-02-22 14:27:23.367 INFO nova.filters
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filtering removed
all hosts for the request with instance ID
'c74f394f-c805-4b5c-ba42-507dfda2c5be'. Filter results: ['RetryFilter:
(start: 0, end: 0)']


n-cond:
​
2017-02-22 14:27:23.375 TRACE nova.conductor.manager   File
"/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 79, in
select_destinations
2017-02-22 14:27:23.375 TRACE nova.conductor.manager raise
exception.NoValidHost(reason=reason)
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.375 TRACE nova.conductor.manager NoValidHost: No valid
host was found. There are not enough hosts available.
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.424 WARNING nova.scheduler.utils
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Failed to
compute_task_build_instances: No valid host was found. There are not enough
hosts available.
Traceback (most recent call last):

  File
"/usr/local/lib/python2.7/dist-packages/oslo_m

Re: [openstack-dev] [stable/ocata] [nova] [devstack multi-node] nova-conductor complaining about "No cell mapping found for cell0"

[Matt Riedemann]

On 2/22/2017 9:33 AM, Prashant Shetty wrote:

Thanks Matt.

Here are the steps I have performed, I dont see any error related to
cell0 now but n-cond still not able to detect computes after discover as
well :(.

Do we need any cell setting on nova-compute nodes as well?.

vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova service-list
++--+---+--+-+---++-+
| Id | Binary   | Host  | Zone | Status  | State |
Updated_at | Disabled Reason |
++--+---+--+-+---++-+
| 7  | nova-conductor   | cntr11| internal | enabled | up|
2017-02-22T14:23:34.00 | -   |
| 9  | nova-scheduler   | cntr11| internal | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 10 | nova-consoleauth | cntr11| internal | enabled | up|
2017-02-22T14:23:33.00 | -   |
| 11 | nova-compute | esx-ubuntu-02 | nova | enabled | up|
2017-02-22T14:23:35.00 | -   |
| 12 | nova-compute | esx-ubuntu-03 | nova | enabled | up|
2017-02-22T14:23:35.00 | -   |
| 13 | nova-compute | esx-ubuntu-01 | nova | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 14 | nova-compute | kvm-3 | nova | enabled | up|
2017-02-22T14:23:28.00 | -   |
| 15 | nova-compute | kvm-1 | nova | enabled | up|
2017-02-22T14:23:32.00 | -   |
| 16 | nova-compute | kvm-2 | nova | enabled | up|
2017-02-22T14:23:32.00 | -   |
++--+---+--+-+---++-+
vmware@cntr11:~/nsbu_cqe_openstack/devstack$
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
map_cell0 --database_connection
mysql+pymysql://root:vmware@127.0.0.1/nova?charset=utf8

vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
simple_cell_setup --transport-url
rabbit://stackrabbit:vmware@60.0.24.49:5672/

Cell0 is already setup
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2 list_cells
+---+--+
|  Name | UUID |
+---+--+
|  None | ea6bec24-058a-4ba2-8d21-57d34c01802c |
| cell0 | ---- |
+---+--+
vmware@cntr11:~/nsbu_cqe_openstack/devstack$ nova-manage cell_v2
discover_hosts --verbose
Found 2 cell mappings.
Skipping cell0 since it does not contain hosts.
Getting compute nodes from cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
Found 6 computes in cell: ea6bec24-058a-4ba2-8d21-57d34c01802c
Checking host mapping for compute host 'kvm-3':
a4b175d6-f5cc-45a8-9cf2-45726293b5c5
Checking host mapping for compute host 'esx-ubuntu-02':
70281329-590c-4cb7-8839-fd84160345b7
Checking host mapping for compute host 'esx-ubuntu-03':
04ea75a2-789e-483e-8d0e-4b0f79e012dc
Checking host mapping for compute host 'kvm-1':
dfabae3c-4ea9-4e8f-a496-8880dd9e89d9
Checking host mapping for compute host 'kvm-2':
d1cb30f5-822c-4c18-81fb-921ca676b834
Checking host mapping for compute host 'esx-ubuntu-01':
d00f8f16-af6b-437d-8136-bc744eb2472f
vmware@cntr11:~/nsbu_cqe_openstack/devstack$

​n-sch:
2017-02-22 14:26:51.467 INFO nova.scheduler.host_manager
[req-56d1cefb-1dfb-481d-aaff-b7b6e05f83f0 None None] Successfully synced
instances from host 'kvm-2'.
2017-02-22 14:26:51.608 INFO nova.scheduler.host_manager
[req-690b1a18-a709-49b2-bfad-2a6a75a3bee2 None None] Successfully synced
instances from host 'kvm-3'.
2017-02-22 14:27:23.366 INFO nova.filters
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filter
RetryFilter returned 0 hosts
2017-02-22 14:27:23.367 INFO nova.filters
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Filtering
removed all hosts for the request with instance ID
'c74f394f-c805-4b5c-ba42-507dfda2c5be'. Filter results: ['RetryFilter:
(start: 0, end: 0)']


n-cond:
​
2017-02-22 14:27:23.375 TRACE nova.conductor.manager   File
"/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 79, in
select_destinations
2017-02-22 14:27:23.375 TRACE nova.conductor.manager raise
exception.NoValidHost(reason=reason)
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.375 TRACE nova.conductor.manager NoValidHost: No
valid host was found. There are not enough hosts available.
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.375 TRACE nova.conductor.manager
2017-02-22 14:27:23.424 WARNING nova.scheduler.utils
[req-1085ec50-29f7-4946-81e2-03c1378e8077 alt_demo admin] Failed to
compute_task_build_instances: No valid host

[openstack-dev] [Neutron][FWaaS][PTG] FWaaS team gathering Thursday for lunch

[German Eichberger]

All,

The FWaaS team will meet for lunch at the Sheraton tomorrow, Thursday, to tlak 
about Pike priorities (https://etherpad.openstack.org/p/fwaas-pike) and prepare 
for Friday’s Advanced Srrvices session. Ping us on irc if you can’t find our 
table.

German
__
OpenStack Development Mailing 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 api on https

[Gyorgy Szombathelyi]

Hi,

Ok, opened a bug report, I'll upload a new patchset soon, too.

https://bugs.launchpad.net/nova/+bug/1666936

Br,
György

> -Original Message-
> From: Sylvain Bauza [mailto:sba...@redhat.com]
> Sent: 2017 február 22, szerda 13:49
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova]Placement api on https
> 
> 
> 
> Le 22/02/2017 05:14, Gyorgy Szombathelyi a écrit :
> > Hi!
> >
> > As the placement API is mandatory in Ocata, I found out that you cannot
> give a custom CA cert or skip the validation in its clients. That would be 
> bad,
> as you can give a custom CA cert in the [keystone_authtoken] section, but
> not in the [placement] one, so if you're using this feature, you simply cannot
> use Nova. I made a simple patch, it would be nice if it could land in Ocata.
> >
> > https://review.openstack.org/#/c/436475/
> >
> > If it is accepted, I'll cherry-pick into stable/ocata.
> >
> 
> Could you please open a bug for that so I would triage ?
> 
> Thanks,
> -Sylvain
> 
> > Br,
> > György
> >
> >
> __
> 
> >  OpenStack Development Mailing 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] [QA] [ptg] Team photo

[Yaroslav Lobankov]

+1

Regards,
Yaroslav Lobankov.

On Wed, Feb 22, 2017 at 8:14 AM,  wrote:

> Who can kindly send me a photo as an mail attachment? I am curious about
> it but I can't open the link ^-^
>
>
> Original Mail
> *Sender: * ＜andrea.fritt...@gmail.com＞;
> *To: * ＜openstack-dev@lists.openstack.org＞;
> *Date: *2017/02/22 11:40
> *Subject: **[openstack-dev] [QA] [ptg] Team photo*
>
>
> Here are our team photos: https://www.dropbox.com/home/
> Public/PTG%20Atlanta%20QA%20Team
>
> andrea
>
>
>
>
>
> __
> OpenStack Development Mailing 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] Ocata stable branches opened

[Doug Hellmann]

Now that we have completed the Ocata final release, control over
the stable/ocata branches have been transitioned to the stable
maintenance teams. Patches going into stable/ocata should follow
the stable-backport policy (see the Project Team Guide [1] for
details), and it is now possible to request Ocata stable point
releases.

The release team is all in Atlanta at the PTG, so there may be
delays with releases until next week, but if you have a critical
bug please let us know and we will prioritize it.

Thank you all for your contributions to Ocata, and for making this
release cycle so smooth even though it was shorter than usual!

Doug

[1] https://docs.openstack.org/project-team-guide/stable-branches.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] [infra] merging code from a github repo to an openstack existing repo: how ?

[Thomas Morin]

Hi,

A bit of context to make my question clearer: 
openstack/networking-bagpipe relies on bagpipe-bgp which is not an 
openstack project although done by the same people, and we would see a 
significant benefit in moving the code from github to openstack. This 
post does not relate to licence/CLA questions (all clear AFAIK, licence 
is Apache, all contributions by people who are also Openstack 
contributors). It does not relate to code style or lib dependencies 
either (there are a few things to adapt, which we have identified and 
mostly covered already).


The target would be: have the content of github's bagpipe-bgp repo 
become a sub directory of the networking-bagpipe repo, and then tweak 
setup.cfg/tox.ini so that this subdirectory becomes packaged and tested.


The question is:  how to achieve that without squashing/losing all git 
history (and without pushing one gerrit change per existing commit in 
the current history) ?


Would the following work...?
- in the github repo: prepare a 'move_to_openstack' branch  where all 
repo content is moved in a 'bagpipe_bgp' subdir

- in networking-bagpipe repo:
   * create a 'welcome_bagpipe_bgp' branch
   * have a manual step where someone (infra team ?) adds the github 
repo as a remote and merges the remote 'move_to_openstack' branch into 
the 'welcome_bagpipe_bgp' local branch (without squashing).
   * in this 'welcome_bagpipe_bgp' branch do whatever is needed in 
terms of setup.cfg/requirements.txt/tox.ini ...
   * when everything is ready, merge the 'welcome_bagpipe_bgp' branch 
into master

- (in the gitub repo: replace the content with an explanation message)

(If the above does not work, what other possibility ?)

-Thomas

[1]  https://github.com/Orange-OpenSource/bagpipe-bgp


__
OpenStack Development Mailing 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] [searchlight] IRC Meeting Feb 23rd cancelled

[McLellan, Steven]

Hi,

Due to a combination of the PTG and vacations, I'm cancelling the Searchlight 
IRC meeting for Thursday Feb 23rd. We'll resume as normal the following week.

Thanks!

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

Re: [openstack-dev] [ironic] End-of-Ocata core team updates

[Jim Rollenhagen]

We've a clear majority here, I took the liberty of adding Mario and Vasyl
while Dmitry is busy running our sessions today. Welcome to the team, y'all
:)


// jim

On Fri, Feb 17, 2017 at 4:40 AM, Dmitry Tantsur  wrote:

> Hi all!
>
> I'd like to propose a few changes based on the recent contributor activity.
>
> I have two candidates that look very good and pass the formal barrier of 3
> reviews a day on average [1].
>
> First, Vasyl Saienko (vsaienk0). I'm pretty confident in him, his stats
> [2] are high, he's doing a lot of extremely useful work around networking
> and CI.
>
> Second, Mario Villaplana (mariojv). His stats [3] are quite high too, he
> has been doing some quality reviews for critical patches in the Ocata cycle.
>
> Active cores and interested contributors, please respond with your +-1 to
> these suggestions.
>
> Unfortunately, there is one removal as well. Devananda, our team leader
> for several cycles since the very beginning of the project, has not been
> active on the project for some time [4]. I propose to (hopefully temporary)
> remove him from the core team. Of course, when (look, I'm not even saying
> "if"!) he comes back to active reviewing, I suggest we fast-forward him
> back. Thanks for everything Deva, good luck with your current challenges!
>
> Thanks,
> Dmitry
>
> [1] http://stackalytics.com/report/contribution/ironic-group/90
> [2] http://stackalytics.com/?user_id=vsaienko&metric=marks
> [3] http://stackalytics.com/?user_id=mario-villaplana-j&metric=marks
> [4] http://stackalytics.com/?user_id=devananda&metric=marks
>
> __
> OpenStack Development Mailing 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] [QA]Removal of test runner wrapper scripts in Tempest

[Jordan Pittier]

Hi,
I've proposed https://review.openstack.org/#/c/436983/ in Tempest which
says:

*Remove deprecated test runner wrappers (.sh files) This patch removes
run_tempest.sh, run_tests.sh, tools/pretty_tox.sh
tools/pretty_tox_serial.sh. They all have been deprecated between 7 and 9
months ago. As stated in the deprecation warnings, the way forward is with
os-testr, testr or stestr.*

If you are still using one of these scripts from the Tempest repo, please do
the switch and reply to this email so that we give you some extra time.

Cheers,
Jordan
__
OpenStack Development Mailing 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] Enable arp_responder without l2pop

[Anil Venkata]

On Wed, Feb 22, 2017 at 6:19 PM, Thomas Morin 
wrote:

> Hi Anil,
>
> Tue Feb 21 2017 22:47:46 GMT-0500 (EST), Anil Venkata:
>
>> Currently arp_resonder can enabled only if l2pop is enabled.
>>
>> Can we have arp_responder feature enabled without l2pop(i.e Remove the
>> dependency between arp_responder and l2_pop)?
>>
>>
> I agree that it would be useful.
> networking-bgpvpn ovs/bagpipe driver is relying on arp_responder, and
> hence currently draws this dependency on l2pop (not an issue I find, but
> still an artefact rather than a design decision).
>
> Also setup arp_responder on OVS integration bridge(and not on br-tun)?
>>
>>
> While relevant, I think this is not possible until br-int allows to match
> the network a packet belongs to (the ovsdb port tags don't let you do that
> until the packet leaves br-int with a NORMAL action).
> Ajo has told me yesterday that the OVS firewall driver uses registers
> precisely to do that. Making this generic (and not specific to the OVS
> firewall driver) would be a prerequisite before you can add ARP responder
> rules in br-int.
>
>
Thanks Thomas. Spoke to Ajo on this. He said we can follow above suggestion
i.e do the same what firewall driver is doing  in br-int, or wait till OVS
flow extension is implemented(but this will take time as lack of resources)


> I think this question (of where to put the ARP responder rules) also
> relates to https://review.openstack.org/#/c/320439/ .
>
> -Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] RFC for Intel RDT/CAT Support in Nova for Virtual Machine QoS

[Jay Pipes]

Hi Eli,

Sorry for top-posting. Just a quick note to say I had a good 
conversation on Monday about this with Sean Mooney. I think we have some 
ideas on how to model all of these resources in the new 
placement/resource providers schema.


Are you at the PTG? If so, would be great to meet up to discuss...

Best,
-jay

On 02/21/2017 05:38 AM, Qiao, Liyong wrote:

Hi folks:



Seeking community input on an initial design for Intel Resource Director
Technology (RDT), in particular for Cache Allocation Technology in
OpenStack Nova to protect workloads from co-resident noisy neighbors, to
ensure quality of service (QoS).



1. What is Cache Allocation Technology (CAT)?**

Intel’s RDT(Resource Director Technology) [1]  is a umbrella of
*hardware* support to facilitate the monitoring and reservation of
shared resources such as cache, memory and network bandwidth towards
obtaining Quality of Service. RDT will enable fine grain control of
resources which in particular is valuable in cloud environments to meet
Service Level Agreements while increasing resource utilization through
sharing. CAT is a part of RDT and concerns itself with reserving for a
process(es) a portion of last level cache with further fine grain
control as to how much for code versus data. The below figure shows a
single processor composed of 4 cores and the cache hierarchy. The L1
cache is split into Instruction and Data, the L2 cache is next in speed
to L1. The L1 and L2 caches are per core. The Last Level Cache (LLC) is
shared among all cores. With CAT on the currently available hardware the
LLC can be partitioned on a per process (virtual machine, container, or
normal application) or process group basis.



Libvirt and OpenStack [2] already support monitoring cache (CMT) and
memory bandwidth usage local to a processor socket (MBM_local) and total
memory bandwidth usage across all processor sockets (MBM_total) for a
process or process group.




2. How CAT works  **

To learn more about CAT please refer to the Intel Processor Soft
Developer's Manual

 volume 3b, chapters 17.16 and 17.17 [3]. Linux kernel support for the
same is expected in release 4.10 and documented at [4]


3. Libvirt Interface**


Libvirt support for CAT is underway with the patch at reversion 7



Interface changes of libvirt:



3.1 The capabilities xml has been extended to reveal cache information **





 

   

 

 

   

 





The new `cache` xml element shows that the host has two *banks* of
*type* L3 or Last Level Cache (LLC), one per processor socket. The cache
*type* is l3 cache, its *size* 56320 KiB, and the *cpus* attribute
indicates the physical CPUs associated with the same, here ‘0-21’,
‘44-65’ respectively.



The *control *tag shows that bank belongs to scope L3, with a minimum
possible allocation of 2816 KiB and still has 2816 KiB need to be reserved.



If the host enabled CDP (Code and Data Prioritization) , l3 cache will
be divided as code  (L3CODE)and data (L3Data).



Control tag will be extended to:

...

 

 

…



The scope of L3CODE and L3DATA show that we can allocate cache for
code/data usage respectively, they share same amount of l3 cache.



3.2 Domain xml extended to include new CacheTune element **





   

   

   

   

   

...





This means the guest will be have vcpus 0, 1 running on host’s socket 0,
with 2816 KiB cache exclusively allocated to it and vcpus 2, 3 running
on host’s socket 0, with 2816 KiB cache exclusively allocated to it.



Here we need to make sure vcpus 0, 1 are pinned to the pcpus of socket
0, refer capabilities

 :



Here we need to make sure vcpus 2, 3 are pinned to the pcpus of socket
1, refer capabilities

 :.



3.3 Libvirt work flow for CAT**



 1. Create qemu process and get it’s PIDs
 2. Define a new resource control domain also known as
*Cl*ass-*o*f-*S*ervice (CLOS) under /sys/fs/resctrl and set the
desired *C*ache *B*it *M*ask(CBM) in the libvirt domain xml file in
addition to updating the default schemata of the host



4. Proposed Nova Changes**



 1. Get host capabilities from libvirt and extend compute node’ filed
 2. Add new scheduler filter and weight to help schedule host for
requested guest.
 3. Extend flavor’s (and image meta) extra spec fields:



We need to specify  numa setting for NUMA hosts if we want to enable
CAT, see [5] to learn more about NUMA.

In flavor, we can have:



vcpus=8

mem=4

hw:numa_nodes=2 - numa of NUMA nodes to expose to the guest.

hw:numa_cpus.0=0,1,2,3,4,5

hw:numa_cpus.1=6,7

hw:numa_mem.0=3072

hw:numa_mem.1=1024

//  new added in the proposal

hw:cache_banks=2   ///cache banks to be allocated to a  guest, (can be
less than the number of NUMA nodes)/

hw:cache_type.0=l3  ///cache bank type, could be l3, l3data + l3code/

hw:cache_type.1=l3_c+d  ///cache bank type, could be l3, l3data + l3code/

hw:cac

Re: [openstack-dev] [QA] [ptg] Team photo

[Andrea Frittoli]

My bad, this link should be working:
https://www.dropbox.com/sh/9svvv9cx51s1gzc/AAABHkfOTNtsUwi9Eb2GxPXLa?dl=0

The pictures are quite large so I'd rather not attach them directly.

andrea

On Wed, Feb 22, 2017 at 10:15 AM Yaroslav Lobankov 
wrote:

> +1
>
> Regards,
> Yaroslav Lobankov.
>
> On Wed, Feb 22, 2017 at 8:14 AM,  wrote:
>
> Who can kindly send me a photo as an mail attachment? I am curious about
> it but I can't open the link ^-^
>
>
> Original Mail
> *Sender: * ＜andrea.fritt...@gmail.com＞;
> *To: * ＜openstack-dev@lists.openstack.org＞;
> *Date: *2017/02/22 11:40
> *Subject: **[openstack-dev] [QA] [ptg] Team photo*
>
>
> Here are our team photos:
> https://www.dropbox.com/home/Public/PTG%20Atlanta%20QA%20Team
>
> andrea
>
>
>
>
>
> __
> OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Adam Spiers]

Kosnik, Lubosz  wrote:
> About success of RDO we need to remember that this deployment utilizes 
> Peacemaker and when I was working on this feature and even I spoke with Assaf 
> this external application was doing everything to make this solution working. 
> Peacemaker was responsible for checking external and internal connectivity. 
> To detect split brain. Elect master, even keepalived was running but 
> Peacemaker was automatically killing all services and moving FIP. 
> Assaf - is there any change in this implementation in RDO? Or you’re still 
> doing everything outside of Neutron? 
> 
> Because if RDO success is build on Peacemaker it means that yes, Neutron 
> needs some solution which will be available for more than RH deployments. 

Agreed.

With help from others, I have started an analysis of some of the 
different approaches to L3 HA: 

https://ethercalc.openstack.org/Pike-Neutron-L3-HA 

(although I take responsibility for all mistakes ;-) 

It would be great if someone from RH or RDO could provide information 
on how this RDO (and/or RH OSP?) solution based on Pacemaker + 
keepalived works - if so, I volunteer to: 

  - help populate column E of the above sheet so that we can
understand if there are still remaining gaps in the solution, and

  - document it (e.g. in the HA guide).  Even if this only ended up
being considered as a shorter-term solution, I think it's still
worth documenting so that it's another option available to
everyone.

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] RFC for Intel RDT/CAT Support in Nova for Virtual Machine QoS

[Alex Xu]

@Jay, actually I'm here for CAT. I also have another idea about the
proposal, so catch you about it, let us sync all the ideas. :)

Thanks
Alex

2017-02-22 11:17 GMT-05:00 Jay Pipes :

> Hi Eli,
>
> Sorry for top-posting. Just a quick note to say I had a good conversation
> on Monday about this with Sean Mooney. I think we have some ideas on how to
> model all of these resources in the new placement/resource providers schema.
>
> Are you at the PTG? If so, would be great to meet up to discuss...
>
> Best,
> -jay
>
> On 02/21/2017 05:38 AM, Qiao, Liyong wrote:
>
>> Hi folks:
>>
>>
>>
>> Seeking community input on an initial design for Intel Resource Director
>> Technology (RDT), in particular for Cache Allocation Technology in
>> OpenStack Nova to protect workloads from co-resident noisy neighbors, to
>> ensure quality of service (QoS).
>>
>>
>>
>> 1. What is Cache Allocation Technology (CAT)?**
>>
>> Intel’s RDT(Resource Director Technology) [1]  is a umbrella of
>> *hardware* support to facilitate the monitoring and reservation of
>> shared resources such as cache, memory and network bandwidth towards
>> obtaining Quality of Service. RDT will enable fine grain control of
>> resources which in particular is valuable in cloud environments to meet
>> Service Level Agreements while increasing resource utilization through
>> sharing. CAT is a part of RDT and concerns itself with reserving for a
>> process(es) a portion of last level cache with further fine grain
>> control as to how much for code versus data. The below figure shows a
>> single processor composed of 4 cores and the cache hierarchy. The L1
>> cache is split into Instruction and Data, the L2 cache is next in speed
>> to L1. The L1 and L2 caches are per core. The Last Level Cache (LLC) is
>> shared among all cores. With CAT on the currently available hardware the
>> LLC can be partitioned on a per process (virtual machine, container, or
>> normal application) or process group basis.
>>
>>
>>
>> Libvirt and OpenStack [2] already support monitoring cache (CMT) and
>> memory bandwidth usage local to a processor socket (MBM_local) and total
>> memory bandwidth usage across all processor sockets (MBM_total) for a
>> process or process group.
>>
>>
>>
>>
>> 2. How CAT works  **
>>
>> To learn more about CAT please refer to the Intel Processor Soft
>> Developer's Manual
>> > ures-software-developer-manuals.html>
>>  volume 3b, chapters 17.16 and 17.17 [3]. Linux kernel support for the
>> same is expected in release 4.10 and documented at [4]
>>
>>
>> 3. Libvirt Interface**
>>
>>
>> Libvirt support for CAT is underway with the patch at reversion 7
>>
>>
>>
>> Interface changes of libvirt:
>>
>>
>>
>> 3.1 The capabilities xml has been extended to reveal cache information **
>>
>>
>>
>> 
>>
>>  
>>
>>
>>
>>  
>>
>>  
>>
>>
>>
>>  
>>
>> 
>>
>>
>>
>> The new `cache` xml element shows that the host has two *banks* of
>> *type* L3 or Last Level Cache (LLC), one per processor socket. The cache
>> *type* is l3 cache, its *size* 56320 KiB, and the *cpus* attribute
>> indicates the physical CPUs associated with the same, here ‘0-21’,
>> ‘44-65’ respectively.
>>
>>
>>
>> The *control *tag shows that bank belongs to scope L3, with a minimum
>> possible allocation of 2816 KiB and still has 2816 KiB need to be
>> reserved.
>>
>>
>>
>> If the host enabled CDP (Code and Data Prioritization) , l3 cache will
>> be divided as code  (L3CODE)and data (L3Data).
>>
>>
>>
>> Control tag will be extended to:
>>
>> ...
>>
>>  
>>
>>  
>>
>> …
>>
>>
>>
>> The scope of L3CODE and L3DATA show that we can allocate cache for
>> code/data usage respectively, they share same amount of l3 cache.
>>
>>
>>
>> 3.2 Domain xml extended to include new CacheTune element **
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> vcpus='0, 1/>
>>
>>> vcpus=’2, 3’/>
>>
>> ...
>>
>> 
>>
>>
>>
>> This means the guest will be have vcpus 0, 1 running on host’s socket 0,
>> with 2816 KiB cache exclusively allocated to it and vcpus 2, 3 running
>> on host’s socket 0, with 2816 KiB cache exclusively allocated to it.
>>
>>
>>
>> Here we need to make sure vcpus 0, 1 are pinned to the pcpus of socket
>> 0, refer capabilities
>>
>>  :
>>
>>
>>
>> Here we need to make sure vcpus 2, 3 are pinned to the pcpus of socket
>> 1, refer capabilities
>>
>>  :.
>>
>>
>>
>> 3.3 Libvirt work flow for CAT**
>>
>>
>>
>>  1. Create qemu process and get it’s PIDs
>>  2. Define a new resource control domain also known as
>> *Cl*ass-*o*f-*S*ervice (CLOS) under /sys/fs/resctrl and set the
>> desired *C*ache *B*it *M*ask(CBM) in the libvirt domain xml file in
>> addition to updating the default schemata of the host
>>
>>
>>
>> 4. Proposed Nova Changes**
>>
>>
>>
>>  1. Get host capabilities from libvirt and extend compute node’ filed
>>  2. Add new scheduler filter and weight to help sched

[openstack-dev] [stable] [glance] revising the stable-maintenance list

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 17, 2017 at 10:21:17
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance] revising the core list

> Finally, the following people are dropped from the Glance core list due
> to inactivity during Ocata. On behalf of the entire Glance team, I
> thank each of you for your past service to Glance, and hope to see you
> again as Glance contributors:
> - Kairat Kushaev
> - Mike Fedosin
> - Louis Taylor

On the heels of this removal, I'd like to propose also removing Mike
Fedosin from the stable-maintenance team for Glance.

--
Ian Cordasco
Glance Stable Branch Liaison

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

[openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Truman, Travis]

OpenStack-Ansible team,

I've very much enjoyed being part of the OpenStack community over the past 14 
months. My time in the OpenStack-Ansible community has been one of the most 
rewarding experiences of my career. However, my career is changing directions 
and I'll no longer be able to invest the time and energy required to maintain 
my involvement in the community.

As a result, I'm resigning my core reviewer status effective immediately.

Thank you to all of you in the community that I've worked with in IRC, at 
summits in Austin and Barcelona and to all of you who gave your time to review 
and improve my contributions.

Travis Truman

__
OpenStack Development Mailing 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] [stable] [glance] revising the stable-maintenance list

[Tony Breeds]

On Wed, Feb 22, 2017 at 08:44:49AM -0800, Ian Cordasco wrote:
> -Original Message-
> From: Brian Rosmaita 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: February 17, 2017 at 10:21:17
> To: OpenStack Development Mailing List 
> Subject:  [openstack-dev] [glance] revising the core list
> 
> > Finally, the following people are dropped from the Glance core list due
> > to inactivity during Ocata. On behalf of the entire Glance team, I
> > thank each of you for your past service to Glance, and hope to see you
> > again as Glance contributors:
> > - Kairat Kushaev
> > - Mike Fedosin
> > - Louis Taylor
> 
> On the heels of this removal, I'd like to propose also removing Mike
> Fedosin from the stable-maintenance team for Glance.

okay.  Done.  It's always sad to see cores move on.

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] [neutron] - Neutron team social in Atlanta on Thursday

[Ian Wells]

+1

On 21 February 2017 at 16:18, Ichihara Hirofumi  wrote:

> +1
>
> 2017-02-17 14:18 GMT-05:00 Kevin Benton :
>
>> Hi all,
>>
>> I'm organizing a Neutron social event for Thursday evening in Atlanta
>> somewhere near the venue for dinner/drinks. If you're interested, please
>> reply to this email with a "+1" so I can get a general count for a
>> reservation.
>>
>> Cheers,
>> Kevin Benton
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Ian Cordasco]

-Original Message-
From: Truman, Travis 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 22, 2017 at 10:49:57
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

> OpenStack-Ansible team,
>
> I've very much enjoyed being part of the OpenStack community over the past 14 
> months.
> My time in the OpenStack-Ansible community has been one of the most rewarding 
> experiences
> of my career. However, my career is changing directions and I'll no longer be 
> able to invest
> the time and energy required to maintain my involvement in the community.
>
> As a result, I'm resigning my core reviewer status effective immediately.
>
> Thank you to all of you in the community that I've worked with in IRC, at 
> summits in Austin
> and Barcelona and to all of you who gave your time to review and improve my 
> contributions.

Thank you for all your work on OSA Travis! Your reviews and
contributions have been very valuable.

--
Ian Cordasco

__
OpenStack Development Mailing 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] [QA]Removal of test runner wrapper scripts in Tempest

[Andrea Frittoli]

On Wed, Feb 22, 2017 at 10:40 AM Jordan Pittier 
wrote:

> Hi,
> I've proposed https://review.openstack.org/#/c/436983/ in Tempest which
> says:
>
> *Remove deprecated test runner wrappers (.sh files) This patch removes
> run_tempest.sh, run_tests.sh, tools/pretty_tox.sh
> tools/pretty_tox_serial.sh. They all have been deprecated between 7 and 9
> months ago. As stated in the deprecation warnings, the way forward is with
> os-testr, testr or stestr.*
>
> If you are still using one of these scripts from the Tempest repo, please
> do
> the switch and reply to this email so that we give you some extra time.
>
> Cheers,
> Jordan
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


+1

andrea
__
OpenStack Development Mailing 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] Upstream Training Team meeting at PTG - Are you coming?

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in Savannah 3.
Br,
Gerg0

Sent from Nine

From: Ildiko Vancsa 
Sent: Feb 21, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; user-committee
Subject: Re: [openstack-dev] [all] Upstream Training Team meeting at PTG - Are 
you coming?

Hi All,

A quick reminder that we will have our face to face gathering on __Wednesday 
(tomorrow) at lunch time (12pm ET)__.

I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch box 
after the morning sessions and join us for lunch if you would like to get 
involved with the Upstream Training and/or new contributor on boarding 
activities.

Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa  wrote:
>
> Hi,
>
> We are forming a virtual upstream collaboration training team including 
> everyone who’s either helping us out with maintaining and improving the 
> training material and/or who are attending the course as coaches or mentors.
>
> We are planning to meet at the PTG in person next week on Wednesday at lunch 
> time. We picked this slot as our first face to face gathering as all of us 
> have project related assignments to drive and sessions to attend that makes 
> scheduling a meeting even more challenging.
>
> If you are interested in what we are doing and how we are trying to make the 
> on boarding process for new contributors a pleasant experience and would like 
> to join our activities meet us there!
>
> The meeting time is __Wednesday (February 22) lunch time__. I will share the 
> meeting point next week before the meeting.
>
> If you would like to have a mail reminder prior to the meeting next week 
> please reach out to me.
>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


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

Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team meeting at PTG - Are you coming?

[Amy Marrich]

I tried to get into the google hangout
https://hangouts.google.com/call/4htgw2zmb5ar5mzihizsnppf4ye and it said I
wasn't allowed to join. I did send Ildiko my phone number if I'm the only
remote.

Amy

On Wed, Feb 22, 2017 at 11:04 AM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
> We are waiting in Savannah 1 as there is a meeting still ongoing in
> Savannah 3.
> Br,
> Gerg0
>
> Sent from Nine 
> --
> *From:* Ildiko Vancsa 
> *Sent:* Feb 21, 2017 9:05 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> openstack-d...@lists.openstack.org; user-committee
> *Subject:* Re: [openstack-dev] [all] Upstream Training Team meeting at
> PTG - Are you coming?
>
> Hi All,
>
> A quick reminder that we will have our face to face gathering on
> __Wednesday (tomorrow) at lunch time (12pm ET)__.
>
> I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch
> box after the morning sessions and join us for lunch if you would like to
> get involved with the Upstream Training and/or new contributor on boarding
> activities.
>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov
>
>
> > On 2017. Feb 15., at 13:16, Ildiko Vancsa 
> wrote:
> >
> > Hi,
> >
> > We are forming a virtual upstream collaboration training team including
> everyone who’s either helping us out with maintaining and improving the
> training material and/or who are attending the course as coaches or mentors.
> >
> > We are planning to meet at the PTG in person next week on Wednesday at
> lunch time. We picked this slot as our first face to face gathering as all
> of us have project related assignments to drive and sessions to attend that
> makes scheduling a meeting even more challenging.
> >
> > If you are interested in what we are doing and how we are trying to make
> the on boarding process for new contributors a pleasant experience and
> would like to join our activities meet us there!
> >
> > The meeting time is __Wednesday (February 22) lunch time__. I will share
> the meeting point next week before the meeting.
> >
> > If you would like to have a mail reminder prior to the meeting next week
> please reach out to me.
> >
> > Thanks and Best Regards,
> > Ildikó
> > IRC: ildikov
>
>
> __
> OpenStack Development Mailing 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-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team meeting at PTG - Are you coming?

[Ian Y. Choi]

Hello Csatari,

The previous meeting in Savannah 3 has been finished. Please come here !  :)


With many thanks,

/Ian

Csatari, Gergely (Nokia - HU/Budapest) wrote on 2/23/2017 2:04 AM:

Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in 
Savannah 3.

Br,
Gerg0

Sent from Nine 

*From:* Ildiko Vancsa 
*Sent:* Feb 21, 2017 9:05 AM
*To:* OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; user-committee
*Subject:* Re: [openstack-dev] [all] Upstream Training Team meeting at 
PTG - Are you coming?


Hi All,

A quick reminder that we will have our face to face gathering on 
__Wednesday (tomorrow) at lunch time (12pm ET)__.


I booked Savannah 3 on the second floor (Lobby level). Please grab a 
lunch box after the morning sessions and join us for lunch if you 
would like to get involved with the Upstream Training and/or new 
contributor on boarding activities.


Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa  
wrote:

>
> Hi,
>
> We are forming a virtual upstream collaboration training team 
including everyone who’s either helping us out with maintaining and 
improving the training material and/or who are attending the course as 
coaches or mentors.

>
> We are planning to meet at the PTG in person next week on Wednesday 
at lunch time. We picked this slot as our first face to face gathering 
as all of us have project related assignments to drive and sessions to 
attend that makes scheduling a meeting even more challenging.

>
> If you are interested in what we are doing and how we are trying to 
make the on boarding process for new contributors a pleasant 
experience and would like to join our activities meet us there!

>
> The meeting time is __Wednesday (February 22) lunch time__. I will 
share the meeting point next week before the meeting.

>
> If you would like to have a mail reminder prior to the meeting next 
week please reach out to me.

>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


__
OpenStack Development Mailing 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-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



__
OpenStack Development Mailing 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] [fuel] Weekly meeting Feb 23 is canceled

[Vladimir Kuklin]

Feb 23 meeting is cancelled as majority of Fuel contributors will be on
holidays that day and others are travelling. See you all next week.

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Jesse Pretorius]

Thank you for your valuable input, drive and commitment to make OSA better. You 
are already missed! I wish you the very best in your next career evolution.

From: "Truman, Travis" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 22, 2017 at 11:48 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

OpenStack-Ansible team,

I’ve very much enjoyed being part of the OpenStack community over the past 14 
months. My time in the OpenStack-Ansible community has been one of the most 
rewarding experiences of my career. However, my career is changing directions 
and I’ll no longer be able to invest the time and energy required to maintain 
my involvement in the community.

As a result, I’m resigning my core reviewer status effective immediately.

Thank you to all of you in the community that I’ve worked with in IRC, at 
summits in Austin and Barcelona and to all of you who gave your time to review 
and improve my contributions.

Travis Truman




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] merging code from a github repo to an openstack existing repo: how ?

[Tony Breeds]

On Wed, Feb 22, 2017 at 10:31:34AM -0500, Thomas Morin wrote:
> Hi,
> 
> A bit of context to make my question clearer: openstack/networking-bagpipe
> relies on bagpipe-bgp which is not an openstack project although done by the
> same people, and we would see a significant benefit in moving the code from
> github to openstack. This post does not relate to licence/CLA questions (all
> clear AFAIK, licence is Apache, all contributions by people who are also
> Openstack contributors). It does not relate to code style or lib
> dependencies either (there are a few things to adapt, which we have
> identified and mostly covered already).
> 
> The target would be: have the content of github's bagpipe-bgp repo become a
> sub directory of the networking-bagpipe repo, and then tweak
> setup.cfg/tox.ini so that this subdirectory becomes packaged and tested.

I don't believe that will work.  for the most part PBR assumes 1 repo == 1 
package.

Why not just import github:bagpipe-bgp into openstack/bagpipe-bgp and treat it
like any other OpenStack project?

It's pretty trivial to do that and it's documented in the infra manual:
https://docs.openstack.org/infra/manual/creators.html

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] [qa] Tempest Stable plugin interface change broke gate

[Hayes, Graham]

On 21/02/2017 15:25, Andrea Frittoli wrote:
> Hi Graham,
>
> sorry about that, and good catch.
> You are right, that's a stable interface so that change should not have
> landed.
>
> andrea
>
> On Tue, Feb 21, 2017 at 2:51 PM Hayes, Graham  > wrote:
>
> Hi.
>
> https://review.openstack.org/#/c/434304/ landed yesterday, which was a
> change to the stable interface for tempest plugins.
>
> It also took out the designate gate.
>
> Is this interface stable? - If so, there should have been at least some
> deprecation cycle, notification, or something.
>
> Revert has been proposed - https://review.openstack.org/#/c/436612/
>
> Can someone clarify what the "stable" in "Stable APIs" listed here [1]
> means?
>
> - Graham
>
> 1 -
> 
> https://docs.openstack.org/developer/tempest/plugin.html#stable-tempest-apis-plugins-may-use
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

The revert above still hasn't merged.

The QA team blocked a change that updated HTTP status code, but removed
a stable interface with no deprecation.

The revert needs to land, now, and then the QA team can debate
deprecation / removal.

To stop this happening in the future, can we get tempest to gate on some
tempest plugins?

Just a gate job that runs when any code in the designated stable
sections of tempest change would be incredibly useful.

Thanks,

Graham

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

Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team meeting at PTG - Are you coming?

[Alexandra Settle]

Hi team,

I apologise for not making the meetup this lunch hour; I was caught up with 
documentation priorities.

I am still around for the rest of the week, and would like to see/introduce 
myself to you all at some point :)

Thanks,

Alex

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

Date: Wednesday, February 22, 2017 at 12:06 PM
To: "Csatari, Gergely (Nokia - HU/Budapest)" 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-d...@lists.openstack.org" 
, user-committee 

Subject: Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team 
meeting at PTG - Are you coming?

I tried to get into the google hangout 
https://hangouts.google.com/call/4htgw2zmb5ar5mzihizsnppf4ye and it said I 
wasn't allowed to join. I did send Ildiko my phone number if I'm the only 
remote.

Amy

On Wed, Feb 22, 2017 at 11:04 AM, Csatari, Gergely (Nokia - HU/Budapest) 
mailto:gergely.csat...@nokia.com>> wrote:
Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in Savannah 3.
Br,
Gerg0

Sent from Nine

From: Ildiko Vancsa mailto:ildiko.van...@gmail.com>>
Sent: Feb 21, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; 
user-committee
Subject: Re: [openstack-dev] [all] Upstream Training Team meeting at PTG - Are 
you coming?

Hi All,

A quick reminder that we will have our face to face gathering on __Wednesday 
(tomorrow) at lunch time (12pm ET)__.

I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch box 
after the morning sessions and join us for lunch if you would like to get 
involved with the Upstream Training and/or new contributor on boarding 
activities.

Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa 
> mailto:ildiko.van...@gmail.com>> wrote:
>
> Hi,
>
> We are forming a virtual upstream collaboration training team including 
> everyone who’s either helping us out with maintaining and improving the 
> training material and/or who are attending the course as coaches or mentors.
>
> We are planning to meet at the PTG in person next week on Wednesday at lunch 
> time. We picked this slot as our first face to face gathering as all of us 
> have project related assignments to drive and sessions to attend that makes 
> scheduling a meeting even more challenging.
>
> If you are interested in what we are doing and how we are trying to make the 
> on boarding process for new contributors a pleasant experience and would like 
> to join our activities meet us there!
>
> The meeting time is __Wednesday (February 22) lunch time__. I will share the 
> meeting point next week before the meeting.
>
> If you would like to have a mail reminder prior to the meeting next week 
> please reach out to me.
>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


__
OpenStack Development Mailing 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-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

__
OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Miguel Angel Ajo Pelayo]

I have updated the spreadsheet. In the case of RH/RDO we're using the same
architecture
in the case of HA, pacemaker is not taking care of those anymore since the
HA-NG implementation.

We let systemd take care to restart the services that die, and we worked
with the community
to make sure that agents and services are robust in case of dependent
services (database, rabbitmq
) failures, to make sure they reconnect and continue when those become
available.

On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers  wrote:

> Kosnik, Lubosz  wrote:
> > About success of RDO we need to remember that this deployment utilizes
> Peacemaker and when I was working on this feature and even I spoke with
> Assaf this external application was doing everything to make this solution
> working.
> > Peacemaker was responsible for checking external and internal
> connectivity. To detect split brain. Elect master, even keepalived was
> running but Peacemaker was automatically killing all services and moving
> FIP.
> > Assaf - is there any change in this implementation in RDO? Or you’re
> still doing everything outside of Neutron?
> >
> > Because if RDO success is build on Peacemaker it means that yes, Neutron
> needs some solution which will be available for more than RH deployments.
>
> Agreed.
>
> With help from others, I have started an analysis of some of the
> different approaches to L3 HA:
>
> https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>
> (although I take responsibility for all mistakes ;-)
>
> It would be great if someone from RH or RDO could provide information
> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
> keepalived works - if so, I volunteer to:
>
>   - help populate column E of the above sheet so that we can
> understand if there are still remaining gaps in the solution, and
>
>   - document it (e.g. in the HA guide).  Even if this only ended up
> being considered as a shorter-term solution, I think it's still
> worth documenting so that it's another option available to
> everyone.
>
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat][all]Heat evening event on Thrusday this week

[Rico Lin]

Dear all

We will have a PTG dinner and beer session on Thursday night 7:00
Here is the place: http://www.maxlagersrestaurantatlanta.com/
*location: 320 Peachtree St NE, Atlanta, GA*.
All teams are welcome to join us.


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Anil Venkata]

On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let systemd take care to restart the services that die, and we worked
> with the community
> to make sure that agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
> available.
>
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers  wrote:
>
>> Kosnik, Lubosz  wrote:
>> > About success of RDO we need to remember that this deployment utilizes
>> Peacemaker and when I was working on this feature and even I spoke with
>> Assaf this external application was doing everything to make this solution
>> working.
>> > Peacemaker was responsible for checking external and internal
>> connectivity. To detect split brain. Elect master, even keepalived was
>> running but Peacemaker was automatically killing all services and moving
>> FIP.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> still doing everything outside of Neutron?
>> >
>> > Because if RDO success is build on Peacemaker it means that yes,
>> Neutron needs some solution which will be available for more than RH
>> deployments.
>>
>> Agreed.
>>
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>>
>> https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>>
>> (although I take responsibility for all mistakes ;-)
>>
>

Did you test with this patch https://review.openstack.org/#/c/255237/  ? It
was merged in newton cycle.
With this patch, HA+L2pop doesn't depend on control plane during fail over,
hence failover should be faster(same as without l2pop).


>
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>>
>>   - help populate column E of the above sheet so that we can
>> understand if there are still remaining gaps in the solution, and
>>
>>   - document it (e.g. in the HA guide).  Even if this only ended up
>> being considered as a shorter-term solution, I think it's still
>> worth documenting so that it's another option available to
>> everyone.
>>
>> Thanks!
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Andy McCrae]

Thanks again Travis - it's been great to have your input and help on so
many of the decisions made within OSA over the last year and a bit. You'll
definitely be missed, and I wish you all the best for the future!

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

[openstack-dev] [neutron] br-int to use registers instead of ovsdb tags (was: Re: Enable arp_responder without l2pop)

[Thomas Morin]

Wed Feb 22 2017 11:13:18 GMT-0500 (EST), Anil Venkata:


While relevant, I think this is not possible until br-int allows to 
match the network a packet belongs to (the ovsdb port tags don't let 
you do that until the packet leaves br-int with a NORMAL action).


Ajo has told me yesterday that the OVS firewall driver uses
registers precisely to do that. Making this generic (and not
specific to the OVS firewall driver) would be a prerequisite
before you can add ARP responder rules in br-int.

[...] Spoke to Ajo on this. He said we can follow above suggestion i.e 
do the same what firewall driver is doing in br-int, or wait till OVS 
flow extension is implemented(but this will take time as lack of 
resources)


I think using registers instead of ovsdb port tags should be seen as a 
common pre-requisite for both ARP responder in br-int and doing the OVS 
flow extension work.
So waiting for resource on the later should not be seen as the problem.. 
although you still need some resource to use register in br-int...


-Thomas
__
OpenStack Development Mailing 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] - Neutron team social in Atlanta on Thursday

[Boden Russell]

+1

On 2/17/17 2:18 PM, Kevin Benton wrote:
> Hi all,
> 
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
> 
> Cheers,
> Kevin Benton
> 
> 
> __
> OpenStack Development Mailing 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] br-int to use registers instead of ovsdb tags (was: Re: Enable arp_responder without l2pop)

[Miguel Angel Ajo Pelayo]

On Wed, Feb 22, 2017 at 1:53 PM, Thomas Morin 
wrote:

> Wed Feb 22 2017 11:13:18 GMT-0500 (EST), Anil Venkata:
>
>
> While relevant, I think this is not possible until br-int allows to match
> the network a packet belongs to (the ovsdb port tags don't let you do that
> until the packet leaves br-int with a NORMAL action).
>
>> Ajo has told me yesterday that the OVS firewall driver uses registers
>> precisely to do that. Making this generic (and not specific to the OVS
>> firewall driver) would be a prerequisite before you can add ARP responder
>> rules in br-int.
>>
>>
> [...] Spoke to Ajo on this. He said we can follow above suggestion i.e do
> the same what firewall driver is doing  in br-int, or wait till OVS flow
> extension is implemented(but this will take time as lack of resources)
>
>
> I think using registers instead of ovsdb port tags should be seen as a
> common pre-requisite for both ARP responder in br-int and doing the OVS
> flow extension work.
> So waiting for resource on the later should not be seen as the problem..
> although you still need some resource to use register in br-int...
>
>
Those port/net tagging parts were designed as some of the fixed stages of
the openflow pipeline. If we wanted to pursue this I feel we may need to
wait for the pipeline to eventually be ready.

An alternative option would be moving the port/net tagging to a common
place for ovs firewall and hybrid firewall. But I'm not sure how complex
that could be.




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

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Major Hayden]

On 02/22/2017 11:48 AM, Truman, Travis wrote:
> I’ve very much enjoyed being part of the OpenStack community over the past 14 
> months. My time in the OpenStack-Ansible community has been one of the most 
> rewarding experiences of my career. However, my career is changing directions 
> and I’ll no longer be able to invest the time and energy required to maintain 
> my involvement in the community.

Thanks for all you've done for the project and for all you've done for the 
OpenStack-Ansible community members, too.  We wish you the best in your future 
endeavors! :)

--
Major Hayden

__
OpenStack Development Mailing 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] - Neutron team social in Atlanta on Thursday

[Daniel Mellado]

+1

El 22/02/17 a las 11:52, Ian Wells escribió:
> +1
> 
> On 21 February 2017 at 16:18, Ichihara Hirofumi
> mailto:ichihara.hirof...@gmail.com>> wrote:
> 
> +1
> 
> 2017-02-17 14:18 GMT-05:00 Kevin Benton  >:
> 
> Hi all,
> 
> I'm organizing a Neutron social event for Thursday evening in
> Atlanta somewhere near the venue for dinner/drinks. If you're
> interested, please reply to this email with a "+1" so I can get
> a general count for a reservation.
> 
> Cheers,
> Kevin Benton
> 
> 
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [qa] Tempest Stable plugin interface change broke gate

[Ghanshyam Mann]

> -Original Message-
> From: Hayes, Graham [mailto:graham.ha...@hpe.com]
> Sent: 23 February 2017 03:25
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [qa] Tempest Stable plugin interface change
> broke gate
> 
> On 21/02/2017 15:25, Andrea Frittoli wrote:
> > Hi Graham,
> >
> > sorry about that, and good catch.
> > You are right, that's a stable interface so that change should not
> > have landed.
> >
> > andrea
> >
> > On Tue, Feb 21, 2017 at 2:51 PM Hayes, Graham  > > wrote:
> >
> > Hi.
> >
> > https://review.openstack.org/#/c/434304/ landed yesterday, which was
> a
> > change to the stable interface for tempest plugins.
> >
> > It also took out the designate gate.
> >
> > Is this interface stable? - If so, there should have been at least some
> > deprecation cycle, notification, or something.
> >
> > Revert has been proposed -
> > https://review.openstack.org/#/c/436612/
> >
> > Can someone clarify what the "stable" in "Stable APIs" listed here [1]
> > means?
> >
> > - Graham
> >
> > 1 -
> >
> > https://docs.openstack.org/developer/tempest/plugin.html#stable-
> tempes
> > t-apis-plugins-may-use
> >
> >
> __
> 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> The revert above still hasn't merged.
> 
> The QA team blocked a change that updated HTTP status code, but removed
> a stable interface with no deprecation.
> 
> The revert needs to land, now, and then the QA team can debate
> deprecation / removal.

Sorry about that. We are ok with that patch to merge that and yes we should do 
that with deprecation warning etc.  

> 
> To stop this happening in the future, can we get tempest to gate on some
> tempest plugins?
> 
> Just a gate job that runs when any code in the designated stable sections of
> tempest change would be incredibly useful.

That might be difficult to run lot of plugins tests on job for tempest stable 
interface but yes I agree with idea and we should have some mechanism to block 
the removal of stable interface without deprecation etc.
Let's us think about more on this. 


> 
> Thanks,
> 
> Graham
> 
> __
> 
> OpenStack Development Mailing 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] Alternative approaches for L3 HA

[Armando M.]

On 13 February 2017 at 23:23, Kosnik, Lubosz 
wrote:

> So from my perspective I can tell that problem is completely in
> architecture and even without something outside of Neutron we cannot solve
> that.
> Two releases ago I started to work on hardening that feature but all my
> ideas was killed by Armando and Assaf. The decided that adding outside
> dependency will open the doors for a new bugs from dependencies into
> Neutron [1].
>

I am pretty sure it wasn't our intentions to 'kill' your ideas, but
otherwise set you on the right path for fixing the bug. I still believe
that a complete and robust L3 HA solution cannot be built solely with
Neutron alone, and that's what I was trying to say with the comment
referenced below.


>
> You need to know that there are two outstanding bugs in this feature.
> There is a internal and outside connectivity split brain. [2] this patch
> made by me is “fixing” part of the problem. It allows you specify
> additional tests to verify connectivity from router to GW.
> Also there is a problem with connectivity between network nodes. It’s more
> problematic and like you said it’s unsolvable in my opinion without using
> external mechanism.
>
> If there will be any need to help with anything I would love to help with
> sharing my knowledge about this feature and what exactly is not working. If
> anyone needs any help with anything about this please ping me on email or
> IRC.
>
> [1] https://bugs.launchpad.net/neutron/+bug/1375625/comments/31
> [2] https://review.openstack.org/#/c/273546/
>
> Lubosz
>
> On Feb 13, 2017, at 4:10 AM, Anna Taraday 
> wrote:
>
> To avoid dependency of data plane on control plane it is possible to
> deploy a separate key-value storage cluster on data plane side, using the
> same network nodes.
> I'm proposing to make some changes to enable experimentation in this
> field, we are yet to come up with any other concrete solution.
>
> On Mon, Feb 13, 2017 at 2:01 PM  wrote:
>
>> Hi,
>>
>>
>>
>>
>>
>> We also operate using Juno with the VRRP HA implementation and at had to
>> patch through several bugs before getting to the Mitaka release.
>>
>> An pluggable, drop-in alternative would be highly appreciated. However
>> our experience has been that the decoupling of VRRP from the control plane
>> is actually a benefit as when the control plane is down the traffic is not
>> affected.
>>
>> In a solution where the L3 HA implementation becomes tied to the
>> availability of the control plane (etcd cluster or any other KV store) then
>> an operator would have to account for extra failure scenarios for the KV
>> store which would affect multiple routers than the outage of a single L3
>> node which is the case we usually have to account now.
>>
>>
>>
>>
>>
>> Just my $.02
>>
>>
>>
>> Cristian
>>
>>
>>
>> *From:* Anna Taraday [mailto:akamyshnik...@mirantis.com]
>> *Sent:* Monday, February 13, 2017 11:45 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA
>>
>>
>>
>> In etcd for each HA router we can store key which will identify which
>> agent is active. L3 agents will "watch" this key.
>> All these tools have leader election mechanism which can be used to get
>> agent which is active for current HA router.
>>
>>
>>
>> On Mon, Feb 13, 2017 at 7:02 AM zhi  wrote:
>>
>> Hi, we are using L3 HA in our production environment now. Router
>> instances communicate to each other by VRRP protocol. In my opinion,
>> although VRRP is a control plane thing, but the real VRRP traffic is using
>> data plane nic so that router namespaces can not talk to each other
>> sometimes when the  data plan is busy. If we were used etcd (or other),
>> does every router instance register one "id" in etcd ?
>>
>>
>>
>>
>>
>> Thanks
>>
>> Zhi Chang
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>>
>> Regards,
>> Ann Taraday
>>
>> _
>>
>> 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 b

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

[Assaf Muller]

On Wed, Feb 22, 2017 at 1:40 PM, Miguel Angel Ajo Pelayo
 wrote:
> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let systemd take care to restart the services that die, and we worked
> with the community
> to make sure that agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
> available.

Thanks Miguel, I added a little bit of info the spreadsheet as well.

>
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers  wrote:
>>
>> Kosnik, Lubosz  wrote:
>> > About success of RDO we need to remember that this deployment utilizes
>> > Peacemaker and when I was working on this feature and even I spoke with
>> > Assaf this external application was doing everything to make this solution
>> > working.
>> > Peacemaker was responsible for checking external and internal
>> > connectivity. To detect split brain. Elect master, even keepalived was
>> > running but Peacemaker was automatically killing all services and moving
>> > FIP.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> > still doing everything outside of Neutron?
>> >
>> > Because if RDO success is build on Peacemaker it means that yes, Neutron
>> > needs some solution which will be available for more than RH deployments.
>>
>> Agreed.
>>
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>>
>> https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>>
>> (although I take responsibility for all mistakes ;-)
>>
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>>
>>   - help populate column E of the above sheet so that we can
>> understand if there are still remaining gaps in the solution, and
>>
>>   - document it (e.g. in the HA guide).  Even if this only ended up
>> being considered as a shorter-term solution, I think it's still
>> worth documenting so that it's another option available to
>> everyone.
>>
>> 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
>
>
>
> __
> OpenStack Development Mailing 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] [release] RDO Ocata packages released

[Javier Pena]

The RDO community is pleased to announce the general availability of the RDO 
build for OpenStack Ocata for RPM-based distributions, CentOS Linux 7 and Red 
Hat Enterprise Linux.
RDO is suitable for building private, public, and hybrid clouds. Ocata is the 
15th release from the OpenStack project (http://openstack.org), which is the 
work of more than 2500 contributors from around the world (source 
http://stackalytics.com/).

The RDO community project (https://www.rdoproject.org/) curates, packages, 
builds, tests and maintains a complete OpenStack component set for RHEL and 
CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG 
(https://wiki.centos.org/SpecialInterestGroup/Cloud). The Cloud Infrastructure 
SIG focuses on delivering a great user experience for CentOS Linux users 
looking to build and maintain their own on-premise, public or hybrid clouds.

All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 
100% open source, with all code changes going upstream first.

Interesting things in the Ocata release include:

- Significant Improvements 
(https://www.rdoproject.org/blog/2017/02/testing-rdo-with-tempest-new-features-in-ocata/)
 to Tempest and Tempest plugin packaging in RDO
- The OpenStack-Ansible 
(https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html#new-features)
 project now supports deployment on top of CentOS with the help of RDO-packaged 
dependencies

For cloud operators, RDO now provides packages for some new OpenStack Services:

- Tacker (https://docs.openstack.org/developer/tacker/): an ETSI MANO NFV 
Orchestrator and VNF Manager
- Congress 
(https://docs.openstack.org/developer/congress/architecture.html): an open 
policy framework for the cloud
- Vitrage (https://docs.openstack.org/developer/vitrage/): the OpenStack 
RCA (Root Cause Analysis) Service
- Kolla (https://github.com/openstack/kolla): The Kolla project provides 
tooling to build production-ready container images for deploying OpenStack 
clouds

Some other notable additions:

- novajoin (https://github.com/openstack/novajoin): a dynamic vendordata 
plugin for the OpenStack nova metadata service to manage automatic host 
instantiation in an IPA server
- ironic-ui (https://docs.openstack.org/developer/ironic-ui/): a new 
Horizon plugin to view and manage baremetal servers
- python-virtualbmc (https://github.com/openstack/virtualbmc) VirtualBMC is 
a proxy that translates IPMI commands to libvirt calls. This allows projects 
such as OpenStack Ironic to test IPMI drivers using VMs.
- python-muranoclient (https://github.com/openstack/python-muranoclient): a 
client for the Application Catalog service.
- python-monascaclient (https://github.com/openstack/python-monascaclient): 
a client for the Monasca monitoring-as-a-service solution.
- Shaker (http://pyshaker.readthedocs.io/en/latest/): the distributed 
data-plane testing tool built for OpenStack
- Multi-architecture support: aarch64 builds are now provided through an 
experimental repository - enable the RDO 'testing' repositories to get started

>From a networking perspective, we have added some new Neutron plugins that can 
>help Cloud users and operators to address new use cases and scenarios:

- networking-bagpipe 
(https://docs.openstack.org/developer/networking-bagpipe/): a mechanism driver 
for Neutron ML2 plugin using BGP E-VPNs/IP VPNs as a backend
- networking-bgpvpn 
(https://docs.openstack.org/developer/networking-bgpvpn/): an API and framework 
to interconnect BGP/MPLS VPNs to Openstack Neutron networks
- networking-fujitsu (https://github.com/openstack/networking-fujitsu): 
FUJITSU ML2 plugins/drivers for OpenStack Neutron
- networking-l2gw (https://github.com/openstack/networking-l2gw): APIs and 
implementations to support L2 Gateways in Neutron
- networking-sfc (https://github.com/openstack/networking-sfc): APIs and 
implementations to support Service Function Chaining in Neutron

>From the Packstack (https://github.com/openstack/packstack) side, we have 
>several improvements:

- We have added support to install Panko and Magnum
- Puppet 4 is now supported, and we have updated our manifests to cover the 
latest changes in the supported projects

**Getting Started**

There are three ways to get started with RDO.

- To spin up a proof of concept cloud, quickly, and on limited hardware, 
try the All-In-One Quickstart (http://rdoproject.org/Quickstart). You can run 
RDO on a single node to get a feel for how it works.
- For a production deployment of RDO, use the TripleO Quickstart 
(https://www.rdoproject.org/tripleo/) and you'll be running a production cloud 
in short order.
- Finally, if you want to try out OpenStack, but don't have the time or 
hardware to run it yourself, visit TryStack (http://trystack.org/), where you 
can use a free public OpenStack instance, running RDO packages, to experiment 
with the OpenS

[openstack-dev] [Openstack] OpenStack Ocata for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,

The Ubuntu OpenStack team at Canonical is pleased to announce the general
availability of OpenStack Ocata on Ubuntu 16.04 LTS via the Ubuntu Cloud
Archive. Ocata is the latest release of OpenStack and the first in the new
OpenStack release cadence, with a focus on stabilization of existing
features along with usability improvements. Details of the Ocata release
can be found at:  https://www.openstack.org/software/ocata

To get access to the Ubuntu Ocata packages:

Ubuntu 16.04 LTS



You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
Ubuntu 16.04 installations by running the following commands:

sudo add-apt-repository cloud-archive:ocata

sudo apt update

The Ubuntu Cloud Archive for Ocata includes updates for:

aodh, barbican, ceilometer, cinder, congress, designate,
designate-dashboard, dpdk (16.11), glance, gnocchi, heat, horizon, ironic,
libvirt (2.5.0), keystone, magnum, manila, manila-ui, mistral, murano,
murano-dashboard, networking-ovn, networking-sfc, neutron,
neutron-dynamic-routing, neutron-fwaas, neutron-lbaas,
neutron-lbaas-dashboard, nova, nova-lxd, openstack-trove, panko, qemu
(2.8), sahara, sahara-dashboard, senlin, swift, trove-dashboard, watcher
and zaqar

For a full list of packages and versions, please refer to [0].

Migration considerations



* API’s now running under apache2 with mod_wsgi

In Ocata we’ve updated the following APIs to run under apache2 with
mod_wsgi: aodh-api, barbican-api, ceilometer-api, cinder-api, and the
nova-placement-api. Please keep this in mind as the packages will no longer
install systemd unit files for these services, and will instead install
apache2 with corresponding apache2 site configuration.

* libvirt 2.5.0 changes

In this release of libvirt, the libvirt-bin systemd service has been
renamed to libvirtd, and the unix_sock_group has changed from libvirtd to
libvirt.

* openstack-dashboard changes

In Ocata we’ve moved static assets from
/usr/share/openstack-dashboard/static to
/var/lib/openstack-dashboard/static.

Known Issues

---

nova console log is empty with libvirt 2.5.0:
https://bugs.launchpad.net/bugs/1667033

Branch Package Builds

---

If you would like to try out the latest updates to branches, we deliver
continuously integrated packages on each upstream commit via the following
PPA’s:

  sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

  sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

  sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

  sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata

Reporting bugs

-

If you have any issues please report bugs using the 'ubuntu-bug' tool to
ensure that bugs get logged in the right place in Launchpad:

sudo ubuntu-bug nova-conductor

Thanks to everyone who has contributed to OpenStack Ocata, both upstream
and downstream.  And special thanks to the puppet modules team for their
continued early testing of OpenStack development releases.

Have fun and see you in Pike!

Regards,

Corey

(on behalf of the Ubuntu OpenStack team)

[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.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] [publiccloud-wg]Atlanta Virtual PTG agenda

[Zhipeng Huang]

A reminder for our virtual meetup tomorrow on irc,starting at 9:00 am ET

On Mon, Feb 20, 2017 at 9:22 PM, Zhipeng Huang 
wrote:

> Hi team,
>
> Please find an initial draft of our virtual ptg on Thursday at
> https://etherpad.openstack.org/p/publiccloud-atlanta-ptg , feel free to
> add anything that you want to discuss
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [acceleration]Reminder for Team Photo tomorrow at 2:00pm

[Zhipeng Huang]

Let's meet on the 3rd floor in the prefunction space in front of the Grand
Ballroom (across the hall from Fandangles) at *1:55pm* tmr for team
photo[1] :)

[1] https://docs.google.com/spreadsheets/d/1bgwMDsUm37JgpksUJszoDWcoBMHci
ufXcGV3OYe5A-4/edit?usp=sharing

-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [rdo-list] [release] RDO Ocata packages released

[Emilien Macchi]

On Wed, Feb 22, 2017 at 6:26 PM, Javier Pena  wrote:
>
> The RDO community is pleased to announce the general availability of the RDO 
> build for OpenStack Ocata for RPM-based distributions, CentOS Linux 7 and Red 
> Hat Enterprise Linux.

I think you are too fast!
Excellent work folks, this is really awesome.

> RDO is suitable for building private, public, and hybrid clouds. Ocata is the 
> 15th release from the OpenStack project (http://openstack.org), which is the 
> work of more than 2500 contributors from around the world (source 
> http://stackalytics.com/).
>
> The RDO community project (https://www.rdoproject.org/) curates, packages, 
> builds, tests and maintains a complete OpenStack component set for RHEL and 
> CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG 
> (https://wiki.centos.org/SpecialInterestGroup/Cloud). The Cloud 
> Infrastructure SIG focuses on delivering a great user experience for CentOS 
> Linux users looking to build and maintain their own on-premise, public or 
> hybrid clouds.
>
> All work on RDO, and on the downstream release, Red Hat OpenStack Platform, 
> is 100% open source, with all code changes going upstream first.
>
> Interesting things in the Ocata release include:
>
> - Significant Improvements 
> (https://www.rdoproject.org/blog/2017/02/testing-rdo-with-tempest-new-features-in-ocata/)
>  to Tempest and Tempest plugin packaging in RDO
> - The OpenStack-Ansible 
> (https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html#new-features)
>  project now supports deployment on top of CentOS with the help of 
> RDO-packaged dependencies
>
> For cloud operators, RDO now provides packages for some new OpenStack 
> Services:
>
> - Tacker (https://docs.openstack.org/developer/tacker/): an ETSI MANO NFV 
> Orchestrator and VNF Manager
> - Congress 
> (https://docs.openstack.org/developer/congress/architecture.html): an open 
> policy framework for the cloud
> - Vitrage (https://docs.openstack.org/developer/vitrage/): the OpenStack 
> RCA (Root Cause Analysis) Service
> - Kolla (https://github.com/openstack/kolla): The Kolla project provides 
> tooling to build production-ready container images for deploying OpenStack 
> clouds
>
> Some other notable additions:
>
> - novajoin (https://github.com/openstack/novajoin): a dynamic vendordata 
> plugin for the OpenStack nova metadata service to manage automatic host 
> instantiation in an IPA server
> - ironic-ui (https://docs.openstack.org/developer/ironic-ui/): a new 
> Horizon plugin to view and manage baremetal servers
> - python-virtualbmc (https://github.com/openstack/virtualbmc) VirtualBMC 
> is a proxy that translates IPMI commands to libvirt calls. This allows 
> projects such as OpenStack Ironic to test IPMI drivers using VMs.
> - python-muranoclient (https://github.com/openstack/python-muranoclient): 
> a client for the Application Catalog service.
> - python-monascaclient 
> (https://github.com/openstack/python-monascaclient): a client for the Monasca 
> monitoring-as-a-service solution.
> - Shaker (http://pyshaker.readthedocs.io/en/latest/): the distributed 
> data-plane testing tool built for OpenStack
> - Multi-architecture support: aarch64 builds are now provided through an 
> experimental repository - enable the RDO 'testing' repositories to get started
>
> >From a networking perspective, we have added some new Neutron plugins that 
> >can help Cloud users and operators to address new use cases and scenarios:
>
> - networking-bagpipe 
> (https://docs.openstack.org/developer/networking-bagpipe/): a mechanism 
> driver for Neutron ML2 plugin using BGP E-VPNs/IP VPNs as a backend
> - networking-bgpvpn 
> (https://docs.openstack.org/developer/networking-bgpvpn/): an API and 
> framework to interconnect BGP/MPLS VPNs to Openstack Neutron networks
> - networking-fujitsu (https://github.com/openstack/networking-fujitsu): 
> FUJITSU ML2 plugins/drivers for OpenStack Neutron
> - networking-l2gw (https://github.com/openstack/networking-l2gw): APIs 
> and implementations to support L2 Gateways in Neutron
> - networking-sfc (https://github.com/openstack/networking-sfc): APIs and 
> implementations to support Service Function Chaining in Neutron
>
> >From the Packstack (https://github.com/openstack/packstack) side, we have 
> >several improvements:
>
> - We have added support to install Panko and Magnum
> - Puppet 4 is now supported, and we have updated our manifests to cover 
> the latest changes in the supported projects
>
> **Getting Started**
>
> There are three ways to get started with RDO.
>
> - To spin up a proof of concept cloud, quickly, and on limited hardware, 
> try the All-In-One Quickstart (http://rdoproject.org/Quickstart). You can run 
> RDO on a single node to get a feel for how it works.
> - For a production deployment of RDO, use the TripleO Quickstart 
> (https://www.rdoproject.org/tripleo/) a

[openstack-dev] [third-party][ci] Transition your devstack-gate based CI to local.conf

[Mikhail Medvedev]

Hi third-party CI operators,

This is for those who use devstack-gate with localrc. You might have
started seeing failures since [1] landed. This is due to a few
devstack settings now being ignored. When devstack sees that you have
both localrc and [[local|localrc]] section in local.conf, it only uses
localrc file.

A solution is to move your localrc settings into [[local|localrc]]
section of local.conf. For a temporary fix you can also pin
devstack-gate to a version before [1], until your configuration is
migrated.

I hope this saves some of you some debugging time. I see at least one
CI that is currently affected (nova Virtuozzo Storage CI).

[1] 
https://review.openstack.org/#q,I111a6df3adc07ed426ac714cb9e64667a63e0e5a,n,z

Happy testing,

---
Mikhail Medvedev
IBM

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

[openstack-dev] [monasca] cassandra support in Monasca

[Pradeep Singh]

Hello,

Could you please suggest status of Cassandra support in Monasca.
Is there any plan to support  kairosdb?
If it is not implemented then we can take kairosdb support work.

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

[openstack-dev] openstack jenkins failure

[Guo, Ruijing]

Hi,

There are lots of openstack Jenkins failure. Anyone from 
infrastructure
 team look at the issue?

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