Re: [openstack-dev] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 20

2015-05-19 Thread Alan Kavanagh
Hi Dan et.al

Thanks for reaching out, I attended your IDS talk yesterday and we can meet up 
after our TaaS tech talk where we do a walk through from the why, what and how 
and a demo with detail explanations on its built.
/Alan

-Original Message-
From: Dan Lambright [mailto:dlamb...@redhat.com] 
Sent: May-19-15 2:30 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [security] / IDS + openstack meeting in Vancouver 4:10 
Wednesday May 20

Hello,

While at the Vancouver summit, it would be good to have an informal meeting on 
IDS + openstack. My understanding is there has not been a community driven 
effort in this area to date. It would be good to kick something off. Likely 
subjects would be neutron plug-ins and scalability (management and monitoring).

The best time would probably be after the TaaS talk Wednesday. TaaS may 
influence what direction to take.  

I will be next to the ATM machine on the 1st floor, next to where they give 
away the windbreaker SWAG. I’ll hang out there between 4:10 and 4:30. Please 
feel free to find a drink and  walk over. I will also post this announcement to 
the openstack-dev mailing list 
(http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The 
subject will contain: [security] {IDS}

Thanks,

Dan Lambright
Red Hat

__
OpenStack Development Mailing 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] Data-plane performance testing with Shaker

2015-05-14 Thread Alan Kavanagh
Hi Ilya

I am interested in this and many thanks for posting this. I have to ask how 
relevant the performance testing is given that Neutron overlays are dependent 
on the underlay? I believe your point 4 below I can see some uses and value 
for, but I am struggling to this been used as a “tool for data-plane 
performance testing” in Neutron networks.

I look forward to the lightning talks.
/Alan

From: Ilya Shakhat [mailto:ishak...@mirantis.com]
Sent: May-14-15 11:30 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron] Data-plane performance testing with Shaker

Hi all!
Let me introduce you Shaker - a tool for data-plane performance testing in 
OpenStack. The motivation behind it is to have a simple way for measuring 
networking bandwidth between instances.

Shaker key features are:

1. User-defined topology. The topology is specified as Heat template, so users 
may do arbitrary configuration for instances, networks, routers, floating ips, 
etc. Instance scheduling is controlled, it is possible to specify number of 
instances per compute node and their location.

2. Simultaneous test execution. By default Shaker runs tests synchronously on 
all deployed instances. It is also possible to increase the load, thus 
measuring dependency on number of concurrently working instances. The feature 
is useful when one needs to find bottleneck in the cloud (like usage of non-DVR 
routers).

3. Pluggable tools. Out of the box Shaker supports iperf, netperf and able to 
calculate aggregated stats based on their output. Adding a new tool is easy, in 
the simplest case it does not even require coding.

4. Interactive report. Shaker produces report as single-page HTML application. 
The report contains aggregated charts for bandwidth depending on concurrency, 
bandwidth per node and precise timeline of traffic on every node. The report 
does not have any dependencies and can be shared easily.
If you are interested in knowing more about Shaker welcome to Neutron Lightning 
talk presentation by Oleg Bondarev next Wed in Vancouver (http://sched.co/3BNR).
And certainly welcome to use and contribute!
Code: https://github.com/stackforge/shaker
Docs: http://pyshaker.readthedocs.org/
Launchpad: https://launchpad.net/shaker/
PyPi - https://pypi.python.org/pypi/pyshaker/

Thanks,
Ilya


__
OpenStack Development Mailing 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] [nfv] VM-based VLAN trunking blueprints

2014-11-01 Thread Alan Kavanagh
+1 yep, as an NFV vendor this is how it really works, and no need for an 
active/standby on ports….does not make sense for this type of deployment 
scenario. Typically the two or more sets of apps synch together and address the 
failover/HA, so no need to make this also in the Infra….you gain nothing from 
doing active-standby port mgmt. in ovs.
/Alan

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: October-31-14 11:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Go  read about HSRP and VRRP.  What you propose is akin to turning off one 
physical switch port and turning on another when you want to switch from an 
active physical server to a standby, and this is not how it's done in practice; 
instead, you connect the two VMs to the same network and let them decide which 
gets the primary address.

On 28 October 2014 10:27, A, Keshava 
keshav...@hp.commailto:keshav...@hp.com wrote:
Hi Alan and  Salvatore,

Thanks for response and I also agree we need to take small steps.
However I have below points to make.

It is very important how the Service VM needs will be deployed w.r.t HA.
As per current discussion, you are proposing something like below kind of 
deployment for Carrier Grade HA.
Since there is a separate port for Standby-VM also, then the corresponding 
standby-VM interface address should be globally routable also.
Means it may require the Standby Routing protocols to advertise its interface 
as Next-HOP for prefix it routes.
However external world should not be aware of the standby-routing running in 
the network.

[cid:image001.png@01CFF601.E49C6A50]

[cid:image002.png@01CFF601.E49C6A50]

Instead if we can think of running Standby on same stack with Passive port, ( 
as shown below)  then external world will be unaware of the standing Service 
Routing running.
This may be  something very basic requirement from Service-VM (NFV HA 
perspective) for Routing/MPLS/Packet processing domain.
I am brining this issue now itself, because you are proposing to change the 
basic framework of packer delivering to VM’s.
(Of course there may be  other mechanism of supporting redundancy, however it 
will not be as efficient as that of handing at packet level).

[cid:image003.png@01CFF601.E49C6A50]


Thanks  regards,
Keshava

From: Alan Kavanagh 
[mailto:alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com]
Sent: Tuesday, October 28, 2014 6:48 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Hi Salvatore

Inline below.

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: October-28-14 12:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Keshava,

I think the thread is not going a bit off its stated topic - which is to 
discuss the various proposed approaches to vlan trunking.
Regarding your last post, I'm not sure I saw either spec implying that at the 
data plane level every instance attached to a trunk will be implemented as a 
different network stack.
AK-- Agree
Also, quoting the principle earlier cited in this thread -  make the easy 
stuff easy and the hard stuff possible - I would say that unless five 9s is a 
minimum requirement for a NFV application, we might start worrying about it 
once we have the bare minimum set of tools for allowing a NFV application over 
a neutron network.
AK-- five 9’s is a 100% must requirement for NFV, but lets ensure we don’t mix 
up what the underlay service needs to guarantee and what openstack needs to do 
to ensure this type of service. Would agree, we should focus more on having the 
right configuration sets for onboarding NFV which is what Openstack needs to 
ensure is exposed then what is used underneath guarantee the 5 9’s is a 
separate matter.
I think Ian has done a good job in explaining that while both approaches 
considered here address trunking for NFV use cases, they propose alternative 
implementations which can be leveraged in different way by NFV applications. I 
do not see now a reason for which we should not allow NFV apps to leverage a 
trunk network or create port-aware VLANs (or maybe you can even have VLAN aware 
ports which tap into a trunk network?)
AK-- Agree, I think we can hammer this out once and for all in Paris…….this 
feature has been lingering too long.
We may continue discussing the pros and cons of each approach - but to me it's 
now just a matter of choosing the best solution for exposing them at the API 
layer. At the control/data plane layer, it seems to me that trunk networks are 
pretty much straightforward. VLAN aware ports are instead a bit more 
convoluted, but not excessively complicated in my opinion.
AK-- My thinking too Salvatore, lets ensure the right elements are exposed at 
API Layer, I would also go a little

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-28 Thread Alan Kavanagh
Hi
Please find some additions to Ian and responses below.
/Alan

From: A, Keshava [mailto:keshav...@hp.com]
Sent: October-28-14 9:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Hi,
Pl fine the reply for the same.

Regards,
keshava

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Tuesday, October 28, 2014 1:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

This all appears to be referring to trunking ports, rather than anything else, 
so I've addressed the points in that respect.
On 28 October 2014 00:03, A, Keshava 
keshav...@hp.commailto:keshav...@hp.com wrote:
Hi,

1.   How many Trunk ports can be created ?
Why would there be a limit?

Will there be any Active-Standby concepts will be there ?
I don't believe active-standby, or any HA concept, is directly relevant.  Did 
you have something in mind?
For the NFV kind of the scenario, it is very much required to run the ‘Service 
VM’ in Active and Standby Mode.
AK-- We have a different view on this, the “application runs as a pair” of 
which the application either runs in active-active or active standby…this has 
nothing to do with HA, its down to the application and how its provisioned and 
configured via Openstack. So agree with Ian on this.
Standby is more of passive entity and will not take any action to external 
network. It will be passive consumer of the packet/information.
AK-- Why would we need to care?
In that scenario it will be very meaningful to have
“Active port – connected to  “Active  Service VM”.
“Standby port – connected to ‘Standby Service VM’. Which will turn Active when 
old Active-VM goes down  ?
AK-- Cant you just have two VM’s and then via a controller decide how to 
address MAC+IP_Address control…..FYI…most NFV Apps have that built-in today.
Let us know others opinion about this concept.
AK--Perhaps I am miss reading this but I don’t understand what this would 
provide as opposed to having two VM’s instantiated and running, why does 
Neutron need to care about the port state between these two VM’s? Similarly its 
better to just have 2 or more VM’s up and the application will be able to 
address when failover occurs/requires. Lets keep it simple and not mix up with 
what the apps do inside the containment.

 2.   Is it possible to configure multiple IP address configured on these 
ports ?
Yes, in the sense that you can have addresses per port.  The usual restrictions 
to ports would apply, and they don't currently allow multiple IP addresses 
(with the exception of the address-pair extension).

In case IPv6 there can be multiple primary address configured will this be 
supported ?
No reason why not - we're expecting to re-use the usual port, so you'd expect 
the features there to apply (in addition to having multiple sets of subnet on a 
trunking port).

 3.   If required can these ports can be aggregated into single one 
dynamically ?
That's not really relevant to trunk ports or networks.

 4.   Will there be requirement to handle Nested tagged packet on such 
interfaces ?
For trunking ports, I don't believe anyone was considering it.





Thanks  Regards,
Keshava

From: Ian Wells [mailto:ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk]
Sent: Monday, October 27, 2014 9:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

On 25 October 2014 15:36, Erik Moe 
erik@ericsson.commailto:erik@ericsson.com wrote:
Then I tried to just use the trunk network as a plain pipe to the L2-gateway 
and connect to normal Neutron networks. One issue is that the L2-gateway will 
bridge the networks, but the services in the network you bridge to is unaware 
of your existence. This IMO is ok then bridging Neutron network to some remote 
network, but if you have an Neutron VM and want to utilize various resources in 
another Neutron network (since the one you sit on does not have any resources), 
things gets, let’s say non streamlined.

Indeed.  However, non-streamlined is not the end of the world, and I wouldn't 
want to have to tag all VLANs a port is using on the port in advance of using 
it (this works for some use cases, and makes others difficult, particularly if 
you just want a native trunk and are happy for Openstack not to have insight 
into what's going on on the wire).

 Another issue with trunk network is that it puts new requirements on the 
infrastructure. It needs to be able to handle VLAN tagged frames. For a VLAN 
based network it would be QinQ.

Yes, and that's the point of the VLAN trunk spec, where we flag a network as 
passing VLAN tagged packets; if the operator-chosen network implementation 
doesn't support trunks, the API can refuse to make a trunk network.  Without it 
we're still in the situation 

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-28 Thread Alan Kavanagh
Hi Salvatore

Inline below.

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: October-28-14 12:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Keshava,

I think the thread is not going a bit off its stated topic - which is to 
discuss the various proposed approaches to vlan trunking.
Regarding your last post, I'm not sure I saw either spec implying that at the 
data plane level every instance attached to a trunk will be implemented as a 
different network stack.
AK-- Agree
Also, quoting the principle earlier cited in this thread -  make the easy 
stuff easy and the hard stuff possible - I would say that unless five 9s is a 
minimum requirement for a NFV application, we might start worrying about it 
once we have the bare minimum set of tools for allowing a NFV application over 
a neutron network.
AK-- five 9’s is a 100% must requirement for NFV, but lets ensure we don’t mix 
up what the underlay service needs to guarantee and what openstack needs to do 
to ensure this type of service. Would agree, we should focus more on having the 
right configuration sets for onboarding NFV which is what Openstack needs to 
ensure is exposed then what is used underneath guarantee the 5 9’s is a 
separate matter.
I think Ian has done a good job in explaining that while both approaches 
considered here address trunking for NFV use cases, they propose alternative 
implementations which can be leveraged in different way by NFV applications. I 
do not see now a reason for which we should not allow NFV apps to leverage a 
trunk network or create port-aware VLANs (or maybe you can even have VLAN aware 
ports which tap into a trunk network?)
AK-- Agree, I think we can hammer this out once and for all in Paris…….this 
feature has been lingering too long.
We may continue discussing the pros and cons of each approach - but to me it's 
now just a matter of choosing the best solution for exposing them at the API 
layer. At the control/data plane layer, it seems to me that trunk networks are 
pretty much straightforward. VLAN aware ports are instead a bit more 
convoluted, but not excessively complicated in my opinion.
AK-- My thinking too Salvatore, lets ensure the right elements are exposed at 
API Layer, I would also go a little further to ensure we get those feature sets 
to be supported into the Core API (another can of worms discussion but we need 
to have it).
Salvatore


On 28 October 2014 11:55, A, Keshava 
keshav...@hp.commailto:keshav...@hp.com wrote:
Hi,
Pl find my reply ..


Regards,
keshava

From: Alan Kavanagh 
[mailto:alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com]
Sent: Tuesday, October 28, 2014 3:35 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Hi
Please find some additions to Ian and responses below.
/Alan

From: A, Keshava [mailto:keshav...@hp.com]
Sent: October-28-14 9:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

Hi,
Pl fine the reply for the same.

Regards,
keshava

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Tuesday, October 28, 2014 1:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

This all appears to be referring to trunking ports, rather than anything else, 
so I've addressed the points in that respect.
On 28 October 2014 00:03, A, Keshava 
keshav...@hp.commailto:keshav...@hp.com wrote:
Hi,

1.   How many Trunk ports can be created ?
Why would there be a limit?

Will there be any Active-Standby concepts will be there ?
I don't believe active-standby, or any HA concept, is directly relevant.  Did 
you have something in mind?
For the NFV kind of the scenario, it is very much required to run the ‘Service 
VM’ in Active and Standby Mode.
AK-- We have a different view on this, the “application runs as a pair” of 
which the application either runs in active-active or active standby…this has 
nothing to do with HA, its down to the application and how its provisioned and 
configured via Openstack. So agree with Ian on this.
Standby is more of passive entity and will not take any action to external 
network. It will be passive consumer of the packet/information.
AK-- Why would we need to care?
In that scenario it will be very meaningful to have
“Active port – connected to  “Active  Service VM”.
“Standby port – connected to ‘Standby Service VM’. Which will turn Active when 
old Active-VM goes down  ?
AK-- Cant you just have two VM’s and then via a controller decide how to 
address MAC+IP_Address control…..FYI…most NFV Apps have that built-in today.
Let us know others opinion about this concept.
AK--Perhaps I am miss reading this but I don’t understand what this would

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-23 Thread Alan Kavanagh
+1 many thanks to Kyle for putting this as a priority, its most welcome.
/Alan

-Original Message-
From: Erik Moe [mailto:erik@ericsson.com] 
Sent: October-22-14 5:01 PM
To: Steve Gordon; OpenStack Development Mailing List (not for usage questions)
Cc: iawe...@cisco.com
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints


Hi,

Great that we can have more focus on this. I'll attend the meeting on Monday 
and also attend the summit, looking forward to these discussions.

Thanks,
Erik


-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com]
Sent: den 22 oktober 2014 16:29
To: OpenStack Development Mailing List (not for usage questions)
Cc: Erik Moe; iawe...@cisco.com; calum.lou...@metaswitch.com
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

- Original Message -
 From: Kyle Mestery mest...@mestery.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 
 There are currently at least two BPs registered for VLAN trunk support 
 to VMs in neutron-specs [1] [2]. This is clearly something that I'd 
 like to see us land in Kilo, as it enables a bunch of things for the 
 NFV use cases. I'm going to propose that we talk about this at an 
 upcoming Neutron meeting [3]. Given the rotating schedule of this 
 meeting, and the fact the Summit is fast approaching, I'm going to 
 propose we allocate a bit of time in next Monday's meeting to discuss 
 this. It's likely we can continue this discussion F2F in Paris as 
 well, but getting a head start would be good.
 
 Thanks,
 Kyle
 
 [1] https://review.openstack.org/#/c/94612/
 [2] https://review.openstack.org/#/c/97714
 [3] https://wiki.openstack.org/wiki/Network/Meetings

Hi Kyle,

Thanks for raising this, it would be great to have a converged plan for 
addressing this use case [1] for Kilo. I plan to attend the Neutron meeting and 
I've CC'd Erik, Ian, and Calum to make sure they are aware as well.

Thanks,

Steve

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] ETSI NFV gap analysis [NFV]

2014-10-06 Thread Alan Kavanagh
I believe pointing it to the NFV Wiki would be good and that way it can be 
discussed during one of the weekly meetings run by Steven et.al and match the 
list to what is being requested to what is identified in the wiki list as a 
good starting point.
/Alan

-Original Message-
From: Sylvain Bauza [mailto:sba...@redhat.com] 
Sent: October-06-14 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] ETSI NFV gap analysis [NFV]


Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a écrit :
 Team,

 Following my action item from last week  IRC.
 It seems that the document is ready for submission by ETSI NFV team.
 It was written in a liaison form as this is how they are used to operate.
 They are wondering who should they send it to...
 IMHO it seems a good idea that the NFV sub group will receive it in behalf 
 of the community.

 Thoughts?

 Itai

I don't know the legal conditions of the publication of this document, but I 
would assume it would be worth of interest within the whole OpenStack community 
so anyone could see what's missing and contribute to it.


At least pointing the document to the NFV wiki page sounds important, provided 
this communication can be done this way (ie. no opt-in list for people looking 
at the doc)

-Sylvain


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


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

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


Re: [openstack-dev] [all][tripleo] New Project - Kolla: Deploy and Manage OpenStack using Kubernetes and Docker

2014-09-24 Thread Alan Kavanagh
Steven
I have to ask what is the motivation and benefits we get from integrating 
Kubernetes into Openstack? Would be really useful if you can elaborate and 
outline some use cases and benefits Openstack and Kubernetes can gain.

/Alan


From: Steven Dake [mailto:sd...@redhat.com]
Sent: September-24-14 7:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tripleo] New Project - Kolla: Deploy and 
Manage OpenStack using Kubernetes and Docker

On 09/24/2014 10:12 AM, Joshua Harlow wrote:
Sounds like an interesting project/goal and will be interesting to see where 
this goes.

A few questions/comments:

How much golang will people be exposed to with this addition?

Joshua,

I expect very little.  We intend to use Kubernetes as an upstream project, 
rather then something we contribute to directly.


Seeing that this could be the first 'go' using project it will be interesting 
to see where this goes (since afaik none of the infra support exists, and 
people aren't likely to familiar with go vs python in the openstack community 
overall).

What's your thoughts on how this will affect the existing openstack container 
effort?

I don't think it will have any impact on the existing Magnum project.  At some 
point if Magnum implements scheduling of docker containers, we may add support 
for Magnum in addition to Kubernetes, but it is impossible to tell at this 
point.  I don't want to derail either project by trying to force them together 
unnaturally so early.


I see that kubernetes isn't exactly a small project either (~90k LOC, for those 
who use these types of metrics), so I wonder how that will affect people 
getting involved here, aka, who has the resources/operators/other... available 
to actually setup/deploy/run kubernetes, when operators are likely still just 
struggling to run openstack itself (at least operators are getting used to the 
openstack warts, a new set of kubernetes warts could not be so helpful).

Yup it is fairly large in size.  Time will tell if this approach will work.

This is an experiment as Robert and others on the thread have pointed out :).

Regards
-steve


On Sep 23, 2014, at 3:40 PM, Steven Dake 
sd...@redhat.commailto:sd...@redhat.com wrote:


Hi folks,

I'm pleased to announce the development of a new project Kolla which is Greek 
for glue :). Kolla has a goal of providing an implementation that deploys 
OpenStack using Kubernetes and Docker. This project will begin as a StackForge 
project separate from the TripleO/Deployment program code base. Our long term 
goal is to merge into the TripleO/Deployment program rather then create a new 
program.



Docker is a container technology for delivering hermetically sealed 
applications and has about 620 technical contributors [1]. We intend to produce 
docker images for a variety of platforms beginning with Fedora 20. We are 
completely open to any distro support, so if folks want to add new Linux 
distribution to Kolla please feel free to submit patches :)



Kubernetes at the most basic level is a Docker scheduler produced by and used 
within Google [2]. Kubernetes has in excess of 100 technical contributors. 
Kubernetes is more then just a scheduler, it provides additional functionality 
such as load balancing and scaling and has a significant roadmap.


The #tripleo channel on Freenode will be used for Kolla developer and user 
communication. Even though we plan to become part of the Deployment program 
long term, as we experiment we believe it is best to hold a separate weekly one 
hour IRC meeting on Mondays at 2000 UTC in #openstack-meeting [3].


This project has been discussed with the current TripleO PTL (Robert Collins) 
and he seemed very supportive and agreed with the organization of the project 
outlined above. James Slagle, a TripleO core developer, has kindly offered to 
liase between Kolla and the broader TripleO community.



I personally feel it is necessary to start from a nearly empty repository when 
kicking off a new project. As a result, there is limited code in the repository 
[4] at this time. I suspect folks will start cranking out a kick-ass 
implementation once the Kolla/Stackforge integration support is reviewed by the 
infra team [5].



The initial core team is composed of Steven Dake, Ryan Hallisey, James Lebocki, 
Jeff Peeler, James Slagle, Lars Kellogg-Sedman, and David Vossel. The core team 
will be reviewed every 6 weeks to add fresh developers.


Please join the core team in designing and inventing this rockin' new 
technology!


Regards
-steve


~~



[1] https://github.com/docker/docker [2] 
https://github.com/GoogleCloudPlatform/kubernetes

[3] https://wiki.openstack.org/wiki/Meetings/Kolla [4] 
https://github.com/jlabocki/superhappyfunshow [5] 
https://review.openstack.org/#/c/122972/



___
OpenStack-dev mailing list

Re: [openstack-dev] [nova] [neutron] Specs for K release

2014-08-28 Thread Alan Kavanagh
How to do we handle specs that have slipped through the cracks and did not make 
it for Juno?
/Alan

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: August-28-14 9:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] Specs for K release

I think it's ok to submit specs for Kilo - mostly because it would be a bit 
pointless submitting them for Juno!

Salvatore

On 28 August 2014 09:26, Kevin Benton 
blak...@gmail.commailto:blak...@gmail.com wrote:
You could just make the kilo folder in your commit and then rebase it once Kilo 
is open.

On Thu, Aug 28, 2014 at 12:07 AM, Andreas Scheuring 
scheu...@linux.vnet.ibm.commailto:scheu...@linux.vnet.ibm.com wrote:
Hi,
is it already possible to submit specs (nova  neutron) for the K
release? Would be great for getting early feedback and tracking
comments. Or should I just commit it to the juno folder?

Thanks,
Andreas


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



--
Kevin Benton

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

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


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
+1, that would be the most pragmatic way to address this, silence has different 
meanings to different people, a response would clarify the ambiguity and 
misunderstanding.
/Alan

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: August-28-14 11:18 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/28/2014 03:02 PM, Jay Pipes wrote:

 I understand your frustration about the silence, but the silence from 
 core team members may actually be a loud statement about where their 
 priorities are.

Or it could be that they haven't looked at it, aren't aware of it, or haven't 
been paying attention.

I think it would be better to make feedback explicit and remove any 
uncertainty/ambiguity.

Chris

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

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


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
I don't think silence ever helps, its better to respond even if it is to 
disagree, one on one with the person.
Alan

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: August-28-14 11:02 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?


On 08/28/2014 04:42 PM, Dugger, Donald D wrote:
 I would contend that that right there is an indication that there's a 
 problem with the process.  You submit a BP and then you have no idea 
 of what is happening and no way of addressing any issues.  If the 
 priority is wrong I can explain why I think the priority should be 
 higher, getting stonewalled leaves me with no idea what's wrong and no 
 way to address any problems.

 I think, in general, almost everyone is more than willing to adjust 
 proposals based upon feedback.  Tell me what you think is wrong and 
 I'll either explain why the proposal is correct or I'll change it to 
 address the concerns.

In many of the Gantt IRC meetings as well as the ML, I and others have 
repeatedly raised concerns about the scheduler split being premature and not a 
priority compared to the cleanup of the internal interfaces around the resource 
tracker and scheduler. This feedback was echoed in the mid-cycle meetup session 
as well. Sylvain and I have begun the work of cleaning up those interfaces and 
fixing the bugs around non-versioned data structures and inconsistent calling 
interfaces in the scheduler and resource tracker. Progress is being made 
towards these things.

 Trying to deal with silence is really hard and really frustrating.
 Especially given that we're not supposed to spam the mailing it's 
 really hard to know what to do.  I don't know the solution but we need 
 to do something.  More core team members would help, maybe something 
 like an automatic timeout where BPs/patches with no negative scores 
 and no activity for a week get flagged for special handling.

Yes, I think flagging blueprints for special handling would be a good thing. 
Keep in mind, though, that there are an enormous number of proposed 
specifications, with the vast majority of folks only caring about their own 
proposed specs, and very few doing reviews on anything other than their own 
patches or specific area of interest.

Doing reviews on other folks' patches and blueprints would certainly help in 
this regard. If cores only see someone contributing to a small, isolated 
section of the code or only to their own blueprints/patches, they generally 
tend to implicitly down-play that person's reviews in favor of 
patches/blueprints from folks that are reviewing non-related patches and 
contributing to reduce the total review load.

I understand your frustration about the silence, but the silence from core team 
members may actually be a loud statement about where their priorities are.

Best,
-jay

 I feel we need to change the process somehow.

 -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph:
 303/443-3786

 -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] 
 Sent: Thursday, August 28, 2014 1:44 PM
 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] 
 [nova] Is the BP approval process broken?

 On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there is a 
 problem here.  For the Gantt project to split out the scheduler there 
 is a crucial BP that needs to be implemented ( 
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP 
 has been rejected and we'll have to try again for Kilo.  My question 
 is did we do something wrong or is the process broken?

 Note that we originally proposed the BP on 4/23/14, went through
 10 iterations to the final version on 7/25/14 and the final version 
 got three +1s and a +2 by 8/5.  Unfortunately, even after reaching 
 out to specific people, we didn't get the second +2, hence the 
 rejection.

 I understand that reviews are a burden and very hard but it seems 
 wrong that a BP with multiple positive reviews and no negative 
 reviews is dropped because of what looks like indifference.

 I would posit that this is not actually indifference. The reason that 
 there may not have been 1 +2 from a core team member may very well 
 have been that the core team members did not feel that the blueprint's 
 priority was high enough to put before other work, or that the core 
 team members did have the time to comment on the spec (due to them not 
 feeling the blueprint had the priority to justify the time to do a 
 full review).

 Note that I'm not a core drivers team member.

 Best, -jay


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

 ___ OpenStack-dev mailing 
 list OpenStack-dev@lists.openstack.org 
 

Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
I share Donald's points here, I believe what would help is to clearly describe 
in the Wiki the process and workflow for the BP approval process and build in 
this process how to deal with discrepancies/disagreements and build timeframes 
for each stage and process of appeal etc.
The current process would benefit from some fine tuning and helping to build 
safe guards and time limits/deadlines so folks can expect responses within a 
reasonable time and not be left waiting in the cold. 
My 2cents!
/Alan

-Original Message-
From: Dugger, Donald D [mailto:donald.d.dug...@intel.com] 
Sent: August-28-14 10:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

I would contend that that right there is an indication that there's a problem 
with the process.  You submit a BP and then you have no idea of what is 
happening and no way of addressing any issues.  If the priority is wrong I can 
explain why I think the priority should be higher, getting stonewalled leaves 
me with no idea what's wrong and no way to address any problems.

I think, in general, almost everyone is more than willing to adjust proposals 
based upon feedback.  Tell me what you think is wrong and I'll either explain 
why the proposal is correct or I'll change it to address the concerns.

Trying to deal with silence is really hard and really frustrating.  Especially 
given that we're not supposed to spam the mailing it's really hard to know what 
to do.  I don't know the solution but we need to do something.  More core team 
members would help, maybe something like an automatic timeout where BPs/patches 
with no negative scores and no activity for a week get flagged for special 
handling.

I feel we need to change the process somehow.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Thursday, August 28, 2014 1:44 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
 I'll try and not whine about my pet project but I do think there is a 
 problem here.  For the Gantt project to split out the scheduler there 
 is a crucial BP that needs to be implemented ( 
 https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP 
 has been rejected and we'll have to try again for Kilo.  My question 
 is did we do something wrong or is the process broken?

 Note that we originally proposed the BP on 4/23/14, went through 10 
 iterations to the final version on 7/25/14 and the final version got 
 three +1s and a +2 by 8/5.  Unfortunately, even after reaching out to 
 specific people, we didn't get the second +2, hence the rejection.

 I understand that reviews are a burden and very hard but it seems 
 wrong that a BP with multiple positive reviews and no negative reviews 
 is dropped because of what looks like indifference.

I would posit that this is not actually indifference. The reason that there may 
not have been 1 +2 from a core team member may very well have been that the 
core team members did not feel that the blueprint's priority was high enough to 
put before other work, or that the core team members did have the time to 
comment on the spec (due to them not feeling the blueprint had the priority to 
justify the time to do a full review).

Note that I'm not a core drivers team member.

Best,
-jay


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

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

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


Re: [openstack-dev] [nova] [neutron] Specs for K release

2014-08-28 Thread Alan Kavanagh
That's a fairly good point Michael, and if that can get correlated to the 
proposed incubation section for that project then I believe this would help 
alleviate a lot of frustration and help folks understand what to expect and 
what are the next steps etc. 
How do we get this formulated and agreed so we can have this approved and 
proceed?
/Alan
-Original Message-
From: Michael Still [mailto:mi...@stillhq.com] 
Sent: August-28-14 6:51 PM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [nova] [neutron] Specs for K release

On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange berra...@redhat.com wrote:
 On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote:
 How to do we handle specs that have slipped through the cracks
 and did not make it for Juno?

 Rebase the proposal so it is under the 'kilo' directory path
 instead of 'juno' and submit it for review again. Make sure
 to keep the ChangeId line intact so people see the history
 of any review comments in the earlier Juno proposal.

Yes, but...

I think we should talk about tweaking the structure of the juno
directory. Something like having proposed, approved, and implemented
directories. That would provide better signalling to operators about
what we actually did, what we thought we'd do, and what we didn't do.

I worry that gerrit is a terrible place to archive the things which
were proposed by not approved. If someone else wants to pick something
up later, its super hard for them to find.

Michael

-- 
Rackspace Australia

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

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


Re: [openstack-dev] [nova] Is the BP approval process broken?

2014-08-28 Thread Alan Kavanagh
+1 my sentiments exactly, and this will actually help folks contribute in a 
more meaningful and productive way.
/Alan

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: August-29-14 12:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

On 08/28/2014 04:01 PM, Joe Gordon wrote:



 On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh 
 alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote:

 I share Donald's points here, I believe what would help is to
 clearly describe in the Wiki the process and workflow for the BP
 approval process and build in this process how to deal with
 discrepancies/disagreements and build timeframes for each stage and
 process of appeal etc.
 The current process would benefit from some fine tuning and helping
 to build safe guards and time limits/deadlines so folks can expect
 responses within a reasonable time and not be left waiting in the cold.


 This is a resource problem, the nova team simply does not have enough 
 people doing enough reviews to make this possible.

All the more reason to make it obvious which reviews are not being addressed in 
a timely fashion.  (I'm thinking something akin to the order screen at a fast 
food restaurant that starts blinking in red and beeping if an order hasn't been 
filled in a certain amount of time.)

Perhaps by making it clear that reviews are a bottleneck this will actually 
help to address the problem.

Chris


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

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


Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

2014-08-25 Thread Alan Kavanagh
That's a fair point Jay. The Czar does sound like a reasonable approach and 
what would be useful and helpful would be to appoint additional PTL's and not 
have the burden of everything falling on one individual which becomes over 
loading after a period of time. In this case, imho it would be useful to have 2 
or more PTL's assigned per project to adjust the workload and have different 
views and assess the sticky points with different views.
/Alan

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: August-25-14 1:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 08/23/2014 06:35 PM, Clint Byrum wrote:
  I agree as well. PTL is a servant of the community, as any good 
 leader is. If the PTL feels they have to drop the hammer, or if an 
 impass is reached where they are asked to, it is because they have 
 failed to get everyone communicating effectively, not because that's their 
 job.

The problem isn't really that teams are not communicating effectively, nor is 
the problem to do with some deficit of a PTL in either putting the hammer down 
or failing to figure out common ground.

The issue in my opinion and my experience is that there are multiple valid ways 
of doing something (say, deployment or metering or making
toast) and the TC and our governing structure has decided to pick winners in 
spaces instead of having a big tent and welcoming different solutions and 
projects into the OpenStack fold. We pick winners and by doing so, we are 
exclusionary, and this exclusivity does not benefit our user community, but 
rather just gives it fewer options.

IMHO, the TC should become an advisory team that recommends to interested 
project teams ways in which they can design and architect their projects to 
integrate well with other projects in the OpenStack community, and design their 
projects for the scale, stability and requirements (such as multi-tenancy) that 
an open cloud software ecosystem demands.

Just my two cents,
-jay


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

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


Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Alan Kavanagh
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: August-19-14 8:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

Hi,

The QoS API extension has lived in Gerrit/been in review for about a year. It's 
gone through revisions, summit design sessions, and for a little while, a 
subteam.

I would like to request incubation in the upcoming incubator, so that the code 
will have a more permanent home where we can collaborate and improve.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Alan Kavanagh
+1
I believe Pedro has a very valid point here, and that is the the community to 
approve the spec and that decision should be respected. It makes sense to 
again clearly denote the process and governance and have this noted on the 
thread Stefano started earlier today. 

/Alan

-Original Message-
From: Pedro Marques [mailto:pedro.r.marq...@gmail.com] 
Sent: August-06-14 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way 
forward


On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 However, it seems to me that the end-goal of the GBP effort is *actually* to 
 provide a higher-layer API to Neutron that would essentially enable 
 proprietary vendors to entirely swap out all of Neutron core for a new set of 
 drivers that spoke proprietary device APIs.
 
 If this is the end-goal, it should be stated more clearly, IMO.

I believe that people should be considered innocent until proven otherwise. Is 
there a reason to believe there is some hidden reason behind this proposal ? It 
seems to me that this is uncalled for.

Neutron allows vendors to speak to proprietary device APIs, it was designed to 
do so, AFAIK. It is also possibly to entirely swap out all of the Neutron 
core... the proponents of the group based policy didn't have to go through so 
much trouble if that was their intent. As far as i know most plugins talk to a 
proprietary API.

I happen to disagree technically with a couple of choices made by this 
proposal; but the blueprint was approved. Which means that i lost the argument, 
or didn't raise it on time, or didn't argue convincingly... regardless of the 
reason, the time to argue about the goal has passed. The decision of the 
community was to approve the spec and that decision should be respected.

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

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


Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

2014-08-03 Thread Alan Kavanagh
+1 I think your suggestions are admirable and would be good if this is taken on 
board, having a timeframe around items would definitely help focus and ensure 
reviews in a timely manner.

/Alan

From: Rudra Rugge [mailto:ru...@contrailsystems.com]
Sent: July-31-14 6:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is 
August 21

Hi Kyle,

I also agree with Mandeep's suggestion of putting a time frame on the lingering 
-2 if the addressed concerns have been taken care of. In my experience also a 
sticky -2 detracts other reviewers from reviewing an updated patch.

Either a time-frame or a possible override by PTL (move to -1) would help make 
progress on the review.

Regards,
Rudra

On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami 
dh...@noironetworks.commailto:dh...@noironetworks.com wrote:
Hi Kyle:

As -2 is sticky, and as there exists a possibility that the original core might 
not get time to get back to re-reviewing his, do you think that there should be 
clearer guidelines on it's usage (to avoid what you identified as dropping of 
the balls)?

Salvatore had a good guidance in a related thread [0], do you agree with 
something like that?



I try to avoid -2s as much as possible. I put a -2 only when I reckon your

patch should never be merged because it'll make the software unstable or

tries to solve a problem that does not exist. -2s stick across patches and

tend to put off other reviewers.
[0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html


Or do you think that 3-5 days after an update that addresses the issues 
identified in the original -2, we should automatically remove that -2? If this 
does not happen often, this process does not have to be automated, just an 
exception that the PTL can exercise to address issues where the original 
reason for -2 has been addressed and nothing new has been identified?


On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery 
mest...@mestery.commailto:mest...@mestery.com wrote:
On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday 
yorik@gmail.commailto:yorik@gmail.com wrote:
 On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery 
 mest...@mestery.commailto:mest...@mestery.com wrote:
 and even less
 possibly rootwrap [3] if the security implications can be worked out.

 Can you please provide some input on those security implications that are
 not worked out yet?
 I'm really surprised to see such comments in some ML thread not directly
 related to the BP. Why is my spec blocked? Neither spec [1] nor code (which
 is available for a really long time now [2] [3]) can get enough reviewers'
 attention because of those groundless -2's. Should I abandon these change
 requests and file new ones to get some eyes on my code and proposals? It's
 just getting ridiculous. Let's take a look at timeline, shall we?

I share your concerns here as well, and I'm sorry you've had a bad
experience working with the community here.

 Mar, 25 - first version of the first part of Neutron code is published at
 [2]
 Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of
 BP (thankful it wasn't -2 yet, so reviews continued)
 Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created;
 Apr, 2 - first version of the second part of Neutron code is published at
 [3];
 May, 16 - first version of Neutron spec is published at [1];
 May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not
 approved yet);
 May, 21 - first part of Neutron code [2] is found generally OK by reviewers;
 May, 21 - first version of Oslo spec is published at [4];
 May, 29 - a version of the second part of Neutron code [3] is published that
 later raises only minor comments by reviewers;
 Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark
 because BP isn't approved yet;
 Jun, 23 - Oslo spec [4] is mostly ironed out;
 Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2;
 Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change
 requests;
 Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception;
 Jul, 31 - I'm getting final decision as follows: Your BP will extremely
 unlikely get to Juno.

 Do you see what I see? Code and spec is mostly finished in May (!) where the
 mostly part is lack of reviewers because of that Mark's -2. And 1 month
 later when all bureaucratic reasons fall off nothing happens. Don't think I
 didn't try to approach Mark. Don't think I didn't approach Kyle on this
 issue. Because I did. But nothing happens and another month passes by and I
 get You know, may be later general response. Noone (but those who knew
 about it originally) even looks at my code for 2 months already because Mark
 doesn't think (I hope he did think) he should lift -2 and I'm getting why
 not wait another 3 months?

 What the hell is that? You don't want to land features that doesn't have
 code 2 weeks before Juno-3, I get 

Re: [openstack-dev] [neutron] Spec Approval Deadline (SAD) has passed, next steps

2014-07-24 Thread Alan Kavanagh
Hi Kyle

I do sympathise and know its not easy to accommodate all BP's, and I know it's 
a difficult job to take these decisions.

May I therefore suggest that anything that gets punted from Juno is ensured 
for high priority and acceptance for Kilo Release ? This means we will have 
those that are not approved ensure they take high priority and guaranteed for 
the next release (Kilo in this case) and send an email to confirm this. 

That way we don't have people feeling constantly disappointed and being pushed 
further down the pecking order, and ensure they are not being demoted and 
support on progressing their work at the next release.

Interested to hear your thoughts on this Kyle and others and feel free to 
suggest an alternatives, I know this is a difficult topic to address but I feel 
it is necessary for us to have this discussion.

Alan

-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: July-24-14 9:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Kyle Mestery
Subject: Re: [openstack-dev] [neutron] Spec Approval Deadline (SAD) has passed, 
next steps

On Thu, Jul 24, 2014 at 5:38 AM, Livnat Peer lp...@redhat.com wrote:
 On 07/21/2014 04:16 PM, Kyle Mestery wrote:
 Hi all!

 A quick note that SAD has passed. We briskly approved a pile of BPs 
 over the weekend, most of them vendor related as low priority, best 
 effort attempts for Juno-3. At this point, we're hugely 
 oversubscribed for Juno-3, so it's unlikely we'll make exceptions for 
 things into
 Juno-3 now.

 I don't plan to open a Kilo directory in the specs repository quite 
 yet. I'd like to first let things settle down a bit with Juno-3 
 before going there. Once I do, specs which were not approved should 
 be moved to that directory where they can be reviewed with the idea 
 they are targeting Kilo instead of Juno.

 Also, just a note that we have a handful of bugs and BPs we're trying 
 to land in Juno-3 yet today, so core reviewers, please focus on those 
 today.

 Thanks!
 Kyle

 [1] https://launchpad.net/neutron/+milestone/juno-2



 Hi Kyle,

 Do we have guidelines for what can/should qualify as an exception?
 I see some exception requests and I would like to understand what 
 criteria they should meet in order to qualify as an exception.

 Thanks ,Livnat

Salvatore sent an email to the list [1] which perfectly describes the types of 
things we'll allow exceptions for. To be honest, we're already 4x 
oversubscribed for Juno-3 [2] as it is, and it's unlikely even 2/3 of the 
existing approved BPs will land code. That's one reason it's hard for me to 
think of approving existing ones, especially considering how close we are to 
feature freeze and the end of Juno [3].

Thanks,
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/040969.html
[2] https://launchpad.net/neutron/+milestone/juno-3
[3] https://wiki.openstack.org/wiki/Juno_Release_Schedule


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



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

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

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


Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron

2014-07-24 Thread Alan Kavanagh
Hi Kyle

Thanks for taking the time for writing this note also I know this is not an 
easy discussion and not something being a matter of waving hands or fingers. 
I believe what you have stated is well understood, though the main points I 
raised seems to be missing from this Neutron Policies wiki (interested to see 
if other projects have addressed and document this) such as (1) How to address 
when a contribution gets punted, (2) how to address BP's that are not 
progressing, (3)how to ensure that in the even a given BP/patch/etc gets no 
reviews how to address these. I feel this is around the Governance than just 
about the procedures and processes.

Also, having more Core reviewers from different companies would also go a long 
way to helping to ensure that the different views and expectations are 
addressed community wide. I agree on the need to groom core reviewers, I guess 
what I miss here is the time it takes and how large would the Core Team grow, 
are their limits?

Kyle you are doing an amazing job, full commend you on that and believe you are 
definitely going beyond here to help out and its most appreciated. It would be 
good to get these points ironed out as they are lingering and having them 
addressed will help us going forward.

BR
Alan

-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: July-24-14 11:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [not-only-neutron] How to Contribute 
upstream in OpenStack Neutron

I've received a lot of emails lately, mostly private, from people who feel they 
are being left out of the Neutron process. I'm unsure if other projects have 
people who feel this way, thus the uniquely worded subject above. I wanted to 
broadly address these concerns with this email.

One thing I'd like to reiterate for people here, publicly on the list, is that 
there is no hidden agendas in Neutron, no political machines in the background 
working. As PTL, I've tried to be as transparent as possible. The honest 
reality is that if you want to have influence in Neutron or even in OpenStack 
in general, get involved upstream. Start committing small patches. Start 
looking at bugs. Participate in the weekly meetings. Build relationships 
upstream. Work across projects, not just Neutron. None of this is specific to 
Neutron or even OpenStack, but in fact is how you work in any upstream Open 
Source community.

I'd also like to address the add more core reviewers to solve all these 
problems angle. While adding more core reviewers is a good thing, we need to 
groom core reviewers and meld them into the team.
This takes time, and it's something we in Neutron actively work on.
The process we use is documented here [1].

I'd also like to point out that one of the things I've tried to do in Neutron 
as PTL during the Juno cycle is document as much of the process around working 
in Neutron. That is all documented on this wiki page here [2]. Feedback on this 
is most certainly welcome.

I'm willing to help work with anyone who wants to contribute more to Neutron. I 
spend about half of my time doing just this already, between reviews, emails, 
and IRC conversations. So please feel free to find me on IRC (mestery on 
Freenode), on the ML, or even just use this email address.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/NeutronCore
[2] https://wiki.openstack.org/wiki/NeutronPolicies

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

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


Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron

2014-07-24 Thread Alan Kavanagh


-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info] 
Sent: July-24-14 12:27 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute 
upstream in OpenStack Neutron

On 07/24/2014 11:50 AM, Alan Kavanagh wrote:
 Hi Kyle
 
 Thanks for taking the time for writing this note also I know this is not an 
 easy discussion and not something being a matter of waving hands or 
 fingers. I believe what you have stated is well understood, though the main 
 points I raised seems to be missing from this Neutron Policies wiki 
 (interested to see if other projects have addressed and document this) such 
 as (1) How to address when a contribution gets punted, (2) how to address 
 BP's that are not progressing, (3)how to ensure that in the even a given 
 BP/patch/etc gets no reviews how to address these. I feel this is around the 
 Governance than just about the procedures and processes.
 
Hi Alan,

Let me add some thoughts here.

The listed items mostly boil down to communication.
Are those contributors with punted contributions in IRC channels? Do the attend 
the program weekly meeting? Many punted contributions, be they patches or 
blueprints, have the status they do because noone can find who the owners of 
these contributions are to ask them to fill in the gaps so reviewers even know 
what is being proposed.

AK-- to my understanding our folks have attended the weekly meetings as often 
as possible.

Now if folks don't know what channels to use or how to use IRC then that is an 
issue the we need to address, but having people available so reviewers can ask 
them about their offerings is a great first step and no I personally don't 
think that this is a governance issue.

If you want to find out what items are governance issues, do attend the TC 
weekly meeting:
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee and be sure to 
read the logs of past meetings:
http://eavesdrop.openstack.org/meetings/tc/

 Also, having more Core reviewers from different companies would also go a 
 long way to helping to ensure that the different views and expectations are 
 addressed community wide. I agree on the need to groom core reviewers, I 
 guess what I miss here is the time it takes and how large would the Core Team 
 grow, are their limits?
 
I agree that having diversity in core reviewers is very important. Core 
reviewers are those reviewers that have put in the time to do the reviews to 
demonstrate their commitment to the program. They also have enough experience 
with the program to gain the trust of other core reviewers. How long it takes 
is based on the individual reviewer. As for how large the team can grow, it is 
based on how many people want to do the work that it takes to gain that 
knowledge and experience.
AK-- It's a suggestion that works in other communities.
In short, it is up to the potential core reviewer.

Thanks Alan,
Anita.

 Kyle you are doing an amazing job, full commend you on that and believe you 
 are definitely going beyond here to help out and its most appreciated. It 
 would be good to get these points ironed out as they are lingering and having 
 them addressed will help us going forward.
 
 BR
 Alan
 
 -Original Message-
 From: Kyle Mestery [mailto:mest...@mestery.com]
 Sent: July-24-14 11:10 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron] [not-only-neutron] How to 
 Contribute upstream in OpenStack Neutron
 
 I've received a lot of emails lately, mostly private, from people who feel 
 they are being left out of the Neutron process. I'm unsure if other projects 
 have people who feel this way, thus the uniquely worded subject above. I 
 wanted to broadly address these concerns with this email.
 
 One thing I'd like to reiterate for people here, publicly on the list, is 
 that there is no hidden agendas in Neutron, no political machines in the 
 background working. As PTL, I've tried to be as transparent as possible. The 
 honest reality is that if you want to have influence in Neutron or even in 
 OpenStack in general, get involved upstream. Start committing small patches. 
 Start looking at bugs. Participate in the weekly meetings. Build 
 relationships upstream. Work across projects, not just Neutron. None of this 
 is specific to Neutron or even OpenStack, but in fact is how you work in any 
 upstream Open Source community.
 
 I'd also like to address the add more core reviewers to solve all these 
 problems angle. While adding more core reviewers is a good thing, we need to 
 groom core reviewers and meld them into the team.
 This takes time, and it's something we in Neutron actively work on.
 The process we use is documented here [1].
 
 I'd also like to point out that one of the things I've tried to do in Neutron 
 as PTL during the Juno cycle is document as much of the process around 
 working in Neutron. That is all documented

Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions

2014-07-23 Thread Alan Kavanagh
I find it really hard to comprehend the level of transparency here, or lack 
thereof. It seems to me that when we want to get features into a given release 
we are at the mercy of others and while I do understand that the core team cant 
approve and review everything we also can not wait for another release or 
another release for features that would be of importance for Openstack in 
general. Its very discouraging for other members of the community to have 
certain features which are important for them but maybe not for others being 
demoted and pushed further out.

Also, having a core set of people vote on what is essential for one release to 
the next to me is not very transparent and not very democratic way of working, 
it supports only those who want to guide the community one way. 
While I do see a need for ensuring priority, setting of priority to me is again 
not transparent imho. Also, having folks comment really late on BP's that have 
been progressing and folks working hard to progress them only for at the last 
minute to get it demoted and then moved to another track I find this not a 
nice way to work in the community, politics are a way of life but if they are 
going to be used as the rule for Openstack and its releases and a way for 
others to govern within the community I find this really disappointing.

If we have more work being put on the table, then more Core members would 
definitely go a long way with assisting this, we cant wait for folks to be 
reviewing stuff as an excuse to not get features landed in a given release.

I know this will strike a cord with some, but I see too much going on that 
makes me very disappointed so I hope by reaching out others will take note to 
help us improve this process, perhaps this is something the Openstack Board can 
take note of and jump in and try and resolve.

Alan

-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: July-23-14 9:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions

On Wed, Jul 23, 2014 at 7:28 AM, Salvatore Orlando sorla...@nicira.com wrote:
 I'm sure it is not news to anyone that we already have approved a too 
 many specifications for Juno-3. The PTL made clear indeed that Low priority
 blueprints are considered best effort.

 However, this already leaves us with 23 medium to high specifications 
 to merge in Juno-3. This is already quite close to what the core team 
 can handle, considering history from previous releases and the fact 
 that there are 3 very big items in the list (new LB APIs, distributed 
 router, and group policies).

 I've counted already at least 7 requests for spec freeze exceptions on 
 the mailing list, and it is likely more will come. In order to limit 
 oversubscribing, I would suggest to exclude freeze exceptions requests 
 for items which are not:
 - targeting stability and scalability for Neutron FOSS framework
 - have a community interest. By that I do not mean necessarily 
 targeting the FOSS bits, but necessarily have support and interest 
 from a number of teams of neutron contributors.

 I don't want to be evil to contributors, but I think it is better to 
 be clear now rather than arriving at the end of Juno-3 and having to 
 tell contributors that unfortunately we were not able to give their 
 patches enough review cycles.

Thanks for sending this out Salvatore. We are way oversubscribed, and at this 
point, I'm in agreement on not letting any new exceptions which do not fall 
under the above guidelines. Given how much is already packed in there, this 
makes the most sense.

Thanks,
Kyle

 Salvatore


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


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

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


Re: [openstack-dev] NFV in OpenStack use cases and context

2014-06-12 Thread Alan Kavanagh
Hi Ramki

Really like the smart scheduler idea, we made a couple of blueprints that are 
related to ensuring you have the right information to build a constrained based 
scheduler. I do however want to point out that this is not NFV specific but is 
useful for all applications and services of which NFV is one. 

/Alan

-Original Message-
From: ramki Krishnan [mailto:r...@brocade.com] 
Sent: June-10-14 6:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
Subject: Re: [openstack-dev] NFV in OpenStack use cases and context

Hi Steve,

Forgot to mention, the Smart Scheduler (Solver Scheduler) enhancements for 
NFV: Use Cases, Constraints etc. is a good example of an NFV use case deep 
dive for OpenStack.

https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/document/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlbclagujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118538f

Thanks,
Ramki

-Original Message-
From: ramki Krishnan
Sent: Tuesday, June 10, 2014 3:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
Subject: RE: NFV in OpenStack use cases and context

Hi Steve,

We are have OpenStack gap analysis documents in ETSI NFV under member only 
access. I can work on getting public version of the documents (at least a 
draft) to fuel the kick start.

Thanks,
Ramki

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com]
Sent: Tuesday, June 10, 2014 12:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: Stephen Wong stephen.kf.w...@gmail.com
 
 - Original Message -
  From: Stephen Wong stephen.kf.w...@gmail.com
  To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com,
  OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org
  
  Hi,
  
  Perhaps I have missed it somewhere in the email thread? Where is 
  the use case = bp document we are supposed to do for this week? Has 
  it been created yet?
  
  Thanks,
  - Stephen
 
 Hi,
 
 Itai is referring to the ETSI NFV use cases document [1] and the 
 discussion is around how we distill those - or a subset of them - into 
 a more consumable format for an OpenStack audience on the Wiki. At 
 this point I think the best approach is to simply start entering one 
 of them (perhaps #5) into the Wiki and go from there. Ideally this 
 would form a basis for discussing the format etc.
 
 Thanks,
 
 Steve
 
 [1]
 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV
 001v010101p.pdf

To try and kick start things I have created a table on the wiki [1] based on 
the *DRAFT* NFV Performance  Portability Best Practises document [2]. This 
really lists workload types rather than specific applications, although I've 
put in an examples column we can populate with them.

I find it a useful way to quickly break down some of the characteristics of NFV 
applications at a glance. What do people think of this as something to start 
with? Remember, it's a wiki! So anyone is welcome to either expand the table or 
start adding more concrete user stories (e.g. around ETSI NFV use case number 5 
that Itai and I have been referring to, or any other VNF for that matter) in 
this section (we may/want need to create a separate page but for now it seems 
OK to get started here).

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases
[2] 
http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20%20Portability%20Best%20Practises.pdf

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

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

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


Re: [openstack-dev] NFV in OpenStack use cases and context

2014-06-12 Thread Alan Kavanagh
Hi Yathi

The BP's I am referring too are the nic state aware scheduling 
(https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling ) and 
the PCI device capability aware scheduling (appears to have been deleted, will 
upload it again). I can see NFV utilising this for some apps we have the same 
view point on this too, though my main gripe on this was its applicable to 
others. 

/Alan


-Original Message-
From: Yathiraj Udupi (yudupi) [mailto:yud...@cisco.com] 
Sent: June-12-14 2:53 PM
To: Alan Kavanagh
Cc: OpenStack Development Mailing List (not for usage questions); Debojyoti 
Dutta
Subject: Re: [openstack-dev] NFV in OpenStack use cases and context

Hi Alan, 

Our Smart (Solver) Scheduler blueprint
(https://blueprints.launchpad.net/nova/+spec/solver-scheduler ) has been in the 
works in the Nova community since late 2013.  We have demoed at the Hong Kong 
summit, as well as the Atlanta summit,  use cases using this smart scheduler 
for better, optimized resource placement with complex constrained scenarios.  
So to let you know this work was started as a smart way of doing scheduling, 
applicable in general and not limited to NFV.  Currently we feel NFV is a 
killer app for driving this blueprint and work ahead, however is applicable for 
all kinds of resource placement scenarios. 

We will be very interested in finding out more about your blueprints that you 
are referring to here, and see how it can be integrated as part of our future 
roadmap. 

Thanks,
Yathi. 


On 6/12/14, 10:55 AM, Alan Kavanagh alan.kavan...@ericsson.com wrote:

Hi Ramki

Really like the smart scheduler idea, we made a couple of blueprints 
that are related to ensuring you have the right information to build a 
constrained based scheduler. I do however want to point out that this 
is not NFV specific but is useful for all applications and services of 
which NFV is one.

/Alan

-Original Message-
From: ramki Krishnan [mailto:r...@brocade.com]
Sent: June-10-14 6:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
Subject: Re: [openstack-dev] NFV in OpenStack use cases and context

Hi Steve,

Forgot to mention, the Smart Scheduler (Solver Scheduler) enhancements 
for NFV: Use Cases, Constraints etc. is a good example of an NFV use 
case deep dive for OpenStack.

https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/docu
men 
t/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlb
cla 
gujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2Bx
Y2b 
qaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRz
GZn
z4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118
538
f

Thanks,
Ramki

-Original Message-
From: ramki Krishnan
Sent: Tuesday, June 10, 2014 3:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux; Norival Figueira
Subject: RE: NFV in OpenStack use cases and context

Hi Steve,

We are have OpenStack gap analysis documents in ETSI NFV under member 
only access. I can work on getting public version of the documents (at 
least a draft) to fuel the kick start.

Thanks,
Ramki

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com]
Sent: Tuesday, June 10, 2014 12:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and 
context

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: Stephen Wong stephen.kf.w...@gmail.com
 
 - Original Message -
  From: Stephen Wong stephen.kf.w...@gmail.com
  To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com,
  OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  
  Hi,
  
  Perhaps I have missed it somewhere in the email thread? Where 
  is the use case = bp document we are supposed to do for this week? 
  Has it been created yet?
  
  Thanks,
  - Stephen
 
 Hi,
 
 Itai is referring to the ETSI NFV use cases document [1] and the 
 discussion is around how we distill those - or a subset of them - 
 into a more consumable format for an OpenStack audience on the Wiki. 
 At this point I think the best approach is to simply start entering 
 one of them (perhaps #5) into the Wiki and go from there. Ideally 
 this would form a basis for discussing the format etc.
 
 Thanks,
 
 Steve
 
 [1]
 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NF
 V
 001v010101p.pdf

To try and kick start things I have created a table on the wiki [1] 
based on the *DRAFT* NFV Performance  Portability Best Practises document [2].
This really lists workload types rather than specific applications, 
although I've put in an examples column we can populate with them.

I find it a useful way to quickly break down some of the 
characteristics of NFV applications

Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

2014-06-11 Thread Alan Kavanagh
More than happy to help out, I think we are on a good path by focusing on the 
current BP's we have. I will not make it to IRC meeting today, but will comment 
afterwords.
I think Adrian also pointed out one other point just to put on the table so we 
set the tone and scope accordingly, that is some of these BP's while being NFV 
related and not NFV essential but also benefit the generic cases too imho. 
For example the port-mirroring is in some cases a feature some NFV services 
would utilise (lots of strange stuff in the wild :-) ) this and others would 
never need this.

Alan

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: June-11-14 6:54 AM
To: Alan Kavanagh
Cc: OpenStack Development Mailing List (not for usage questions); ITAI 
MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

- Original Message -
 From: Alan Kavanagh alan.kavan...@ericsson.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org, Steve
 
 Hi Adrian et.al
 
 Adrian thanks for taking a stab at this, I think the use case list is 
 a little long but good to put on the map. One item I would point out 
 is that its fairly difficult and perhaps misleading to map the 
 blueprints list to the ETSI NFV use case, for example you can argue 
 that based on configuration and deployment of say vCPE some may require VLAN 
 Trunking, others will not.
 Similarly for SR-IOV support when you a Transport node that consumes 
 the total CPU and NIC available on the host and would in some cases be 
 provisioned on bare metal SR-IOV is not a required feature set. Also 
 some of these would not require anything in addition to support apart 
 from what we already have in Openstack, for example in the case of CDN 
 do we needed additional feature sets, imho apart from the nice state 
 aware scheduling and VM allocation based on specific attributes 
 required (specific PCI device type, topology based placement, on board 
 SSD, etc) and  IP end point for delivery, do we need anything else beyond 
 this?

 Perhaps what might be more beneficial is to ensure we can deploy a 
 given app in the current OS distro and identify the necessary 
 configuration attributes we would need to expose, would that be a good 
 way forward? Interested to hear from others on this front. A 
 suggestion, is we start with use cases 2 and 7 that are more well 
 defined and simpler to address and this is where I believe Itai had a 
 good statement of “not boiling the ocean”, lets start with some simple 
 ones that are well defined and well known and don’t have too many intrinsic 
 configurations.
 
 /Alan


Yes, thanks all - it's great to see plenty of people putting forward their 
thoughts on this :). I agree that it is somewhat problematic to map the ETSI 
NFV use cases as is directly to the list of blueprints, finding an 
appropriate way to distil them into the hard requirements of the most minimal 
configurations of each is key. I definitely agree concentrating on doing this 
for a subset of them that are particularly well defined first is the best way 
to start off without spreading our efforts too thinly.

Thanks,

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


Re: [openstack-dev] NFV in OpenStack use cases and context

2014-06-11 Thread Alan Kavanagh
Thanks Martin

Perhaps I am missing this a little bit, but in relation to the control plane 
and signal processing, how do you see that fitting into requirements we would 
need in Openstack? If I may jump a little bit here, the only one I can see is 
making sure the app is installed on a given PCI device with a given set of 
necessary capabilities and driver types which is a BP Ericsson+Intel submitted 
for PCI/e device discovery and registration and this is applicable to a whole 
range of apps and services. 

Do you see others that are needed?

/Alan

-Original Message-
From: Martin Taylor [mailto:martin.tay...@metaswitch.com] 
Sent: June-11-14 4:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux
Subject: Re: [openstack-dev] NFV in OpenStack use cases and context

I've added examples in data plane, control plane and signal processing that 
relate to ETSI use case #5 (IMS).

Martin

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com]
Sent: 10 June 2014 20:06
To: OpenStack Development Mailing List (not for usage questions)
Cc: Chris Wright; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

