Re: [openstack-dev] Timeframe for naming the P release?

[Carol Bouchard (caboucha)]

Here are other ideas?  

Paul-Revere   https://en.wikipedia.org/wiki/Paul_Revere
Peabody A town north east of Boston.  No special reason except 
saying the name personally makes me chuckle  
Patriots  https://en.wikipedia.org/wiki/New_England_Patriots


-Original Message-
From: Jonathan D. Proulx [mailto:j...@csail.mit.edu] 
Sent: Tuesday, May 03, 2016 10:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Timeframe for naming the P release?

On Tue, May 03, 2016 at 12:09:40AM -0400, Adam Young wrote:
:On 05/02/2016 08:07 PM, Rochelle Grober wrote:
:>But, the original spelling of the landing site is Plimoth Rock.  There were 
still highway signs up in the 70's directing folks to "Plimoth Rock"

There are trill signs with both spellings. Presumably for sligtly different 
contexts. Even having lived here basically my whole life I'm not sure if 
there's a consistent distinction except the legal entity that is the town is 
always with a y

:>
:>--Rocky
:>Who should know about rocks ;-)



:And Providnece is, I think close enough for inclusion as well.  And :that is 
just the towns.

:
:
:Plymouth is the only County in Mass with a P name, but Penobscott ME :used to 
be part of MA, and should probably be in the running as well.


I'd second Providnece and Penobscott as 'close enough'.  I'm actually partial 
to Providence...

-Jon

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

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

Re: [openstack-dev] [neutron] Neutron debugging tool

[Carol Bouchard (caboucha)]

There was a presentation on DON at the Vancouver summit.  Here is the link:

https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/don-diagnosing-ovs-in-neutron

From: Salvatore Orlando [mailto:salv.orla...@gmail.com]
Sent: Tuesday, September 22, 2015 3:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron debugging tool

Thanks Ganesh!

I did not know about this tool.
I also quite like the network visualization bits, though I wonder how practical 
that would be when one debugs very large deployments.

I think it won't be a bad idea to list these tools in the networking guide or 
in neutron's devref, or both.

Salvatore

On 22 September 2015 at 04:25, Ganesh Narayanan (ganeshna) 
> wrote:
Another project for diagnosing OVS in Neutron:

https://github.com/CiscoSystems/don

Thanks,
Ganesh

From: Salvatore Orlando >
Reply-To: OpenStack Development Mailing List 
>
Date: Monday, 21 September 2015 2:55 pm
To: OpenStack Development Mailing List 
>
Subject: Re: [openstack-dev] [neutron] Neutron debugging tool

It sounds like indeed that easyOVS covers what you're aiming too.
However, from what I gather there is still plenty to do in easy OVS, so perhaps 
rather than starting a new toolset from scratch you might build on the existing 
one.

Personally I'd welcome its adoption into the Neutron stadium as debugging 
control plane/data plane issues in the neutron reference impl is becoming 
difficult also for expert users and developers.
I'd just suggest renaming it because calling it "OVS" is just plain wrong. The 
neutron reference implementation and OVS are two distinct things.

As concern neutron-debug, this is a tool that was developed in the early stages 
of the project to verify connectivity using "probes" in namespaces. These 
probes are simply tap interfaces associated with neutron ports. The 
neutron-debug tool is still used in some devstack exercises. Nevertheless, I'd 
rather keep building something like easyOVS and then deprecated neutron-debug 
rather than develop it.

Salvatore


On 21 September 2015 at 02:40, Li Ma 
> wrote:
AFAIK, there is a project available in the github that does the same thing.
https://github.com/yeasy/easyOVS

I used it before.

On Mon, Sep 21, 2015 at 12:17 AM, Nodir Kodirov 
> wrote:
> Hello,
>
> I am planning to develop a tool for network debugging. Initially, it
> will handle DVR case, which can also be extended to other too. Based
> on my OpenStack deployment/operations experience, I am planning to
> handle common pitfalls/misconfigurations, such as:
> 1) check external gateway validity
> 2) check if appropriate qrouter/qdhcp/fip namespaces are created in
> compute/network hosts
> 3) execute probing commands inside namespaces, to verify reachability
> 4) etc.
>
> I came across neutron-debug [1], which mostly focuses on namespace
> debugging. Its coverage is limited to OpenStack, while I am planning
> to cover compute/network nodes as well. In my experience, I had to ssh
> to the host(s) to accurately diagnose the failure (e.g., 1, 2 cases
> above). The tool I am considering will handle these, given the host
> credentials.
>
> I'd like get community's feedback on utility of such debugging tool.
> Do people use neutron-debug on their OpenStack environment? Does the
> tool I am planning to develop with complete diagnosis coverage sound
> useful? Anyone is interested to join the development? All feedback are
> welcome.
>
> Thanks,
>
> - Nodir
>
> [1] 
> http://docs.openstack.org/cli-reference/content/neutron-debug_commands.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--

Li Ma (Nick)
Email: skywalker.n...@gmail.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: 

Re: [openstack-dev] [keystone] is all CLI commands supported in V3?

[Carol Bouchard (caboucha)]

Danny:

Not sure it's the same thing but I've been doing the following to create a 
subnet (for example):

neutron net-create --tenant-id cf0a9274022540f9bc5b65a932778cd4 net-carol1
neutron subnet-create --tenant-id cf0a9274022540f9bc5b65a932778cd4 --gateway 
172.17.16.1 --ip-version 4 --enable-dhcp --name subnet-carol1 net-carol1 
172.17.16.0/20

To get the tenant information used in this command I had to change to use:

openstack  --os-username=admin --os-password=nova project list

But you'll need to do some install first.
http://ronaldbradford.com/blog/moving-to-openstackclient-cli-2015-04-20/

Carol

From: Danny Choi (dannchoi)
Sent: Wednesday, September 16, 2015 3:39 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [keystone] is all CLI commands supported in V3?

Hi,

I'm running keystone V3.

It does not seem to support all CLI commands.

E.g. There is no "subnet create" command available.

Is this expected?

How to create a subnet in this case?

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

[Carol Bouchard (caboucha)]

Hi Muguel:

Either works for me.

Carol

From: Vikram Choudhary [mailto:vikram.choudh...@huawei.com]
Sent: Wednesday, April 08, 2015 1:49 AM
To: Miguel Ángel Ajo
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

Hi Miguel,

Voting for timeslot: b.

Thanks
Vikram

From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: 07 April 2015 21:49
To: OpenStack Development Mailing List (not for usage questions)
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 openstack/neutron meeting, 
so, I don't know 

[openstack-dev] [neutron][stable] Review request

[Carol Bouchard (caboucha)]

Neutron cores:

I submitted a bug fix a bit over a month ago which is waiting for one
more core (+2) review.  The changes are rather simple which affects
the ovs/ofa code.  Could a core person take the time to review?

Here are the pointers to the changes:
https://review.openstack.org/127654

https://bugs.launchpad.net/neutron/+bug/1367697

Carol
[http://wwwin.cisco.com/marketing/corporate/brand/intelbrand/brandstrat/signature/none]

Carol Bouchard
TECHNICAL LEADER.ENGINEERING

cabou...@cisco.commailto:cabou...@cisco.com
WebEx Social profilehttp://iwe.cisco.com/web/caboucha
Phone: +1 978 936 2124


Cisco.comhttp://www.cisco.com



[Description: Think before you print.]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.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev