Re: [openstack-dev] [puppet] [ceph] puppet-ceph working session

[David Gurtner]

Hi Andrew

Sadly I'm not present at the summit - but I'm looking forward to the
outcome of the meeting.

Please let me know if there is anything specific I can contribute
towards getting rid of CI issues?

Cheers,
David


On Wed, Oct 28, 2015 at 4:52 AM, Andrew Woodward  wrote:
> Thanks,
> I've added it to the puppet-code session etherpad.
>
> https://etherpad.openstack.org/p/HND-puppet-code
>
>
> On Wed, Oct 28, 2015 at 12:00 PM Emilien Macchi 
> wrote:
>>
>>
>>
>> On 10/28/2015 11:09 AM, Andrew Woodward wrote:
>> > For those of you interested at the summit, I'd like to get together at
>> > some point and discuss / resolve issues on CI, and then talk about
>> > release and possible roadmap.
>> >
>> > Let's pick a time so that we can meet together on this.
>>
>> Good idea, I suggest we meet in the Puppet work sessions, so we get
>> attention from the team.
>>
>> Thanks,
>>
>> Emilien
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __
> OpenStack Development Mailing 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] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Yuriy Nesenenko]

Hi. Look at https://review.openstack.org/#/c/239837/

On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann 
wrote:

> That job is failing at a decent rate, tracking with bug:
>
> https://bugs.launchpad.net/cinder/+bug/1510656
>
> It lines up with the novaclient 2.33 release on 10/27, I'm checking out
> what the change was that caused the regression.
>
> This is a heads up that rechecks on this failure probably won't help.
>
> So far I haven't seen any related patches up to fix it although there were
> already 2 bugs reported when I got in this morning.
>
> --
>
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Matt Riedemann]

On 10/28/2015 9:06 AM, Yuriy Nesenenko wrote:

Hi. Look at https://review.openstack.org/#/c/239837/

On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann
> wrote:

That job is failing at a decent rate, tracking with bug:

https://bugs.launchpad.net/cinder/+bug/1510656

It lines up with the novaclient 2.33 release on 10/27, I'm checking
out what the change was that caused the regression.

This is a heads up that rechecks on this failure probably won't help.

So far I haven't seen any related patches up to fix it although
there were already 2 bugs reported when I got in this morning.

--

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




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



Heh, well that's 3 bugs then, I didn't see that one. jgriffith and I 
were talking in IRC about just handling both exceptions in cinder to fix 
this but we also agreed that this is a backward incompatible change on 
the novaclient side, which was also discussed in the original novaclient 
wishlist bug that prompted the breaking change.


Given the backward compat issues, we might not just be breaking cinder 
here, so I've proposed a revert of the novaclient change with 
justification in the commit message:


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

At least with the cinder change above we're OK for mitaka, and logstash 
isn't yet showing failures for cinder in stable/liberty, but given the 
requirements there it will be a failure in cinder python34 tests in 
stalbe/liberty also - so we can backport the cinder fix or block the 
2.33 novaclient version on stable/liberty global-requirements depending 
on what we do with the proposed novaclient revert.


--

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

[openstack-dev] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Matt Riedemann]

That job is failing at a decent rate, tracking with bug:

https://bugs.launchpad.net/cinder/+bug/1510656

It lines up with the novaclient 2.33 release on 10/27, I'm checking out 
what the change was that caused the regression.


This is a heads up that rechecks on this failure probably won't help.

So far I haven't seen any related patches up to fix it although there 
were already 2 bugs reported when I got in this morning.


--

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] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Matt Riedemann]

On 10/28/2015 9:22 AM, Matt Riedemann wrote:



On 10/28/2015 9:06 AM, Yuriy Nesenenko wrote:

Hi. Look at https://review.openstack.org/#/c/239837/

On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann
> wrote:

That job is failing at a decent rate, tracking with bug:

https://bugs.launchpad.net/cinder/+bug/1510656

It lines up with the novaclient 2.33 release on 10/27, I'm checking
out what the change was that caused the regression.

This is a heads up that rechecks on this failure probably won't help.

So far I haven't seen any related patches up to fix it although
there were already 2 bugs reported when I got in this morning.

--

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




__

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



Heh, well that's 3 bugs then, I didn't see that one. jgriffith and I
were talking in IRC about just handling both exceptions in cinder to fix
this but we also agreed that this is a backward incompatible change on
the novaclient side, which was also discussed in the original novaclient
wishlist bug that prompted the breaking change.

Given the backward compat issues, we might not just be breaking cinder
here, so I've proposed a revert of the novaclient change with
justification in the commit message:

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

At least with the cinder change above we're OK for mitaka, and logstash
isn't yet showing failures for cinder in stable/liberty, but given the
requirements there it will be a failure in cinder python34 tests in
stalbe/liberty also - so we can backport the cinder fix or block the
2.33 novaclient version on stable/liberty global-requirements depending
on what we do with the proposed novaclient revert.



I have an alternative to the revert here:

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

That makes novaclient.exceptions.RequestTimeout extend requests.Timeout 
so that older cinder continues to work.


I also have changes to block novaclient 2.33.0 in g-r on master and 
stable/liberty:


https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z

I personally think we need to block 2.33.0 since it breaks cinder, then 
release a new version of novaclient with either the revert or the 
alternative change to extend requests.Timeout.


If we block novaclient 2.33.0 then we can also revert the workaround in 
cinder (which would start breaking if we reverted the new exception type 
out of novaclient w/o blacklisting 2.33 first).


--

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] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Russell,

Please see my replies inline.

Thanks,
Cathy

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, October 28, 2015 4:21 PM
To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie
Subject: [neutron][networking-sfc] API clarification questions

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API in OVN.  
I have a prototype, but I had to make some pretty big assumptions, so I wanted 
to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on the same 
Neutron network?  That keeps things simple.  If its intended to allow a chain 
of ports on different networks, is it just required that you pick ports that 
all have addresses routable from one port to the next in the chain? 

Cathy> It can allow a chain of ports on different networks as along it belongs 
to the same tenant. Yes, it is required that you pick ports that all have 
addresses routable from one port to the next in the chain. 



An arbitrary set of ports can't always work, so there has to be some bounds 
around what set of ports are valid to be in a chain.

Second, where is it expected that the match is applied?  The API for creating a 
port chain doesn't associate the chain with a network, but just matching 
"globally" doesn't make any sense.  If all ports are expected to be on the same 
network, is the match applied for any traffic entering that network from any 
port?

Cathy> As long as the ports are routable, they do not need to associated with 
the same network. 

I'm in Tokyo this week, so if the group working on this would like to talk in 
person, that would be great too.

Cathy> Sure. I am going to the "Neutron: Extensibility mechanisms: Plugin and 
Agent" session. If you also plan to go, we can meet there. Or we can meet at 
tomorrow afternoon's "Neutron: NFV foundation elements" 
session (Crown room at 4:30pm). 

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

Re: [openstack-dev] [mistral] sort dir of executions, asc or desc?

[Anastasia Kuznetsova]

Hi Lingxian,

I am agree with you that from user's point of view it is more convenient to
show execution
in the descending order (latest created execution on the top), but all
other get_all methods
(for tasks, workflows, etc) return list of objects in the ascending order.

I prefer to have consistent behavior for all items, so if it is better to
have descending order,
than let's have it for all lists, not just for one.


On Wed, Oct 28, 2015 at 4:14 AM, Lingxian Kong  wrote:

> Hi, guys,
>
> I found this bug[1] this morning which was fixed just now, and I have
> to say, it is my intention that to make the query executions result in
> descending order when I implemented the query pagination blueprint,
> which is different with workflows list result behavior. Because in
> user's perspective, I think it's more convinient to show the lasted
> execution first, right? maybe the most commonly used scenario of
> 'execution-list' is, user creates some executions first, then he/she
> just wants to see what's the status of them, it‘s inconvenience for
> the users to scroll down the page to find their executions in
> ascending order, executions are more time sensitive than workflows.
>
> [1]: https://bugs.launchpad.net/mistral/+bug/1510417
>
> --
> Regards!
> ---
> Lingxian Kong
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Anastasia Kuznetsova
__
OpenStack Development Mailing 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][networking-sfc] API clarification questions

[Russell Bryant]

- Original Message -
> Hi Russell,
> 
> Please see my replies inline.
> 
> Thanks,
> Cathy
> 
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Wednesday, October 28, 2015 4:21 PM
> To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie
> Subject: [neutron][networking-sfc] API clarification questions
> 
> I read through the proposed SFC API here:
> 
> http://docs.openstack.org/developer/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API in
> OVN.  I have a prototype, but I had to make some pretty big assumptions, so
> I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on the
> same Neutron network?  That keeps things simple.  If its intended to allow a
> chain of ports on different networks, is it just required that you pick
> ports that all have addresses routable from one port to the next in the
> chain?
> 
> Cathy> It can allow a chain of ports on different networks as along it
> belongs to the same tenant. Yes, it is required that you pick ports that all
> have addresses routable from one port to the next in the chain.

Thanks.  I think it would be good to clarify this in the API doc, so it's clear 
what makes a valid set of ports in a chain.

> An arbitrary set of ports can't always work, so there has to be some bounds
> around what set of ports are valid to be in a chain.
> 
> Second, where is it expected that the match is applied?  The API for creating
> a port chain doesn't associate the chain with a network, but just matching
> "globally" doesn't make any sense.  If all ports are expected to be on the
> same network, is the match applied for any traffic entering that network
> from any port?
> 
> Cathy> As long as the ports are routable, they do not need to associated with
> the same network.

Let me rephrase the question ... where is the flow classifier applied?  What 
traffic exactly?  "All traffic on all networks accessible to the tenant who 
created the port chain" doesn't seem right to me, but the API doesn't seem to 
specify it.


-- 
Russell

__
OpenStack Development Mailing 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] [oslo.messaging] Why the needed version of kombu to support heartbeat is >=3.0.7

[me,apporc]

Thank you for pointing this out, dims. I didn't notice this process of
openstack. But i wonder how do you find the relationship between that bot's
commit and the global requirements commit.

And sileht, from this commit
https://github.com/openstack/requirements/commit/c7f69afd6af56e8f7956c6fa0bea8fd776151fe6,
there seems not a robust reason to require kombu >= 3.0.7.
It's because ubuntu Trusty's default kombu version is 3.0.7, and it works
with amqp 1.4.0, right?

On Wed, Oct 28, 2015 at 12:46 PM, Davanum Srinivas 
wrote:

> "Bot with No reason" <<< Not really accurate. The process in openstack is
> to update global requirements first and then bot proposes the update to
> different projects. So please look at
>
> https://github.com/openstack/requirements/commit/c7f69afd6af56e8f7956c6fa0bea8fd776151fe6
> for the commit which updated the global requirements
>
> Thanks,
> dims
>
> On Wed, Oct 28, 2015 at 1:07 PM, me,apporc 
> wrote:
>
>> Thanks again.
>>
>> This kombu >=3.0.7 requirement is added in commit
>> 5b9fb6980220dbfa18bac4c3231d57efb493ebf0, which is from a Bot with no
>> reason.
>>
>>  As i see, we are directly requiring amqp >=1.4.0 in requirement.txt from
>> commit 0c954cffa2f3710acafa79f01b958a8955823640 on.
>> So maybe there is no need to require kombu >= 3.0.7 ?
>>
>> Another reason I am asking about this, in the latest centos 7 epel repo,
>> the versions of these two packages are :
>> python-kombu : 2.5.16-1.el7
>> python-amqp : 1.4.5-1.el7
>>
>> I have not test whether there are problems about heartbeat with this
>> version pair though.
>>
>> On Tue, Oct 27, 2015 at 11:02 PM, Mehdi Abaakouk 
>> wrote:
>>
>>>
>>> [1] seems just socket timeout issue, and admins can adjust those kernel
 params themselves.

>>>
>>> Yes, but if you trick kernel settings, like putting very low tcp
>>> keepalive values, you don't need to have/enable heartbeat.
>>>
>>> [2] and [3] truly a problem about the heartbeat implementation, but it
 says
 the fix is a part of py-amqp 1.4.0, and the dependency with kombu was
 not
 specified.
 [4] is a bug of kombu's autoretry method which is said to be fixed in
 kombu
 3.0.0, it is not directly related to heartbeat.

>>>
>>> As far as I can remember, this is because oslo.messaging doesn't really
>>> require py-amqp but only kombu, so to ensure kombu depends of py-amqp 1.4.0
>>> we have to depends on kombu 3.0.7 (that have amqp>=1.4.0 in its
>>> requirements I guess).
>>>
>>>
>>> ---
>>> Mehdi Abaakouk
>>> mail: sil...@sileht.net
>>> irc: sileht
>>>
>>
>>
>>
>> --
>> Regards,
>> apporc
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing 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,
apporc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

[Dmitry Guryanov]

On 10/28/2015 03:55 PM, Eric Harney wrote:

On 10/28/2015 03:18 PM, Dmitry Guryanov wrote:

Hello!

Can we discuss this on the summit?

As I promised, I've written a blueprint for this change:

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


I assume we can talk about this at the Cinder contributors meetup on Friday.


Ok, I'll be there.




On 10/14/2015 03:57 AM, Dmitry Guryanov wrote:

Hello,

RemoteFS drivers combine 2 logical tasks. The first one is how to
mount a filesystem and select proper share for a new or existing
volume. The second one: how to deal with an image files in given
directory (mount point) (create, delete, create snapshot e.t.c.).

The first part is different for each volume driver. The second - the
same for all volume drivers, but it depends on selected volume format:
you can create qcow2 file on NFS or smbfs with the same code.

Since there are several volume formats (raw, qcow2, vhd and possibly
some others), I propose to move the code, which works with image to
separate classes, 'VolumeFormat' handlers.

This change have 3 advantages:

1. Duplicated code from remotefs driver will be removed.
2. All drivers will support all volume formats.
3. New volume formats could be added easily, including non-qcow2
snapshots.

Here is a draft version of a patch:
https://review.openstack.org/#/c/234359/

Although there are problems in it, most of the operations with volumes
work and there are only about 10 fails in tempest.


I'd like to discuss this approach before further work on the patch.


--
Dmitry Guryanov

__

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


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


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



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

[openstack-dev] [cinder][ironic] Cinder + Ironic meetup

[Ivan Kolodyazhny]

Hi team,

Let's discuss "Cinder w/o Nova" [1] or "Cinder and Ironic integration"
 this Friday, 11am at Cinder Contributors Meetup, Amethyst room. This topic
is important for our projects and users, so let's discuss it together to
find a best solution to implement it.

[1] https://etherpad.openstack.org/p/cinder-mitaka-summit-topics

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

Re: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

[Eric Harney]

On 10/28/2015 03:18 PM, Dmitry Guryanov wrote:
> Hello!
> 
> Can we discuss this on the summit?
> 
> As I promised, I've written a blueprint for this change:
> 
> https://review.openstack.org/#/c/237094/
> 

I assume we can talk about this at the Cinder contributors meetup on Friday.

> 
> On 10/14/2015 03:57 AM, Dmitry Guryanov wrote:
>> Hello,
>>
>> RemoteFS drivers combine 2 logical tasks. The first one is how to
>> mount a filesystem and select proper share for a new or existing
>> volume. The second one: how to deal with an image files in given
>> directory (mount point) (create, delete, create snapshot e.t.c.).
>>
>> The first part is different for each volume driver. The second - the
>> same for all volume drivers, but it depends on selected volume format:
>> you can create qcow2 file on NFS or smbfs with the same code.
>>
>> Since there are several volume formats (raw, qcow2, vhd and possibly
>> some others), I propose to move the code, which works with image to
>> separate classes, 'VolumeFormat' handlers.
>>
>> This change have 3 advantages:
>>
>> 1. Duplicated code from remotefs driver will be removed.
>> 2. All drivers will support all volume formats.
>> 3. New volume formats could be added easily, including non-qcow2
>> snapshots.
>>
>> Here is a draft version of a patch:
>> https://review.openstack.org/#/c/234359/
>>
>> Although there are problems in it, most of the operations with volumes
>> work and there are only about 10 fails in tempest.
>>
>>
>> I'd like to discuss this approach before further work on the patch.
>>
>>
>> -- 
>> Dmitry Guryanov
>>
>> __
>>
>> OpenStack Development Mailing 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] [neutron][networking-sfc] API clarification questions

[Russell Bryant]

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API
in OVN.  I have a prototype, but I had to make some pretty big
assumptions, so I wanted to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on
the same Neutron network?  That keeps things simple.  If its intended to
allow a chain of ports on different networks, is it just required that
you pick ports that all have addresses routable from one port to the
next in the chain?  An arbitrary set of ports can't always work, so
there has to be some bounds around what set of ports are valid to be in
a chain.

Second, where is it expected that the match is applied?  The API for
creating a port chain doesn't associate the chain with a network, but
just matching "globally" doesn't make any sense.  If all ports are
expected to be on the same network, is the match applied for any traffic
entering that network from any port?

I'm in Tokyo this week, so if the group working on this would like to
talk in person, that would be great too.

-- 
Russell Bryant

__
OpenStack Development Mailing 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][Manila] Nova API to attach/detach file volume/share

[Thomas Bechtold]

On Mon, 2015-10-26 at 22:13 -0700, Sage Weil wrote:
[snipped]
> If you're at the summit, I'll be talking a bit about this on
> Wednesday at 
> 4:40 (http://sched.co/4A03).

The link doesn't work for me. Can you resent or post the room?

TIA

Tom

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

[openstack-dev] [nova] [searchlight] Difference in nova notifications versus API

[McLellan, Steven]

Hi,

One of our questions this summit for Searchlight is whether we can reduce the 
time and effort required to index resources by getting as much information from 
notifications as possible.

Nova's API and notifications provide data in different formats; some 
information is missing and some is in different formats (1). In addition, 
notification information isn't versioned and can change at will. Currently 
we've taken the approach of treating the notification as a sign that something 
has happened and that we should get current state from the API.

We'd love to be able to process notifications directly, and have some assurance 
that the format won't change drastically without warning. Michael suggested i 
start a mailing thread, but we also have a session tomorrow set aside for these 
kinds of discussions with other projects (2). If anyone's available to join us 
that would be splendid.

Steve (apologies if this ends up getting sent twice)

(1) For instance, 'accessIPv4' vs 'access_ip_v4', 'name' vs 'displayname'; 
extension information and some networking info like security groups generally 
isn't in notifications; notifications return more image information than the API

(2) 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.VjBRWK4rJE4

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

[openstack-dev] [glance] [swift] [searchlight] Searchlight cross-project session

[McLellan, Steven]

Hi,

As you may know, Searchlight became an Openstack project after the Vancouver 
summit with the goal of providing a unified search API over many Openstack 
resources. A big goal for the Mitaka cycle is to add support for more resources 
(and improve existing support), and to that end we'd love to have some 
representatives from other projects attend a cross-project session tomorrow.

The session is scheduled at 4:30pm on Thursday, Oct 29th. Details are at 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.ViUm7RCrQxM
 and notes will be added to 
https://etherpad.openstack.org/p/searchlight-mitaka-summit-priorities-integrations.

We hope to see some of you there and apologies for the late notice.

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] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

[Dmitry Guryanov]

Hello!

Can we discuss this on the summit?

As I promised, I've written a blueprint for this change:

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


On 10/14/2015 03:57 AM, Dmitry Guryanov wrote:

Hello,

RemoteFS drivers combine 2 logical tasks. The first one is how to 
mount a filesystem and select proper share for a new or existing 
volume. The second one: how to deal with an image files in given 
directory (mount point) (create, delete, create snapshot e.t.c.).


The first part is different for each volume driver. The second - the 
same for all volume drivers, but it depends on selected volume format: 
you can create qcow2 file on NFS or smbfs with the same code.


Since there are several volume formats (raw, qcow2, vhd and possibly 
some others), I propose to move the code, which works with image to 
separate classes, 'VolumeFormat' handlers.


This change have 3 advantages:

1. Duplicated code from remotefs driver will be removed.
2. All drivers will support all volume formats.
3. New volume formats could be added easily, including non-qcow2 
snapshots.


Here is a draft version of a patch:
https://review.openstack.org/#/c/234359/

Although there are problems in it, most of the operations with volumes 
work and there are only about 10 fails in tempest.



I'd like to discuss this approach before further work on the patch.


--
Dmitry Guryanov

__ 


OpenStack Development Mailing 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] [oslo.messaging] Why the needed version of kombu to support heartbeat is >=3.0.7

[Davanum Srinivas]

apporc,

I do a git blame on global-requirements.txt to figure that out. I'll let
@sileht answer the other one :)

-- dims

On Wed, Oct 28, 2015 at 3:15 PM, me,apporc 
wrote:

> Thank you for pointing this out, dims. I didn't notice this process of
> openstack. But i wonder how do you find the relationship between that bot's
> commit and the global requirements commit.
>
> And sileht, from this commit
> https://github.com/openstack/requirements/commit/c7f69afd6af56e8f7956c6fa0bea8fd776151fe6,
> there seems not a robust reason to require kombu >= 3.0.7.
> It's because ubuntu Trusty's default kombu version is 3.0.7, and it works
> with amqp 1.4.0, right?
>
> On Wed, Oct 28, 2015 at 12:46 PM, Davanum Srinivas 
> wrote:
>
>> "Bot with No reason" <<< Not really accurate. The process in openstack is
>> to update global requirements first and then bot proposes the update to
>> different projects. So please look at
>>
>> https://github.com/openstack/requirements/commit/c7f69afd6af56e8f7956c6fa0bea8fd776151fe6
>> for the commit which updated the global requirements
>>
>> Thanks,
>> dims
>>
>> On Wed, Oct 28, 2015 at 1:07 PM, me,apporc 
>> wrote:
>>
>>> Thanks again.
>>>
>>> This kombu >=3.0.7 requirement is added in commit
>>> 5b9fb6980220dbfa18bac4c3231d57efb493ebf0, which is from a Bot with no
>>> reason.
>>>
>>>  As i see, we are directly requiring amqp >=1.4.0 in requirement.txt
>>> from commit 0c954cffa2f3710acafa79f01b958a8955823640 on.
>>> So maybe there is no need to require kombu >= 3.0.7 ?
>>>
>>> Another reason I am asking about this, in the latest centos 7 epel repo,
>>> the versions of these two packages are :
>>> python-kombu : 2.5.16-1.el7
>>> python-amqp : 1.4.5-1.el7
>>>
>>> I have not test whether there are problems about heartbeat with this
>>> version pair though.
>>>
>>> On Tue, Oct 27, 2015 at 11:02 PM, Mehdi Abaakouk 
>>> wrote:
>>>

 [1] seems just socket timeout issue, and admins can adjust those kernel