- Original Message -
 From: Steve Gordon sgor...@redhat.com
 To: Stephen Wong stephen.kf.w...@gmail.com
 
 - Original Message -
  From: Stephen Wong stephen.kf.w...@gmail.com
  To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com,
  OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org
  
  Hi,
  
  Perhaps I have missed it somewhere in the email thread? Where is 
  the use case = bp document we are supposed to do for this week? Has 
  it been created yet?
  
  Thanks,
  - Stephen
 
 Hi,
 
 Itai is referring to the ETSI NFV use cases document [1] and the 
 discussion is around how we distill those - or a subset of them - into 
 a more consumable format for an OpenStack audience on the Wiki. At 
 this point I think the best approach is to simply start entering one 
 of them (perhaps #5) into the Wiki and go from there. Ideally this 
 would form a basis for discussing the format etc.
 
 Thanks,
 
 Steve
 
 [1]
 http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV
 001v010101p.pdf

To try and kick start things I have created a table on the wiki [1] based on 
the *DRAFT* NFV Performance  Portability Best Practises document [2]. This 
really lists workload types rather than specific applications, although I've 
put in an examples column we can populate with them.

I find it a useful way to quickly break down some of the characteristics of NFV 
applications at a glance. What do people think of this as something to start 
with? Remember, it's a wiki! So anyone is welcome to either expand the table or 
start adding more concrete user stories (e.g. around ETSI NFV use case number 5 
that Itai and I have been referring to, or any other VNF for that matter) in 
this section (we may/want need to create a separate page but for now it seems 
OK to get started here).

Thanks,

Steve

[1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases
[2] 
http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20%20Portability%20Best%20Practises.pdf

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

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

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


Re: [openstack-dev] NFV BoF at design summit

2014-05-22 Thread Alan Kavanagh
+1

I believe the main point is not to confuse what we is need on the Hypervisor 
and networking but focus on what we need Openstack to support to be a robust 
and reliable system, for example most systems aim for 5 9's due to various 
requirements but what they really want to aim for us predictable and 
deterministic systems.

I think to be fair to Kevins email, the focus should be that when we issue a 
port connection that we guanrantee its connected and we have a way to validate 
that. 

Carrier grade is not just about system availability/uptime but also that we can 
ensure when a call for an object/resource is requested we can ensure its 
99.999% of the time going to be handled and not dropped etc etc etc.

Alan

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: May-22-14 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit



- Original Message -
 From: Kevin Benton blak...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Thursday, May 22, 2014 2:48:37 AM
 Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
 
 3. OpenStack itself should ( its own Compute Node/L3/Routing,  
 Controller
 )  have (5 nine capable) reliability.
 
 Can you elaborate on this a little more? Reliability is pretty 
 deployment specific (e.g. database chosen, number of cluster members, 
 etc). I'm sure nobody would disagree that OpenStack should be 
 reliable, but without specific issues to address it doesn't really give us a 
 clear target.
 
 Thanks,
 Kevin Benton

I think this comment applies equally to the other items listed. There seemed to 
be agreement at the BoF that one of our key tasks/challenges is to boil down 
such high level NFV requirements to create actionable feature 
requests/proposals in the context of OpenStack.

Thanks,

Steve

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

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


Re: [openstack-dev] Link to patch/review for allowing instances to receive vlan tagged traffic

2014-05-22 Thread Alan Kavanagh
Hi Steven

More than happy to help out here: The BP in question is this, patches have been 
submitted 3 weeks ago by Erik Moe: 
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms 
https://review.openstack.org/#/c/92541/ 
This is a generic feature a lot of Telco traffic nodes have and even non telco 
nodes too ;-) so it’s a great feature to have supported.
Alan

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: May-22-14 2:05 PM
To: Alan Kavanagh; Balázs Gibizer
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: [NFV][Neutron] Link to patch/review for allowing instances to receive 
vlan tagged traffic

Hi Alan/Balazs,

In one of the NFV BoF sessions in Atlanta one of you (I assume one of you 
anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a 
patch to Neutron which would allow instances to use tagged vlan traffic. Do you 
happen to have a link handy to the review for this?

Thanks in advance,

Steve

[1] https://etherpad.openstack.org/p/juno-nfv-bof
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic

2014-05-22 Thread Alan Kavanagh
Yes that’s the one Yi, thanks ;-)
/Alan

From: Yi Sun [mailto:beyo...@gmail.com]
Sent: May-22-14 2:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Alan Kavanagh; Balázs Gibizer
Subject: Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing 
instances to receive vlan tagged traffic

Is this the one?
https://review.openstack.org/#/c/92541/

On Thu, May 22, 2014 at 11:04 AM, Steve Gordon 
sgor...@redhat.commailto:sgor...@redhat.com wrote:
Hi Alan/Balazs,

In one of the NFV BoF sessions in Atlanta one of you (I assume one of you 
anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a 
patch to Neutron which would allow instances to use tagged vlan traffic. Do you 
happen to have a link handy to the review for this?

Thanks in advance,

Steve

[1] https://etherpad.openstack.org/p/juno-nfv-bof

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



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


Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

2014-05-22 Thread Alan Kavanagh
Hi 

Just wanted to comment on some points below inline.

/Alan

-Original Message-
From: A, Keshava [mailto:keshav...@hp.com] 
Sent: May-22-14 2:25 AM
To: Kyle Mestery; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

Hi

In my opinion the first and foremost requirement for NFV ( which is from 
carrier class ) is 99.9 ( 5 nines ) reliability.
If we want OpenStack architecture to scale to Carrier class below are basic 
thing we need to address.

1. There should be a framework from open-stack to support 5 nine level 
reliability  to Service/Tennant-VM . ? ( Example for Carrier Class NAT Service/ 
SIP Service/HLR/VLR service/BRAS service)
AK-- I believe what is important is for Openstack to support various degrees 
of configurations for a given tenant network. The reliability of the network is 
outside of Openstack, but where Openstack plays a role here imho is for check 
and validation of the network when its been provisioned and configured. 
Similarly for VM to ensure we have sufficient check and validation 
(watchdogs/event call backs etc etc) so that we can expose faults and act on 
them.

2. They also should be capable of 'In-service up gradation (ISSU) without 
service disruption.
AK-- Fully agree, its imperative to be able to upgrade Openstack without any 
service interruption.

3. OpenStack itself should ( its own Compute Node/L3/Routing,  Controller )  
have (5 nine capable) reliability.
AK-- If we are referring to Openstack controllers/agents/db's etc then yes 
makes perfect sense, I would however stop short on saying you can achieve 5 
nine's in various ways and its typically up to the vendors themselves how they 
want to implement this even in OS.

If we can provide such of infrastructure to NFV then we think of adding rest of 
requirement .

Let me know others/NFv people opinion for the same.



Thanks  regards,
Keshava.A

-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Monday, May 19, 2014 11:49 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

On Mon, May 19, 2014 at 1:44 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:
 I think the Service VM discussion resolved itself in a way that 
 reduces the problem to a form of NFV - there are standing issues using 
 VMs for services, orchestration is probably not a responsibility that 
 lies in Neutron, and as such the importance is in identifying the 
 problems with the plumbing features of Neutron that cause 
 implementation difficulties.  The end result will be that VMs 
 implementing tenant services and implementing NFV should be much the 
 same, with the addition of offering a multitenant interface to Openstack 
 users on the tenant service VM case.

 Geoff Arnold is dealing with the collating of information from people 
 that have made the attempt to implement service VMs.  The problem 
 areas should fall out of his effort.  I also suspect that the key 
 points of NFV that cause problems (for instance, dealing with VLANs 
 and trunking) will actually appear quite high up the service VM list as well.
 --
There is a weekly meeting for the Service VM project [1], I hope some 
representatives from the NFB sub-project can make it to this meeting and 
participate there.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Meetings/ServiceVM

 Ian.



 On 18 May 2014 20:01, Steve Gordon sgor...@redhat.com wrote:

 - Original Message -
  From: Sumit Naiksatam sumitnaiksa...@gmail.com
 
  Thanks for initiating this conversation. Unfortunately I was not 
  able to participate during the summit on account of overlapping sessions.
  As has been identified in the wiki and etherpad, there seem to be 
  obvious/potential touch points with the advanced services'
  discussion we are having in Neutron [1]. Our sub team, and I, will 
  track and participate in this NFV discussion. Needless to say, we 
  are definitely very keen to understand and accommodate the NFV 
  requirements.
 
  Thanks,
  ~Sumit.
  [1] https://wiki.openstack.org/wiki/Neutron/AdvancedServices

 Yes, there are definitely touch points across a number of different 
 existing projects and sub teams. The consensus seemed to be that 
 while a lot of people in the community have been working in 
 independent groups on advancing the support for NFV use cases in 
 OpenStack we haven't necessarily been coordinating our efforts 
 effectively. Hopefully having a cross-project sub team will allow us to do 
 this.

 In the BoF sessions we started adding relevant *existing* blueprints 
 on the wiki page, we probably need to come up with a more robust way 
 to track these from launchpad :). Further proposals will no doubt 
 need to be built out from use cases as we discuss them further:

 https://wiki.openstack.org/wiki/Meetings/NFV

 Feel free to add any blueprints from the Advanced 

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

2014-05-15 Thread Alan Kavanagh
+1 can we reschedule to push this forward Chris please?

Alan

From: Stephen Wong [mailto:s3w...@midokura.com]
Sent: May-15-14 10:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: iawe...@cisco.com
Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

Hi Chris,

A good number of people involved in Neutron advanced service / group-policy 
/ individual services subteams will be at the Group Policy conference session 
(at 1:30pm). Is it possible to reschedule this to a different time?

Thanks,
- Stephen

On Wed, May 14, 2014 at 10:06 AM, Chris Wright 
chr...@redhat.commailto:chr...@redhat.com wrote:
Thursday at 1:30 PM in the Neutron Pod we'll do
an NFV BoF.  If you are at design summit and
interested in Neutron + NFV please come join us.

thanks,
-chris

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

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


Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

2014-05-08 Thread Alan Kavanagh
+1 would be interested.

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: May-06-14 12:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking 
pod at the design summit?

For those attending, to discuss the QoS API current status?

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

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


Re: [openstack-dev] [Neutron] Flavor(?) Framework

2014-04-23 Thread Alan Kavanagh
Suggest “service-type” Eugene.

/Alan

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: April-23-14 11:05 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Flavor(?) Framework

Hi neutrons,

A quick question of the ^^^
I heard from many of you that a term 'flavor' is undesirable, but so far there 
were no suggestions for the notion that we are going to introduce.
So please, suggest you name for the resource.
Names that I've been thinking of:
 - Capability group
 - Service Offering

Thoughts?

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


Re: [openstack-dev] [Neutron] Flavor(?) Framework

2014-04-23 Thread Alan Kavanagh
Think that's a good idea Jay
A slight twist perhaps: Network Service Type 

/Alan 

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: April-23-14 11:29 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework

On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote:
 Thanks, that can be an option.

 Just wondering, can we find a single name?

service type? :)

Oh, I guess that's taken. Well, we could always rename the existing service 
type to service class or service family.

Best,
-jay



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

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


Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

2014-04-16 Thread Alan Kavanagh
I think Ascii diagrams do make sense if the Blueprint is a major architecture 
input and will be long lived through many Os cycles, if it's a small short 
feature and the diagram is useful to describe the architecture then I think its 
overly painful, speaking from experience!

Alan

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: April-16-14 1:19 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack][nova][specs] Where to store images 
used in the spec

On 04/16/2014 12:55 PM, Russell Bryant wrote:
 On 04/16/2014 12:42 PM, Kevin Benton wrote:
 The only downside to putting it on the wiki is that it no longer has 
 a shared fate with the specification in the repo. If someone deletes 
 it or replaces it on the wiki, information for the spec is lost. 
 External connectivity is also required just to view a template as well.
 
 Yeah, that's right. I'd honestly really prefer simple ascii diagrams 
 in almost all cases anyway.  Requiring an external diagram should be a 
 rare exception, not the rule, IMO.
 

After some additional discussion on this topic on IRC, I really think we should 
start by requiring diagrams in ASCII and see if that becomes overly painful.

Proposed update to the template regarding this topic here:
https://review.openstack.org/88028

--
Russell Bryant

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

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


Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-16 Thread Alan Kavanagh
Tend to agree Nachi, that would be my preference, especially when the diagrams 
are fairly complex which is the case most of the time in Neutron. However if 
the BP is long lived then I think it makes sense to use ASCII, but if its short 
for a small feature to be included in next release then I agree the simplest 
and quickest way is a better use of our time.

/Alan

-Original Message-
From: Nachi Ueno [mailto:na...@ntti3.com] 
Sent: April-16-14 3:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Hi folks

I don't think to use ASCII digrams is good idea because it is hard to 
maintenance  update  diagrams..
so I would like to recommend Blockdiag  Netdiag which are plugins for sphinx.

Blockdiag
http://blockdiag.com/en/blockdiag/

blockdiag {
   A - B - C - D;
   A - E - F - G;
}

will be
http://blockdiag.com/en/_images/blockdiag-69b48ddf499e79e437fbdf9f0e767e365f846d7a.png

(see more example
http://blockdiag.com/en/blockdiag/examples.html )

or you can try online http://blockdiag.appspot.com/

NetDiag
http://blockdiag.com/en/nwdiag/

nwdiag {
  network dmz {
  address = 210.x.x.x/24

  web01 [address = 210.x.x.1];
  web02 [address = 210.x.x.2];
  }
  network internal {
  address = 172.x.x.x/24;

  web01 [address = 172.x.x.1];
  web02 [address = 172.x.x.2];
  db01;
  db02;
  }
}

will be

http://blockdiag.com/en/_images/nwdiag-472a0e8ead9b236d7d929e645767514615bb2392.png

try
http://blockdiag.appspot.com/nwdiag/

http://blockdiag.com/en/nwdiag/nwdiag-examples.html

We have more diagrams can be generated

Activity diagram
http://blockdiag.appspot.com/actdiag/

Sequence diagram
http://blockdiag.appspot.com/seqdiag/

Best
Nachi

2014-04-16 10:42 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
 On Wed, Apr 16, 2014 at 12:23 PM, Russell Bryant rbry...@redhat.com wrote:
 On 04/16/2014 09:51 AM, Russell Bryant wrote:
 On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
 if the image you're adding is a diagram, I would think about 
 asciiflow.com http://asciiflow.com first!

 In all seriousness, I think that's a very nice solution for simple 
 diagrams.  :-)

 For other diagrams, I wonder if it makes sense to just upload them 
 to the wiki and include links to them from the spec using the image 
 directive.


 Another thread got started on this topic for Nova.

 I put up a proposal to require ASCII digrams for nova-specs here:

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

 Great idea! I've done the same for neutron-specs here:

 https://review.openstack.org/88037


 --
 Russell Bryant

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

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

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

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


Re: [openstack-dev] Operators Design Summit ideas for Atlanta

2014-04-08 Thread Alan Kavanagh
Hi Steve

I believe this is a good idea, and what would also be good is to get input from 
the Telco Cloud Providers who run and view networks much differently that the 
traditional enterprise/hosting companies and the type of services and 
Configuration Deployment models are very differently.  The Telco services is 
something Openstack clearly need help in understanding.

/Alan

-Original Message-
From: Steven Hardy [mailto:sha...@redhat.com] 
Sent: April-08-14 5:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Operators  Design Summit ideas for Atlanta

On Fri, Mar 28, 2014 at 03:01:30PM +0800, Tom Fifield wrote:
 Thanks to those projects that responded. I've proposed sessions in 
 swift, ceilometer, tripleO and horizon.

I just created a session for Heat:

http://summit.openstack.org/cfp/details/247

