[openstack-dev] OpenStack-dev Digest, Vol 18, Issue 67
Santosh Kumar
Santosh8.Kumar at aricent.com
Tue Oct 29 12:14:54 UTC 2013
Hi Experts,
Just wanted to understand , is there any specific configuration for creating network type VLAN in Havana.
Things are not behaving as per expectation while following command in Havana doc.
Net-create command :
neutron net-create ext-net -- --router:external=True --provider:network_type vlan --provider:physical_network physnet1 --
provider:segmentation_id 2
Error : I am getting error like - Invalid vlan string.
Any pointer for the same ?
Regards
Santosh
-----Original Message-----
From: openstack-dev-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org]
Sent: Tuesday, October 29, 2013 5:16 PM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 18, Issue 67
Send OpenStack-dev mailing list submissions to
openstack-dev at lists.openstack.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request at lists.openstack.org
You can reach the person managing the list at
openstack-dev-owner at lists.openstack.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."
Today's Topics:
1. Re: [heat] Proposal for new heat-core member (Steven Hardy)
2. Re: [Heat] Network topologies (Steven Hardy)
3. Re: [heat] Proposal for new heat-core member (Liang Chen)
4. [nova][scheduler] Instance Group Model and APIs - Updated
document with an example request payload (Yathiraj Udupi (yudupi))
5. Re: [Heat] Comments on Steve Baker's Proposal on HOT Software
Config (Steven Hardy)
6. Re: [Heat] Comments on Steve Baker's Proposal on HOT Software
Config (Steven Hardy)
7. Re: [nova][scheduler] Instance Group Model and APIs - Updated
document with an example request payload (Alex Glikson)
8. [Trove] Design Summit Etherpads (Nikhil Manchanda)
9. Re: Full schedule for HongKong summit? (Sylvain Bauza)
10. Re: Full schedule for HongKong summit? (Dina Belova)
11. Re: [Neutron] Security groups with XenAPI (Simon Pasquier)
12. [Nova]Ideas of idempotentcy-client-token (haruka tanizawa)
13. [Marconi] Design Summit Etherpads (Flavio Percoco)
14. [Neutron][LBaaS] Object status and admin_state_up
(Eugene Nikanorov)
15. Unable to logging to guest console on XCP/xenserver
(Rajshree Thorat)
16. Re: [nova][scheduler] Instance Group Model and APIs - Updated
document with an example request payload (David koo)
17. Reminder: Project & release status meeting - 21:00 UTC
(Thierry Carrez)
18. Re: [nova] [neutron] PCI pass-through network support
(Robert Li (baoli))
19. Re: [nova] [neutron] PCI pass-through network support
(Jiang, Yunhong)
20. Re: [Nova] Blueprint review process (John Garbutt)
21. Re: [Nova] Preserving ephemeral block device on rebuild?
(Day, Phil)
22. Re: [nova] [neutron] PCI pass-through network support
(Irena Berezovsky)
23. Re: [Nova] Preserving ephemeral block device on rebuild?
(Robert Collins)
24. Re: [Nova] Blueprint review process (John Garbutt)
25. Re: Full schedule for HongKong summit? (Thierry Carrez)
26. Re: [Nova]Ideas of idempotentcy-client-token (Joe Gordon)
27. [nova] reason for python-novaclient revert (Sean Dague)
28. Re: [Nova] Preserving ephemeral block device on rebuild?
(John Garbutt)
29. Re: [nova] [neutron] PCI pass-through network support
(John Garbutt)
30. Re: [Nova]Ideas of idempotentcy-client-token (haruka tanizawa)
31. Re: Remove vim modelines? (Joe Gordon)
32. Re: Remove vim modelines? (Robert Collins)
33. Re: [nova][scheduler] Instance Group Model and APIs - Updated
document with an example request payload (John Garbutt)
34. Re: [nova][qa] user-oriented release notes for v3 api?
(John Garbutt)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Oct 2013 06:19:01 +0000
From: Steven Hardy <shardy at redhat.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] Proposal for new heat-core member
Message-ID: <20131029061901.GB7801 at t430slt.redhat.com>
Content-Type: text/plain; charset=us-ascii
On Fri, Oct 25, 2013 at 12:12:54PM -0700, Steven Dake wrote:
> Please have a vote +1/-1
+1
------------------------------
Message: 2
Date: Tue, 29 Oct 2013 06:32:54 +0000
From: Steven Hardy <shardy at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Heat] Network topologies
Message-ID: <20131029063254.GC7801 at t430slt.redhat.com>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
> Hello Folks,
>
> Thank you Zane, Steven and Clint for you input.
>
> Our main goal in this BP is to provide networking users such as Heat (we
> consider it as a neutron user) a better and consolidated network building
> block in terms of an API that you could use for orchestration of
> application-driven requirements. This building block does not add any
> "intelligence" to the network topology because it does not have it and
> this is why I think this BP is different from the work that you are doing
> in Heat.
So how do you propose to handle dependencies between elements in the
topology, e.g where things need to be created/deleted in a particular
order, or where one resource must be in a particular state before another
can be created?
> The network topologies BP is not related to the Neutron Network Service
> Insertion BP:
> https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-c
> haining-steering
So I wasn't saying they were related, only that they both, arguably, may
have some scope overlap with what Heat is doing.
> I do agree with Steven that the insertion work add "intelligence"
> (explicit management of dependencies, state and workflow) to the network
> orchestration simply because user will need to know the insertion
> mechanism and dependencies between Network Advances Services, that work is
> more into Heat space that the BP that I am proposing but that is just my
> opinion.
This seems a good reason to leverage the work we're doing rather than
reinventing it. I'm not arguing that Heat should necessarily be the
primary interface to such functionality, only that Heat could (and possibly
should) be used to do the orchestration aspects.
> However, is there a session where I can discuss this BP with you guys?,
> the session that I proposed in Neutron has been rejected because it was
> considered by the PTL as an overlapping work with the Heat goals,
> therefore I wanted to know if you can to discuss it or I just simple go
> ahead and start the implementation. I do still believe it can be easily
> implemented in Neutron and then exposed to Heat but I am really looking
> forward to having a broader discussion.
I don't think we have any sessions directly related to Neutron, but we are
definitely interested in discussing this (and other Neutron BPs which may
have integration points requiring orchestration).
I suggest we have an informal breakout session with those interested on
Tuesday or Wednesday, or it could be a topic which Steve Baker may consider
for this placeholder session:
http://summit.openstack.org/cfp/details/360
Steve
------------------------------
Message: 3
Date: Tue, 29 Oct 2013 14:44:16 +0800
From: Liang Chen <cbjchen at linux.vnet.ibm.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] Proposal for new heat-core member
Message-ID: <1383029056.32073.1.camel at localhost.localdomain>
Content-Type: text/plain; charset="UTF-8"
+1 !
On Fri, 2013-10-25 at 12:12 -0700, Steven Dake wrote:
> Hi,
>
> I would like to propose Randall Burt for Heat Core. He has shown
> interest in Heat by participating in IRC and providing high quality
> reviews. The most important aspect in my mind of joining Heat Core is
> output and quality of reviews. Randall has been involved in Heat
> reviews for atleast 6 months. He has had 172 reviews over the last 6
> months staying "in the pack" [1] of core heat reviewers. His 90 day
> stats are also encouraging, with 97 reviews (compared to the top
> reviewer Steve Hardy with 444 reviews). Finally his 30 day stats also
> look good, beating out 3 core reviewers [2] on output with good
> quality reviews.
>
> Please have a vote +1/-1 and take into consideration:
> https://wiki.openstack.org/wiki/Heat/CoreTeam
>
> Regards,
> -steve
>
> [1] http://russellbryant.net/openstack-stats/heat-reviewers-180.txt
> [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 4
Date: Tue, 29 Oct 2013 06:46:30 +0000
From: "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [nova][scheduler] Instance Group Model and
APIs - Updated document with an example request payload
Message-ID:
<2AB0F5F851B5644A9B0AA69323D1100538FBE4BD at xmb-aln-x15.cisco.com>
Content-Type: text/plain; charset="us-ascii"
The Instance Group API document is now updated with a simple example request payload of a nested group, and some description of how the API implementation should handle the registration of the components of a nested instance group.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
Hope we will have a good API design session at the summit, and also continue the discussion face-to-face over there.
Thanks,
Yathi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/ca553179/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 29 Oct 2013 07:03:18 +0000
From: Steven Hardy <shardy at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal
on HOT Software Config
Message-ID: <20131029070317.GD7801 at t430slt.redhat.com>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 28, 2013 at 04:48:45PM -0400, Mike Spreitzer wrote:
> Steve Baker <sbaker at redhat.com> wrote on 10/28/2013 04:24:30 PM:
>
> > On 10/29/2013 02:53 AM, Steven Hardy wrote:
> > > ...
> > > Can anyone provide me with a clear argument for what the "fundamental
> > > differences" actually are?
> > ...
> > Since writing those proposals my thinking has evolved too. I'm currently
> > thinking it would be best to implement software configuration resources
> > rather than create a new component construct.
>
> Please pardon the newbie question, but I do not understand. A resource
> type is implemented in OpenStack code --- a part of Heat that calls a
> fixed service API that expects Keystone credentials.
This is not true at all.
A resource is simply an abstraction, a container for data, possibly logic,
which has interfaces (inputs/properties, and outputs/attributes)
There a several ways to define a resource. One of them is to write a Heat
python plugin, which may, or may not talk to another OpenStack API, but
this is completely unrelated to the concept of a resource.
Another way to define a resource is via a Heat template ("Provider"
resources, combined with environments). This is a convenient way for users
to define their own resources, and to layer additional data, logic and
dependencies on top of existing Heat built-in resources.
> A component is
> implemented by a bit of user code (and/or other sorts of instructions)
> embedded in or referenced by a template, with no fixed API and not invoked
> with Keystone credentials. We desire the heat engine to invoke operations
> on resources; we do not desire the heat engine to invoke components (the
> VMs do that themselves, via whatever bootstrapping mechanism is used). So
> yes, I do see fundamental differences. What am I missing?
A component is simply some user-provided data, possibly combined with some
logic, which needs to be passed to some resource (or service, or
in-instance tool) which knows how to interpret it.
So the existing resource interface is a perfectly appropriate abstraction
to use to describe what folks have been calling components, IMO.
If we can avoid creating a new template abstraction, we avoid a whole pile
of complexity, as well as user confusion - it's much better to leverage what
we have, unless the abstraction turns out to be fundamentally incompatible
with the feature (my argument is that it's not).
Steve
------------------------------
Message: 6
Date: Tue, 29 Oct 2013 07:23:14 +0000
From: Steven Hardy <shardy at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal
on HOT Software Config
Message-ID: <20131029072314.GE7801 at t430slt.redhat.com>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote:
> I believe we had a discussion about difference between declarative approach
> and workflows. A component approach is consistent with declarative format
> as all actions\operations are hidden inside the service. If you want to use
> actions and operations explicitly you will have to add a workflows specific
> language to HOT format. You will need to have some conditions and other
> control structures.
Please don't confuse the component/resource discussion further by adding
all these unrelated terms into the mix:
- Resources are declarative, components aren't in any way more declarative
- The resource/component discussion is unrelated to workflows, we're
discussing the template level interfaces.
- Adding imperative control-flow interfaces to the template is the opposite
of a declarative approach
> I also want to highlight that in most of examples on wiki pages there are
> actions instead of components. Just check names: install_mysql,
> configure_app.
Having descriptions of the actions required to do configure an application
is not declarative. Having a resource define the properties of the
application is.
> I think you revealed the major difference between resource and component.
> While the first has a fixed API and Heat already knows how to work with it,
A resource doesn't have a fixed API as such - it has flexible, user-definable
interfaces (inputs/properties and outputs/attributes)
> components are not determined and Heat does not know what this component
> actually does.
Heat doesn't need to know what a resource or component actually does, it
needs to know what do do with the inputs/properties, and how to obtain the
outputs/attributes.
> I remember the first draft for Software components and it
> had a specific examples for yum invocation for package installation. This
> is a good example of declarative component. When scripts and recipes
> appeared a component definition was blurred.
This makes no sense, scripts defining platform specific installation
methods are the exact opposite of a declarative component.
The blurred component definition you refer to is a very good reason not to
add a new abstraction IMO - we should focus on adding the functionality via
the existing, well understood interfaces.
Steve
------------------------------
Message: 7
Date: Tue, 29 Oct 2013 09:37:41 +0200
From: Alex Glikson <GLIKSON at il.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model
and APIs - Updated document with an example request payload
Message-ID:
<OF7A356ABA.03A94B01-ONC2257C13.002703EB-C2257C13.0029EBF9 at il.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Nice example.. I think this is certainly a step in the right direction.
However, I am a bit lost when trying to figure out how this kind of API
(which makes perfect sense at the conceptual level) can be implemented.
IMO, when we make the attempt to design the actual implementation that
would be provided behind the API, with all the inter-dependencies etc, it
might have significant impact on the API itself. Couple of specific
questions.
1. I assume that the motivation for rack-level anti-affinity is to survive
a rack failure. Is this indeed the case?
This is a very interesting and important scenario, but I am curious about
your assumptions regarding all the other OpenStack resources and services
in this respect. Recovering stateless VMs is probably the easiest part,
that can be done fairly quickly without instance groups (of course, not
with close to zero RTO that can be achieved with this approach -- but
probably few minutes, with some level of automation on top), so it would
be great to understand how this fits an overall approach to recovery from
a rack failure, basically referring to resources and metadata of all the
(other) OpenStack services (storage, network, images, etc). For example,
if we can claim that we already can achieve rack-level HA for the entire
environment with RTO of 1 hour, and with instance groups we improve it to
1 minute -- this would be very impressive!
2. What exactly do you mean by "network reachibility" between the two
groups? Remember that we are in Nova (at least for now), so we don't have
much visibility to the topology of the physical or virtual networks. Do
you have some concrete thoughts on how such policy can be enforced, in
presence of potentially complex environment managed by Neutron?
3. The JSON somewhat reminds me the interface of Heat, and I would assume
that certain capabilities that would be required to implement it would be
similar too. What is the proposed approach to 'harmonize' between the two,
in environments that include Heat? What would be end-to-end flow? For
example, who would do the orchestration of individual provisioning steps?
Would "create" operation delegate back to Heat for that? Also, how other
relationships managed by Heat (e.g., links to storage and network) would
be incorporated in such an end-to-end scenario?
Indeed, would be great if we could spend some time at the summit to
discuss the implementation details (and not just the API).
Regards,
Alex
From: "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
Date: 29/10/2013 08:49 AM
Subject: [openstack-dev] [nova][scheduler] Instance Group Model and
APIs - Updated document with an example request payload
The Instance Group API document is now updated with a simple example
request payload of a nested group, and some description of how the API
implementation should handle the registration of the components of a
nested instance group.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
Hope we will have a good API design session at the summit, and also
continue the discussion face-to-face over there.
Thanks,
Yathi.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/230e2e7b/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 29 Oct 2013 00:38:22 -0700
From: Nikhil Manchanda <nikhil at manchanda.me>
To: "OpenStack Development Mailing List"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Trove] Design Summit Etherpads
Message-ID: <m1bo28le6p.fsf at gmail.com>
Content-Type: text/plain
The list of Etherpads for the design summit sessions for Trove is now
posted at:
https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Trove
Feel free to add any relevant notes to the Etherpads.
Thanks,
Cheers,
-Nikhil
------------------------------
Message: 9
Date: Tue, 29 Oct 2013 08:48:48 +0100
From: Sylvain Bauza <sylvain.bauza at bull.net>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Full schedule for HongKong summit?
Message-ID: <526F6860.20209 at bull.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
I had the same concern, and only ended up exporting my Sched.org agendas
(the sessions I starred) to my own Google agenda (using iCal) in order
to see the conflicts.
Hope it can helps,
-Sylvain
Le 29/10/2013 04:08, Lu, Lianhao a ?crit :
> Hi all,
>
> Looks like we have http://icehousedesignsummit.sched.org/ for the summit session schedules and http://openstacksummitnovember2013.sched.org/ for presentations/panels schedules. Do we have a schedule combined both of the two?
>
> -Lianhao
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 10
Date: Tue, 29 Oct 2013 12:08:10 +0400
From: Dina Belova <dbelova at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Full schedule for HongKong summit?
Message-ID:
<CACsCO2z6qDUSpMmGMkFH4qjsimJWqYRDYrRygea8aPoCWwEnkA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
There is no such mixed calendar. It was made, as far as I remember, because
design and summit talks are very different and should be separated.
But still, it is not really comfortable.
On Tue, Oct 29, 2013 at 11:48 AM, Sylvain Bauza <sylvain.bauza at bull.net>wrote:
> I had the same concern, and only ended up exporting my Sched.org agendas
> (the sessions I starred) to my own Google agenda (using iCal) in order to
> see the conflicts.
>
> Hope it can helps,
> -Sylvain
>
> Le 29/10/2013 04:08, Lu, Lianhao a ?crit :
>
> Hi all,
>>
>> Looks like we have http://icehousedesignsummit.**sched.org/<http://icehousedesignsummit.sched.org/>for the summit session schedules and
>> http://**openstacksummitnovember2013.**sched.org/<http://openstacksummitnovember2013.sched.org/>for presentations/panels schedules. Do we have a schedule combined both of
>> the two?
>>
>> -Lianhao
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
--
Best regards,
Dina Belova
Software Engineer
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/097c4455/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 29 Oct 2013 09:29:28 +0100
From: Simon Pasquier <simon.pasquier at bull.net>
To: <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Security groups with XenAPI
Message-ID: <526F71E8.9020209 at bull.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi Bob,
Thanks for the reply.
Le 28/10/2013 17:47, Bob Ball a ?crit :
> Hi Simon,
>
> Yes, I believe you are right.
>
> We were already planning to discuss this very topic at the XenAPI roadmap session at the summit. Hopefully someone will take on tying up this loose end there.
>
> Security group support is the only thing we are aware of that is missing from the XenAPI neutron integration.
>
> Thanks for raising it - a bug report would be useful to track it!
Done => https://bugs.launchpad.net/neutron/+bug/1245809
>
> Bob
------------------------------
Message: 12
Date: Tue, 29 Oct 2013 17:50:29 +0900
From: haruka tanizawa <harubelle at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Message-ID:
<CAG=R24A1hnGBtytTMhm--zeeOyZhLNEQHByD7aD3L30+V8-z6w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all!
I proposed 'Idempotency for OpenStack API' as before.
In this time, I rewrote BP(
https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token ) and
I implemented proto of it.
I image below use-case.
User can't know instance ID when the client has gone away before user get
'create server' response of request.
So, User need to something which User can specify token like a mark.
In the service, which can also be a problem of charging.
In this case, idempotency client token is so useful.
To specify the token itself by User, User can know status of server.
How many times User put POST method, it is guaranteed the state of the POST
which was same with return of User's first POST request.
Moreover, I found that this BP(
https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency )
is based on my blueprint.
If you have any idea about or question, please feel free to discuss
anything.
** Also, I will attend HK summit.
Sincerely,
Haruka Tanizawa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/cd4d84c3/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 29 Oct 2013 10:09:16 +0100
From: Flavio Percoco <flavio at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Marconi] Design Summit Etherpads
Message-ID: <20131029090916.GC3577 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Greetings,
Here[0] you can find Marconi's etherpads for the Icehouse Design Summit.
[0] https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Marconi
--
@flaper87
Flavio Percoco
------------------------------
Message: 14
Date: Tue, 29 Oct 2013 13:19:16 +0400
From: Eugene Nikanorov <enikanorov at mirantis.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Neutron][LBaaS] Object status and
admin_state_up
Message-ID:
<CAJfiwORXCoPCtdjBg2RRUo+NCqEzAoAfYoW9yxBQmrX4pjVMUQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi folks,
Currently there are two attributes of vips/pools/members that represent a
status: 'status' and 'admin_state_up'.
The first one is used to represent deployment status and can be
PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR.
We also have admin_state_up which could be True or False.
I'd like to know your opinion on how to change 'status' attribute based on
admin_state_up changes.
For instance. If admin_state_up is updated to be False, how do you think
'status' should change?
Also, speaking of reference implementation (HAProxy), changing vip or pool
admin_state_up to False effectively destroys the balancer (undeploys it),
while the objects remain in ACTIVE state.
There are two options to fix this discrepancy:
1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes to
False
2) Don't destroy the loadbalancer and use HAProxy capability to disable
frontend and backend while leave vip/pool in ACTIVE state
Please share your opinion.
Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/4a0cfd37/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 29 Oct 2013 14:55:58 +0530
From: Rajshree Thorat <rajshree.thorat at gslab.com>
To: openstack Users <openstack at lists.openstack.org>, OpenStack
Development Mailing List <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] Unable to logging to guest console on
XCP/xenserver
Message-ID:
<CAPKJDd=x5SF_VD0d_zgZO9c6jkvi=f2TD=ouFZHx+QJfviT+hw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to use Openstack Havana to control XCP hypervisor with neutron
OVS plugin. I can launch instances normally but unable to logging to guest
console. Please see the below log from nova compute to get a clear idea.
Log:
2013-10-29 14:09:10.203 954 AUDIT nova.compute.manager
[req-157fb348-69fb-4b7f-b50c-44ef85e85f11 42ffb12172244726a1a15d044167de86
2c4acdf64eed40f7a9efcf3b7dd13259] [instance:
cf5678ec-5284-48cc-a8d6-005eac42118e] Get console output
2013-10-29 14:09:10.296 954 ERROR nova.virt.xenapi.vmops
[req-157fb348-69fb-4b7f-b50c-44ef85e85f11 42ffb12172244726a1a15d044167de86
2c4acdf64eed40f7a9efcf3b7dd13259] ['XENAPI_PLUGIN_FAILURE',
'get_console_log', 'IOError', "[Errno 2] No such file or directory:
'/var/log/xen/guest/console.7'"]
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops Traceback (most
recent call last):
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 1446, in
get_console_output
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops
'get_console_log', {'dom_id': dom_id})
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/driver.py", line 796, in
call_plugin
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops host, plugin,
fn, args)
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/driver.py", line 851, in
_unwrap_plugin_exceptions
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops return
func(*args, **kwargs)
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/local/lib/python2.7/dist-packages/XenAPI.py", line 229, in __call__
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops return
self.__send(self.__name, args)
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/local/lib/python2.7/dist-packages/XenAPI.py", line 133, in
xenapi_request
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops result =
_parse_result(getattr(self, methodname)(*full_params))
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops File
"/usr/local/lib/python2.7/dist-packages/XenAPI.py", line 203, in
_parse_result
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops raise
Failure(result['ErrorDescription'])
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops Failure:
['XENAPI_PLUGIN_FAILURE', 'get_console_log', 'IOError', "[Errno 2] No such
file or directory: '/var/log/xen/guest/console.7'"]
2013-10-29 14:09:10.296 954 TRACE nova.virt.xenapi.vmops
2013-10-29 14:09:10.358 954 ERROR nova.openstack.common.rpc.amqp
[req-157fb348-69fb-4b7f-b50c-44ef85e85f11 42ffb12172244726a1a15d044167de86
2c4acdf64eed40f7a9efcf3b7dd13259] Exception during message handling
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp Traceback
(most recent call last):
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line
461, in _process_data
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp **args)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py",
line 172, in dispatch
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp result
= getattr(proxyobj, method)(ctxt, **kwargs)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/exception.py", line 90, in wrapped
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp
payload)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/exception.py", line 73, in wrapped
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp return
f(self, context, *args, **kw)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 271, in
decorated_function
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp e,
sys.exc_info())
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 258, in
decorated_function
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp return
function(self, context, *args, **kwargs)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 3502, in
get_console_output
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp output
= self.driver.get_console_output(instance)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/driver.py", line 374, in
get_console_output
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp return
self._vmops.get_console_output(instance)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 1450, in
get_console_output
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp raise
exception.NovaException(msg)
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp
NovaException: Guest does not have a console available
2013-10-29 14:09:10.358 954 TRACE nova.openstack.common.rpc.amqp
2013-10-29 14:09:10.362 954 ERROR nova.openstack.common.rpc.common
[req-157fb348-69fb-4b7f-b50c-44ef85e85f11 42ffb12172244726a1a15d044167de86
2c4acdf64eed40f7a9efcf3b7dd13259] Returning exception Guest does not have a
console available to caller
Any pointers to debug the issue would be really helpful. Please let me know
how I can debug this issue.
Regards,
Rajshree
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/3c979f4d/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 29 Oct 2013 09:19:24 +0000
From: David koo <david.koo at huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model
and APIs - Updated document with an example request payload
Message-ID:
<B5A18EA8FCC1814E9B14B968A3C370423D0040D5 at szxeml558-mbx.china.huawei.com>
Content-Type: text/plain; charset="us-ascii"
Hi Yathi,
> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
Would it be possible to provide an alternate link to the doc? The GFW blocks google docs :(.
Thanks.
--
Koo
------------------------------
Message: 17
Date: Tue, 29 Oct 2013 11:01:20 +0100
From: Thierry Carrez <thierry at openstack.org>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] Reminder: Project & release status meeting -
21:00 UTC
Message-ID: <526F8770.1080806 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1
One week before the OpenStack Summit in Hong-Kong, this meeting should
be short. We will focus on solving the last conflicts with the tentative
Design Summit schedule and make it "official".
Feel free to add extra topics to the agenda:
[1] http://wiki.openstack.org/Meetings/ProjectMeeting
All program leads should be present (if you can't make it, please name a
substitute on [1]). Everyone else is very welcome to attend.
The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131029T21
Please doublecheck the meeting time since some parts of the world
dropped DST over the weekend.
See you there,
--
Thierry Carrez (ttx)
------------------------------
Message: 18
Date: Mon, 28 Oct 2013 19:22:08 +0000
From: "Robert Li (baoli)" <baoli at cisco.com>
To: Irena Berezovsky <irenab at mellanox.com>,
"prashant.upadhyaya at aricent.com" <prashant.upadhyaya at aricent.com>,
"yunhong.jiang at intel.com" <yunhong.jiang at intel.com>,
"chris.friesen at windriver.com" <chris.friesen at windriver.com>,
"yongli.he at intel.com" <yongli.he at intel.com>, Itzik Brown
<ItzikB at mellanox.com>
Cc: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
support
Message-ID:
<1705659276F6A540A34DBC19195799841027A7A4 at xmb-rcd-x03.cisco.com>
Content-Type: text/plain; charset="windows-1252"
Hi Irena,
Thank you very much for your comments. See inline.
--Robert
On 10/27/13 3:48 AM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi Robert,
Thank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest to bind Nova and Neutron?
The end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.
Normally, one will invoke "nova boot" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn't allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn't provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for 'nova boot':
-- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:
. PCI alias
. direct pci-passthrough/macvtap
. port profileid that is compliant with 802.1Qbh
The above information is optional. In the absence of them, the existing behavior remains.
-- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose
-- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.
-- Nova compute invokes neutron services with PCI passthrough information if any
-- Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It's also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:
binding:vif_type
binding:host_id
binding:profile
binding:capabilities
-- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.
The blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.
On the Neutron side, there is a need to support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.
I haven't sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.
During the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.
We want to integrate our solution with PCI pass-through Nova support. I will be glad to share more details if you are interested.
Good to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I'm interested in knowing its details.
The PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.
I agree. Maybe we can steal some time in that discussion.
Would you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?
Sure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.
Regards,
Irena
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Friday, October 25, 2013 11:16 PM
To: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi Irena,
This is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco's systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt), I registered a couple of blueprints (one on Nova side, the other on the Neutron side):
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov
in order to address SRIOV support in openstack.
Please take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.
I noticed that there is another thread on this topic, so copy those folks from that thread as well.
thanks,
Robert
On 10/16/13 4:32 PM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi,
As one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.
While nova takes care of PCI pass-through device resources management and VIF settings, neutron should manage their networking configuration.
I would like to register asummit proposal to discuss the support for PCI pass-through networking.
I am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.
There is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.
I think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.
Is there any other people who are interested to discuss it and share their thoughts and experience?
Regards,
Irena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/ba1ae583/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 29 Oct 2013 07:03:33 +0000
From: "Jiang, Yunhong" <yunhong.jiang at intel.com>
To: "Robert Li (baoli)" <baoli at cisco.com>, Irena Berezovsky
<irenab at mellanox.com>, "prashant.upadhyaya at aricent.com"
<prashant.upadhyaya at aricent.com>, "chris.friesen at windriver.com"
<chris.friesen at windriver.com>, "He, Yongli" <yongli.he at intel.com>,
"Itzik Brown" <ItzikB at mellanox.com>
Cc: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
support
Message-ID:
<DDCAE26804250545B9934A2056554AA01FBA9084 at ORSMSX108.amr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Robert, is it possible to have a IRC meeting? I'd prefer to IRC meeting because it's more openstack style and also can keep the minutes clearly.
To your flow, can you give more detailed example. For example, I can consider user specify the instance with -nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?
Thanks
--jyh
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Monday, October 28, 2013 12:22 PM
To: Irena Berezovsky; prashant.upadhyaya at aricent.com; Jiang, Yunhong; chris.friesen at windriver.com; He, Yongli; Itzik Brown
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi Irena,
Thank you very much for your comments. See inline.
--Robert
On 10/27/13 3:48 AM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi Robert,
Thank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest to bind Nova and Neutron?
The end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.
Normally, one will invoke "nova boot" api with the -nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn't allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn't provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for 'nova boot':
-- Specifies networking requirements in the -nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:
. PCI alias
. direct pci-passthrough/macvtap
. port profileid that is compliant with 802.1Qbh
The above information is optional. In the absence of them, the existing behavior remains.
-- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose
-- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.
-- Nova compute invokes neutron services with PCI passthrough information if any
-- Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It's also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the -nic option. Neutron returns nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:
binding:vif_type
binding:host_id
binding:profile
binding:capabilities
-- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.
The blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.
On the Neutron side, there is a need to support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.
I haven't sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.
During the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.
We want to integrate our solution with PCI pass-through Nova support. I will be glad to share more details if you are interested.
Good to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I'm interested in knowing its details.
The PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it's worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.
I agree. Maybe we can steal some time in that discussion.
Would you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?
Sure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.
Regards,
Irena
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Friday, October 25, 2013 11:16 PM
To: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi Irena,
This is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco's systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt), I registered a couple of blueprints (one on Nova side, the other on the Neutron side):
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov
in order to address SRIOV support in openstack.
Please take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.
I noticed that there is another thread on this topic, so copy those folks from that thread as well.
thanks,
Robert
On 10/16/13 4:32 PM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi,
As one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.
While nova takes care of PCI pass-through device resources management and VIF settings, neutron should manage their networking configuration.
I would like to register asummit proposal to discuss the support for PCI pass-through networking.
I am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.
There is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.
I think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.
Is there any other people who are interested to discuss it and share their thoughts and experience?
Regards,
Irena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/55aac05c/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 29 Oct 2013 10:06:44 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Blueprint review process
Message-ID:
<CABib2_qmXcywz7AQLZhxgtRZEVjdbsE6Ak3X__jdj7Ew5WbQCg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 28 October 2013 15:39, Anne Gentle <anne at openstack.org> wrote:
> On Mon, Oct 28, 2013 at 9:24 AM, John Garbutt <john at johngarbutt.com> wrote:
>> Here is a really bad attempt at codifying what I think about features vs
>> bugs:
>> 1) If its a new API call, or a change in behaviour, or a new config
>> setting, its a feature
>> 2) If its just refactoring or just adding tests, it is neither a
>> feature or a bug
>> 4) A bug is a change to ensure the system operates "as expected" by
>> the current documentation
>
> This line is the only one I have a little bit of concern with when looking
> across all projects. We just have to get better at documentation if we're
> going to make the docs the measure to log bugs against a project. John, your
> docs are really on target here, but I fear other projects would struggle to
> set expectations for how something is supposed to work. For example I don't
> think Hyper-V is documented much at all. So just be careful with this one,
> use good judgement, and keep this in mind when looking for docs to write.
Yes very good point. I was/am in two minds about that:
* Part of me wants to say: 5) if there is no documentation, it needs a
blueprint, so we can add some.
* The other part of me want's to say: "as expected" by the related
blueprint specification, documentation and current user expectations.
I am not sure which is best.
>>
>> 3) A bug should be changed to a feature if it matches case (1)
>>
>> If we don't approve the blueprint first, we may end up not having
>> enough information to create the required documentation, so I vote we
>> enforce that a blueprint should be approved before we merge code.
>>
>> Getting a blueprint approved as low priority, should be quicker and
>> easier than getting the associated code approved. Granted that might
>> not be the case today, but we need to fix that.
>>
------------------------------
Message: 21
Date: Tue, 29 Oct 2013 10:06:47 +0000
From: "Day, Phil" <philip.day at hp.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>, Russell Bryant
<rbryant at redhat.com>, Joe Gordon <joe.gordon0 at gmail.com>
Subject: Re: [openstack-dev] [Nova] Preserving ephemeral block device
on rebuild?
Message-ID:
<BD26CCD58723F74AA8E6BCB31052A1F006EA1ADF at G6W2490.americas.hpqcorp.net>
Content-Type: text/plain; charset="us-ascii"
Hi Rob,
I think it looks like a good option - but I'd like to see it exposed as such to the user rather than a change in the default behavior as such. I.e. "rebuild --keep-ephemenral=True ...."
Phil
> -----Original Message-----
> From: Robert Collins [mailto:robertc at robertcollins.net]
> Sent: 28 October 2013 02:00
> To: OpenStack Development Mailing List; Russell Bryant; Joe Gordon
> Subject: [openstack-dev] [Nova] Preserving ephemeral block device on
> rebuild?
>
> For context, in TripleO we have precious state to preserve when we push
> updates out to a cluster: nova instance volumes (obviously), swift data
> stores, mysql db's etc. We have a long term plan to have a volume model and
> interface that with Cinder, but thats an Ironic planed feature, and somewhat
> down the track : in the short term we'd like to use the ephemeral volume for
> such storage: it seems like 'nova rebuild' could easily be extended to
> preserve the ephemeral block device.
>
> From a nova bm perspective, all that needs to happen is for us to /not/
> format the volume - simples - and we can do that in the current rebuild code
> path where destroy + spawn is called, as long as we end up on the same
> host.
>
> However, we'd like to support this for libvirt too, because that lets us test
> workflows in virt rather than on purely baremetal (or emulated baremetal).
> For that, it looks to me like we need to push rebuild down a layer to the virt
> driver : so rather than destroy(); spawn(); have a
> rebuild() method that takes the same data spawn would, and will be able to
> preserve data as needed.
>
> Seeking thoughts on this - both the use of ephemeral in this way, and
> sketched out code change - are sought!
>
> Thanks,
> Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 22
Date: Tue, 29 Oct 2013 10:17:05 +0000
From: Irena Berezovsky <irenab at mellanox.com>
To: "Jiang, Yunhong" <yunhong.jiang at intel.com>, "Robert Li (baoli)"
<baoli at cisco.com>, "prashant.upadhyaya at aricent.com"
<prashant.upadhyaya at aricent.com>, "chris.friesen at windriver.com"
<chris.friesen at windriver.com>, "He, Yongli" <yongli.he at intel.com>,
"Itzik Brown" <ItzikB at mellanox.com>
Cc: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
support
Message-ID:
<9D25E123B44F4A4291F4B5C13DA94E778024CC05 at MTLDAG01.mtl.com>
Content-Type: text/plain; charset="us-ascii"
Hi Jiang, Robert,
IRC meeting option works for me.
If I understand your question below, you are looking for a way to tie up between requested virtual network(s) and requested PCI device(s). The way we did it in our solution is to map a provider:physical_network to an interface that represents the Physical Function. Every virtual network is bound to the provider:physical_network, so the PCI device should be allocated based on this mapping. We can map a PCI alias to the provider:physical_network.
Another topic to discuss is where the mapping between neutron port and PCI device should be managed. One way to solve it, is to propagate the allocated PCI device details to neutron on port creation.
In case there is no qbg/qbh support, VF networking configuration should be applied locally on the Host.
The question is when and how to apply networking configuration on the PCI device?
We see the following options:
* it can be done on port creation.
* It can be done when nova VIF driver is called for vNIC plugging. This will require to have all networking configuration available to the VIF driver or send request to the neutron server to obtain it.
* It can be done by having a dedicated L2 neutron agent on each Host that scans for allocated PCI devices and then retrieves networking configuration from the server and configures the device. The agent will be also responsible for managing update requests coming from the neutron server.
For macvtap vNIC type assignment, the networking configuration can be applied by a dedicated L2 neutron agent.
BR,
Irena
From: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]
Sent: Tuesday, October 29, 2013 9:04 AM
To: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com; chris.friesen at windriver.com; He, Yongli; Itzik Brown
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support
Robert, is it possible to have a IRC meeting? I'd prefer to IRC meeting because it's more openstack style and also can keep the minutes clearly.
To your flow, can you give more detailed example. For example, I can consider user specify the instance with -nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?
Thanks
--jyh
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Monday, October 28, 2013 12:22 PM
To: Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Jiang, Yunhong; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi Irena,
Thank you very much for your comments. See inline.
--Robert
On 10/27/13 3:48 AM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi Robert,
Thank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest to bind Nova and Neutron?
The end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.
Normally, one will invoke "nova boot" api with the -nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn't allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn't provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for 'nova boot':
-- Specifies networking requirements in the -nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:
. PCI alias
. direct pci-passthrough/macvtap
. port profileid that is compliant with 802.1Qbh
The above information is optional. In the absence of them, the existing behavior remains.
-- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose
-- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.
-- Nova compute invokes neutron services with PCI passthrough information if any
-- Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It's also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the -nic option. Neutron returns nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:
binding:vif_type
binding:host_id
binding:profile
binding:capabilities
-- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.
The blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.
On the Neutron side, there is a need to support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.
I haven't sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.
During the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.
We want to integrate our solution with PCI pass-through Nova support. I will be glad to share more details if you are interested.
Good to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I'm interested in knowing its details.
The PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it's worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.
I agree. Maybe we can steal some time in that discussion.
Would you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?
Sure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.
Regards,
Irena
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Friday, October 25, 2013 11:16 PM
To: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>
Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi Irena,
This is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco's systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt), I registered a couple of blueprints (one on Nova side, the other on the Neutron side):
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov
in order to address SRIOV support in openstack.
Please take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.
I noticed that there is another thread on this topic, so copy those folks from that thread as well.
thanks,
Robert
On 10/16/13 4:32 PM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:
Hi,
As one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.
While nova takes care of PCI pass-through device resources management and VIF settings, neutron should manage their networking configuration.
I would like to register asummit proposal to discuss the support for PCI pass-through networking.
I am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.
There is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.
I think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.
Is there any other people who are interested to discuss it and share their thoughts and experience?
Regards,
Irena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/f31f58b3/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 29 Oct 2013 23:20:20 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Preserving ephemeral block device
on rebuild?
Message-ID:
<CAJ3HoZ3iPyHK0zmydN5FpdMwPzEcrTjx0vmQP+Srbc=aBEHr8A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 29 October 2013 23:06, Day, Phil <philip.day at hp.com> wrote:
> Hi Rob,
>
> I think it looks like a good option - but I'd like to see it exposed as such to the user rather than a change in the default behavior as such. I.e. "rebuild --keep-ephemenral=True ...."
Oh, I must not have been clear. That was absolutely my intent.
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
------------------------------
Message: 24
Date: Tue, 29 Oct 2013 10:25:10 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Blueprint review process
Message-ID:
<CABib2_piPhxNvLiZX2TzETJxLUYoCwxGeb+J+E2mFORKcuDoDQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> John Garbutt wrote:
>> On 25 October 2013 11:52, Nikola ?ipanov <ndipanov at redhat.com> wrote:
>>> I don't have the numbers but I have a feeling that what happened in
>>> Havana was that a lot of blueprints slipped until the time for feature
>>> freeze. Reviewers thought it was a worthwile feature at that point (this
>>> was, I feel, when *actual* blueprint reviews are done - whatever the
>>> process says. It's natural too - once the code is there so much more is
>>> clear) and wanted to get it in - but it was late in the cycle so we
>>> ended up accepting things that could have been done better.
>>
>> Maybe we need a clarification around the priority, something like:
>> * the priority applies only to the target milestone when the priority was agreed
>> * should the blueprint move to a new milestone, the priority should be
>> reset to low priority
> We should definitely revise priority when a blueprint slips, I'm just
> not sure there is value in automatically resetting those to Low.
I am just wondering about the best way to communicate the revisiting
of all the priorities at the beginning of every milestone.
I want a way of saying:
* reviewers only sign up for a single milestone
* if you slip, you (the blueprint developer) need to go make your case
again (to raise the prioirty above low)
* in most cases the original reviewers will still have bandwidth to
help, so ask them first
* in many cases the reviewers may have already signed up for the next
milestone and re-priortiesed the blueprint for you
* but understand you are likely to have a lower priority after the
slip, and they could all say no, leaving you as low priority
I picked low rather than "none" because there is no reason to
re-approve the blueprint. If it was sane before, its probably still
OK, in most cases.
> Priorities are used to convey how critical a feature is to a given
> development cycle / release. When people look at our roadmap, they can
> assume that Essential stuff is more likely to make it than Low stuff.
> This is in turn reflected in weekly release status meetings where I nag
> about Essential/High stuff a lot, and I happily ignore Low stuff.
>
> We can't just reset Essential stuff to Low if it slips. It will likely
> stay Essential, it may drop to High, it could go to Low (but that sounds
> unlikely), it may be deferred. In the (hopefully rare) latter case, we
> should communicate that and why we did it to our community, so that they
> can recalibrate their expectations about what will probably be in the
> release.
I agree. I am just wondering about the best way to communicate the
"cost" of slipping.
John
------------------------------
Message: 25
Date: Tue, 29 Oct 2013 11:29:17 +0100
From: Thierry Carrez <thierry at openstack.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Full schedule for HongKong summit?
Message-ID: <526F8DFD.7040009 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1
Dina Belova wrote:
> There is no such mixed calendar. It was made, as far as I remember,
> because design and summit talks are very different and should be separated.
>
> But still, it is not really comfortable.
Yes, it's a bit of a trade-off...
In the past we had a lot of people, attracted by catchy session titles,
wandering in the design summit area and be really surprised by the
absence of presentations and the chaotic nature of the discussions
there. For this time around we decided that further separating the two
events (while keeping compatible time slots) was less confusing, and
keeping two separate schedules was the simplest way of making that happen.
I agree it's inconvenient for people who want to juggle between the two
parts of the event. The best solution for those is probably to look at
both schedules and use the iCal/ics exports to build your personal calendar:
http://icehousedesignsummit.sched.org/mobile-site
http://openstacksummitnovember2013.sched.org/mobile-site
Hope this helps,
--
Thierry Carrez (ttx)
------------------------------
Message: 26
Date: Tue, 29 Oct 2013 10:32:18 +0000
From: Joe Gordon <joe.gordon0 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Message-ID:
<CAHXdxOeJY0qh-Y=p=N-wnGxPMa5arr=MDfJh6MfzC5oJODZRvQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Oct 29, 2013 at 8:50 AM, haruka tanizawa <harubelle at gmail.com>wrote:
> Hi all!
>
>
> I proposed 'Idempotency for OpenStack API' as before.
> In this time, I rewrote BP(
> https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token )
> and I implemented proto of it.
>
>
> I image below use-case.
> User can't know instance ID when the client has gone away before user get
> 'create server' response of request.
> So, User need to something which User can specify token like a mark.
> In the service, which can also be a problem of charging.
>
> In this case, idempotency client token is so useful.
> To specify the token itself by User, User can know status of server.
> How many times User put POST method, it is guaranteed the state of the
> POST which was same with return of User's first POST request.
>
>
> Moreover, I found that this BP(
> https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency)
> is based on my blueprint.
>
>
> If you have any idea about or question, please feel free to discuss
> anything.
> ** Also, I will attend HK summit.
>
I like the idea but two comments:
* Can you fill out the questions found in
http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/
* Can you break down the blueprint into work items, so we can see what
steps are involved
* Since this is for OpenStack APIs only the name client-token makes me
think of keystone tokens, so I think we need a better name.
> Sincerely,
> Haruka Tanizawa
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/1467d648/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 29 Oct 2013 06:36:06 -0400
From: Sean Dague <sean at dague.net>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [nova] reason for python-novaclient revert
Message-ID: <526F8F96.8000405 at dague.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andrew Laski correctly called us out for not really proving enough
information n the python-novaclient revert yesterday -
https://review.openstack.org/#/c/54108/. Appologies there. At the time
we were dealing with a gate that grenade was failing every change (for
the prior 6 hours), we were all on our first cup of coffee, and while we
got to resolution, we did so with an entirely unuseful commit message to
explain it.
Here's what happened. python-novaclient landed a change that changed the
user interface. This change meant that devstack exercises failed on
validating the details on getting aggregates.
However, upgrade testing is hard, and we had a loophole, that led us to
a wedge in the gate.
For the grenade jobs we prep 2 versions of the OpenStack codebase,
grizzly and master (yes, still grizzly and master, we're working on
that). The grizzly tree is grizzly devstack, which means it's grizzly on
all the core servers, but master on all the clients. However, the
grizzly tree doesn't get "zuulified", which was the crux of the issue.
By zuulified I mean think about the zuul queue. How do we actually test
a change 15 deep in the gate? We aren't testing just that change, but
all the gerrit proposed changes above it. That means that zuul needs to
go through and update relevant git trees beyond master, but to the
proposed change sets for all the jobs in front of it. This is accross
projects, and should be across branches.
But we'd not gotten the system to do this correctly on the "old" side
yet. Which means that python-novaclient landed a breaking change, but
the "old" side built a grizzly cloud with only master, not master +
gerrit. It passed the verification of the "old" cloud, then moved to the
new cloud, then ran a different set of tests to verify the new cloud,
which passed.
However, by threading the needle in this way, it meant no one else could
ever pass grenade again. The quick fix was the python-novaclient revert.
The real fix is probably this - https://review.openstack.org/#/c/53940/
which we were actually working on last week, to both update the set of
trees we are using, and update the zuul refs on the "old" side of the
equation. Once that lands I'll attempt to revert the revert, and ensure
that it actually gets caught in the system. Then we can work on updating
tests so it can get through. But right now it's a perfect test case to
proove that we did this right, so leaving it in the reverted state is
critical.
This also highlights one of the reasons I've been hard on folks recently
about some alternative upgrade or mixed version testing models, and
doing it outside of grenade. Everything is simple when you talk about a
single change. But when you are 15 or 20 deep in zuul gate, and have to
handle 3 proposed stable nova changes, 5 proposed master nova changes, a
keystone stable, a keystone master, and a few cinder master changes in
front of you to build the environments you need to test in the gate....
this gets complicated fast. Basically you aren't allowed to use git
inside your upgrade tool for this reason, because your tool has no idea
what it's supposed to actually test, only ZUUL knows. And, as you can
see, we've yet to get this whole thing mapped out the first time. :)
-Sean
--
Sean Dague
http://dague.net
------------------------------
Message: 28
Date: Tue, 29 Oct 2013 10:36:23 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Preserving ephemeral block device
on rebuild?
Message-ID:
<CABib2_py1StRw=Sp_GNvkPjKGcix3+NQV8oUA1N+E3UjUd=9uQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 29 October 2013 10:20, Robert Collins <robertc at robertcollins.net> wrote:
> On 29 October 2013 23:06, Day, Phil <philip.day at hp.com> wrote:
>> Hi Rob,
>>
>> I think it looks like a good option - but I'd like to see it exposed as such to the user rather than a change in the default behavior as such. I.e. "rebuild --keep-ephemenral=True ...."
>
> Oh, I must not have been clear. That was absolutely my intent.
Ok, thinking about this more, I am cool with rebuild having a
--keep-ephemeral option. I have been thinking about adding the same
thing to migrate (for different reasons).
We should probably consider discussing the plan to deprecate Nova's
disk handing code a bit more at the summit, if thats the route we want
to take.
John
------------------------------
Message: 29
Date: Tue, 29 Oct 2013 10:46:51 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Cc: Itzik Brown <ItzikB at mellanox.com>
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
support
Message-ID:
<CABib2_o6tVKB+pEk6p-OByYd5ZF23JcMLM0yN37pcX6bHOHNAQ at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
I would love to see a symmetry between Cinder local volumes and
Neutron PCI passthrough VIFs.
Not entirely sure I have that clear in my head right now, but I just
wanted to share the idea:
* describe resource external to nova that is attached to VM in the API
(block device mapping and/or vif references)
* ideally the nova scheduler needs to be aware of the local capacity,
and how that relates to the above information (relates to the cross
service scheduling issues)
* state of the device should be stored by Neutron/Cinder
(attached/detached, capacity, IP, etc), but still exposed to the
"scheduler"
* connection params get given to Nova from Neutron/Cinder
* nova still has the vif driver or volume driver to make the final connection
* the disk should be formatted/expanded, and network info injected in
the same way as before (cloud-init, config drive, DHCP, etc)
John
On 29 October 2013 10:17, Irena Berezovsky <irenab at mellanox.com> wrote:
> Hi Jiang, Robert,
>
> IRC meeting option works for me.
>
> If I understand your question below, you are looking for a way to tie up
> between requested virtual network(s) and requested PCI device(s). The way we
> did it in our solution is to map a provider:physical_network to an
> interface that represents the Physical Function. Every virtual network is
> bound to the provider:physical_network, so the PCI device should be
> allocated based on this mapping. We can map a PCI alias to the
> provider:physical_network.
>
>
>
> Another topic to discuss is where the mapping between neutron port and PCI
> device should be managed. One way to solve it, is to propagate the allocated
> PCI device details to neutron on port creation.
>
> In case there is no qbg/qbh support, VF networking configuration should be
> applied locally on the Host.
>
> The question is when and how to apply networking configuration on the PCI
> device?
>
> We see the following options:
>
> ? it can be done on port creation.
>
> ? It can be done when nova VIF driver is called for vNIC plugging.
> This will require to have all networking configuration available to the VIF
> driver or send request to the neutron server to obtain it.
>
> ? It can be done by having a dedicated L2 neutron agent on each
> Host that scans for allocated PCI devices and then retrieves networking
> configuration from the server and configures the device. The agent will be
> also responsible for managing update requests coming from the neutron
> server.
>
>
>
> For macvtap vNIC type assignment, the networking configuration can be
> applied by a dedicated L2 neutron agent.
>
>
>
> BR,
>
> Irena
>
>
>
> From: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]
> Sent: Tuesday, October 29, 2013 9:04 AM
>
>
> To: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com;
> chris.friesen at windriver.com; He, Yongli; Itzik Brown
>
>
> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery
> (kmestery); Sandhya Dasu (sadasu)
> Subject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network
> support
>
>
>
> Robert, is it possible to have a IRC meeting? I?d prefer to IRC meeting
> because it?s more openstack style and also can keep the minutes clearly.
>
>
>
> To your flow, can you give more detailed example. For example, I can
> consider user specify the instance with ?nic option specify a network id,
> and then how nova device the requirement to the PCI device? I assume the
> network id should define the switches that the device can connect to , but
> how is that information translated to the PCI property requirement? Will
> this translation happen before the nova scheduler make host decision?
>
>
>
> Thanks
>
> --jyh
>
>
>
> From: Robert Li (baoli) [mailto:baoli at cisco.com]
> Sent: Monday, October 28, 2013 12:22 PM
> To: Irena Berezovsky; prashant.upadhyaya at aricent.com; Jiang, Yunhong;
> chris.friesen at windriver.com; He, Yongli; Itzik Brown
> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery
> (kmestery); Sandhya Dasu (sadasu)
> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
> support
>
>
>
> Hi Irena,
>
>
>
> Thank you very much for your comments. See inline.
>
>
>
> --Robert
>
>
>
> On 10/27/13 3:48 AM, "Irena Berezovsky" <irenab at mellanox.com> wrote:
>
>
>
> Hi Robert,
>
> Thank you very much for sharing the information regarding your efforts. Can
> you please share your idea of the end to end flow? How do you suggest to
> bind Nova and Neutron?
>
>
>
> The end to end flow is actually encompassed in the blueprints in a nutshell.
> I will reiterate it in below. The binding between Nova and Neutron occurs
> with the neutron v2 API that nova invokes in order to provision the neutron
> services. The vif driver is responsible for plugging in an instance onto the
> networking setup that neutron has created on the host.
>
>
>
> Normally, one will invoke "nova boot" api with the ?nic options to specify
> the nic with which the instance will be connected to the network. It
> currently allows net-id, fixed ip and/or port-id to be specified for the
> option. However, it doesn't allow one to specify special networking
> requirements for the instance. Thanks to the nova pci-passthrough work, one
> can specify PCI passthrough device(s) in the nova flavor. But it doesn't
> provide means to tie up these PCI devices in the case of ethernet adpators
> with networking services. Therefore the idea is actually simple as indicated
> by the blueprint titles, to provide means to tie up SRIOV devices with
> neutron services. A work flow would roughly look like this for 'nova boot':
>
>
>
> -- Specifies networking requirements in the ?nic option. Specifically
> for SRIOV, allow the following to be specified in addition to the existing
> required information:
>
> . PCI alias
>
> . direct pci-passthrough/macvtap
>
> . port profileid that is compliant with 802.1Qbh
>
>
>
> The above information is optional. In the absence of them, the
> existing behavior remains.
>
>
>
> -- if special networking requirements exist, Nova api creates PCI
> requests in the nova instance type for scheduling purpose
>
>
>
> -- Nova scheduler schedules the instance based on the requested flavor
> plus the PCI requests that are created for networking.
>
>
>
> -- Nova compute invokes neutron services with PCI passthrough
> information if any
>
>
>
> -- Neutron performs its normal operations based on the request, such
> as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it
> should validate the information such as profileid, and stores them in its
> db. It's also possible to associate a port profileid with a neutron network
> so that port profileid becomes optional in the ?nic option. Neutron returns
> nova the port information, especially for PCI passthrough related
> information in the port binding object. Currently, the port binding object
> contains the following information:
>
> binding:vif_type
>
> binding:host_id
>
> binding:profile
>
> binding:capabilities
>
>
>
> -- nova constructs the domain xml and plug in the instance by calling
> the vif driver. The vif driver can build up the interface xml based on the
> port binding information.
>
>
>
>
>
>
>
>
>
> The blueprints you registered make sense. On Nova side, there is a need to
> bind between requested virtual network and PCI device/interface to be
> allocated as vNIC.
>
> On the Neutron side, there is a need to support networking configuration of
> the vNIC. Neutron should be able to identify the PCI device/macvtap
> interface in order to apply configuration. I think it makes sense to provide
> neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow
> PCI pass-through vNIC support along with other networking technologies.
>
>
>
> I haven't sorted through this yet. A neutron port could be associated with a
> PCI device or not, which is a common feature, IMHO. However, a ML2 driver
> may be needed specific to a particular SRIOV technology.
>
>
>
>
>
> During the Havana Release, we introduced Mellanox Neutron plugin that
> enables networking via SRIOV pass-through devices or macvtap interfaces.
>
> We want to integrate our solution with PCI pass-through Nova support. I
> will be glad to share more details if you are interested.
>
>
>
>
>
> Good to know that you already have a SRIOV implementation. I found out some
> information online about the mlnx plugin, but need more time to get to know
> it better. And certainly I'm interested in knowing its details.
>
>
>
> The PCI pass-through networking support is planned to be discussed during
> the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth
> to drill down into more detailed proposal and present it during the summit,
> especially since it impacts both nova and neutron projects.
>
>
>
> I agree. Maybe we can steal some time in that discussion.
>
>
>
> Would you be interested in collaboration on this effort? Would you be
> interested to exchange more emails or set an IRC/WebEx meeting during this
> week before the summit?
>
>
>
> Sure. If folks want to discuss it before the summit, we can schedule a webex
> later this week. Or otherwise, we can continue the discussion with email.
>
>
>
>
>
>
>
> Regards,
>
> Irena
>
>
>
> From: Robert Li (baoli) [mailto:baoli at cisco.com]
> Sent: Friday, October 25, 2013 11:16 PM
> To: prashant.upadhyaya at aricent.com; Irena Berezovsky;
> yunhong.jiang at intel.com; chris.friesen at windriver.com; yongli.he at intel.com
> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery
> (kmestery); Sandhya Dasu (sadasu)
> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network
> support
>
>
>
> Hi Irena,
>
>
>
> This is Robert Li from Cisco Systems. Recently, I was tasked to investigate
> such support for Cisco's systems that support VM-FEX, which is a SRIOV
> technology supporting 802-1Qbh. I was able to bring up nova instances with
> SRIOV interfaces, and establish networking in between the instances that
> employes the SRIOV interfaces. Certainly, this was accomplished with hacking
> and some manual intervention. Based on this experience and my study with the
> two existing nova pci-passthrough blueprints that have been implemented and
> committed into Havana
> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and
> https://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt), I
> registered a couple of blueprints (one on Nova side, the other on the
> Neutron side):
>
>
>
> https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
>
> https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov
>
>
>
> in order to address SRIOV support in openstack.
>
>
>
> Please take a look at them and see if they make sense, and let me know any
> comments and questions. We can also discuss this in the summit, I suppose.
>
>
>
> I noticed that there is another thread on this topic, so copy those folks
> from that thread as well.
>
>
>
> thanks,
>
> Robert
>
>
>
> On 10/16/13 4:32 PM, "Irena Berezovsky" <irenab at mellanox.com> wrote:
>
>
>
> Hi,
>
> As one of the next steps for PCI pass-through I would like to discuss is the
> support for PCI pass-through vNIC.
>
> While nova takes care of PCI pass-through device resources management and
> VIF settings, neutron should manage their networking configuration.
>
> I would like to register asummit proposal to discuss the support for PCI
> pass-through networking.
>
> I am not sure what would be the right topic to discuss the PCI pass-through
> networking, since it involve both nova and neutron.
>
> There is already a session registered by Yongli on nova topic to discuss the
> PCI pass-through next steps.
>
> I think PCI pass-through networking is quite a big topic and it worth to
> have a separate discussion.
>
> Is there any other people who are interested to discuss it and share their
> thoughts and experience?
>
>
>
> Regards,
>
> Irena
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 30
Date: Tue, 29 Oct 2013 19:49:56 +0900
From: haruka tanizawa <harubelle at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Message-ID:
<CAG=R24CfadvQQw7pV3jk6WFo0FdQ8w2FvfwtnH1vUdjdCGYRjw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Joe!
Thank you for your reply and sharing the information.
I am going to rewrite blueprint from many point of view.
Sincerely,
Haruka Tanizawa
2013/10/29 Joe Gordon <joe.gordon0 at gmail.com>
>
>
>
> On Tue, Oct 29, 2013 at 8:50 AM, haruka tanizawa <harubelle at gmail.com>wrote:
>
>> Hi all!
>>
>>
>> I proposed 'Idempotency for OpenStack API' as before.
>> In this time, I rewrote BP(
>> https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token )
>> and I implemented proto of it.
>>
>>
>> I image below use-case.
>> User can't know instance ID when the client has gone away before user get
>> 'create server' response of request.
>> So, User need to something which User can specify token like a mark.
>> In the service, which can also be a problem of charging.
>>
>> In this case, idempotency client token is so useful.
>> To specify the token itself by User, User can know status of server.
>> How many times User put POST method, it is guaranteed the state of the
>> POST which was same with return of User's first POST request.
>>
>>
>> Moreover, I found that this BP(
>> https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency)
>> is based on my blueprint.
>>
>>
>> If you have any idea about or question, please feel free to discuss
>> anything.
>> ** Also, I will attend HK summit.
>>
>
> I like the idea but two comments:
>
> * Can you fill out the questions found in
> http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/
> * Can you break down the blueprint into work items, so we can see what
> steps are involved
> * Since this is for OpenStack APIs only the name client-token makes me
> think of keystone tokens, so I think we need a better name.
>
>> Sincerely,
>> Haruka Tanizawa
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/b2e2a4d3/attachment-0001.html>
------------------------------
Message: 31
Date: Tue, 29 Oct 2013 10:53:38 +0000
From: Joe Gordon <joe.gordon0 at gmail.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Remove vim modelines?
Message-ID:
<CAHXdxOfviZKUgBPrOwko7MskktB_QwW-2VhX_Oh1DWyTUDPiRA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
So after over 20 messages in this thread, now what?
>From my count we have 3 -, and 12 +1s. Is that enough for consensus? Do we
move modelines lines to the bottom? Put them in every file? Or just remove
them?
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z
https://review.openstack.org/#/c/51295/
On Mon, Oct 28, 2013 at 10:54 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> On Mon, Oct 28, 2013 at 9:35 AM, Alexis Lee <alexisl at hp.com> wrote:
>
>> As a new OpenStack contributor, +1 for lower barriers to entry. It's
>> helpful for OS to inform editor style and I don't believe in the
>> arguments to remove them.
>>
>> > Why remove them?
>> > * we could shrink our codebase by a little bit.
>>
>> Why do you want to shrink it? Simplify, sure, but modelines are not
>> code (not Python anyway). Even so, it's only one line per file.
>>
>> > * Modelines aren't supported by default in debian or ubuntu due to
>> > security reasons: https://wiki.python.org/moin/Vim
>>
>> As I believe with many Vim users, my .vimrc greatly predates my
>> involvement with OpenStack and it reflects my personal preferences (like
>> Termie's). I really wouldn't rely on the defaults surviving initial user
>> contact.
>>
>> > * Having modelines for vim means if someone wants we should support
>> > modelines for emacs
>> > (
>> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables
>> )
>>
>> I don't see a problem supporting Emacs, as the other major UNIX editor.
>> The slippery slope runs dry very quickly after that, I don't see gedit
>> users petitioning for inclusion (no offense intended to any gedit
>> devotees!).
>>
>> Alternatively Emacs users as self-proclaimed users of the bestest editor
>> ever could just install: https://github.com/cinsk/emacs-vim-modeline
>> and brag about how flexible their editor is.
>
>
>> > * There are other ways of making sure tabstop is set correctly for
>> > python files, see https://wiki.python.org/moin/Vim. I am a vIm user
>> > myself and have never used modelines.
>>
>> I am a Vim user and frequently use modelines! I like that they 'stick'
>> to files so even if a file gets separated from its project, the modeline
>> remains.
>>
>
> From an OpenStack point of view, that is not an issue. If a file gets
> separated then why should we worry about if it has a pep8 friendly tabstop?
>
>
>>
>> If I wanted to work on a project with style contrary to OpenStack's, I'd
>> need to write project-specific autocommands. It feels right to me that
>> if a project requires specific style, it should gate it (as OS does) and
>> provide some informative help as well (the modelines).
>>
>
> We don't just gate without telling people, the first two items in hacking
> are read pep8
>
> http://docs.openstack.org/developer/hacking/
>
>
>>
>> OS could provide a vim script to set up project-specific style but this
>> fails the barrier-to-entry test.
>>
>> > * We have vim modelines in only 828 out of 1213 python files in nova
>> > (68%), so if anyone is using modelines today, then it only works 68% of
>> > the time in nova
>>
>> Then we should fix that, in accordance with OS style guidelines.
>> It's also possible those are the high-touch files?
>>
>
> As of writing this email we don't OS style guidelines (hacking) don't
> require vim modelines. This thread is trying to resolve this.
>
>
>>
>> > * Why have the same config 828 times for one repo alone? This
>> > violates the DRY principle (Don't Repeat Yourself).
>>
>> Because afaik there's no standard way to inform editors of
>> project-specific style guidelines. Plus previously mentioned benefit of
>> stickiness.
>>
>
> PEP8 is hardly project specific.
>
>
>
>>
>>
>> John Dennis said on Fri, Oct 25, 2013 at 04:12:35PM -0400:
>> > Emacs... requires the per file variables to be the 1st line . So don't
>> > see how vim and emacs specifications will coexist nicely and stay that
>> > way consistently.
>>
>> What's the problem? Vim has no such limitation, Emacs can have 1st line
>> + Vim 2nd.
>>
>> > My personal feeling is you need to have enough awareness to configure
>> > your editor correctly to contribute to a project. It's your
>> > responsibility and our gate tools will hold you to that promise.
>>
>> That's not very welcoming. If a project want to be particular about
>> its style, it has a responsibilty to not just gate but also assist in
>> following that style.
>>
>
> We do try to make it easy to follow the style. Its fully documented here
> http://docs.openstack.org/developer/hacking/. Also the modeline we use
> is hardly enough to follow the style (80 char limit, spacing between
> functions, between classes etc.) And we provide several ways for a user to
> run the full set of style tests locally.
>
> * Install hacking locally (pip install hacking), and run 'flake8' - which
> has a really nice vim plugin too (https://github.com/nvie/vim-flake8)
> * Just run 'tox -epep8'
>
>
>
>> I should mention that not long ago I spent a good half day reading
>> OpenStack materials on "this is how things must be done", too long imho.
>>
>> > Let's just remove the mode lines, they really don't belong in every
>> file.
>>
>> Let's just leave them. It's a big change, some people like them and the
>> benefits of removal are minimal at best.
>>
>>
>> Alexis
>> --
>> Nova Engineer, HP Cloud. AKA lealexis, lxsli.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/0491be16/attachment-0001.html>
------------------------------
Message: 32
Date: Wed, 30 Oct 2013 00:17:38 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Remove vim modelines?
Message-ID:
<CAJ3HoZ3U4TuNRnWf4NtcL2X2f73H-ZxAcBK1e9cG65--kk4nXA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 28 October 2013 23:54, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> We don't just gate without telling people, the first two items in hacking
> are read pep8
>
> http://docs.openstack.org/developer/hacking/
The gate is super useful, but it's reactive, not proactive. And good
documentation isn't a replacement for just doing the right thing.
>> > * Why have the same config 828 times for one repo alone? This
>> > violates the DRY principle (Don't Repeat Yourself).
>>
>> Because afaik there's no standard way to inform editors of
>> project-specific style guidelines. Plus previously mentioned benefit of
>> stickiness.
>
>
> PEP8 is hardly project specific.
The definition of PEP8 is (moderately) global. The choice to use PEP8
is project specific.
>> That's not very welcoming. If a project want to be particular about
>> its style, it has a responsibilty to not just gate but also assist in
>> following that style.
>
> We do try to make it easy to follow the style. Its fully documented here
> http://docs.openstack.org/developer/hacking/. Also the modeline we use is
> hardly enough to follow the style (80 char limit, spacing between functions,
> between classes etc.) And we provide several ways for a user to run the full
> set of style tests locally.
Documentation isn't the same as helping. Yes, it's true that the modeline isn't
sufficient, but it does get some of the key variation project
guidelines tend to have: spaces and tabs.
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
------------------------------
Message: 33
Date: Tue, 29 Oct 2013 11:29:19 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][scheduler] Instance Group Model
and APIs - Updated document with an example request payload
Message-ID:
<CABib2_qnkvwcivDeouafPA4Ytrw1_-WWD1KqbYwJ2DobiZ+yGA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 29 October 2013 06:46, Yathiraj Udupi (yudupi) <yudupi at cisco.com> wrote:
> The Instance Group API document is now updated with a simple example request
> payload of a nested group, and some description of how the API
> implementation should handle the registration of the components of a nested
> instance group.
> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
>
> Hope we will have a good API design session at the summit, and also continue
> the discussion face-to-face over there.
Its looking good, but I was thinking about a slightly different approach:
* I would like to see instance groups be used to describe all
scheduler hints (including, please run on cell X, or please run on
hypervisor Y)
* passing old scheduler hints to the API will just create a new
instance group to persist the request
* ensure live-migrate/migrate never lets you violate the rules in the
user hints, at least don't allow it to happen by accident
* I was expecting to see hard and soft constraints/hints, like: try
keep in same switch, but make sure on separate servers
* Would be nice to have admin defined global options, like: "ensure
tenant does note have two servers on the same hypervisor" or soft
* I expected to see the existing boot server command simply have the
addition of a reference to a group, keeping the existing methods of
specifying multiple instances
* I aggree you can't change a group's spec once you have started some
VMs in that group, but you could then simply launch more VMs keeping
to the same policy
* New task API (see summit session) should help with the reporting if
the VM actually could be started or not, and the reason why it was not
possible
* augment the server details (and group?) with more location
information saying where the scheduler actually put things, obfuscated
on per tenant basis. So imagine nova, cinder, neutron exposing ordered
(arbitrary tagged) location metadata like nova: (("host_id", "foo"),
("switch_group_id": "bar"), ("power_group": "bas"))
* the above should help us define the "scope" of a constraint relative
to either a nova, cinder or neutron resource.
* Consider a constraint that includes constraints about groups, like
must be separate to group X, in the scope of the switch, or something
like that
* Need more thought on constraints between volumes, servers and
networks, I don't think edges are the right way to state that, I think
it would be better as a cross group constraint, where the scope of the
constraint is related to neutron.
Anyways, just a few thoughts I was having. Does that fit in with what
you were thinking?
John
------------------------------
Message: 34
Date: Tue, 29 Oct 2013 11:46:01 +0000
From: John Garbutt <john at johngarbutt.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][qa] user-oriented release notes
for v3 api?
Message-ID:
<CABib2_oWzxhPeL-HQ-++7go481HX+1rwfpA0zhnm8sjnikFs=g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 28 October 2013 23:40, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Tue, Oct 29, 2013 at 7:22 AM, David Kranz <dkranz at redhat.com> wrote:
>>
>> As I looked at the havana release notes that talk about the v3 api, and as
>> I was reviewing
>> "port test_images and test_server_actions into v3 part2"
>> https://review.openstack.org/#/c/39609/,
>> I saw some less-than-obvious differences. For example, the images/get it
>> seems now goes directly to glance which
>> results in the returned state being 'active' instead of 'ACTIVE' as it was
>> in v2. Another test was changed to expect the state to be
>> 'queued' when it used to be 'SAVING'. There are also all the changes
>> regarding CamelCase of dict keywords.
>>
>> I saw there was work on documenting the v3 api but doesn't there also need
>> to be some kind of release note that documents the incompatible changes that
>> users need to account for in their client code when they start pointing it
>> at a v3 server? Such a document would also make it much easier to review the
>> v3 api tests in tempest. Does such information exist already?
>>
>
> Unfortunately, no there isn't really - nothing that is specific to
> individual APIs. I've mainly been focussing on getting a V3 specification
> documentation up first (which I think is more important), but I do agree
> that a transition document would be very useful as well.
>
> This is a broad description of what was done:
>
> https://etherpad.openstack.org/p/NovaV3APIHavana
>
> which lists the types of changes which were made - eg CamelCase changes,
> removal of proxying of services like glance through Nova etc. But I agree we
> could do with something much better so its something we will do, I just
> can't make any guarantees of when it will be available yet.
+1 it would be a good doc to have ready by the end of Icehouse.
Was it also clear enough in the docs that the v3 API is not really
ready to use until Icehouse? There may be non-backwards compatible
changes made to the API while we polish it, I assume.
John
------------------------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
End of OpenStack-dev Digest, Vol 18, Issue 67
*********************************************
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
More information about the OpenStack-dev
mailing list