> params themselves.
>

 Yes, but if you trick kernel settings, like putting very low tcp
 keepalive values, you don't need to have/enable heartbeat.

 [2] and [3] truly a problem about the heartbeat implementation, but it
> says
> the fix is a part of py-amqp 1.4.0, and the dependency with kombu was
> not
> specified.
> [4] is a bug of kombu's autoretry method which is said to be fixed in
> kombu
> 3.0.0, it is not directly related to heartbeat.
>

 As far as I can remember, this is because oslo.messaging doesn't really
 require py-amqp but only kombu, so to ensure kombu depends of py-amqp 1.4.0
 we have to depends on kombu 3.0.7 (that have amqp>=1.4.0 in its
 requirements I guess).


 ---
 Mehdi Abaakouk
 mail: sil...@sileht.net
 irc: sileht

>>>
>>>
>>>
>>> --
>>> Regards,
>>> apporc
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing 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,
> apporc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing 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] Is there any incubating Data Backup projects?

[Yitao Jiang]

Hi, gurus

I wanna to know if there any data backup incubating projects in OpenStack .
I googled and found freezer, and will we make it as one of the community
supported project?


​[1]: https://github.com/openstack/freezer​

-- 

Regards,

Yitao
jiangyt.github.io
__
OpenStack Development Mailing 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][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  wrote:

> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
>
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
>
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
>

Hi Russell,

We have similarly been experimenting with a MidoNet implementation of the
SFC API.

I hope there's no restriction on the location of the Neutron ports in a
chain.

In terms of addresses, I believe the API is lacking (or we use a
chain_parameter?) a way to indicate the service insertion model:
- L2 - The service can accept packets sent from any MAC (service NIC in
promiscuous mode). The MAC address may be used to identify where the packet
came from before it entered the chain.
- L3 -  The service expects packets to be routed to it. So the destination
MAC of the packet must be set to the service's NIC's MAC.

Any thoughts on this?


>
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "globally" doesn't make any sense.  If all ports are
> expected to be on the same network, is the match applied for any traffic
> entering that network from any port?
>

Here's what we were thinking for MidoNet:

use the logical_source_port in the flow classifier: when we render the SFC
API in MidoNet's models we will associate the chain with the source port.

Our packet pipeline (for packets egressing the VM) is:

   1. Port Mirroring
   2. Service Chaining
   3. Filtering (Port Security, anti-spoofing, Security Groups)


Do you think we can standardise on a single order in all implementations?
We'd be happy to change the order if it makes sense.



>
> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
>

I'd love to be included.

Great topic, thanks!

Pino


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

[openstack-dev] [Nova] Migration type refactor proposal.

[Tang Chen]

Hi all,

Please take a look at this BP.

https://blueprints.launchpad.net/nova/+spec/migration-type-refactor

I'm now working on migration state machine, and I think migration type 
also has some problems we need to fix.


This can be part of the whole migration refactoring work.

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] [searchlight] Difference in nova notifications versus API

[Balázs Gibizer]

Hi,

There is a spec up [3] in nova to version notifications and also there will be 
a half session [4] tomorrow aftrenoon on the nova track to discuss it.

Cheers,
Gibi

[3] https://review.openstack.org/#/c/224755/
[4] 
https://mitakadesignsummit.sched.org/mobile/#session:2bbda0e5e052e5249fa1a118e906df46



Sent from my iPad
> On 2015. okt. 28., at 15:10, McLellan, Steven  wrote:
> 
> Hi,
> 
> One of our questions this summit for Searchlight is whether we can reduce the 
> time and effort required to index resources by getting as much information 
> from notifications as possible.
> 
> Nova's API and notifications provide data in different formats; some 
> information is missing and some is in different formats (1). In addition, 
> notification information isn't versioned and can change at will. Currently 
> we've taken the approach of treating the notification as a sign that 
> something has happened and that we should get current state from the API.
> 
> We'd love to be able to process notifications directly, and have some 
> assurance that the format won't change drastically without warning. Michael 
> suggested i start a mailing thread, but we also have a session tomorrow set 
> aside for these kinds of discussions with other projects (2). If anyone's 
> available to join us that would be splendid.
> 
> Steve (apologies if this ends up getting sent twice)
> 
> (1) For instance, 'accessIPv4' vs 'access_ip_v4', 'name' vs 'displayname'; 
> extension information and some networking info like security groups generally 
> isn't in notifications; notifications return more image information than the 
> API
> 
> (2) 
> http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.VjBRWK4rJE4
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [kuryr] meetup

[Antoni Segura Puimedon]

Hi fellow Kuryrs,

I want to remind you that we'll be meeting up at some corner of [1] to
discuss all things kuryr. The agenda will be:

- Current challenges with multinode
- The path to Mitaka:
  + Functional testing
  + COE Integrations
  + VM nested containers.


[1] http://sched.co/4Qan

Regards,

Toni
__
OpenStack Development Mailing 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][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Oleg Gelbukh]

Vladimir,

Sorry for delayed response. Let's continue inline.

On Thu, Oct 22, 2015 at 2:16 PM, Vladimir Kuklin 
wrote:

>
>
>>
>>  Each task can use some code to transform this output to the
>> representation that is actually needed for this particular task. Whenever a
>> task transforms this data it can access API and do version negotiation, for
>> example. Each time this transformation is performed this task can return
>> the data to some storage that will save this data for sake of control and
>> troubleshooting, such as, for example, user can always see which changes
>> are going to be applied and decide what to do next.
>>
>> Also, this means that the process of data calculation itself is very
>> 'lazy' or 'delayed', i. e. the data itself is calculated right at the
>> beginning of deployment transaction, so that it is not locked to some
>> particular details of deployment engine data processing and not prone to
>> issues like 'oh, I cannot get VIP because it has not been allocated yet by
>> Nailgun/oh, I cannot set it because it has already been set by Nailgun and
>> there is no way to alter it'.
>>
>
> >> To me, the two paragraphs above a contradictory. If the data
> calculations are lazy, I don't really see how one can introspect into
> changes that will be applied by a component at any given run. You just >>
> don't have this information, and you need to calculate it anyways to see
> which settings will be passed to a component. Might be I got your point
> wrong here. Please correct me if this is the case.
>
> Oleg, I actually meant that we do it in the following stages:
>
> 1) Change stuff in any amount of business logic engines you want,
> configuration databases, wikipedia, 4chan, etc.
>

Every business logic provider is a 'component' with it's own 'view' in the
proposed notation. Component has full control over 'authoritative' settings
in its view. In case of components that serve as sources of configuration,
it is likely that most all of settings in their views will be
'authoritative'.


> 2) Schedule a transaction of deployment
> 3) Make 'transformers/serializers' for each of the task collect all the
> data and store them before execution is started
>

The idea of configuration provisioning system is to strictly define all
sources of changes to settings and automate recalculation. Recalculation
should happen every time any setting is changed, and must 'touch' all
connected components. Otherwise we'll stuck with situations similar to
described in this bug [1].

[1] https://bugs.launchpad.net/fuel/+bug/1450100

4) Allow user to compare differences and decide whether he actually wants
> to apply this change
> 5) Commit the deployment - run particular tasks with particular set of
> settings which are staged and frozen (otherwise it will be impossible to
>  debug this stuff)
>

Versioning and persistent storage of views should be useful to solve this.


> 6) If there is lack of data for some task, e.g. you need some entitties to
> be created during the deployment so that other task will use their output
> or side-effects to calculate things - this task should not be executed
> within this transaction. This means that the whole deployment should be
> splitted into 2 transactions. I can mention an old story here - when we
> were running puppet we needed to create some stuff for neutron knowing ID
> of the network that had been created by another resource 5 seconds earlier.
> But we could not do this because puppet 'freezes' the input provided with
> "facts" before this transaction runs. This is exactly the same usecase.
>

Ideally, every task should be a separate component with its own view, and
should update their authoritative values upon execution.


>
> So these 6 items actually mean:
>
> 1) Clear separation between layers of the system and their functional
> boundaries
> 2) Minimum of cross-dependencies between component data - e.g. deployment
> tasks should not ever produce anything that is then stored in the storage.
>

This contradicts requirement to control and track the state and inputs of
components, isn't it? If deployment task does produce some parameters that
are used by another component, it should be stored and versioned just as
any other change to the state of configuration.


> Instead, you should have an API that provides you with data which is the
> result of deployment run. E.g. if you need to create a user in LDAP and you
> need this user's ID for some reason, your deployment task should create
> this user and, instead of returning this output to the storage, you just
> run another transaction and the task that requires this ID fetches it from
> LDAP.
>

It seems to me that here you're mixing responsibilities of orchestrator and
settings store. Orchestrator tells a component when to start, and it could
ask poll the settings store to determine if certain task has to be started.
Alternatively, the component itself might be notified by settings store
about 

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Russell Bryant]

On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  > wrote:
> 
> I read through the proposed SFC API here:
> 
> http://docs.openstack.org/developer/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
> 
> 
> Hi Russell,
> 
> We have similarly been experimenting with a MidoNet implementation of
> the SFC API.

Great!  It's nice to have multiple people looking at this with different
implementations in mind.  That should help us shake out these sorts of
issues before the API is too locked down.  Thanks for jumping in.  :-)

> I hope there's no restriction on the location of the Neutron ports in a
> chain. 

Yes, that makes sense.  Cathy's response seems to support that there
isn't a limitation.  We do need to clearly define it in the API
reference though.  Maybe something like ...

  All ports must:
  * be owned by the tenant.
  * have IP addresses such that the address of port N+1 in the chain
is routable from port N in the chain.

> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the
> packet came from before it entered the chain.

If the ports in the chain don't have to all be on the same L2 network,
then it doesn't seem like you could use the source MAC address to know
where the packet came from before it entered the chain.

> - L3 -  The service expects packets to be routed to it. So the
> destination MAC of the packet must be set to the service's NIC's MAC.

This seems to make more sense to me.  You've got the "coorelation chain
parameter" to know what chain the packet is in, and you use the source
IP address to know where the packet came from originally before it
entered the chain.

>  
> 
> 
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "globally" doesn't make any sense.  If all ports are
> expected to be on the same network, is the match applied for any traffic
> entering that network from any port?
> 
> 
> Here's what we were thinking for MidoNet:
> 
> use the logical_source_port in the flow classifier: when we render the
> SFC API in MidoNet's models we will associate the chain with the source
> port.
> 
> Our packet pipeline (for packets egressing the VM) is:
> 
>  1. Port Mirroring
>  2. Service Chaining
>  3. Filtering (Port Security, anti-spoofing, Security Groups)

OK, so it sounds like you're applying the "flow classifier" to packets
as the come from a neutron port and enter a neutron network.  That makes
sense.

Which ports' traffic do you apply the flow classifier to?  That's the
key piece I'm missing.

If the flow classifier includes a logical-source-port match, then it's
easy.  You only check traffic from a specific Neutron port.  The same
seems to apply if you only specified a logical-destination port, since
in that case you'd be matching on traffic ingressing the VM.

If tenant A creates the port chain and both logical-source-port and
logical-destination-port are not specified, then what packets do you
apply the flow classifier to?

> 
> 
> Do you think we can standardise on a single order in all
> implementations? We'd be happy to change the order if it makes sense. 

I think we do need to standardize where we can, yes.  We want the
resulting network behavior from the end user perspective to be as close
as possible to the same thing regardless of backend.

> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
> 
> 
> I'd love to be included.

OK, it's probably best that we try to keep it on the mailing list as
much as possible.  I really don't want to exclude anyone, and it's
important that this stuff is written down anyway.