Historically Heat sessions have been quite well attended by operators and 
deployers with lots of real-world feedback from users.

However I still think having a specific session dedicated to this discussion 
could be good, and would potentially serve to provide some additional focus and 
defininition between user-visible and internal-design discussions.

Steve

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

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


Re: [openstack-dev] Operators Design Summit ideas for Atlanta

2014-04-08 Thread Alan Kavanagh
This is a really good initiative Tom, and from an ops perspective the main 
frustration we have is on the Neutron side and also on lack to Tool support.

Alan

-Original Message-
From: Tom Fifield [mailto:t...@openstack.org] 
Sent: April-06-14 10:23 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Operators  Design Summit ideas for Atlanta

So far, there's been no comment from anyone working on nova, so there's been no 
session proposed.

I can, of course, propose a session ... but without buy-in from the project 
team it's unlikely to be accepted.


Regards,


Tom


On 01/04/14 22:44, Matt Van Winkle wrote:
 So, I've been watching the etherpad and the summit submissions and I
 noticed that there isn't anything for nova.  Maybe I'm off base, but it
 seems like we'd be missing the mark to not have a Developer/Operator's
 exchange on the key product.  Is there anything we can do to get a session
 slotted like these other products?

 Thanks!
 Matt

 On 3/28/14 2:01 AM, Tom Fifield t...@openstack.org wrote:

 Thanks to those projects that responded. I've proposed sessions in
 swift, ceilometer, tripleO and horizon.

 On 17/03/14 07:54, Tom Fifield wrote:
 All,

 Many times we've heard a desire for more feedback and interaction from
 users. However, their attendance at design summit sessions is met with
 varied success.

 However, last summit, by happy accident, a swift session turned into a
 something a lot more user driven. A competent user was able to describe
 their use case, and the developers were able to stage a number of
 question to them. In this way, some of the assumptions about the way
 certain things were implemented, and the various priorities of future
 plans became clearer. It worked really well ... perhaps this is
 something we'd like to have happen for all the projects?

 *Idea*: Add an ops session for each project in the design summit

 https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


 Most operators running OpenStack tend to treat it more holistically than
 those coding it. They are aware of, but don't necessarily think or work
 in terms of project  breakdowns. To this end, I'd imagine the such
 sessions would:

* have a primary purpose for developers to ask the operators to answer
  questions, and request information

* allow operators to tell the developers things (give feedback) as a
  secondary purpose that could potentially be covered better in a
  cross-project session

* need good moderation, for example to push operator-to-operator
  discussion into forums with more time available (eg
  https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

* be reinforced by having volunteer good users in potentially every
  design summit session
  (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


 Anyway, just a strawman - please jump on the etherpad

 (https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-session
 s)
 or leave your replies here!


 Regards,


 Tom


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



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


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



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

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


Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?

2014-02-09 Thread Alan Kavanagh
Hi Paul

Yes I would be interested in this as I believe its an area we have not got 
around to so far in Neutron.

/Alan

From: Paul Michali [mailto:p...@cisco.com]
Sent: February-03-14 5:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 
services?

I'd like to see if there is interest in discussing vendor plugins for L3 
services. The goal is to strive for consistency across vendor plugins/drivers 
and across service types (if possible/sensible). Some of this could/should 
apply to reference drivers as well. I'm thinking about these topics (based on 
questions I've had on VPNaaS - feel free to add to the list):

* How to handle vendor specific validation (e.g. say a vendor has 
restrictions or added capabilities compared to the reference drivers for 
attributes).
* Providing client feedback (e.g. should help and validation be 
extended to include vendor capabilities or should it be delegated to server 
reporting?)
* Handling and reporting of errors to the user (e.g. how to indicate to 
the user that a failure has occurred establishing a IPSec tunnel in device 
driver?)
* Persistence of vendor specific information (e.g. should new tables be 
used or should/can existing reference tables be extended?).
* Provider selection for resources (e.g. should we allow --provider 
attribute on VPN IPSec policies to have vendor specific policies or should we 
rely on checks at connection creation for policy compatibility?)
* Handling of multiple device drivers per vendor (e.g. have service 
driver determine which device driver to send RPC requests, or have agent 
determine what driver requests should go to - say based on the router type)
If you have an interest, please reply to me and include some days/times that 
would be good for you, and I'll send out a notice on the ML of the time/date 
and we can discuss.

Looking to hearing form you!

PCM (Paul Michali)

MAIL  p...@cisco.commailto:p...@cisco.com
IRCpcm_  (irc.freenode.nethttp://irc.freenode.net)
TW@pmichali
GPG key4525ECC253E31A83
Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83

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


Re: [openstack-dev] [ironic] Disk Eraser

2014-01-19 Thread Alan Kavanagh
+1, that is another point Rob. When I started this thread my main interest was 
disk and then firmware. It is clear we really need to have a clear discussion 
on this, as imho I would not be supportive or lease baremetal to tenants if I 
can not guarantee the service, otherwise the cost of risking tenants to adverse 
attacks and data screening are far greater that the revenue generated from the 
service. When it comes to the tenants in our DC we consider all tenants need to 
be provided a guarantee of the baremetal service on the disk, loaders etc etc, 
otherwise its difficult to assure your customer.

/Alan

-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: January-18-14 12:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser

On 18 January 2014 12:21, Chris Friesen chris.frie...@windriver.com wrote:
 On 01/17/2014 04:20 PM, Devananda van der Veen wrote:

 tl;dr, We should not be recycling bare metal nodes between untrusted 
 tenants at this time. There's a broader discussion about firmware 
 security going on, which, I think, will take a while for the hardware 
 vendors to really address.


 What can the hardware vendors do?  Has anyone proposed a meaningful 
 solution for the firmware issue?


So historically, for 99% of users of new machines, it's been considered a super 
low risk right - they don't boot off of unknown devices, and they aren't 
reusing machines across different users.
Second hand users had risks, but vendors aren't designing for the second hand 
purchaser.

However more and more viruses are targeting lower and lower parts of the boot 
stack (see why UEFI is so important) and there are now multiple confirmations 
of hostile payloads that can live in hard disk drive microcontrollers - and 
some of the NSA payloads look like they inhabit system management bioses... - 
it's become clear that this is something that is a genuine risk for all users; 
new users from viruses and other malware, second hand users from the original 
user.

So, industry wise, I think over the next few years folk will finish auditing 
their supply chain to determine what devices are at risk and then start 
implementing defenses. The basic problem though is that our entire machine 
architecture trusts that the rest of the machine is trusted (e.g. device can 
DMA anything they want... - one previous class of attack was compromised 
firewire devices - plugin, and they would disable your screen saver without 
password entry.)

 Given the number of devices (NIC, GPU, storage controllers, etc.) that 
 could potentially have firmware update capabilities it's not clear to 
 me how this could be reliably solved.

Slowly and carefully :)

-Rob

--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

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


[openstack-dev] FW: OpenStack Cloud Virtualization Implementation Strategies

2014-01-17 Thread Alan Kavanagh
FYI

From: Light Reading [mailto:sen...@responses.lightreading.com]
Sent: January-17-14 2:20 PM
To: Alan Kavanagh
Subject: OpenStack Cloud Virtualization Implementation Strategies

If you have trouble viewing this email, read the online 
versionhttp://app.reg.techweb.com/e/es.aspx?s=2150e=212470elq=62671bda0e344eeb82af3927ad56d07f.


[http://twimgs.com/audiencedevelopment/JT/OE/promos/LR/logos/LR_Windriver_hdr.jpg]http://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f





OpenStack Cloud Virtualization Implementation 
Strategieshttp://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f

Dear Alan,

Join us on Wednesday, January 29, 2014, 12:00 pm New York for this live radio 
show sponsored by Wind River.

[Register 
Now]http://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f

In only a few years, OpenStack has emerged as a leading approach for meeting 
the massive cloud compute, networking, and storage challenges that datacenters 
and network infrastructures now face. However, since implementation 
requirements differ based on a number of factors, including type of cloud 
architecture supported (public, private, hybrid), no single implementation 
strategy exists. Rather, operators and equipment providers must create 
individualized cloud virtualization strategies to best meet unique service 
agility and monetization requirements.

Accordingly, join Davide Ricci, Product Line Manager at Wind River, and Jim 
Hodges, Heavy Reading Analyst, for a technical discussion addressing the 
factors and design attributes to be considered in creating a cohesive 
OpenStack-based cloud virtualization implementation strategy. Topics they will 
discuss include:

  *   The impact of OpenStack on existing open-source embedded software 
ecosystem projects
  *   The factors and timeline that must be considered in the creation of a 
virtualized cloud network (including cloud-based hardware and software clusters)
  *   Best-practices for OpenStack component integration (including OpenStack 
Neutron and Swift)
  *   The value proposition of existing and new OpenStack release capabilities
  *   OpenStack Cloud implementation challenges, including the need to provide 
carrier-grade reliability ensuring maximum possible uptime
  *   Wind River's OpenStack roadmap and how it fits into its network functions 
virtualization product and solution portfolio
Register 
Todayhttp://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f




TO UNSUBSCRIBE
This email was sent to 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com.
You are receiving this email because you provided Light Reading with your email 
address.
If you wish to opt-out of webinar promotions via Light Reading, please respond 
herehttp://reg.techweb.com/forms/LightReadingWebinars.


Light Reading
150 West 30th Street, 20th Floor
New York, NY 10001


[http://app.reg.techweb.com/e/FooterImages/FooterImage1?elq=62671bda0e344eeb82af3927ad56d07fsiteid=2150]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] Disk Eraser

2014-01-17 Thread Alan Kavanagh
Hi Rob

Then apart from the disk eraser and reinstalling the blade from scratch 
everytime it is returned from lease, and ensure network isolation, what are the 
other many concerns you are worried about for sharing the bare metal then? 
Would really like to know what the other major issues are that you see?

/Aaln

-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: January-17-14 3:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser

On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote:
 Hi fellow OpenStackers



 Does anyone have any recommendations on open source tools for disk 
 erasure/data destruction software. I have so far looked at DBAN and 
 disk scrubber and was wondering if ironic team have some better 
 recommendations?

So for Ironic this is a moderately low priority thing right now - and certainly 
I think it should be optional (what the default is is a different discussion).

It's low priority because there are -so- many other concerns about sharing bare 
metal machines between tenants that don't have comprehensive mutual trust, that 
it's really not viable today (even on relatively recent platforms IMNSHO).

-Rob


--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

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


Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

2014-01-16 Thread Alan Kavanagh


-Original Message-
From: CARVER, PAUL [mailto:pc2...@att.com] 
Sent: January-16-14 8:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of 
cinder.


Alan Kavanagh wrote: 

I posted a query to Ironic which is related to this discussion. My thinking 
was I want to ensure the case you note here (1)  a tenant can not read 
another tenants disk.. the next (2) was where in Ironic you provision a 
baremetal server that has an onboard dish as part of the blade provisioned to 
a given tenant-A. then when tenant-A finishes his baremetal blade lease and 
that blade comes back into the pool and tenant-B comes along, I was asking 
what open source tools guarantee data destruction so that no ghost images  or 
file retrieval is possible?

That is an excellent point. I think the needs of Ironic may be different from 
Cinder. As a volume manager Cinder isn't actually putting the raw disk under 
the control of a tenant. If it can be assured that (as is the case with NetApp 
and other storage vendor hardware) that a fake all zeros is returned on a 
read-before-first-write of a chunk of disk space then that's sufficient to 
address the case of some curious ne'er-do-well alllancating volumes purely for 
the purpose of reading them to see what's left on them.
 exactly, that was my thinking too. My main concern is to ensure that no 
 ghost file and no way for another tenant to retrieve any data stored from a 
 previous tenant. 

But with bare metal the whole physical disk is at the mercy of the tenant so 
you're right that it must be ensured that the none of the previous tenant's 
bits are left lying around to be snooped on.
 Fully agree Paul,. What I was thinking was that when the tenants bare metal 
 node lease has expired and the blade is to be brought back into the pool for 
 available scheduling to other tenants, we should run a disk eraser before 
 making the blade available, so Ironic would run a disk eraser and validate 
 this before taking it back into the pool. IF folks think this is a good 
 idea, I will write up a blueprint on this for Ironic.

But I still think an *option* of wipe=none may be desirable because a cautious 
client might well take it into their own hands to wipe the disk before 
releasing it (and perhaps encrypt as well). In which case always doing an 
additional wipe is going to be more disk I/O for no real benefit.
 I hear you on this one, and most clients who go for baremetal service are 
 not novice, however it is also good to not take the chance and ensure all 
 data is wiped before taking the blade back into service, at least that is 
 what I would do and we typically do that with our laptops and PC's that we 
 move/lease around ;-)

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

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


Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

2014-01-16 Thread Alan Kavanagh
+1makes sense to me. I will write up a Blueprint for this for review in 
Ironic and we take it from their. 

I don't see this as evil firmware, more a good process we need to automate as 
part of sanity checks before taking a leased baremetal back and making it 
available in the pool again, imho. Or do others see it differently, if so would 
like to hear so.

/Alan

-Original Message-
From: CARVER, PAUL [mailto:pc2...@att.com] 
Sent: January-16-14 8:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of 
cinder.

Clint Byrum wrote:

Is that really a path worth going down, given that tenant-A could just 
drop evil firmware in any number of places, and thus all tenants 
afterward are owned anyway?

I think a change of subject line is in order for this topic (assuming it hasn't 
been discussed in sufficient depth already). I propose [Ironic] Evil Firmware 
but I didn't change it on this message in case folks interested in this thread 
aren't reading Ironic threads.

Ensuring clean firmware is definitely something Ironic needs to account for. 
Unless you're intending to say that multi-tenant bare metal is a dead end that 
shouldn't be done at all.

As long as anyone is considering Ironic and bare metal in general as a viable 
project and service it is critically important that people are focused on how 
to ensure that a server released by one tenant is clean before being provided 
to another tenant.

It doesn't even have to be evil firmware. Simply providing a tenant with a 
server where the previous tenant screwed up a firmware update or messed with 
BIOS settings or whatever is a problem. If you're going to lease bare metal out 
on a short term basis you've GOT to have some sort of QC to ensure that when 
the hardware is reused for another tenant it's as good as new.

If not, it will be all too common for a tenant to receive a bare metal server 
that's been screwed up by a previous tenant through incompetence as much as 
through maliciousness.

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

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


Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

2014-01-16 Thread Alan Kavanagh
The point was that tenant-A can not read or be able to retrieve any data once 
the blade lease is over the the blade is returned to the pool. 
Therefore, what would make sense is that we build an in-service a method to 
ensure that the disk is erased before being brought back into the pool to be 
made available for provisioning, at least that is my thinking here and the 
concerns Paul had too. Do I sense a Blueprint!!!

Alan

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com] 
Sent: January-16-14 12:25 AM
To: openstack-dev
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of 
cinder.

Excerpts from Alan Kavanagh's message of 2014-01-15 19:11:03 -0800:
 Hi Paul
 
 I posted a query to Ironic which is related to this discussion. My thinking 
 was I want to ensure the case you note here (1)  a tenant can not read 
 another tenants disk.. the next (2) was where in Ironic you provision a 
 baremetal server that has an onboard dish as part of the blade provisioned to 
 a given tenant-A. then when tenant-A finishes his baremetal blade lease and 
 that blade comes back into the pool and tenant-B comes along, I was asking 
 what open source tools guarantee data destruction so that no ghost images  or 
 file retrieval is possible?
 

Is that really a path worth going down, given that tenant-A could just drop 
evil firmware in any number of places, and thus all tenants afterward are owned 
anyway?


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

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


Re: [openstack-dev] [ironic] Disk Eraser

2014-01-16 Thread Alan Kavanagh
Cheers Chris

I have used diskscrub and its one of the better tools. It would make sense as I 
noted in a previous email to have ironic run some dd tool before bringing the 
compute blade back into pool for scheduling. Should we write up a blueprint for 
this?

Would also good to know if anyone has tried to do any data recovery after doing 
dd on the local disk?

/Alan

From: Chris Jones [mailto:c...@tenshu.net]
Sent: January-16-14 6:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser

Hi

https://code.google.com/p/diskscrub/


If you need more than /dev/zero, scrub should be packaged in most distros and 
offers a choice of high grade algorithms.

Cheers,
--
Chris Jones

On 15 Jan 2014, at 14:31, Alan Kavanagh 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote:
Hi fellow OpenStackers

Does anyone have any recommendations on open source tools for disk erasure/data 
destruction software. I have so far looked at DBAN and disk scrubber and was 
wondering if ironic team have some better recommendations?

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


Re: [openstack-dev] [ironic] Disk Eraser

2014-01-16 Thread Alan Kavanagh
Although the performance is important the more critical feature is to 
guarantee complete dd for the disk.

Alan

From: Oleg Gelbukh [mailto:ogelb...@mirantis.com]
Sent: January-16-14 5:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser



On Wed, Jan 15, 2014 at 10:25 PM, Alan Kavanagh 
alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote:
Cheers Guys

So what would you recommend Oleg. Yes its for linux system.

Alan,

Approach proposed below (/dev/zero) is probably better as it allows to perform 
at around 60MB/s. Another approach that I've seen flying around is to generate 
random string and use it's hashes for dd. There are some one-liners out there 
which do that with openssl, just one example:


openssl enc -aes-256-ctr -pass pass:$(dd if=/dev/urandom bs=128 count=1 
2/dev/null | base64) -nosalt  /dev/zero  randomfile.bin
Hope this helps.

--
Best regards,
Oleg Gelbukh


/Alan

From: Oleg Gelbukh [mailto:ogelb...@mirantis.commailto:ogelb...@mirantis.com]
Sent: January-15-14 10:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser


On Wed, Jan 15, 2014 at 6:42 PM, Alexei Kornienko 
alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote:
If you are working on linux system following can help you:

dd if=/dev/urandom of=/dev/sda bs=4k

I would not recommend that as /dev/urandom is real slow (10-15 MB/s).

--
Best regards,
Oleg Gelbukh


:)
Best Regards,


On 01/15/2014 04:31 PM, Alan Kavanagh wrote:
Hi fellow OpenStackers

Does anyone have any recommendations on open source tools for disk erasure/data 
destruction software. I have so far looked at DBAN and disk scrubber and was 
wondering if ironic team have some better recommendations?

BR
Alan


___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

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


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

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

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


[openstack-dev] [ironic] Disk Eraser

2014-01-15 Thread Alan Kavanagh
Hi fellow OpenStackers

Does anyone have any recommendations on open source tools for disk erasure/data 
destruction software. I have so far looked at DBAN and disk scrubber and was 
wondering if ironic team have some better recommendations?

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


Re: [openstack-dev] [ironic] Disk Eraser

2014-01-15 Thread Alan Kavanagh
Cheers Guys

So what would you recommend Oleg. Yes its for linux system.

/Alan

From: Oleg Gelbukh [mailto:ogelb...@mirantis.com]
Sent: January-15-14 10:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] Disk Eraser


