Re: [openstack-dev] [neutron] Social at the summit

[Howard, Victor]

+2 Thanks.

On 4/26/16, 9:57 AM, "Ben Pfaff"  wrote:

>Sign me up, too.
>
>On Mon, Apr 25, 2016 at 01:07:02PM -0500, Kyle Mestery wrote:
>> OK, there is enough interest, I'll find a place on 6th Street for us
>> and get a reservation for Thursday around 7 or so.
>> 
>> Thanks folks!
>> 
>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
>> > +1 :)
>> >
>> > Han Zhou
>> > Irc: zhouhan
>> >
>> >
>> > On Monday, April 25, 2016, Korzeniewski, Artur
>> >  wrote:
>> >>
>> >> Sign me up :)
>> >>
>> >> Artur
>> >> IRC: korzen
>> >>
>> >> -Original Message-
>> >> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>> >> Sent: Monday, April 25, 2016 7:19 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> 
>> >> Subject: Re: [openstack-dev] [neutron] Social at the summit
>> >>
>> >> Count me in!
>> >> Will be good to meet all you guys!
>> >>
>> >> Darek (dasm) Smigiel
>> >>
>> >> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>> >> >  wrote:
>> >> >
>> >> >
>> >> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka
>>
>> >> >> wrote:
>> >> >>
>> >> >> WAT???
>> >> >>
>> >> >> It was never supposed to be core only. Everyone is welcome!
>> >> >
>> >> > +2
>> >> >
>> >> > irony intended.
>> >> >
>> >> > Socials are not controlled by gerrit ACLs.  :-)
>> >> >
>> >> > doug
>> >> >
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >>> On 25 Apr 2016, at 11:56, Edgar Magana 
>> >> >>> wrote:
>> >> >>>
>> >> >>> Would you extend it to ex-cores?
>> >> >>>
>> >> >>> Edgar
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >>  On 4/25/16, 10:55 AM, "Kyle Mestery" 
>>wrote:
>> >> 
>> >>  Ihar, Henry and I were talking and we thought Thursday night
>>makes
>> >>  sense for a Neutron social in Austin. If others agree, reply on
>>this thread
>> >>  and we'll find a place.
>> >> 
>> >>  Thanks!
>> >>  Kyle
>> >> 
>> >>  
>>___
>> >>  ___ OpenStack Development Mailing 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 Development Mailing 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 Development Mailing 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] [Sender Auth Failure] [neutron] New cycle started. What are you up to, folks?

[Howard, Victor]

I¹d like to help out in some fashion with FwaaS and the IPV6 needs
mentioned.  Current working on the DSCP Spec and patches to implement
ontop of QOS.

I liked Seans comments about devstack, we have been doing tons of testing
for DSCP there without really understanding how things are going to be
updated or knowing if its current with production on master. Would like to
help out in discussing the best way to move forward to keep devstack in
synch or help to update it.

On 10/1/15, 9:45 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I talked recently with several contributors about what each of us plans
>for the next cycle, and found it¹s quite useful to share thoughts with
>others, because you have immediate yay/nay feedback, and maybe find
>companions for next adventures, and what not. So I¹ve decided to ask
>everyone what you see the team and you personally doing the next cycle,
>for fun or profit.
>
>That¹s like a PTL nomination letter, but open to everyone! :) No
>commitments, no deadlines, just list random ideas you have in mind or in
>your todo lists, and we¹ll all appreciate the huge pile of awesomeness no
>one will ever have time to implement even if scheduled for Xixao release.
>
>To start the fun, I will share my silly ideas in the next email.
>
>Ihar


__
OpenStack Development Mailing 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] [QoS] QoS weekly meeting

[Howard, Victor]

I prefer Timeslot B, thanks for coordinating.  I would be interested in helping 
out in any way with the design session let me know!

From: Sandhya Dasu (sadasu) sad...@cisco.commailto:sad...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 7, 2015 12:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

Hi Miguel,
Both time slots work for me. Thanks for rekindling this effort.

Thanks,
Sandhya

From: Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 7, 2015 1:45 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote:
On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando 
sorla...@nicira.commailto:sorla...@nicira.com wrote:


On 7 April 2015 at 00:33, Armando M. 
arma...@gmail.commailto:arma...@gmail.com wrote:

On 6 April 2015 at 08:56, Miguel Ángel Ajo 
majop...@redhat.commailto:majop...@redhat.com wrote:
I’d like to co-organized a QoS weekly meeting with Sean M. Collins,

In the last few years, the interest for QoS support has increased, Sean has 
been leading
this effort [1] and we believe we should get into a consensus about how to 
model an extension
to let vendor plugins implement QoS capabilities on network ports and tenant 
networks, and
how to extend agents, and the reference implementation  others [2]

As you surely know, so far every attempt to achieve a consensus has failed in a 
pretty miserable way.
This mostly because QoS can be interpreted in a lot of different ways, both 
from the conceptual and practical perspective.
Yes, I’m fully aware of it, it was also a new feature, so it was out of scope 
for Kilo.
It is important in my opinion to clearly define the goals first. For instance a 
simple extensions for bandwidth limiting could be a reasonable target for the 
Liberty release.
I quite agree here, but IMHO, as you said it’s a quite open field (limiting, 
guaranteeing,
marking, traffic shaping..), we should do our best in trying to define a model 
allowing us
to build that up in the future without huge changes, on the API side I guess 
micro versioning
is going to help in the API evolution.

Also, at some point, we should/could need to involve the nova folks, for 
example, to define
port flavors that can be associated to nova
instance flavors, providing them
1) different types of network port speeds/guarantees/priorities,
2) being able to schedule instance/ports in coordination to be able to met 
specified guarantees.

yes, complexity can sky rocket fast,
Moving things such as ECN into future works is the right thing to do in my 
opinion. Attempting to define a flexible framework that can deal with advanced 
QoS policies specification is a laudable effort, but I am a bit skeptical about 
its feasibility.

++, I think focusing on perhaps bandwidth limiting may make a lot of sense
Yes, I believe we should look into the future , but at the same pick our very 
first feature (or a
very simple set of them) for L, stick to it, and try to make a design that can 
be extended.



As per discussion we’ve had during the last few months [3], I believe we 
should start simple, but
prepare a model allowing future extendibility, to allow for example specific 
traffic rules (per port,
per IP, etc..), congestion notification support [4], …

Simple in my mind is even more extreme then what you're proposing here... I'd 
start with bare APIs for specifying bandwidth limiting, and then phase them out 
once this framework is in place.
Also note that this kind of design bears some overlap with the flavor framework 
which is probably going to be another goal for Liberty.

Indeed, and the flavor framework is something I'm hoping we can land by 
Liberty-1 (yes, I just said Liberty-1).
Yes it’s something I looked at, I must admit I wasn’t able to see it work 
together (It doesn’t
mean it doesn’t play well, but most probably I was silly enough not to see it 
:) ),

I didn’t want to distract attention from the Kilo cycle focus making questions, 
so it should
be a good thing to talk about during the first meetings.

Who are the flavor fathers/mothers? ;)


Morever, consider using common tools such as the specs repo to share and 
discuss design documents.

Also a good idea.
Yes, that was the plan now, we didn’t use it before to avoid creating 
unnecessary noise during this cycle.



It’s the first time I’m trying to organize an