There is an "NFV foundation elements" design summit session where I
think networking-sfc is going to be discussed, but unfortunately I have
a regular conference talk at the same time.

> Great topic, thanks!

Thanks for jumping in!

-- 
Russell Bryant

Re: [openstack-dev] [nova] [searchlight] Difference in nova notifications versus API

[McLellan, Steven]

Excellent! I'll try to be there. Thanks for the response!

 Original message 
From: Balázs Gibizer
Date:10/28/2015 18:54 (GMT+09:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [nova] [searchlight] Difference in nova 
notifications versus API

Hi,

There is a spec up [3] in nova to version notifications and also there will be 
a half session [4] tomorrow aftrenoon on the nova track to discuss it.

Cheers,
Gibi

[3] https://review.openstack.org/#/c/224755/
[4] 
https://mitakadesignsummit.sched.org/mobile/#session:2bbda0e5e052e5249fa1a118e906df46



Sent from my iPad
On 2015. okt. 28., at 15:10, McLellan, Steven 
> wrote:

Hi,

One of our questions this summit for Searchlight is whether we can reduce the 
time and effort required to index resources by getting as much information from 
notifications as possible.

Nova's API and notifications provide data in different formats; some 
information is missing and some is in different formats (1). In addition, 
notification information isn't versioned and can change at will. Currently 
we've taken the approach of treating the notification as a sign that something 
has happened and that we should get current state from the API.

We'd love to be able to process notifications directly, and have some assurance 
that the format won't change drastically without warning. Michael suggested i 
start a mailing thread, but we also have a session tomorrow set aside for these 
kinds of discussions with other projects (2). If anyone's available to join us 
that would be splendid.

Steve (apologies if this ends up getting sent twice)

(1) For instance, 'accessIPv4' vs 'access_ip_v4', 'name' vs 'displayname'; 
extension information and some networking info like security groups generally 
isn't in notifications; notifications return more image information than the API

(2) 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.VjBRWK4rJE4

__
OpenStack Development Mailing 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] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Ivan Kolodyazhny]

Matt,

Thank you for bring this topic to the ML.

In cinder, we've merged [1] patch to unblock gates. I've proposed other
patch [2] to fix global-requirements for the stable/liberty branch.


[1] https://review.openstack.org/#/c/239837/
[2] https://review.openstack.org/#/c/239799/

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

On Thu, Oct 29, 2015 at 12:13 AM, Matt Riedemann  wrote:

>
>
> On 10/28/2015 9:22 AM, Matt Riedemann wrote:
>
>>
>>
>> On 10/28/2015 9:06 AM, Yuriy Nesenenko wrote:
>>
>>> Hi. Look at https://review.openstack.org/#/c/239837/
>>>
>>> On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann
>>> > wrote:
>>>
>>> That job is failing at a decent rate, tracking with bug:
>>>
>>> https://bugs.launchpad.net/cinder/+bug/1510656
>>>
>>> It lines up with the novaclient 2.33 release on 10/27, I'm checking
>>> out what the change was that caused the regression.
>>>
>>> This is a heads up that rechecks on this failure probably won't help.
>>>
>>> So far I haven't seen any related patches up to fix it although
>>> there were already 2 bugs reported when I got in this morning.
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Heh, well that's 3 bugs then, I didn't see that one. jgriffith and I
>> were talking in IRC about just handling both exceptions in cinder to fix
>> this but we also agreed that this is a backward incompatible change on
>> the novaclient side, which was also discussed in the original novaclient
>> wishlist bug that prompted the breaking change.
>>
>> Given the backward compat issues, we might not just be breaking cinder
>> here, so I've proposed a revert of the novaclient change with
>> justification in the commit message:
>>
>> https://review.openstack.org/#/c/239941/
>>
>> At least with the cinder change above we're OK for mitaka, and logstash
>> isn't yet showing failures for cinder in stable/liberty, but given the
>> requirements there it will be a failure in cinder python34 tests in
>> stalbe/liberty also - so we can backport the cinder fix or block the
>> 2.33 novaclient version on stable/liberty global-requirements depending
>> on what we do with the proposed novaclient revert.
>>
>>
> I have an alternative to the revert here:
>
> https://review.openstack.org/#/c/239963/
>
> That makes novaclient.exceptions.RequestTimeout extend requests.Timeout so
> that older cinder continues to work.
>
> I also have changes to block novaclient 2.33.0 in g-r on master and
> stable/liberty:
>
>
> https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z
>
> I personally think we need to block 2.33.0 since it breaks cinder, then
> release a new version of novaclient with either the revert or the
> alternative change to extend requests.Timeout.
>
> If we block novaclient 2.33.0 then we can also revert the workaround in
> cinder (which would start breaking if we reverted the new exception type
> out of novaclient w/o blacklisting 2.33 first).
>
>
> --
>
> 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
>
__
OpenStack Development Mailing 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] [searchlight] Difference in nova notifications versus API

[Tripp, Travis S]

Thank, Gibi!

A key aspect for notifications for Searchlight would be able to have the 
notification produce the same data that you’d get from the API.  So, with micro 
versions, it would probably need to be configurable for the notifications 
emitted on perhaps a certain topic to be able to be emitted according to a 
specified API version.

Like most summits, there is a timing conflict for me, but at least a couple of 
us Searchlighters should be able to make that time.

Thanks,
Travis

From: Balázs Gibizer 
>
Reply-To: OpenStack List 
>
Date: Wednesday, October 28, 2015 at 6:50 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [nova] [searchlight] Difference in nova 
notifications versus API

Hi,

There is a spec up [3] in nova to version notifications and also there will be 
a half session [4] tomorrow aftrenoon on the nova track to discuss it.

Cheers,
Gibi

[3] https://review.openstack.org/#/c/224755/
[4] 
https://mitakadesignsummit.sched.org/mobile/#session:2bbda0e5e052e5249fa1a118e906df46



Sent from my iPad
On 2015. okt. 28., at 15:10, McLellan, Steven 
> wrote:

Hi,

One of our questions this summit for Searchlight is whether we can reduce the 
time and effort required to index resources by getting as much information from 
notifications as possible.

Nova's API and notifications provide data in different formats; some 
information is missing and some is in different formats (1). In addition, 
notification information isn't versioned and can change at will. Currently 
we've taken the approach of treating the notification as a sign that something 
has happened and that we should get current state from the API.

We'd love to be able to process notifications directly, and have some assurance 
that the format won't change drastically without warning. Michael suggested i 
start a mailing thread, but we also have a session tomorrow set aside for these 
kinds of discussions with other projects (2). If anyone's available to join us 
that would be splendid.

Steve (apologies if this ends up getting sent twice)

(1) For instance, 'accessIPv4' vs 'access_ip_v4', 'name' vs 'displayname'; 
extension information and some networking info like security groups generally 
isn't in notifications; notifications return more image information than the API

(2) 
http://mitakadesignsummit.sched.org/event/1d1ef3b50d8d8607834697f0ef6d70d9#.VjBRWK4rJE4

__
OpenStack Development Mailing 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] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Matt Riedemann]

On 10/28/2015 12:28 PM, Matt Riedemann wrote:



On 10/28/2015 10:41 AM, Ivan Kolodyazhny wrote:

Matt,

Thank you for bring this topic to the ML.

In cinder, we've merged [1] patch to unblock gates. I've proposed other
patch [2] to fix global-requirements for the stable/liberty branch.


[1] https://review.openstack.org/#/c/239837/
[2] https://review.openstack.org/#/c/239799/

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

On Thu, Oct 29, 2015 at 12:13 AM, Matt Riedemann
> wrote:



On 10/28/2015 9:22 AM, Matt Riedemann wrote:



On 10/28/2015 9:06 AM, Yuriy Nesenenko wrote:

Hi. Look at https://review.openstack.org/#/c/239837/

On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann

>> wrote:

 That job is failing at a decent rate, tracking with bug:

https://bugs.launchpad.net/cinder/+bug/1510656

 It lines up with the novaclient 2.33 release on 10/27,
I'm checking
 out what the change was that caused the regression.

 This is a heads up that rechecks on this failure
probably won't help.

 So far I haven't seen any related patches up to fix it
although
 there were already 2 bugs reported when I got in this
morning.

 --

 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





__


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

openstack-dev-requ...@lists.openstack.org?subject:unsubscribe


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


Heh, well that's 3 bugs then, I didn't see that one. jgriffith
and I
were talking in IRC about just handling both exceptions in
cinder to fix
this but we also agreed that this is a backward incompatible
change on
the novaclient side, which was also discussed in the original
novaclient
wishlist bug that prompted the breaking change.

Given the backward compat issues, we might not just be breaking
cinder
here, so I've proposed a revert of the novaclient change with
justification in the commit message:

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

At least with the cinder change above we're OK for mitaka, and
logstash
isn't yet showing failures for cinder in stable/liberty, but
given the
requirements there it will be a failure in cinder python34
tests in
stalbe/liberty also - so we can backport the cinder fix or
block the
2.33 novaclient version on stable/liberty global-requirements
depending
on what we do with the proposed novaclient revert.


I have an alternative to the revert here:

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

That makes novaclient.exceptions.RequestTimeout extend
requests.Timeout so that older cinder continues to work.

I also have changes to block novaclient 2.33.0 in g-r on master and
stable/liberty:


https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z


I personally think we need to block 2.33.0 since it breaks cinder,
then release a new version of novaclient with either the revert or
the alternative change to extend requests.Timeout.

If we block novaclient 2.33.0 then we can also revert the workaround
in cinder (which would start breaking if we reverted the new
exception type out of novaclient w/o blacklisting 2.33 first).


--

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




__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [Nova] Migration state machine proposal.

[Andrew Laski]

On 10/27/15 at 09:02am, Jay Pipes wrote:

On 10/22/2015 11:13 AM, Tang Chen wrote:

On 10/22/2015 05:17 AM, Joshua Harlow wrote:

Overall I'm very much inclined to have three state machines (one
for each type), vs the mix-mash of all three into one state machine
(which causes the confusion around states in the first diagram in
that paste).


That is an idea. But I would prefer to have one single state machine
for migration, because resize and evacuate are reusing migration.
They can be in one state machine.


Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs 
from their original source image.


I support Nikola in that I believe the different migration types 
should have different state machines entirely (but be as consistent 
as possible in the naming of terminal states like "finished" vs 
"done" etc)


+1.

It seems that there's also some work to do to disambiguate what the 
different operations are and what they actually do.


Migrate/resize share a code path, and then there's a big switch to 
change behavior if the migration is a live-migrate.  I agree with the 
comment below that we should deprecate the resize terminology and 
consolidate cold-migrate and resize under one umbrella with one state 
machine.  Then live-migrate could have a separate state machine.


Rebuild/evacuate share a code path though evacuate involves a scheduler 
decision which is why it seems like a move.  It's actually a bit tricky 
to classify because if the instance is volume backed it is essentially 
just a move operation, if it's image backed it's a destructive rebuild.  
But I think it makes sense to not consider this a move operation and 
think of it as an administrative rebuild when a host is down.





It would be very helpful if the designer of the migration process
could share his idea. But if it is just some code modified by many
people many times, I think we should remove the confusing states and
give a easier, better state machine.


There isn't a designer of the migration process :( The original 
(crap, IMHO) API from Rackspace Cloud Servers API was used for the 
resize functionality in the compute API and it's been a source of 
confusion and frustration ever since. Relying on a manual 
confirmation or revert input from the user was and continues to be a 
horrible idea.


Agreed.  In my experience with operating a public cloud I am not aware 
of anyone benefiting from the manual checkpoint in the middle of resize.  
But we should solicit feedback from the operator community on this.




I believe strongly that we should deprecate the existing migrate, 
resize, an live-migrate APIs in favor of a single consolidated, 
consistent "move" REST API that would have the following 
characteristics:


I'm not sure that we should abstract away live vs cold migrate behind a 
single move API, but I strongly agree with consolidate cold-migrate and 
resize.




* No manual or wait-input states in any FSM graph
* Removal of the term "resize" from the API entirely (the target 
resource sizing is an attribute of the move operation, not a 
different type of API operation in and of itself)
* Transition to a task-based API for poll-state requests. This means 
that in order for a caller to determine the state of a VM the caller 
would call something like GET /servers//tasks/ in order 
to see the history of state changes or subtask operations for a 
particular request to move a VM


Huge +1 from me.



Timofei Durakov (cc'd) has a blueprint for splitting the 
live-migration types into separate task classes here:


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

I think there's a lot of good ideas in that proposal. Please do have 
a look at it.


Best,
-jay

__
OpenStack Development Mailing 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] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release

[Matt Riedemann]

On 10/28/2015 10:41 AM, Ivan Kolodyazhny wrote:

Matt,

Thank you for bring this topic to the ML.

In cinder, we've merged [1] patch to unblock gates. I've proposed other
patch [2] to fix global-requirements for the stable/liberty branch.


[1] https://review.openstack.org/#/c/239837/
[2] https://review.openstack.org/#/c/239799/

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

On Thu, Oct 29, 2015 at 12:13 AM, Matt Riedemann
> wrote:



On 10/28/2015 9:22 AM, Matt Riedemann wrote:



On 10/28/2015 9:06 AM, Yuriy Nesenenko wrote:

Hi. Look at https://review.openstack.org/#/c/239837/

On Wed, Oct 28, 2015 at 3:52 PM, Matt Riedemann

>> wrote:

 That job is failing at a decent rate, tracking with bug:

https://bugs.launchpad.net/cinder/+bug/1510656

 It lines up with the novaclient 2.33 release on 10/27,
I'm checking
 out what the change was that caused the regression.

 This is a heads up that rechecks on this failure
probably won't help.

 So far I haven't seen any related patches up to fix it
although
 there were already 2 bugs reported when I got in this
morning.

 --

 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





__

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

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


Heh, well that's 3 bugs then, I didn't see that one. jgriffith and I
were talking in IRC about just handling both exceptions in
cinder to fix
this but we also agreed that this is a backward incompatible
change on
the novaclient side, which was also discussed in the original
novaclient
wishlist bug that prompted the breaking change.

Given the backward compat issues, we might not just be breaking
cinder
here, so I've proposed a revert of the novaclient change with
justification in the commit message:

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

At least with the cinder change above we're OK for mitaka, and
logstash
isn't yet showing failures for cinder in stable/liberty, but
given the
requirements there it will be a failure in cinder python34 tests in
stalbe/liberty also - so we can backport the cinder fix or block the
2.33 novaclient version on stable/liberty global-requirements
depending
on what we do with the proposed novaclient revert.


I have an alternative to the revert here:

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

That makes novaclient.exceptions.RequestTimeout extend
requests.Timeout so that older cinder continues to work.

I also have changes to block novaclient 2.33.0 in g-r on master and
stable/liberty:


https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z

I personally think we need to block 2.33.0 since it breaks cinder,
then release a new version of novaclient with either the revert or
the alternative change to extend requests.Timeout.

If we block novaclient 2.33.0 then we can also revert the workaround
in cinder (which would start breaking if we reverted the new
exception type out of novaclient w/o blacklisting 2.33 first).


--

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




__
OpenStack Development Mailing List 

Re: [openstack-dev] [Nova] Migration state machine proposal.

[Tang Chen]

Hi Andrew,

On 10/29/2015 12:53 AM, Andrew Laski wrote:

On 10/27/15 at 09:02am, Jay Pipes wrote:

On 10/22/2015 11:13 AM, Tang Chen wrote:

On 10/22/2015 05:17 AM, Joshua Harlow wrote:

Overall I'm very much inclined to have three state machines (one
for each type), vs the mix-mash of all three into one state machine
(which causes the confusion around states in the first diagram in
that paste).


That is an idea. But I would prefer to have one single state machine
for migration, because resize and evacuate are reusing migration.
They can be in one state machine.


Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs 
from their original source image.


I support Nikola in that I believe the different migration types 
should have different state machines entirely (but be as consistent 
as possible in the naming of terminal states like "finished" vs 
"done" etc)


+1.

It seems that there's also some work to do to disambiguate what the 
different operations are and what they actually do.


Migrate/resize share a code path, and then there's a big switch to 
change behavior if the migration is a live-migrate.  I agree with the 
comment below that we should deprecate the resize terminology and 
consolidate cold-migrate and resize under one umbrella with one state 
machine.  Then live-migrate could have a separate state machine.


Rebuild/evacuate share a code path though evacuate involves a 
scheduler decision which is why it seems like a move.  It's actually a 
bit tricky to classify because if the instance is volume backed it is 
essentially just a move operation, if it's image backed it's a 
destructive rebuild.  But I think it makes sense to not consider this 
a move operation and think of it as an administrative rebuild when a 
host is down.


I'm little think of that we should define each migration type clearly 
first, and then improve migration state machine. If we don't agree on 
what type represents what operation,  the state machine won't be good.


Please also help to review this BP, although the idea may be not exactly 
the same as yours.


Thanks.






It would be very helpful if the designer of the migration process
could share his idea. But if it is just some code modified by many
people many times, I think we should remove the confusing states and
give a easier, better state machine.


There isn't a designer of the migration process :( The original 
(crap, IMHO) API from Rackspace Cloud Servers API was used for the 
resize functionality in the compute API and it's been a source of 
confusion and frustration ever since. Relying on a manual 
confirmation or revert input from the user was and continues to be a 
horrible idea.


Agreed.  In my experience with operating a public cloud I am not aware 
of anyone benefiting from the manual checkpoint in the middle of 
resize.  But we should solicit feedback from the operator community on 
this.




I believe strongly that we should deprecate the existing migrate, 
resize, an live-migrate APIs in favor of a single consolidated, 
consistent "move" REST API that would have the following 
characteristics:


I'm not sure that we should abstract away live vs cold migrate behind 
a single move API, but I strongly agree with consolidate cold-migrate 
and resize.




* No manual or wait-input states in any FSM graph
* Removal of the term "resize" from the API entirely (the target 
resource sizing is an attribute of the move operation, not a 
different type of API operation in and of itself)
* Transition to a task-based API for poll-state requests. This means 
that in order for a caller to determine the state of a VM the caller 
would call something like GET /servers//tasks/ in order 
to see the history of state changes or subtask operations for a 
particular request to move a VM


Huge +1 from me.



Timofei Durakov (cc'd) has a blueprint for splitting the 
live-migration types into separate task classes here:


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

I think there's a lot of good ideas in that proposal. Please do have 
a look at it.


Best,
-jay

__ 


OpenStack Development Mailing 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] [Nova] Migration state machine proposal.

[Tang Chen]

On 10/29/2015 09:26 AM, Tang Chen wrote:

Hi Andrew,

On 10/29/2015 12:53 AM, Andrew Laski wrote:

On 10/27/15 at 09:02am, Jay Pipes wrote:

On 10/22/2015 11:13 AM, Tang Chen wrote:

On 10/22/2015 05:17 AM, Joshua Harlow wrote:

Overall I'm very much inclined to have three state machines (one
for each type), vs the mix-mash of all three into one state machine
(which causes the confusion around states in the first diagram in
that paste).


That is an idea. But I would prefer to have one single state machine
for migration, because resize and evacuate are reusing migration.
They can be in one state machine.


Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs 
from their original source image.


I support Nikola in that I believe the different migration types 
should have different state machines entirely (but be as consistent 
as possible in the naming of terminal states like "finished" vs 
"done" etc)


+1.

It seems that there's also some work to do to disambiguate what the 
different operations are and what they actually do.


Migrate/resize share a code path, and then there's a big switch to 
change behavior if the migration is a live-migrate.  I agree with the 
comment below that we should deprecate the resize terminology and 
consolidate cold-migrate and resize under one umbrella with one state 
machine.  Then live-migrate could have a separate state machine.


Rebuild/evacuate share a code path though evacuate involves a 
scheduler decision which is why it seems like a move.  It's actually 
a bit tricky to classify because if the instance is volume backed it 
is essentially just a move operation, if it's image backed it's a 
destructive rebuild.  But I think it makes sense to not consider this 
a move operation and think of it as an administrative rebuild when a 
host is down.


I'm little think of that we should define each migration type clearly 
first, and then improve migration state machine. If we don't agree on 
what type represents what operation,  the state machine won't be good.


Please also help to review this BP, although the idea may be not 
exactly the same as yours.


https://blueprints.launchpad.net/nova/+spec/migration-type-refactor

https://blueprints.launchpad.net/nova/+spec/migration-state-field-machine



Thanks.






It would be very helpful if the designer of the migration process
could share his idea. But if it is just some code modified by many
people many times, I think we should remove the confusing states and
give a easier, better state machine.


There isn't a designer of the migration process :( The original 
(crap, IMHO) API from Rackspace Cloud Servers API was used for the 
resize functionality in the compute API and it's been a source of 
confusion and frustration ever since. Relying on a manual 
confirmation or revert input from the user was and continues to be a 
horrible idea.


Agreed.  In my experience with operating a public cloud I am not 
aware of anyone benefiting from the manual checkpoint in the middle 
of resize.  But we should solicit feedback from the operator 
community on this.




I believe strongly that we should deprecate the existing migrate, 
resize, an live-migrate APIs in favor of a single consolidated, 
consistent "move" REST API that would have the following 
characteristics:


I'm not sure that we should abstract away live vs cold migrate behind 
a single move API, but I strongly agree with consolidate cold-migrate 
and resize.




* No manual or wait-input states in any FSM graph
* Removal of the term "resize" from the API entirely (the target 
resource sizing is an attribute of the move operation, not a 
different type of API operation in and of itself)
* Transition to a task-based API for poll-state requests. This means 
that in order for a caller to determine the state of a VM the caller 
would call something like GET /servers//tasks/ in order 
to see the history of state changes or subtask operations for a 
particular request to move a VM


Huge +1 from me.



Timofei Durakov (cc'd) has a blueprint for splitting the 
live-migration types into separate task classes here:


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

I think there's a lot of good ideas in that proposal. Please do have 
a look at it.


Best,
-jay

__ 


OpenStack Development Mailing 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] manila-api failure in liberty

[Igor Feoktistov]

The API service fails to load with the error below.
The scheduler and share services seems to load fine. What could be wrong?
I compared api/versions.py for kilo and liberty. And it seems liberty is 
missing Versions class.
I appreciate your hep on this.