On Wed, Jan 15, 2014 at 6:42 PM, Alexei Kornienko 
alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote:
If you are working on linux system following can help you:

dd if=/dev/urandom of=/dev/sda bs=4k

I would not recommend that as /dev/urandom is real slow (10-15 MB/s).

--
Best regards,
Oleg Gelbukh


:)
Best Regards,


On 01/15/2014 04:31 PM, Alan Kavanagh wrote:
Hi fellow OpenStackers

Does anyone have any recommendations on open source tools for disk erasure/data 
destruction software. I have so far looked at DBAN and disk scrubber and was 
wondering if ironic team have some better recommendations?

BR
Alan


___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

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


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


Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

2014-01-15 Thread Alan Kavanagh
Hi Paul

I posted a query to Ironic which is related to this discussion. My thinking was 
I want to ensure the case you note here (1)  a tenant can not read another 
tenants disk.. the next (2) was where in Ironic you provision a baremetal 
server that has an onboard dish as part of the blade provisioned to a given 
tenant-A. then when tenant-A finishes his baremetal blade lease and that blade 
comes back into the pool and tenant-B comes along, I was asking what open 
source tools guarantee data destruction so that no ghost images  or file 
retrieval is possible?

/Alan

-Original Message-
From: CARVER, PAUL [mailto:pc2...@att.com] 
Sent: January-15-14 6:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of 
cinder.

Chris Friesen [mailto:chris.frie...@windriver.com] wrote:

I read a proposal about using thinly-provisioned logical volumes as a 
way around the cost of wiping the disks, since they zero-fill on demand 
rather than incur the cost at deletion time.

I think it make a difference where the requirement for deletion is coming from.

If it's just to make sure that a tenant can't read another tenant's disk then 
what you're talking about should work. It sounds similar (or perhaps identical 
to) how NetApp (and I assume others) work by tracking whether the current 
client has written to the volume and returning zeros rather than the actual 
contents of the disk sector on a read that precedes the first write to that 
sector.

However, in that case the previous client's bits are still on the disk. If they 
were unencrypted then they're still available if someone somehow got ahold of 
the physical disk out of the storage array.

That may not be acceptable depending on the tenant's security requirements.

Though one may reasonably ask why they were writing unencrypted bits to a disk 
that they didn't have physical control over.

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

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


Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

2014-01-10 Thread Alan Kavanagh
+1 PCI Flavor.

From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
Sent: January-10-14 1:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

BTW, I like the PCI flavor :)

From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
Sent: Thursday, January 09, 2014 10:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Hi, Ian, when you in aggrement with all of this, do you agree with the 'group 
name', or agree with John's pci flavor?
I'm against the PCI group and will send out a reply later.

--jyh

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Thursday, January 09, 2014 9:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

I think I'm in agreement with all of this.  Nice summary, Robert.
It may not be where the work ends, but if we could get this done the rest is 
just refinement.

On 9 January 2014 17:49, Robert Li (baoli) 
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi Folks,

With John joining the IRC, so far, we had a couple of productive meetings in an 
effort to come to consensus and move forward. Thanks John for doing that, and I 
appreciate everyone's effort to make it to the daily meeting. Let's reconvene 
on Monday.

But before that, and based on our today's conversation on IRC, I'd like to say 
a few things. I think that first of all, we need to get agreement on the 
terminologies that we are using so far. With the current nova PCI passthrough

PCI whitelist: defines all the available PCI passthrough devices on a 
compute node. pci_passthrough_whitelist=[{ 
vendor_id:,product_id:}]
PCI Alias: criteria defined on the controller node with which requested 
PCI passthrough devices can be selected from all the PCI passthrough devices 
available in a cloud.
Currently it has the following format: 
pci_alias={vendor_id:, product_id:, name:str}

nova flavor extra_specs: request for PCI passthrough devices can be 
specified with extra_specs in the format for 
example:pci_passthrough:alias=name:count

As you can see, currently a PCI alias has a name and is defined on the 
controller. The implications for it is that when matching it against the PCI 
devices, it has to match the vendor_id and product_id against all the available 
PCI devices until one is found. The name is only used for reference in the 
extra_specs. On the other hand, the whitelist is basically the same as the 
alias without a name.

What we have discussed so far is based on something called PCI groups (or PCI 
flavors as Yongli puts it). Without introducing other complexities, and with a 
little change of the above representation, we will have something like:

pci_passthrough_whitelist=[{ vendor_id:,product_id:, 
name:str}]

By doing so, we eliminated the PCI alias. And we call the name in above as a 
PCI group name. You can think of it as combining the definitions of the 
existing whitelist and PCI alias. And believe it or not, a PCI group is 
actually a PCI alias. However, with that change of thinking, a lot of benefits 
can be harvested:

 * the implementation is significantly simplified
 * provisioning is simplified by eliminating the PCI alias
 * a compute node only needs to report stats with something like: PCI 
group name:count. A compute node processes all the PCI passthrough devices 
against the whitelist, and assign a PCI group based on the whitelist definition.
 * on the controller, we may only need to define the PCI group names. 
if we use a nova api to define PCI groups (could be private or public, for 
example), one potential benefit, among other things (validation, etc),  they 
can be owned by the tenant that creates them. And thus a wholesale of PCI 
passthrough devices is also possible.
 * scheduler only works with PCI group names.
 * request for PCI passthrough device is based on PCI-group
 * deployers can provision the cloud based on the PCI groups
 * Particularly for SRIOV, deployers can design SRIOV PCI groups based 
on network connectivities.

Further, to support SRIOV, we are saying that PCI group names not only can be 
used in the extra specs, it can also be used in the -nic option and the neutron 
commands. This allows the most flexibilities and functionalities afforded by 
SRIOV.

Further, we are saying that we can define default PCI groups based on the PCI 
device's class.

For vnic-type (or nic-type), we are saying that it defines the link 
characteristics of the nic that is attached to a VM: a nic that's connected to 
a virtual switch, a nic that is connected to a physical switch, or a nic that 
is connected to a physical switch, but has a host macvtap device in between. 
The actual 

Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

2013-12-20 Thread Alan Kavanagh
Cheers Gao. So my only comment here is how complex and how many attributes are 
we expecting the scheduler to take as input. Similarly the more variables you 
schedule on the more complex the beast becomes and from experience you end up 
having cross dependencies.

I can see power be an item of concern but don't you think that we could solve 
that one with Nova Cells Parent being aware of the Power consumption costs at 
time-T and then just forward the Nova API call to the appropriate Child which 
has say the least power consumption cost?

Also, on a priority scale, some DC providers (speaking as one of the DC 
Providers here) will not have power cost on their top say 5 list for 
scheduling. So I agree its definitely interesting but if you consider 
scheduling inside a large DC in the same geographical region and Dc site, 
Scheduling for power consumption becomes null and void. ;-(

BR
Alan



From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-19-13 11:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Yes, Alan, you got me.
Providing power/temperature to scheduler, set threshold or different weight, 
then the scheduler can boot VM on the most suitable node.

Thanks

--fengqian

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Friday, December 20, 2013 11:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Cheers Gao

It definitely makes sense to collect additional metrics such as power and 
temperature, and make that available for selective decisions you would want to 
take. However, I am just wondering if you could realistically feed those 
metrics as variables for scheduling, this is the main part I feel is 
questionable. I assume then you would use temperature || power etc to gauge if 
you want to schedule another VM on a given node when a given temperature 
threshold is reached. Is this the main case you are thinking of Gao?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 10:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, Alan,
I think, for nova-scheduler it is better if we gather more information.  And In 
today's DC, power and temperature are very important facts to considering.
CPU/Memory utilization is not enough to describe nodes' status. Power/inlet 
temperature should be noticed.

Best Wishes

--fengqian

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Thursday, December 19, 2013 2:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi Gao

What is the reason why you see it would be important to have these two 
additional metrics power and temperature for Nova to base scheduling on?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 1:00 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, all,
I am planning to extend bp 
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with 
power and temperature. In other words, power and temperature can be collected 
and used for nova-scheduler just as CPU utilization.
I have a question here. As you know, IPMI is used to get power and temperature 
and baremetal implements IPMI functions in Nova. But baremetal driver is being 
split out of nova, so if I want to change something to the IPMI, which part 
should I choose now? Nova or Ironic?


Best wishes

--fengqian

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


Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

2013-12-20 Thread Alan Kavanagh
One additional item Gao and apologies as I was thinking power on two front 
here. I assume then the limit here is per compute node within a given DC site, 
so yes I can see some small benefits on that for sure. I still however have a 
hard time seeing if I want to do scheduling based on power as one of my main 
attributes I need to schedule based on, but sure I can see some value in this.
Let me know when you flesh this out in the blueprint, would be willing to 
support and take some items for dev for this.

BR
Alan

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: December-20-13 8:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Cheers Gao. So my only comment here is how complex and how many attributes are 
we expecting the scheduler to take as input. Similarly the more variables you 
schedule on the more complex the beast becomes and from experience you end up 
having cross dependencies.

I can see power be an item of concern but don't you think that we could solve 
that one with Nova Cells Parent being aware of the Power consumption costs at 
time-T and then just forward the Nova API call to the appropriate Child which 
has say the least power consumption cost?

Also, on a priority scale, some DC providers (speaking as one of the DC 
Providers here) will not have power cost on their top say 5 list for 
scheduling. So I agree its definitely interesting but if you consider 
scheduling inside a large DC in the same geographical region and Dc site, 
Scheduling for power consumption becomes null and void. ;-(

BR
Alan



From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-19-13 11:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Yes, Alan, you got me.
Providing power/temperature to scheduler, set threshold or different weight, 
then the scheduler can boot VM on the most suitable node.

Thanks

--fengqian

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Friday, December 20, 2013 11:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Cheers Gao

It definitely makes sense to collect additional metrics such as power and 
temperature, and make that available for selective decisions you would want to 
take. However, I am just wondering if you could realistically feed those 
metrics as variables for scheduling, this is the main part I feel is 
questionable. I assume then you would use temperature || power etc to gauge if 
you want to schedule another VM on a given node when a given temperature 
threshold is reached. Is this the main case you are thinking of Gao?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 10:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, Alan,
I think, for nova-scheduler it is better if we gather more information.  And In 
today's DC, power and temperature are very important facts to considering.
CPU/Memory utilization is not enough to describe nodes' status. Power/inlet 
temperature should be noticed.

Best Wishes

--fengqian

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Thursday, December 19, 2013 2:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi Gao

What is the reason why you see it would be important to have these two 
additional metrics power and temperature for Nova to base scheduling on?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 1:00 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, all,
I am planning to extend bp 
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with 
power and temperature. In other words, power and temperature can be collected 
and used for nova-scheduler just as CPU utilization.
I have a question here. As you know, IPMI is used to get power and temperature 
and baremetal implements IPMI functions in Nova. But baremetal driver is being 
split out of nova, so if I want to change something to the IPMI, which part 
should I choose now? Nova or Ironic?


Best wishes

--fengqian

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


Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

2013-12-19 Thread Alan Kavanagh
Cheers Gao

It definitely makes sense to collect additional metrics such as power and 
temperature, and make that available for selective decisions you would want to 
take. However, I am just wondering if you could realistically feed those 
metrics as variables for scheduling, this is the main part I feel is 
questionable. I assume then you would use temperature || power etc to gauge if 
you want to schedule another VM on a given node when a given temperature 
threshold is reached. Is this the main case you are thinking of Gao?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 10:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, Alan,
I think, for nova-scheduler it is better if we gather more information.  And In 
today's DC, power and temperature are very important facts to considering.
CPU/Memory utilization is not enough to describe nodes' status. Power/inlet 
temperature should be noticed.

Best Wishes

--fengqian

From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com]
Sent: Thursday, December 19, 2013 2:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi Gao

What is the reason why you see it would be important to have these two 
additional metrics power and temperature for Nova to base scheduling on?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 1:00 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, all,
I am planning to extend bp 
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with 
power and temperature. In other words, power and temperature can be collected 
and used for nova-scheduler just as CPU utilization.
I have a question here. As you know, IPMI is used to get power and temperature 
and baremetal implements IPMI functions in Nova. But baremetal driver is being 
split out of nova, so if I want to change something to the IPMI, which part 
should I choose now? Nova or Ironic?


Best wishes

--fengqian

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


Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

2013-12-18 Thread Alan Kavanagh
Hi Gao

What is the reason why you see it would be important to have these two 
additional metrics power and temperature for Nova to base scheduling on?

Alan

From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 1:00 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI

Hi, all,
I am planning to extend bp 
https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with 
power and temperature. In other words, power and temperature can be collected 
and used for nova-scheduler just as CPU utilization.
I have a question here. As you know, IPMI is used to get power and temperature 
and baremetal implements IPMI functions in Nova. But baremetal driver is being 
split out of nova, so if I want to change something to the IPMI, which part 
should I choose now? Nova or Ironic?


Best wishes

--fengqian

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


Re: [openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload

2013-10-30 Thread Alan Kavanagh
Sorry Russell but I have to ask, what is the different you see between 
traditional datacenter virtualization and cloud. IMHO the two co-exist and 
Cloud (the buzz word that it is) is the umbrella for all encompassing data 
center. That said im still missing why this would not be a useful feature for 
us?

BR
Alan

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: October-30-13 4:21 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto 
VM Discovery in OpenStack for existing workload

On 10/30/2013 03:13 AM, Alex Glikson wrote:
 Maybe a more appropriate approach could be to have a tool/script that 
 does it, as a one time thing.
 For example, it could make sense in a scenario when Nova DB gets lost 
 or corrupted, a new Nova controller is deployed, and the DB needs to 
 be recreated. Potentially, since Nova DB is primarily a cache, this 
 could be done by 'discovery' (maybe with some manual intervention) - 
 instead of dealing with backup/restore of the DB, or similar approaches.

The need for this sort of thing makes more sense for traditional datacenter 
virtualization, but not as much for cloud.  That's the root of my objection.

--
Russell Bryant

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

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


Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

2013-10-24 Thread Alan Kavanagh
Hi Swami

I am interested in this, please keep me in the loop.

/Alan

From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hp.com]
Sent: October-22-13 8:50 PM
To: cloudbengo; Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); 
OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

