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
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
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
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
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
+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:
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:
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:
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
+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:
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
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
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
] [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
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
+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
+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
+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
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
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
-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
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
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
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
-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
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
+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
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
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
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
+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
+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
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
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,
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
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
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.
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
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]
+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
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
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
-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
+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,
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
/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
] 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
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
___
:)
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
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
+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
, 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
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
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
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:
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
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
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-
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
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
-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
+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:
+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
+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
64 matches
Mail list logo