2015-10-28 15:39:58.458 8267 CRITICAL manila [-] ImportError:  has no 'Versions' 
attribute
2015-10-28 15:39:58.458 8267 ERROR manila Traceback (most recent call last):
2015-10-28 15:39:58.458 8267 ERROR manila   File "/usr/bin/manila-api", line 
10, in 
2015-10-28 15:39:58.458 8267 ERROR manila sys.exit(main())
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/cmd/api.py", line 48, in main
2015-10-28 15:39:58.458 8267 ERROR manila server = 
service.WSGIService('osapi_share')
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/service.py", line 276, in __init__
2015-10-28 15:39:58.458 8267 ERROR manila self.app = 
self.loader.load_app(name)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/wsgi.py", line 546, in load_app
2015-10-28 15:39:58.458 8267 ERROR manila return deploy.loadapp("config:%s" 
% self.config_path, name=name)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
2015-10-28 15:39:58.458 8267 ERROR manila return loadobj(APP, uri, 
name=name, **kw)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
2015-10-28 15:39:58.458 8267 ERROR manila return context.create()
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710, in create
2015-10-28 15:39:58.458 8267 ERROR manila return 
self.object_type.invoke(self)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2015-10-28 15:39:58.458 8267 ERROR manila **context.local_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 56, in fix_call
2015-10-28 15:39:58.458 8267 ERROR manila val = callable(*args, **kw)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/api/__init__.py", line 35, in 
root_app_factory
2015-10-28 15:39:58.458 8267 ERROR manila return 
paste.urlmap.urlmap_factory(loader, global_conf, **local_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/urlmap.py", line 25, in urlmap_factory
2015-10-28 15:39:58.458 8267 ERROR manila app = loader.get_app(app_name, 
global_conf=global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2015-10-28 15:39:58.458 8267 ERROR manila name=name, 
global_conf=global_conf).create()
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
2015-10-28 15:39:58.458 8267 ERROR manila APP, name=name, 
global_conf=global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
2015-10-28 15:39:58.458 8267 ERROR manila global_additions=global_additions)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 559, in 
_pipeline_app_context
2015-10-28 15:39:58.458 8267 ERROR manila APP, pipeline[-1], global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
2015-10-28 15:39:58.458 8267 ERROR manila section)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
2015-10-28 15:39:58.458 8267 ERROR manila value = import_string(found_expr)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 22, in 
import_string
2015-10-28 15:39:58.458 8267 ERROR manila return 
pkg_resources.EntryPoint.parse("x=" + s).load(False)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/pkg_resources.py", line 2265, in load
2015-10-28 15:39:58.458 8267 ERROR manila raise ImportError("%r has no %r 
attribute" % (entry,attr))
2015-10-28 15:39:58.458 8267 ERROR manila ImportError:  has no 'Versions' 
attribute
2015-10-28 15:39:58.458 8267 ERROR manila 

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

[openstack-dev] [manila] manila-api failure in liberty

[Igor Feoktistov]

The API service fails to load with the error below.
The scheduler and share services seems to load fine. What could be wrong?
I compared api/versions.py for kilo and liberty. And it seems liberty is 
missing Versions class.
I appreciate your hep on this.

2015-10-28 15:39:58.458 8267 CRITICAL manila [-] ImportError:  has no 'Versions' 
attribute
2015-10-28 15:39:58.458 8267 ERROR manila Traceback (most recent call last):
2015-10-28 15:39:58.458 8267 ERROR manila   File "/usr/bin/manila-api", line 
10, in 
2015-10-28 15:39:58.458 8267 ERROR manila sys.exit(main())
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/cmd/api.py", line 48, in main
2015-10-28 15:39:58.458 8267 ERROR manila server = 
service.WSGIService('osapi_share')
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/service.py", line 276, in __init__
2015-10-28 15:39:58.458 8267 ERROR manila self.app = 
self.loader.load_app(name)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/wsgi.py", line 546, in load_app
2015-10-28 15:39:58.458 8267 ERROR manila return deploy.loadapp("config:%s" 
% self.config_path, name=name)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
2015-10-28 15:39:58.458 8267 ERROR manila return loadobj(APP, uri, 
name=name, **kw)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
2015-10-28 15:39:58.458 8267 ERROR manila return context.create()
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710, in create
2015-10-28 15:39:58.458 8267 ERROR manila return 
self.object_type.invoke(self)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2015-10-28 15:39:58.458 8267 ERROR manila **context.local_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 56, in fix_call
2015-10-28 15:39:58.458 8267 ERROR manila val = callable(*args, **kw)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/manila/api/__init__.py", line 35, in 
root_app_factory
2015-10-28 15:39:58.458 8267 ERROR manila return 
paste.urlmap.urlmap_factory(loader, global_conf, **local_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/urlmap.py", line 25, in urlmap_factory
2015-10-28 15:39:58.458 8267 ERROR manila app = loader.get_app(app_name, 
global_conf=global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2015-10-28 15:39:58.458 8267 ERROR manila name=name, 
global_conf=global_conf).create()
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
2015-10-28 15:39:58.458 8267 ERROR manila APP, name=name, 
global_conf=global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
2015-10-28 15:39:58.458 8267 ERROR manila global_additions=global_additions)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 559, in 
_pipeline_app_context
2015-10-28 15:39:58.458 8267 ERROR manila APP, pipeline[-1], global_conf)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
2015-10-28 15:39:58.458 8267 ERROR manila section)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
2015-10-28 15:39:58.458 8267 ERROR manila value = import_string(found_expr)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 22, in 
import_string
2015-10-28 15:39:58.458 8267 ERROR manila return 
pkg_resources.EntryPoint.parse("x=" + s).load(False)
2015-10-28 15:39:58.458 8267 ERROR manila   File 
"/usr/lib/python2.7/site-packages/pkg_resources.py", line 2265, in load
2015-10-28 15:39:58.458 8267 ERROR manila raise ImportError("%r has no %r 
attribute" % (entry,attr))
2015-10-28 15:39:58.458 8267 ERROR manila ImportError:  has no 'Versions' 
attribute
2015-10-28 15:39:58.458 8267 ERROR manila 

Thanks,
Igor.



   
__
OpenStack Development Mailing 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] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

[Kamat, Maruti Haridas]

Hi

I am exploring IPAM feature in OpenStack Neutron. In particular, I wanted to 
look at the IPAM drivers for BlueCat Networks' (Proteus) and Alcatel-Lucent's 
VitalQIP.

If someone can provide me with pointers, it would be of great help.

Thanks,
Maruti



__
OpenStack Development Mailing 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] [Tempest]Non service clients migration to tempest-lib

[Jordan Pittier]

Hi guys,
As discussed this morning, here is an etherpad to track the progress in the
migration of files other than the service clients from Tempest to
tempest-lib:
https://etherpad.openstack.org/p/tempest-lib-non-service-clients-migration

A couple of work items already have assignee, thanks :) If I forgot
something or want to add a bit more details, feel free !

I am not sure I fully understand the scope of the "migrate :Test base class
fixtures": which files/class are we talking about ? Andrea, could you
please check/edit the etherpad on this please ?

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] [tricircle][neutron][dragonflow]Joint session at Design Summit Venue

[Zhipeng Huang]

Hi All,

For those of you who are interested, we are having the session at Hinoki
room at Building 4#, and agenda is available at
https://etherpad.openstack.org/p/TricircleDFMitakaSession

On Fri, Oct 23, 2015 at 9:38 PM, Zhipeng Huang 
wrote:

> Hi All,
>
> Team Tricircle and Dragonflow will hold joint design session at design
> summit venue, and since both teams are not top level official projects, we
> will try to gather what we could grab at the site for logistic of the
> meeting :)
>
> The time slot for our session would be 1:30-3:30pm, on Wed and Thurs. The
> agenda for the session would be to discuss design update and plan for M
> release.
>
> Look forward to see y'all at the summit !
>
> --
> 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] [Heat] userdata empty when using software deployment/config in Kilo

[Gabe Black]

Using my own template or the example template:
https://github.com/openstack/heat-templates/blob/master/hot/software-config/example-templates/example-deploy-sequence.yaml

results in the VM's /var/lib/cloud/instance/script/userdata being empty.

The only warnings during the cloud-init boot sequence are:
[   14.470601] cloud-init[775]: 2015-10-28 17:48:15,104 - util.py[WARNING]: 
Failed running /var/lib/cloud/instance/scripts/userdata [-]
[   15.051625] cloud-init[775]: 2015-10-28 17:48:15,685 - 
cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in 
/var/lib/cloud/instance/scripts)
[   15.057189] cloud-init[775]: 2015-10-28 17:48:15,690 - util.py[WARNING]: 
Running module scripts-user () failed

I believe those warnings are simply because the userdata file is empty

I googled and searched and couldn't find why it wasn't working for me.

The nova.api logs show the transfer of the files, no problem there.  It is 
really sending empty userdata and it thinks it should be doing that.

To verify I added some debug prints in 
heat/engine/resources/openstack/nova/server.py:612 in handle_create() method.  
Below is the first part of the method for reference:

def handle_create(self):
security_groups = self.properties.get(self.SECURITY_GROUPS)

user_data_format = self.properties.get(self.USER_DATA_FORMAT)
ud_content = self.properties.get(self.USER_DATA)  #<---

if self.user_data_software_config() or self.user_data_raw(): #<---
if uuidutils.is_uuid_like(ud_content):
# attempt to load the userdata from software config
ud_content = self.get_software_config(ud_content) #<--- 

I added some debug log prints after the #<--- above to see what it was getting 
for user_data, and it turns out it is empty (e.g. I don't even see the third 
debug print I put in).  Spending more time looking through the code it appears 
to me that the self.properties.get(self.USER_DATA) should be returning the uuid 
for the software config resource associated with the deployment, but I could be 
wrong.  Either way, it is empty which I think is not right.

Does anyone have an idea what I might be doing wrong?  I've been struggling for 
the past couple of days on this one!  Or is deployment just not stable in Kilo? 
 Documentation seems to indicate it has been supported even before Kilo.

Thanks in advance!
Gabe



__
OpenStack Development Mailing 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] [searchlight] Difference in nova notifications versus API

[Jay Pipes]

On 10/28/2015 03:08 PM, McLellan, Steven wrote:

Hi,

One of our questions this summit for Searchlight is whether we can
reduce the time and effort required to index resources by getting as
much information from notifications as possible.

Nova's API and notifications provide data in different formats; some
information is missing and some is in different formats (1). In
addition, notification information isn't versioned and can change at
will. Currently we've taken the approach of treating the notification
as a sign that something has happened and that we should get current
state from the API.

We'd love to be able to process notifications directly, and have some
assurance that the format won't change drastically without warning.


This is why notification payloads need to be versioned. Until they are 
versioned, there can be no such guarantee.


See this thread for some more background:

http://lists.openstack.org/pipermail/openstack-dev/2014-July/039858.html

Best,
-jay

