[Openstack] what is a problem??
hi, i have this error.. -- root@ubuntu:/home/khalid# gedit /etc/network/interfaces root@ubuntu:/home/khalid# sudo nova-manage network create 192.168.3.0/24 1 255 network does not match any options: user project role shell vpn floating root@ubuntu:/home/khalid# sudo nova-manage network create 192.168.3.0/24 1 255 network does not match any options: user project role shell vpn floating - no help?? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] what is a problem??
Your nova-manage command does not know the network subcommand. It only know the 6 it lists. This means you have a *very* old installation of Nova. You should upgrade to a more recent version. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] what is a problem??
2011/5/24 abbou khalid abbou.khali...@gmail.com: what abou this error: root@ubuntu:/home/khalid# sudo nova-manage db sync Command failed, please check log for more info I would guess that command was unsuccessful in some way. Perhaps you can find a hint in the log files as to what went wrong? (Remember to reply-to-all to keep this discussion on the mailing list) -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] what is a problem??
Hi, what this error: root@ubuntu:/home/khalid# sudo nova-manage db sync Command failed, please check log for more info tanks you all. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Reminder: OpenStack team meeting - 21:00 UTC
Hello everyone, Our weekly team meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please name a substitute on [2]. One week away from the first Diablo milestones, we'll discuss the status and priorities in preparation for those. Check out how that time translates for *your* timezone: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110524T21 See the meeting agenda, edit the wiki to add new topics for discussion: [2] http://wiki.openstack.org/Meetings Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to limit the total virtual processors/memory for one compute node?
Huang, If you are willing to modify code, you might want to take a look at the code at lp:~usc-isi/nova/hpc-trunk that has a scheduler (nova/scheduler/arch.py) that does not allow creating new instances if cpu or other resources are used up. If you have any question on the branch, please feel free to ask me. Thanks, Joseph - Original Message - From: Lorin Hochstein lo...@isi.edu To: Huang Zhiteng winsto...@gmail.com Cc: openstack@lists.launchpad.net Sent: Monday, May 23, 2011 11:00:22 PM Subject: Re: [Openstack] How to limit the total virtual processors/memory for one compute node? Hi Huang: You can use the simple scheduler, allocates new instances to hosts that have the fewest instances currently running. --scheduler_driver=nova.scheduler.simple.SimpleScheduler More sophisticated schedulers are currently under active development, but they haven't made it to the trunk yet. Take care, Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On May 23, 2011, at 10:00 PM, Huang Zhiteng wrote: Hi all, In my setup of Cactus, I found Nova scheduler would place newly created instance to a compute node that is already full occupied (in terms of memory or # of virtual processors), which lead to swapping and VP overcommitting. That would cause serious performance issue on a busy environment. So I was wondering if there's some kinda mechanism to limit to resource one compute node could use, something like the 'weight' in OpenNebula. I'm using Cactus (with GridDynamic's RHEL package), default scheduler policy, one zone only. Any suggestion? -- Regards Huang Zhiteng ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
On Mon, May 23, 2011 at 5:54 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. I'll bring the Festivus pole. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Only a small scream on PUT /zones/server/ PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Thanks to all for the input. I don't think we've really come to any conclusions for the near term. Unless someone screams, we will be proceeding along the following lines: 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Actually, I'm cool with it either way. I'm not really sure of the value in letting users generate their own Reservation ID though. What would the typical motivation be? That said, anyone else have preferences (PUT + user defined reservation ID's) vs. (POST + zone generated ID's)? -S From: Brian Lamar [brian.la...@rackspace.com] Sent: Tuesday, May 24, 2011 11:30 AM To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Only a small scream on PUT /zones/server/ PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Thanks to all for the input. I don't think we've really come to any conclusions for the near term. Unless someone screams, we will be proceeding along the following lines: 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
On May 24, 2011, at 10:30 AM, Brian Lamar wrote: Only a small scream on PUT /zones/server/ PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server. Agreed. Server creation should certainly be a POST. If we are going to add an optional parameter to specify the number of instances, would it be acceptable to specify that when that parameter is included, a reservation ID is returned instead of an instance ID? IOW, existing calls will work the same, but calls that take advantage of this new option would expect a different result. -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Hmm, not sure I like changing the return type based on the input type. Return types should be consistent. From: Ed Leafe If we are going to add an optional parameter to specify the number of instances, would it be acceptable to specify that when that parameter is included, a reservation ID is returned instead of an instance ID? IOW, existing calls will work the same, but calls that take advantage of this new option would expect a different result. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote: Hmm, not sure I like changing the return type based on the input type. Return types should be consistent. Agreed, but I liked changing the meaning of PUT even less. :) -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
On May 24, 2011, at 10:43 AM, Sandy Walsh wrote: I'm not really sure of the value in letting users generate their own Reservation ID though. What would the typical motivation be? That said, anyone else have preferences (PUT + user defined reservation ID's) vs. (POST + zone generated ID's)? Easy - user-generated reservation IDs would almost certainly result in duplicates. Imagine if 3rd parties using the API each set up a system that generated sequential integer reservation IDs... -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
I'm for zone-generated ids. If we take user input it is one more thing to sanitize and scope accordingly. As the number is essentially disposable, I don't know why they would care to provide one anyway, it just seems like changing who is responsible for making a uuid. On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: Actually, I'm cool with it either way. I'm not really sure of the value in letting users generate their own Reservation ID though. What would the typical motivation be? That said, anyone else have preferences (PUT + user defined reservation ID's) vs. (POST + zone generated ID's)? -S From: Brian Lamar [brian.la...@rackspace.com] Sent: Tuesday, May 24, 2011 11:30 AM To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Only a small scream on PUT /zones/server/ PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Thanks to all for the input. I don't think we've really come to any conclusions for the near term. Unless someone screams, we will be proceeding along the following lines: 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
POST isn't an issue for me. I honestly don't know why I wrote PUT ... I blame the Canadian holiday. From: Ed Leafe On May 24, 2011, at 11:05 AM, Sandy Walsh wrote: Hmm, not sure I like changing the return type based on the input type. Return types should be consistent. Agreed, but I liked changing the meaning of PUT even less. :) -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [NetStack] Quantum Service API extension proposal
Hi
I think I was unclear. What I meant were having network wire constructs
like a T where there are actually 3 end points and one of the end points
of the T could be in sniff mode or in a bump-in-the-wire mode. I am not
sure how the current API would support these semantics.
Use case: imagine vm A talks to B and one wants to monitor the content
by sniffing and the monitoring agent is in vm C. This is not a uncommon
use case.
Regards
Debo
-Original Message-
From: Kyle Mestery (kmestery)
Sent: Monday, May 23, 2011 4:54 PM
To: Debo Dutta (dedutta)
Cc: Troy Toman; openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
Debo:
A tap is nothing different than a VM vnics from a switch perspective, it
still contains a portion owned by Nova (the tap itself) and it connects
to a port, which is owned by Quantum. So in essence, the tap still has
both a vif and a port in this terminology.
Thanks,
Kyle
On May 23, 2011, at 4:10 PM, Debo Dutta (dedutta) wrote:
Hi Troy
What about a tap? Its also like a port Should that be in quantum?
Regards
Debo
From: Troy Toman [mailto:troy.to...@rackspace.com]
Sent: Monday, May 23, 2011 2:10 PM
To: Debo Dutta (dedutta)
Cc: Alex Neefus; Ying Liu (yinliu2); openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
I think the idea was slightly different. We were equating a vif to
NIC in a physical server. A port was equated to a switch port on a
physical switch. Doesn't necessarily mean they have to be different.
But, there was a reason we used different terminology.
In particular, we felt the vif was something that would continue to be
in the server's domain and managed within Nova. A port was a construct
that is owned and managed by the network service (Quantum).
Troy
On May 23, 2011, at 3:56 PM, Debo Dutta (dedutta) wrote:
Quick question: it seems we are calling one end of the virtual wire a
port and the other a vif. Is there a reason to do that? Can we just call
say that that a wire connects 2 ports?
Also another interesting network scenario is when there is a wire
connecting 2 ports and you have a tap (for all sorts of scenarios). I
think the semantics of the tap might be quite basic.
Regards
debo
From: openstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On
Behalf Of Alex Neefus
Sent: Monday, May 23, 2011 1:05 PM
To: Ying Liu (yinliu2); openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
Hi All -
I wanted to lend support to this proposal, however I don't think we
should be so quick to say this whole thing is an extension.
We benefit a lot from having a standard capabilities mechanism as part
of our core Quantum API. I like Ying's key value method as well. I think
it's logical, clean and scalable. I propose that basic read access of
cap off of our major objects: network, port, interface be included in
our first release.
So in summary I would like to encourage us to add:
GET /networks/{net_id}/conf
GET /networks/{net_id}/ports/{port_id}/conf/
GET {entity}/VIF/conf/
Each of these would return a list of keys.
Additionally Quantum base should support
GET /networks/{net_id}/conf/{key}
GET /networks/{net_id}/ports/{port_id}/conf/{key}
GET {entity}/VIF/conf/{key}
Where {key} is the name of either a standard capability or an
extention capability. We can define an error code now to designate a
capability not supported by the plugin. (i.e. 472 - CapNotSupported)
Finally we don't need to standardize on every capability that might be
supported if we provide this simple mechanism. Specific capabilities
Key,Value sets can be added later but or included as vendor specific
extensions.
I'm happy to add this to the wiki if there is consensus. Rick/Dan -
Maybe this should be a topic for Tuesdays meeting.
Alex
---
Alex Neefus
Senior System Engineer | Mellanox Technologies
(o) 617.337.3116 | (m) 201.208.5771 | (f) 617.337.3019
From: openstack-bounces+alex=mellanox@lists.launchpad.net
[mailto:openstack-bounces+alex=mellanox@lists.launchpad.net] On
Behalf Of Ying Liu (yinliu2)
Sent: Saturday, May 21, 2011 1:10 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] [NetStack] Quantum Service API extension proposal
Hi all,
We just posted a proposal for OpenStack Quantum Service API extension
on community wiki page
athttp://wiki.openstack.org/QuantumAPIExtensions?action=AttachFiledo=vi
ewtarget=quantum_api_extension.pdf
or
http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFiledo=view
target=quantum_api_extension.docx
Please review and let us know your comments/suggestions. An etherpad
page is created for API extension
discussionhttp://etherpad.openstack.org/uWXwqQNU4s
Best,
Ying
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Yup ... agreed. I'll press on in this direction (POST with zone generated ID's) -S From: Todd Willey [t...@ansolabs.com] Sent: Tuesday, May 24, 2011 12:13 PM To: Sandy Walsh Cc: Brian Lamar; openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... I'm for zone-generated ids. If we take user input it is one more thing to sanitize and scope accordingly. As the number is essentially disposable, I don't know why they would care to provide one anyway, it just seems like changing who is responsible for making a uuid. On Tue, May 24, 2011 at 10:43 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: Actually, I'm cool with it either way. I'm not really sure of the value in letting users generate their own Reservation ID though. What would the typical motivation be? That said, anyone else have preferences (PUT + user defined reservation ID's) vs. (POST + zone generated ID's)? -S From: Brian Lamar [brian.la...@rackspace.com] Sent: Tuesday, May 24, 2011 11:30 AM To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Only a small scream on PUT /zones/server/ PUT would work in my mind if we allowed users to create their own ReservationIDs, but since (I assume) we're generating them it would make more sense to me to use POST on /zones/server. -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Monday, May 23, 2011 5:54pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ... Thanks to all for the input. I don't think we've really come to any conclusions for the near term. Unless someone screams, we will be proceeding along the following lines: 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-instances parameter. (I'll refactor with the existing code to keep the duplication to a minimum) 2. python-novaclient will be extended to take an optional reservation ID for GET /servers, which will be used to list instances across zones based on Reservation ID None of this should affect the existing OS API or EC2 API functionality. We can have Feats of Strength later to decide how this should live on in an OS API 2.0 world. /me listens for the screams ... -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [NetStack] Quantum Service API extension proposal
Glad to see we are converging.
Couple of things/questions that we need to discuss/decide in our meeting
today.
1. For plugin-specific extensions - Option 1: Use DataExtension
scheme as in Jorge proposal with Key-Value pairs.
Any other options? Or just go with. BTW, I agree with this model.
2. Port Profile construct - To have it as part of Core API or we
don't need it now have, if any plugin wants it have it as a extension?
a. I see a great value in having the port profile as a core API
construct. Please refer to Ying's previous email.
3. If I understand correctly, I also see a valid point in Alex's
proposal - Use key-value pairs for Core API for standard capability, as
well.
a. Do we go with this or not?
Ram
From: openstack-bounces+radurair=cisco@lists.launchpad.net
[mailto:openstack-bounces+radurair=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, May 23, 2011 10:33 PM
To: Ying Liu (yinliu2)
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
Hi Ying,
Thanks for the detailed example. You are correct, this is inline with
what I was thinking.
A data extension mechanism like this would let any interested party
cleanly expose additional properties for API port objects, and as Alex
mentioned, potentially for API network objects as well. From an
internal Quantum architecture perspective, we'll have to discuss how
this data gets passed to the plugin, what validation happens at the API
layer, as well as how plugins are able go beyond basic data extension to
add new API methods and objects. This is what I'd like to tackle with
the blueprint:
https://blueprints.launchpad.net/network-service/+spec/quantum-api-exten
sions
During the meeting tomorrow we can see if people are largely on the same
page, in which case we can move on to the blueprint on this.
Dan
On Mon, May 23, 2011 at 7:48 PM, Ying Liu (yinliu2) yinl...@cisco.com
wrote:
Hi Dan,
Totally agree. Data Extensions is the way we can extend the key,
value list for non-base keys.
Actually, we can use this mechanism to extend the extensible key,
value construct proposed earlier, assuming that data construct is
already in the name space.
The extension can be something like this (pdf and wadl files defines
extension content):
extension name=Port Configuration Extension
namespace=http://docs.rackspacecloud.com/network/api/ext/conf/v1.0;
alias=CSCO-CONF
atom:link rel=describedby type=application/pdf
href=http://docs.ciscocloud.com/network/api/ext/net-conf-2011.pdf/
atom:link rel=describedby type=application/vnd.sun.wadl+xml
href=http://docs.ciscocloud.com/network/api/ext/net-conf.wadl/
description
Adds the configurations to the port.
/description
/extension
The data extension:
{
port : {
id : 8,
name : My L2 Network,
created_at : 2011-05-18 18:30:40,
status : Active,
configureations : {
COSO-CONF:acl : permit ip any 209.165.201.2
255.255.255.255,
vlan_segment : 5
}
}
Thus, the registration, discovery and promotion mechanism can all follow
the standard extension mechanism. Just my understanding, please correct
me if I missed something here.
Best,
Ying
From: Dan Wendlandt [mailto:d...@nicira.com]
Sent: Monday, May 23, 2011 4:54 PM
To: Alex Neefus
Cc: Ying Liu (yinliu2); openstack@lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal
On Mon, May 23, 2011 at 1:05 PM, Alex Neefus a...@mellanox.com wrote:
Hi All -
I wanted to lend support to this proposal, however I don't think we
should be so quick to say this whole thing is an extension.
Hi Alex, all,
I'd like to try and level-set here for a minute, as I don't believe
people are saying that such a mechanism itself would be an extension,
but rather that it would be a mechanism for plugins to expose
extensions.
Here is the situation as I understand it: I believe most people would
feel that having a conf/cap/profile attribute on ports and networks in
the core API is (at least) one reasonable way of letting plugins
exposing additional data via the Quantum API. Where the issue of
OpenStack extensions would come in is providing a mechanism to introduce
new key-value pairs to something like the conf/cap/profile attribute.
I'm not expert on API extensibility, but doing so seems to be a direct
application of the Data Extensions portion of the OpenStack extensions
proposal (see slide 29 of
http://www.slideshare.net/RackerWilliams/openstack-extensions)
The OpenStack extensions proposal focuses on standardizing several key
questions around introducing new data, such as these key-value pairs:
- How do you prevent naming conflicts between keys?
- How does
[Openstack] Fall Event 2011 discussion on forums
Just a note for those not watching the forums, Stephen just posted a topic about the Fall 2011 event - in case any of you would like to join/follow the discussion on that: http://opns.tk/4 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
2011/5/23 Sandy Walsh sandy.wa...@rackspace.com: To Soren's point about losing the ability to rely on a fixed set of topics in the message queue for doing scheduling this is not the case, there are no new topics introduced. That's not exactly what I meant. If we stuck with the simple flavours that we have right now, we could schedule stuff exclusively using the message queue. The scheduler would not need to know *anything* about the various compute nodes. Scheduling an instance of flavour X would be achieved simply by sending a run this instance message on the message queue with the flavour-X topic. Any compute node able to accommodate an instance of that size would be subscribed to that topic, and the message queue would simply route the message to a random one of them. As a compute node fills up, it'll unsubscribe from the topics representing flavours that it no longer has room for. This sounds Very Scalable[tm] to me :) Even if all the scheduling attributes we come up with were discrete and enumerable, the cartesian product of all of them is potentially *huge*, so having a topic for each of the possible combinations sounds like very little fun. If any of them are not enumerable, it gets even less fun. So, adding these capabilities would get in the way of implementing something like the above. I guess it could be a configuration option, i.e. if you choose the rich scheduling option set, you don't get to use the cool scheduler. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Branch coverage
Hi openstackers Coverage 3.4 supports branch a coverage feature now. http://nedbatchelder.com/code/coverage/branch.html We can use it on nose using dstanekcom-python-nose branch. I run it for nova. (See wiki page) http://wiki.openstack.org/branch_coverage # You can download a result of branch coverage. Is it possible to let http://jenkins.openstack.org/ support branch coverage? This feature helps QA of nova. Regards, Nachi Ueno ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