Hi Folks,
Thanks for your interests in the DVR feature.
We should get together to start discussing the details in the DVR.
Please let me know who else is interested, probably the time slot and we can 
start nailing down the details.
 https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
Thanks
Swami

From: Robin Wang [mailto:cloudbe...@gmail.com]
Sent: Tuesday, October 22, 2013 11:45 AM
To: Artem Dmytrenko; yong sheng gong 
(gong...@unitedstack.commailto:gong...@unitedstack.com); OpenStack 
Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

Hi Artem,

Very happy to see more stackers working on this feature. : )

Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. 
I met the same issue at first. Downloading the doc and open it locally may 
help. It works for me.

Also, a wiki page for DVR/VDR feature is created, including some interesting 
performance test output. Thanks.
https://wiki.openstack.org/wiki/Distributed_Router_for_OVS

Best,
Robin Wang

From: Artem Dmytrenkomailto:nexton...@yahoo.com
Date: 2013-10-22 02:51
To: yong sheng gong 
\(gong...@unitedstack.com\)mailto:gong...@unitedstack.com; 
cloudbe...@gmail.commailto:cloudbe...@gmail.com; OpenStack Development 
Mailing Listmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
Hi Swaminathan.

I work for a virtual networking startup called Midokura and I'm very interested 
in joining the discussion. We currently have distributed router implementation 
using existing Neutron API. Could you clarify why distributed vs centrally 
located routing implementation need to be distinguished? Another question is 
that are you proposing distributed routing implementation for tenant routers or 
for the router connecting the virtual cloud to the external network? The reason 
that I'm asking this question is because our company would also like to propose 
a router implementation that would eliminate a single point uplink failures. We 
have submitted a couple blueprints on that topic 
(https://blueprints.launchpad.net/neutron/+spec/provider-router-support, 
https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would 
appreciate an opportunity to collaborate on making it a reality.

Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. Could you update your document with 
legible diagrams?

Looking forward to further discussing this topic with you!

Sincerely,
Artem Dmytrenko


On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) 
swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com wrote:

 Subject: [openstack-dev] Distributed Virtual Router Discussion
 To: yong sheng gong 
(gong...@unitedstack.commailto:gong...@unitedstack.com) 
gong...@unitedstack.commailto:gong...@unitedstack.com, 
cloudbe...@gmail.commailto:cloudbe...@gmail.com 
cloudbe...@gmail.commailto:cloudbe...@gmail.com, OpenStack Development 
Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Date: Monday, October 21, 2013, 12:18 PM









 Hi Folks,
 I am currently working on a
 blueprint for Distributed Virtual Router.
 If anyone interested in
 being part of the discussion please let me know.
 I have put together a first
 draft of my blueprint and have posted it on Launchpad for
 review.
 https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr



 Thanks.

 Swaminathan Vasudevan
 Systems Software Engineer
 (TC)


 HP Networking
 Hewlett-Packard
 8000 Foothills Blvd
 M/S 5541
 Roseville, CA - 95747
 tel: 916.785.0937
 fax: 916.785.1815
 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com







 -Inline Attachment Follows-

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

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


Re: [openstack-dev] [Nova] Blueprint review process

2013-10-24 Thread Alan Kavanagh
Is this really a viable solution? 
I believe its more democratic to ensure everyone gets a chance to present the 
blueprint someone has spent time to write. This was no favoritism or biased 
view will ever take place and we let the community gauge the interest. 

/Alan

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: October-24-13 5:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Blueprint review process

On 10/24/2013 10:52 AM, Gary Kotton wrote:
 
 
 On 10/24/13 4:46 PM, Dan Smith d...@danplanet.com wrote:
 
 In the last meeting we discussed an idea that I think is worth 
 trying at least for icehouse-1 to see if we like it or not.  The 
 idea is that
 *every* blueprint starts out at a Low priority, which means best 
 effort, but no promises.  For a blueprint to get prioritized 
 higher, it should have 2 nova-core members signed up to review the 
 resulting code.

 Huge +1 to this. I'm in favor of the whole plan, but specifically the 
 prioritization piece is very important, IMHO.
 
 I too am in favor of the idea. It is just not clear how 2 Nova cores 
 will be signed up.

Good point, there was no detail on that.  I propose just comments on the 
blueprint whiteboard.  It can be something simple like this to indicate that 
Dan and I have agreed to review the code for something:

nova-core reviewers: russellb, dansmith

--
Russell Bryant

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

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


Re: [openstack-dev] [Neutron] QoS API Extension update

2013-10-16 Thread Alan Kavanagh
Hi Sean

Just an FYI, we are also planning a QoS API Extension Blueprint for the 
Icehouse Design Summit. Will hopefully submit that really soon. Perhaps we can 
look at combining both of them and discuss this in Hong Kong as I have looked 
over your BP and I can see some benefit in combining them both.

BR
Alan

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: October-16-13 10:55 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] QoS API Extension update

Hello,

Just a quick update on the QoS API Extension - I plan on attending the summit 
in Hong Kong and have registered a summit proposal to discuss the current work 
that has been done.

Currently I have two reviews under way:

API Extension  Database models:

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

Agent  OVS implementation:

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

Our current environment uses provider networking  VLANs, so I've been 
targeting the work to what we currently are deploying inside of Comcast, so the 
work on the OVS agent is a bit narrow - I haven't done any work on the GRE side.

Both are currently WIP - I need better test coverage in places, handle some 
edge cases (Agent restarts for example) and code quality improvements.

If people would be so kind as to look over the Agent  OVS implementation and 
give me some feedback, I would really appreciate it.

I plan to study up on the ML2 plugin and add support for the QoS extension, so 
we can transition away from the OVS plugin when it is deprecated.

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


Re: [openstack-dev] [Neutron] QoS API Extension update

2013-10-16 Thread Alan Kavanagh
Cheers Sean

I will take a look at the wiki and update accordingly. I took a look at your 
BP, its right along the lines of what I feel is also needed and what we are 
planning to submit (being finalised as I write this email) though we are also 
adding some additional QoS attributes to be supported based on OVS as one 
source.  I took a look at your API and the BP we are going to submit is very 
much inline and complementary to yours hence why I think we can actually 
combine them and do a joint pitch on thisat least that’s my thinking on it!

Will send BP as soon as its finalised ;-)

BR
Alan

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: October-16-13 12:08 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] QoS API Extension update

On Wed, Oct 16, 2013 at 03:45:29PM +, Alan Kavanagh wrote:
 Will hopefully submit that really soon. Perhaps we can look at combining both 
 of them and discuss this in Hong Kong as I have looked over your BP and I can 
 see some benefit in combining them both.

Hi Alan,

That sounds great - the objective of my BP was to try and make a QoS API 
extension that was flexible enough that everyone could make their own 
implementation. At this point, this is accomplished through storing key/value 
pairs that are linked back to a QoS object, via the policies attribute (which 
maps to the qos_policies table), that stores implementation specific 
behavior/configuration.

There is also a wiki page, that has some useful links:

https://wiki.openstack.org/wiki/Neutron/QoS


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


[openstack-dev] Blueprint Submission Deadline

2013-10-02 Thread Alan Kavanagh
Hi All

Does anyone know when is the Blueprint Icehouse Submission deadline?

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


Re: [openstack-dev] Blueprint Submission Deadline

2013-10-02 Thread Alan Kavanagh
Cheers Thierry

I was looking for some cut off date for blueprints submission to the actual 
Icehouse Design Summit, so that it gives folks a date to shoot towards and then 
time for the relevant projects/team to review/discuss. Perhaps that is 
something we should put in as a hard limit, a cut off date say 2 weeks before 
the Design Summit which in this case if mid-October and we apply that for all 
future Design Summits going forward, just my 2 cents on it.

BR
Alan

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: October-02-13 2:51 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Blueprint Submission Deadline

Alan Kavanagh wrote:
 Does anyone know when is the Blueprint Icehouse Submission deadline?

There are a number of soft deadlines, depending on how early you want to be on 
the release radar (which generally increases the odds of being included in the 
final release).

The first one is the Icehouse design summit. If you want your blueprint 
discussed there, you should submit your blueprint and a session suggestion 
linking to it (on summit.openstack.org) before mid-October.

The second one is the original icehouse roadmap, which is generally built a 
couple weeks after the summit. If you want to be formally included in it, your 
blueprint should be filed (and targeted to one of the icehouse milestones) 
before mid-November.

Then blueprints can be added pretty much until Feature Proposal Freeze, which 
should be somewhere around the end of February (release schedule is not final 
yet). But the later it is visible, the less likely it is to make it.

Reference:
https://wiki.openstack.org/wiki/Release_Cycle

Hope this helps,

--
Thierry Carrez (ttx)

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

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


Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

2013-09-10 Thread Alan Kavanagh
+1

This is the best approach and one we discussed in Portland and a track most 
folks are developing plugins under ML2 

/Alan

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com] 
Sent: September-10-13 12:27 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

On 09/10/2013 10:45 AM, Mark McClain wrote:
 I think Gary and Kyle have answered this very well; however I do have a few 
 things to add.  It is definitely too late for Havana, so Icehouse is next 
 available release for new plugins.  I can work with you offline to find you a 
 core sponsor.

One more thing: Rather than implementing and maintaining an entire new plugin, 
consider whether it might make sense to integrate as an ml2 MechanismDriver 
instead. The ml2 plugin's MechanismDrivers can interface with network devices 
or controllers, and can work in conjunction with the existing L2 agents if 
needed. See
https://wiki.openstack.org/wiki/Neutron/ML2 for more info.

-Bob

 
 mark
  
 On Sep 10, 2013, at 9:37 AM, Kyle Mestery (kmestery) kmest...@cisco.com 
 wrote:
 
 On Sep 10, 2013, at 4:05 AM, P Balaji-B37839 b37...@freescale.com wrote:

 Hi,

 We have gone through the below link for new plug-in development.

 https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neut
 ron_Plugin

 Just want to confirm that is it mandatory to be Core Neutron Developer for 
 submitting a new plug-in.?

 It's not necessary for you to have a core developer from your company, but 
 you will need an existing core developer to support your plugin upstream. 
 When you file the blueprint, let us know and we'll work with you on this one 
 Balaji.

 Thanks,
 Kyle

 How do we get a reviewer for this like Can we approach any Core Neutron 
 developer for review our plugin?

 We are developing new plug-in for our product and want to make it upstream 
 to Neutron Core.

 Any information on this will be helpful!.

 Regards,
 Balaji.P


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


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

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


Re: [openstack-dev] [Ceilometer] what's in scope of Ceilometer

2013-08-29 Thread Alan Kavanagh
+1

I believe the important point here is to identify additional metrics required 
and the relevant attributes which can be specified and have them returned to 
the Collector. Then in turn the collector can either push/pull those 
metrics/etc into an Anlytics Engine and tools. Its not a good idea to start 
designing and building analytics engines etc into Ceilometer, it should just 
the monitor and collecting project.

For the metrics Ceilometer is definitely the place to set and collect what 
metrics you need to know of for both the Hardware functions 
(cpu/mem/disk-i/o/nic utilisation etc etc) and also for some base application 
sets for example on an Apache server the number of TCP-sessions in utilisation 
etc etc. 

BR
Alan


-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info] 
Sent: August-29-13 4:20 AM
To: Gordon Chung
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] what's in scope of Ceilometer

On Thu, Aug 29 2013, Gordon Chung wrote:

 the first question is, Ceilometer currently does 
 metering/alarming/maybe a few other things... will it go beyond that? 
 specifically: capacity planning, optimization, dashboard(i assume this 
 falls under horizon/ceilometer plugin work), analytics.
 they're pretty broad items so i would think they would probably end up 
 being separate projects?

I think we can extend Ceilometer API to help build such tools, but I don't 
think we should build these tools inside Ceilometer.

 another question is what metrics will we capture.  some of the product 
 teams we have collect metrics on datacenter memory/cpu utilization, 
 cluster cpu/memory/vm, and a bunch of other clustered stuff.
 i'm a nova-idiot, but is this info possible to retrieve? is the 
 consensus that Ceilometer will collect anything and everything the 
 other projects allow for?

Yeah, I think that Ceilometer's the place to collect anything. I don't know if 
that metrics you are talking about are collectable through Nova though.

--
Julien Danjou
-- Free Software hacker - independent consultant
-- http://julien.danjou.info

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


Re: [openstack-dev] [networking] Changes to the OVS agent tunneling

2013-07-02 Thread Alan Kavanagh
+1 eagerly awaiting, sounds good.

Alan

-Original Message-
From: Edgar Magana [mailto:emag...@plumgrid.com] 
Sent: July-02-13 12:15 PM
To: OpenStack List
Subject: Re: [openstack-dev] [networking] Changes to the OVS agent tunneling

Hi Kyle,

It seems that the document is locked, could you provide the access code?

Thanks,

Edgar

On 7/2/13 8:32 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote:

I've been spending a fair amount of time working with the OVS agent 
recently, and I've written up a small Google Document [1] detailing the 
end goal of all of this work. The short story is that I am introducing 
changes into the OVS agent to add support for multiple tunnel_types 
when the agent is run with the ML2 plugin. The ML2 plugin will support 
both GRE and VXLAN tunnels at the same time, for example. I'd 
appreciate feedback from folks on this document.

Thanks,
Kyle

[1]
https://docs.google.com/a/mestery.com/document/d/1NT3JVn2lNk_Hp7lP7spc3
ysW
gSyHa4V0pYELAiePD1s/edit?usp=sharing
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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