__
OpenStack Development Mailing 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][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Giuseppe,

Please see inline,

Regards,
Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Wednesday, October 28, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
> wrote:
I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API
in OVN.  I have a prototype, but I had to make some pretty big
assumptions, so I wanted to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on
the same Neutron network?  That keeps things simple.  If its intended to
allow a chain of ports on different networks, is it just required that
you pick ports that all have addresses routable from one port to the
next in the chain?  An arbitrary set of ports can't always work, so
there has to be some bounds around what set of ports are valid to be in
a chain.

Hi Russell,

We have similarly been experimenting with a MidoNet implementation of the SFC 
API.

I hope there's no restriction on the location of the Neutron ports in a chain.

In terms of addresses, I believe the API is lacking (or we use a 
chain_parameter?) a way to indicate the service insertion model:
- L2 - The service can accept packets sent from any MAC (service NIC in 
promiscuous mode). The MAC address may be used to identify where the packet 
came from before it entered the chain.
- L3 -  The service expects packets to be routed to it. So the destination MAC 
of the packet must be set to the service's NIC's MAC.

Any thoughts on this?

Cathy> No restriction as long as the ports are routable. Originally we think we 
need to specify L2 and L3 service type. But later we found out it is not needed 
if we program the switch to set the next hop destination to the service 
function’s MAC. This way no matter whether it is L2 or L3, it always works.


Second, where is it expected that the match is applied?  The API for
creating a port chain doesn't associate the chain with a network, but
just matching "globally" doesn't make any sense.  If all ports are
expected to be on the same network, is the match applied for any traffic
entering that network from any port?

Here's what we were thinking for MidoNet:

use the logical_source_port in the flow classifier: when we render the SFC API 
in MidoNet's models we will associate the chain with the source port.

Cathy> Yes, that is the way to specify the flow classifier. Note that one or 
more flow classifiers can be associated with the same chain.

Our packet pipeline (for packets egressing the VM) is:

  1.  Port Mirroring
  2.  Service Chaining
  3.  Filtering (Port Security, anti-spoofing, Security Groups)

Do you think we can standardise on a single order in all implementations? We'd 
be happy to change the order if it makes sense.



I'm in Tokyo this week, so if the group working on this would like to
talk in person, that would be great too.

I'd love to be included.

Great topic, thanks!

Cathy> I discussed briefly with Russell in yesterday’s Neutron design session. 
If needed, we can meet in today’s Neutron NFV session.

Thanks,
Cathy


Pino


--
Russell Bryant

__
OpenStack Development Mailing 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] Troubleshooting cross-project comms

[Shamail]

Hi Anne,

> On Oct 29, 2015, at 8:15 AM, Anne Gentle  
> wrote:
> 
> Hi all, 
> 
> I wanted to write up some of the discussion points from a cross-project 
> session here at the Tokyo Summit about cross-project communications. The 
> etherpad is here: 
> https://etherpad.openstack.org/p/mitaka-crossproject-comms
> 
> One item that came up that I wanted to ensure we gather feedback on is 
> evolving the cross-project meeting to an "as needed" rotation, held at any 
> time on Tuesdays or Wednesdays. We can set up meetbot in a new meeting room, 
> #cross-project-meeting, and then bring in the necessary participants while 
> also inviting everyone to attend. 
I wasn't at the meeting (I really wish I could've attended though...)

 Does any time on Tuesdays or Wednesdays mean that the (1) volunteer chair for 
the meeting will set the time, (2) is the time for the meeting the same each 
week but changes every other week (e.g. AM meeting one week, PM the other), or 
are we going to (3) use a doodle to determine a new time and the range is 
Tuesday or Wednesday?  If #1 then we should also determine how soon in advance 
of the actual meeting should the time be set.  
> 
> I sense this helps with the timezone issues we all face, as well as brings 
> together the relevant projects in a moment, while allowing other projects to 
> filter out unnecessary discussions to help everyone focus further on solving 
> cross-project issues.
> 
> The rest of the action items are in the etherpad, but since I originally 
> suggested changing the meeting time, I wanted to circle back on this new idea 
> specifically. Let us know your thoughts.
> 
> Thanks,
> Anne
> 
> -- 
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.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
__
OpenStack Development Mailing 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] Troubleshooting cross-project comms

[Anne Gentle]

Hi all,

I wanted to write up some of the discussion points from a cross-project
session here at the Tokyo Summit about cross-project communications. The
etherpad is here:
https://etherpad.openstack.org/p/mitaka-crossproject-comms

One item that came up that I wanted to ensure we gather feedback on is
evolving the cross-project meeting to an "as needed" rotation, held at any
time on Tuesdays or Wednesdays. We can set up meetbot in a new meeting
room, #cross-project-meeting, and then bring in the necessary participants
while also inviting everyone to attend.

I sense this helps with the timezone issues we all face, as well as brings
together the relevant projects in a moment, while allowing other projects
to filter out unnecessary discussions to help everyone focus further on
solving cross-project issues.

The rest of the action items are in the etherpad, but since I originally
suggested changing the meeting time, I wanted to circle back on this new
idea specifically. Let us know your thoughts.

Thanks,
Anne

-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.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] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Russell,

Please see inline.

Regards,
Cathy

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, October 28, 2015 5:27 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List; Henry Fourie
Subject: Re: [neutron][networking-sfc] API clarification questions
> 
> First, does it assume that all of the neutron ports in a chain are on 
> the same Neutron network?  That keeps things simple.  If its intended 
> to allow a chain of ports on different networks, is it just required 
> that you pick ports that all have addresses routable from one port to 
> the next in the chain?
> 
> Cathy> It can allow a chain of ports on different networks as along it
> belongs to the same tenant. Yes, it is required that you pick ports 
> that all have addresses routable from one port to the next in the chain.

Thanks.  I think it would be good to clarify this in the API doc, so it's clear 
what makes a valid set of ports in a chain.

Cathy> Sure, will do. 

> An arbitrary set of ports can't always work, so there has to be some 
> bounds around what set of ports are valid to be in a chain.
> 
> Second, where is it expected that the match is applied?  The API for 
> creating a port chain doesn't associate the chain with a network, but 
> just matching "globally" doesn't make any sense.  If all ports are 
> expected to be on the same network, is the match applied for any 
> traffic entering that network from any port?
> 
> Cathy> As long as the ports are routable, they do not need to 
> Cathy> associated with
> the same network.

Let me rephrase the question ... where is the flow classifier applied?  What 
traffic exactly?  "All traffic on all networks accessible to the tenant who 
created the port chain" doesn't seem right to me, but the API doesn't seem to 
specify it.

Cathy> What traffic will go through the chain is specified in the flow 
classifier API. As I presented in the Neutron SFC session of the Summit, there 
are two ways to specify the type of flows. One is through specification of the 
source neutron port that a tenant's flow will originate and/or the destination 
neutron port that a tenant's flow will exit which means all traffic that 
originates from that port and/or terminates at that port needs to go through 
the chain. The other is through specification of the n-tuple of a tenant's 
flow. If it is the first specification, the flow classifier will locate at the 
host of the neutron port and the flow classifier can either run on the host or 
the vSwitch or a VM depending on implementation. If it is the second 
specification, then if the flow's IP or mac is specified, we can locate the 
host and program the host to do the flow classification, but if there is no 
information available to locate the host, then all hosts that could originate 
traffic 
 into the network will be programmed for classification of the flow. So to have 
better performance, we recommend the first way of specification. 

Thanks,
Cathy 



--
Russell
__
OpenStack Development Mailing 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] Learning to Debug the Gate

[Anita Kuno]

On 10/28/2015 12:14 AM, Matt Riedemann wrote:
> 
> 
> On 10/27/2015 4:08 AM, Anita Kuno wrote:
>> Learning how to debug the gate was identified as a theme at the
>> "Establish Key Themes for the Mitaka Cycle" cross-project session:
>> https://etherpad.openstack.org/p/mitaka-crossproject-themes
>>
>> I agreed to take on this item and facilitate the process.
>>
>> Part one of the conversation includes referencing this video created by
>> Sean Dague and Dan Smith:
>> https://www.youtube.com/watch?v=fowBDdLGBlU
>>
>> Please consume this as you are able.
>>
>> Other suggestions for how to build on this resource were mentioned and
>> will be coming in the future but this was an easy, actionable first step.
>>
>> Thank you,
>> Anita.
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/tales-from-the-gate-how-debugging-the-gate-helps-your-enterprise
> 
> 

The source for the definition of "the gate":
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n34

Thanks for following along,
Anita.

__
OpenStack Development Mailing 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][networking-sfc] API clarification questions

[Gal Sagie]

Hi Pino,

Just one note on the order of the pipeline, shouldnt the security part be
before the service chaining (and also after)?
(Unless you only meant egress security and you still do the ingress before)

Gal.

On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
gdecan...@midokura.com> wrote:

> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
> wrote:
>
>> I read through the proposed SFC API here:
>>
>> http://docs.openstack.org/developer/networking-sfc/api.html
>>
>> I'm looking at implementing what would be required to support this API
>> in OVN.  I have a prototype, but I had to make some pretty big
>> assumptions, so I wanted to clarify the intent of the API.
>>
>> First, does it assume that all of the neutron ports in a chain are on
>> the same Neutron network?  That keeps things simple.  If its intended to
>> allow a chain of ports on different networks, is it just required that
>> you pick ports that all have addresses routable from one port to the
>> next in the chain?  An arbitrary set of ports can't always work, so
>> there has to be some bounds around what set of ports are valid to be in
>> a chain.
>>
>
> Hi Russell,
>
> We have similarly been experimenting with a MidoNet implementation of the
> SFC API.
>
> I hope there's no restriction on the location of the Neutron ports in a
> chain.
>
> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the packet
> came from before it entered the chain.
> - L3 -  The service expects packets to be routed to it. So the destination
> MAC of the packet must be set to the service's NIC's MAC.
>
> Any thoughts on this?
>
>
>>
>> Second, where is it expected that the match is applied?  The API for
>> creating a port chain doesn't associate the chain with a network, but
>> just matching "globally" doesn't make any sense.  If all ports are
>> expected to be on the same network, is the match applied for any traffic
>> entering that network from any port?
>>
>
> Here's what we were thinking for MidoNet:
>
> use the logical_source_port in the flow classifier: when we render the SFC
> API in MidoNet's models we will associate the chain with the source port.
>
> Our packet pipeline (for packets egressing the VM) is:
>
>1. Port Mirroring
>2. Service Chaining
>3. Filtering (Port Security, anti-spoofing, Security Groups)
>
>
> Do you think we can standardise on a single order in all implementations?
> We'd be happy to change the order if it makes sense.
>
>
>
>>
>> I'm in Tokyo this week, so if the group working on this would like to
>> talk in person, that would be great too.
>>
>
> I'd love to be included.
>
> Great topic, thanks!
>
> Pino
>
>
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Best Regards ,

The G.
__
OpenStack Development Mailing 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] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Tripp, Travis S]

On 10/28/15, 11:43 AM, "Flavio Percoco"  wrote:

>On 26/10/15 17:20 +, Ian Cordasco wrote:
>>Hi everyone,
>>
>>
>>Today I'm removing myself from the core reviewer (and driver)
>>teams for the
>>
>>
>>following projects:
>>
>>- Bandit (bandit-core and transitively security-specs-core)
>>
>>- Glance (glance-core and glance-specs-core)
>>
>>- OpenStack Ansible (openstack-ansible-core)
>>
>>- Searchlight (searchlight-core)
>>
>>Recent events both in my position at Rackspace and my personal
>>life mean I no longer have sufficient time to properly act as a core reviewer 
>>for
>>These projects. My personal life has suffered from attempts to continue
>>to uphold my responsibilities to OpenStack and the other open source projects 
>>I
>>develop, maintain, and direct. Changing responsibilities in my current role
>>in the last 8-10 months mean that I don't have sufficient time during the
>>normal 0900-1700 period to accurately and thoroughly conduct reviews. I'm 
>>confident
>>this is only a temporary hiatus and that sometime next year, I will be
>>able to fully rejoin the OpenStack community.
>>
>
>Ian,
>
>I can't stress enough how sorry I am to see you go from the team. Your
>reviews, comments and contributions have always been excelent and of
>huge help to our community.
>
>I look forward for that time when you'll be able to come back and as a
>*member* of the community I'd be more than happy to have you back.
>
>Thanks for all the time you've spent on these projectes, for your
>honest and clear email on your situation and availability.
>
>Take good care and, please, come back :)
>Flavio
>
>-- 
>@flaper87
>Flavio Precook


Ian,

Your core status on all of these projects is a true testament to your
abilities, dedication, and character.  All of which we greatly
appreciate about having you on the searchlight team and are why
you will always be welcome on our team. In the meantime, I fully
support you making decisions that are best for you and your family.
I hope that you will be able to find a balance which works for you.


Thank you for all that you have done and contributed!

-Travis
__
OpenStack Development Mailing 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] New migration state field and better state machine proposal.

[Tang Chen]

Hi all,

Please help to review this BP:

https://blueprints.launchpad.net/nova/+spec/migration-state-field-machine


I have post a BP to improve current migration state machine [1].
Please also refer to the picture of current migration state machine [2].

The current migration state machine has mixed 3 state machines for 
different 3 types of migration all together, which makes the whole 
migration framework unclear and hard to maintain. So a better solution 
is split it into 3 new state machines, one for each migration type.


The state of each migration object is maintained by the Migration.status 
field. After some discussion, we cannot change the current definition of 
status field because it has been exposed through API. So we'd better 
keep the current "status" field, and add an new field "state" to class 
Migration, representing the migration state in the new defined state 
machine. And also redefine the states for each type of migration.


There are also some problems in current migration type. Please refer to 
[3]. I think the migration framework refactor work relates to several 
BPs, and it is a long term work.


Thanks.


[1] https://blueprints.launchpad.net/nova/+spec/migration-state-machine
[2] http://paste.openstack.org/show/476954/
[3] https://blueprints.launchpad.net/nova/+spec/migration-type-refactor


__
OpenStack Development Mailing 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] [metrics] Summary of the BOF session on software engineering metrics

[Jesus M. Gonzalez-Barahona]

Hi all

This morning we had the BOF session on software engineering metrics for
OpenStack. Since we agreed on continuing the conversation in this
mailing list, here is a summary of the session, based on the notes
taken by Dani (in CC).

First of all, the link to the slides we used to frame the session:

http://bit.ly/openstack-bof-15

Now, some comments about what we talked.

The general idea of the BOF can be found in slide #3: OpenStack is a
project leading in open development metrics, the idea was talking about
current experiences with this, and about what we would like to have in
the future.

Current dashboards, collections of metrics, etc. In addition to the
ones presented in the slides (Stackalytics, Activity Dashboard, Kibana
-based dashboards, Russell Bryant's stats, Bitergia reports, Jenkins
Logstash dashboard), some others, below, were mentioned. If you know of
any other, please comment about it in this thread.

- Somebody has been looking at patterns of how persons contribute over
time.
- There are some in-house (non public) machinery to check the
total time to deploy in companies for their customers.
- A tool
reporting on coverage in reporting unit tests was mentioned.

We discussed about how each of these efforts is targeted at different
uses, at answering different questions. Some of them are focused on the
contributions by different actors like persons or companies (such as
Stackalytics), some allow for getting knowledge about how development
processes are happening and performing (such as the Activity Board,
Russell's stats, or the Jenkins Logstash dashboard), some are summaries
of interest about certain aspects (such as the reports). In most cases,
they there are overlappings.

It was also mentioned how OpenStack is one of the projects which has
advanced more in the idea of open development analytics, thanks in part
to all the previous efforts, and to a certain state of mind that makes
participants in the OpenStack community more aware of the importance of
metrics than in other projects.

Then we discussed about use cases of metrics within OpenStack, both
cases that are happening now, cases that are happening in other
communities but could be translated, and others not yet happening that
could be interesting. In addition to those mentioned in slide #11, some
others were:

- QA: being able to look at code test coverage, duplication of testing,
test time cycle.
- Hotspots: places of the code where more people are
touching (more 
complex areas).
- Bugs: what files are having more bugs?
How's the complexity in them?
- Complexity: changes that are touching
more complex areas than others?
- Operators: stats about backporting
fixes to stable branches
- Metrics in stable branch, such as failures on
stable branches
- Dependencies on feature requests: Have a new feature
tested internally and later uploaded to upstream, to find that this
breaks even when it was previously in master.
- Frequency of rebase
requirements.
- How fast fixes for critical vulnerabilities are merged
into master
- External example: Wikimedia Gerrit clean up days: lists of
changesets, times, etc. to track the impact of the day.
- External
example: Xen community checking current status of the time to merge,to
see if their perception was in line with real metrics.

Some other issues that were discussed include:

- Should SonarQube be used, and the results made public to the people
when releasing? Every day?
- It may be hard to compare metrics in Stackalytics with other
projects, given that it is very specific of Openstack. On the other
hand, this specificity makes it very well adapted to OpenStack.
- It would be interesting tracking contributions coming from operators
- Having public performance metrics could be of interest, although that
may be a bit beyond the current discussion on software development
metrics.

As a summary, we had time to agree on two lines (see slide #13):

* Open development analytics is a core value of the
OpenStack community
* Let's fostering more lively discussions about metrics in OpenStack,
using the openstack-dev mailing list

Please, comment about any other conclusion that you may propose (were
you in the BOF or not), by answering in this thread.

Thanks to all of you who made this BOF possible! Please, those of you
who attended, comment anything that could missing in these notes.

Saludos,

Jesus.


-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


__
OpenStack Development Mailing 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] [bandit] [glance] [openstack-ansible] [searchlight] Resigning from core reviewers teams

[Kelsey, Timothy John]

On 28/10/2015 09:35, "Tripp, Travis S"  wrote:

>
>
>On 10/28/15, 11:43 AM, "Flavio Percoco"  wrote:
>
>>On 26/10/15 17:20 +, Ian Cordasco wrote:
>>>Hi everyone,
>>>
>>>
>>>Today I'm removing myself from the core reviewer (and driver)
>>>teams for the
>>>
>>>
>>>following projects:
>>>
>>>- Bandit (bandit-core and transitively security-specs-core)
>>>
>>>- Glance (glance-core and glance-specs-core)
>>>
>>>- OpenStack Ansible (openstack-ansible-core)
>>>
>>>- Searchlight (searchlight-core)
>>>
>>>Recent events both in my position at Rackspace and my personal
>>>life mean I no longer have sufficient time to properly act as a core
>>>reviewer for
>>>These projects. My personal life has suffered from attempts to continue
>>>to uphold my responsibilities to OpenStack and the other open source
>>>projects I
>>>develop, maintain, and direct. Changing responsibilities in my current
>>>role
>>>in the last 8-10 months mean that I don't have sufficient time during
>>>the
>>>normal 0900-1700 period to accurately and thoroughly conduct reviews.
>>>I'm confident
>>>this is only a temporary hiatus and that sometime next year, I will be
>>>able to fully rejoin the OpenStack community.
>>>
>>
>>Ian,
>>
>>I can't stress enough how sorry I am to see you go from the team. Your
>>reviews, comments and contributions have always been excelent and of
>>huge help to our community.
>>
>>I look forward for that time when you'll be able to come back and as a
>>*member* of the community I'd be more than happy to have you back.
>>
>>Thanks for all the time you've spent on these projectes, for your
>>honest and clear email on your situation and availability.
>>
>>Take good care and, please, come back :)
>>Flavio
>>
>>-- 
>>@flaper87
>>Flavio Precook
>
>
>Ian,
>
>Your core status on all of these projects is a true testament to your
>abilities, dedication, and character.  All of which we greatly
>appreciate about having you on the searchlight team and are why
>you will always be welcome on our team. In the meantime, I fully
>support you making decisions that are best for you and your family.
>I hope that you will be able to find a balance which works for you.
>
>
>Thank you for all that you have done and contributed!
>
>-Travis

Thank you for your time and dedication Ian, your input will be missed.
Finding a good work/life balance is important and I for one would hate
to see you negatively effected by the time you have generously given to
all the projects your involved in. This is a good move and I¹m sure we
will all look forward to your eventual return.

Thanks again for your hard work.

- Tim

(IRC: tkelsey)

>


__
OpenStack Development Mailing 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][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi All,

We will have a chat about the feature regarding design and next steps at the 
contributors' meet-up on Friday at 10am.

https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track

Best Regards,
Ildikó
(IRC: ildikov)

> -Original Message-
> From: Ildikó Váncsa [mailto:ildiko.van...@ericsson.com]
> Sent: October 22, 2015 10:15
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Bence Romsics; Petr Savelyev
> Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN aware 
> VMs)
> 
> Hi Armando,
> 
> Great, thank you for the pointers and hints. I will contact Rossella to move 
> forward with the process and implementation.
> 
> Best Regards,
> /Ildikó
> 
> > -Original Message-
> > From: Armando M. [mailto:arma...@gmail.com]
> > Sent: October 22, 2015 01:00
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: Bence Romsics; Petr Savelyev
> > Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN
> > aware VMs)
> >
> >
> >
> > On 21 October 2015 at 15:40, Ildikó Váncsa  
> > wrote:
> >
> >
> > Hi Folks,
> >
> > During Liberty we started the implementation of the VLAN aware VMs
> > blueprint (https://review.openstack.org/#/c/94612/). We had quite a
> > good progress, although we could use some extra hands on Neutron side and 
> > some thoughts on the Nova-Neutron interaction
> aspect of the feature.
> >
> > The status of the code can be checked here:
> >
> > https://review.openstack.org/#/q/status:open+project:openstack/neutron
> > +branch:master+topic:bp/vlan-aware-
> > vms,n,z
> >
> > https://review.openstack.org/#/q/status:open+project:openstack/python-
> > neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
> > https://review.openstack.org/#/c/213120/
> > The spec proposed for Nova can be found here:
> > https://review.openstack.org/#/c/213644/
> >
> >
> > We also added a note to the corresponding cross-project session to 
> > discuss further the impacts of this feature on Nova:
> > 
> > https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
> >
> > https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-int
> > egration
> >
> > If you are interested in this feature and would like to help out
> > please let me know. If you will be in Tokyo, we can catch up during/after 
> > the cross-project session or set up a separate discussion to
> move forward and speed up the feature implementation.
> >
> >
> >
> > Hi,
> >
> > Thanks for the email. We discussed blueprint [1] during the last IRC
> > meeting [2] and based on our latest blueprint procedures [3], Rossella
> > has volunteered to help you through the process. She is going to be
> > the main point of contact for anything related to the feature. We'll watch 
> > the progress of the blueprint over the course of the cycle
> and the meeting participation is encouraged to raise/discuss blockers.
> >
> > HTH
> > Armando
> >
> > [1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> > [2]
> > http://eavesdrop.openstack.org/meetings/networking/2015/networking.201
> > 5-10-20-14.00.log.html [3]
> > http://docs.openstack.org/developer/neutron/policies/blueprints.html#n
> > eutron-request-for-feature-enhancements
> >
> >
> >
> > 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
__
OpenStack Development Mailing 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] [Congress] Monasca @10a on Thu in Tokyo

[Fabio Giannetti (fgiannet)]

Tim,
  We are at the round tables in Building 4 1st floor opposite the reception.
Fabio
[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_06.png?ct=1430182397611]

Fabio Giannetti
Cloud Innovation Architect
Cisco Services
fgian...@cisco.com
Phone: +1 408 527 1134
Mobile: +1 408 854 0020


Cisco Systems, Inc.
285 W. Tasman Drive
San Jose
California
95134
United States
Cisco.com





[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

Please click 
here for 
Company Registration Information.



From: Tim Hinrichs >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 22, 2015 at 10:15 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Congress] Monasca @10a on Thu in Tokyo

Hi all,

At the summit next week, we're planning on a 10a meeting on Thursday with the 
Monasca team for a deep dive.  All are welcome.

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