Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
Hello all, I am part of the SF south bay meetup group and trying to add a Disk I/O QoS feature which is based on the blkiotune in libvirt. We would like to add flavor types in which we specify the blkiotune in the create flavor screen. After reviewing the discussions and some emails it appears that it makes sense to use the "instance_type_extra_specs" to add the blkiotune as a key/value pair instead of extending the "instance_type" table in nova db. I am able to use nova-manage to create instance type and use "set_key" to add extra specs. The set_key seems to make a direct call to the db to insert the keys whereas the instance_type create takes the more traditional path through the flavomanage controller. However I notice that there is no documentation on how to add the extra_specs keys using a RESTful api. Is this something still in discussions? Thanks Vinay On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit < patrick.michel.pe...@gmail.com> wrote: > Hi Don, > > I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding > your point. > Best regards, > Patrick > > 2012/8/24 Dugger, Donald D > > Patrick- >> >> ** ** >> >> We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, >> c.f. https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value, >> You can add an `extra_specs’ key/value pair to a flavor with the command: >> >> >> ** ** >> >> nova-manage instance_type add_key m1.humongous cpu_type >> itanium >> >> ** ** >> >> And delete a key/value pair with the command: >> >> ** ** >> >> nova-manage instance_type del_key m1.humongous cpu_type** >> ** >> >> ** ** >> >> We’re in the process of enhancing `python-novaclient’ and Horizon with >> similar capabilities and hope to have them ready for the Folsom release.* >> *** >> >> ** ** >> >> Currently, there’s no hook to set `extra_specs’ through the `nova.conf’ >> file, the mechanism is to dynamically add the `extra_specs’ key/values >> after the administrator has created a flavor. >> >> ** ** >> >> Currently, the keys are completely free form but there are some issues >> with that so that should change. Checkout the bug: >> >> ** ** >> >> https://bugs.launchpad.net/nova/+bug/1039386 >> >> ** ** >> >> Based upon that bug we need to put some sort of scope on the keys to >> indicate which components a key applies to. I’m in favor of adding a new >> column to the `extra_specs’ table that would explicitly set the scope but >> an alternative would be to encode the scope into the key itself, something >> like `TrustedFilter:trust’ to indicate that the `trust’ key only applies >> to the `TrustedFilter’ scheduler component. Feel free to chime in on the >> BZ entry on how to specify the scope, once we decide on how to deal with >> this I’ll create a patch to handle it. >> >> ** ** >> >> -- >> >> Don Dugger >> >> "Censeo Toto nos in Kansa esse decisse." - D. Gale >> >> Ph: 303/443-3786 >> >> ** ** >> >> *From:* >> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net[mailto: >> openstack-bounces+donald.d.dugger=intel@lists.launchpad.net] *On >> Behalf Of *Patrick Petit >> *Sent:* Friday, August 24, 2012 7:13 AM >> *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net) >> *Subject:* [Openstack] [Nova] Instance Type Extra Specs clarifications*** >> * >> >> ** ** >> >> Hi, >> >> ** ** >> >> Could someone give a practical overview of how configuring and using the >> instance type extra specs extension capability introduced in Folsom? >> >> ** ** >> >> If how extending an instance type is relatively clear. >> >> ** ** >> >> Eg.: #nova-manage instance_type set_key --name= --key >> --value <'s== x86_64'> >> >> ** ** >> >> The principles of capability advertising is less clearer. Is it assumed >> that the key/value pairs are always declared statically as flags in >> nova.conf of the compute node, or can they be generated dynamically and if >> so, who would that be? And also, are the keys completely free form strings >> or strings that are known (reserved) by Nova? >> >> ** ** >> >> Thanks in advance for clarifying this. >> >> ** ** >> >> Patrick >> > > > > -- > *"Give me a place to stand, and I shall move the earth with a lever"* > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] [Nova] Instance Type Extra Specs clarifications
Yes, the intent has been to use something along the lines of "OS-FLV-EXTRA-DATA:disk_qos" This leads to another question which I saw being discussed earlier in the email thread. Are we looking for consistency in adding the extra specs? For the most obvious ones it may be worth while to come up with a standardized convention for the names. I was looking at the code and it appears that the extra_specs and the instance_types creation don't have similar code flow. When you delete a instance_type that you created with extra_specs (using the set_key method in nova-manage), the extra_specs are not cleaned up. I would have thought that they should go away too, right? Unless I understood the concept of extra_specs wrong. Vinay On Fri, Sep 7, 2012 at 1:27 PM, Dugger, Donald D wrote: > Well, Yunhong added the API to allow you to update the extra specs table > so he should be able to give you the details on that (he’s in China, he > might not get back to you until next week). > > ** ** > > Also, make sure you add a scope (where scope is a string followed by a `:’ > at the beginning of the key) to whatever key you are adding to the extra > specs table, otherwise your key will create problems with some of the > scheduler filters. > > ** ** > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > ** ** > > *From:* Vinay Bannai [mailto:vban...@gmail.com] > *Sent:* Friday, September 07, 2012 2:20 PM > *To:* Patrick Petit > *Cc:* Dugger, Donald D; openstack@lists.launchpad.net ( > openstack@lists.launchpad.net) > *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > ** ** > > Hello all, > > ** ** > > I am part of the SF south bay meetup group and trying to add a Disk I/O > QoS feature which is based on the blkiotune in libvirt. > > We would like to add flavor types in which we specify the blkiotune in the > create flavor screen. After reviewing the discussions and some emails it > appears that it makes sense to use the "instance_type_extra_specs" to add > the blkiotune as a key/value pair instead of extending the "instance_type" > table in nova db. > > ** ** > > I am able to use nova-manage to create instance type and use "set_key" to > add extra specs. The set_key seems to make a direct call to the db to > insert the keys whereas the instance_type create takes the more traditional > path through the flavomanage controller. However I notice that there is no > documentation on how to add the extra_specs keys using a RESTful api. Is > this something still in discussions? > > ** ** > > Thanks > > Vinay > > ** ** > > On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit < > patrick.michel.pe...@gmail.com> wrote: > > Hi Don, > > ** ** > > I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding > your point. > > > Best regards, > > Patrick > > 2012/8/24 Dugger, Donald D > > ** ** > > Patrick- > > > > We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, c.f. > https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value, > You can add an `extra_specs’ key/value pair to a flavor with the command: > > > > > nova-manage instance_type add_key m1.humongous cpu_type > itanium > > > > And delete a key/value pair with the command: > > > > nova-manage instance_type del_key m1.humongous cpu_type*** > * > > > > We’re in the process of enhancing `python-novaclient’ and Horizon with > similar capabilities and hope to have them ready for the Folsom release.** > ** > > > > Currently, there’s no hook to set `extra_specs’ through the `nova.conf’ > file, the mechanism is to dynamically add the `extra_specs’ key/values > after the administrator has created a flavor. > > > > Currently, the keys are completely free form but there are some issues > with that so that should change. Checkout the bug: > > > > https://bugs.launchpad.net/nova/+bug/1039386 > > > > Based upon that bug we need to put some sort of scope on the keys to > indicate which components a key applies to. I’m in favor of adding a new > column to the `extra_specs’ table that would explicitly set the scope but > an alternative would be to encode the scope into the key itself, something > like `TrustedFilter:trust’ to indicate that the `trust’ key only applies > to the `TrustedFilter’ scheduler component.
Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
Thanks Yunhong, I picked your changes for flavors.py from your review to give it a try in my setup. I wrote a little python script to create a flavor id and set_key using the new RESTful apis that you defined. After creating the flavor, when I try to set the key I am getting error message from the nova side. Do I need pick to any changes from nova side to make it work? I can send you my sample code and error message privately or put it on the mailing list if that helps. Vinay On Sat, Sep 8, 2012 at 6:42 AM, Jiang, Yunhong wrote: > The extra_specs do have the RESTful interface as > “/flavors/flavor_type/os-extra_specs”. You can refer to > https://review.openstack.org/#/c/10768/ for some changes. (I didn’t > update the patch because I’m recently busy on another task, and will > restore that patch when I finish current task). > > ** ** > > Thanks > > --jyh > > ** ** > > *From:* Dugger, Donald D > *Sent:* Saturday, September 08, 2012 4:28 AM > *To:* Vinay Bannai; Patrick Petit; Jiang, Yunhong > *Cc:* openstack@lists.launchpad.net (openstack@lists.launchpad.net) > *Subject:* RE: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > ** ** > > Well, Yunhong added the API to allow you to update the extra specs table > so he should be able to give you the details on that (he’s in China, he > might not get back to you until next week). > > ** ** > > Also, make sure you add a scope (where scope is a string followed by a `:’ > at the beginning of the key) to whatever key you are adding to the extra > specs table, otherwise your key will create problems with some of the > scheduler filters. > > ** ** > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > ** ** > > *From:* Vinay Bannai [mailto:vban...@gmail.com] > *Sent:* Friday, September 07, 2012 2:20 PM > *To:* Patrick Petit > *Cc:* Dugger, Donald D; openstack@lists.launchpad.net ( > openstack@lists.launchpad.net) > *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > ** ** > > Hello all, > > ** ** > > I am part of the SF south bay meetup group and trying to add a Disk I/O > QoS feature which is based on the blkiotune in libvirt. > > We would like to add flavor types in which we specify the blkiotune in the > create flavor screen. After reviewing the discussions and some emails it > appears that it makes sense to use the "instance_type_extra_specs" to add > the blkiotune as a key/value pair instead of extending the "instance_type" > table in nova db. > > ** ** > > I am able to use nova-manage to create instance type and use "set_key" to > add extra specs. The set_key seems to make a direct call to the db to > insert the keys whereas the instance_type create takes the more traditional > path through the flavomanage controller. However I notice that there is no > documentation on how to add the extra_specs keys using a RESTful api. Is > this something still in discussions? > > ** ** > > Thanks > > Vinay > > ** ** > > On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit < > patrick.michel.pe...@gmail.com> wrote: > > Hi Don, > > ** ** > > I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding > your point. > > > Best regards, > > Patrick > > 2012/8/24 Dugger, Donald D > > ** ** > > Patrick- > > > > We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, c.f. > https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value, > You can add an `extra_specs’ key/value pair to a flavor with the command: > > > > > nova-manage instance_type add_key m1.humongous cpu_type > itanium > > > > And delete a key/value pair with the command: > > > > nova-manage instance_type del_key m1.humongous cpu_type*** > * > > > > We’re in the process of enhancing `python-novaclient’ and Horizon with > similar capabilities and hope to have them ready for the Folsom release.** > ** > > > > Currently, there’s no hook to set `extra_specs’ through the `nova.conf’ > file, the mechanism is to dynamically add the `extra_specs’ key/values > after the administrator has created a flavor. > > > > Currently, the keys are completely free form but there are some issues > with that so that should change. Checkout the bug: > > > > https://bugs.launchpad.net/nova/+bug/1039386 > >
Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
Sorry Yunhong, it was my mistake. I was able to get it to work with your changes. I am a little confused by the terminology of "instance_id" and "flavor_id" in the tables. Either their meaning is crossed or I am not reading it right. Vinay On Sat, Sep 8, 2012 at 12:02 PM, Vinay Bannai wrote: > Thanks Yunhong, > > I picked your changes for flavors.py from your review to give it a try in > my setup. I wrote a little python script to create a flavor id and set_key > using the new RESTful apis that you defined. After creating the flavor, > when I try to set the key I am getting error message from the nova side. > Do I need pick to any changes from nova side to make it work? I can send > you my sample code and error message privately or put it on the mailing > list if that helps. > > Vinay > > > On Sat, Sep 8, 2012 at 6:42 AM, Jiang, Yunhong wrote: > >> The extra_specs do have the RESTful interface as >> “/flavors/flavor_type/os-extra_specs”. You can refer to >> https://review.openstack.org/#/c/10768/ for some changes. (I didn’t >> update the patch because I’m recently busy on another task, and will >> restore that patch when I finish current task). >> >> ** ** >> >> Thanks**** >> >> --jyh >> >> ** ** >> >> *From:* Dugger, Donald D >> *Sent:* Saturday, September 08, 2012 4:28 AM >> *To:* Vinay Bannai; Patrick Petit; Jiang, Yunhong >> *Cc:* openstack@lists.launchpad.net (openstack@lists.launchpad.net) >> *Subject:* RE: [Openstack] [Nova] Instance Type Extra Specs >> clarifications >> >> ** ** >> >> Well, Yunhong added the API to allow you to update the extra specs table >> so he should be able to give you the details on that (he’s in China, he >> might not get back to you until next week). >> >> ** ** >> >> Also, make sure you add a scope (where scope is a string followed by a >> `:’ at the beginning of the key) to whatever key you are adding to the >> extra specs table, otherwise your key will create problems with some of the >> scheduler filters. >> >> ** ** >> >> -- >> >> Don Dugger >> >> "Censeo Toto nos in Kansa esse decisse." - D. Gale >> >> Ph: 303/443-3786 >> >> ** ** >> >> *From:* Vinay Bannai [mailto:vban...@gmail.com] >> *Sent:* Friday, September 07, 2012 2:20 PM >> *To:* Patrick Petit >> *Cc:* Dugger, Donald D; openstack@lists.launchpad.net ( >> openstack@lists.launchpad.net) >> *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs >> clarifications >> >> ** ** >> >> Hello all, >> >> ** ** >> >> I am part of the SF south bay meetup group and trying to add a Disk I/O >> QoS feature which is based on the blkiotune in libvirt. >> >> We would like to add flavor types in which we specify the blkiotune in >> the create flavor screen. After reviewing the discussions and some emails >> it appears that it makes sense to use the "instance_type_extra_specs" to >> add the blkiotune as a key/value pair instead of extending the >> "instance_type" table in nova db. >> >> ** ** >> >> I am able to use nova-manage to create instance type and use "set_key" to >> add extra specs. The set_key seems to make a direct call to the db to >> insert the keys whereas the instance_type create takes the more traditional >> path through the flavomanage controller. However I notice that there is no >> documentation on how to add the extra_specs keys using a RESTful api. Is >> this something still in discussions? >> >> ** ** >> >> Thanks >> >> Vinay >> >> ** ** >> >> On Tue, Aug 28, 2012 at 8:02 AM, Patrick Petit < >> patrick.michel.pe...@gmail.com> wrote: >> >> Hi Don, >> >> ** ** >> >> I added a comment in https://bugs.launchpad.net/nova/+bug/1039386regarding >> your point. >> >> >> Best regards, >> >> Patrick >> >> 2012/8/24 Dugger, Donald D >> >> ** ** >> >> Patrick- >> >> >> >> We’ve enhanced `nova-manage’ to manipulate the `extra_specs’ entries, >> c.f. https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value, >> You can add an `extra_specs’ key/value pair to a flavor with the command: >> >> >> >> >> nova-manage instance_type add_key m1.humongous cpu_type >> itanium &
Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
I am talking about the "instance_type_extra_specs" table. The instance_id and the flavor_id seem a little confusing. I saw an email thread from you from couple of weeks ago and you seem raise the same issue. On Sun, Sep 9, 2012 at 7:31 AM, Jiang, Yunhong wrote: > Glad that the patch works for you. > > ** ** > > For the instance_id and flavor_id, I’m not sure which table are you > talking about. But I think flavor_id is same as “instance_type_id”, while > instance_id is purely an id for an instance, which is usually created based > on an instance_type (or, flavor). > > ** ** > > Thanks**** > > --jyh > > ** ** > > *From:* Vinay Bannai [mailto:vban...@gmail.com] > *Sent:* Sunday, September 09, 2012 6:26 AM > *To:* Jiang, Yunhong > *Cc:* Dugger, Donald D; Patrick Petit; openstack@lists.launchpad.net ( > openstack@lists.launchpad.net) > > *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > ** ** > > Sorry Yunhong, it was my mistake. I was able to get it to work with your > changes. > > I am a little confused by the terminology of "instance_id" and "flavor_id" > in the tables. Either their meaning is crossed or I am not reading it > right. > > ** ** > > Vinay > > > On Sat, Sep 8, 2012 at 12:02 PM, Vinay Bannai wrote:** > ** > > Thanks Yunhong, > > ** ** > > I picked your changes for flavors.py from your review to give it a try in > my setup. I wrote a little python script to create a flavor id and set_key > using the new RESTful apis that you defined. After creating the flavor, > when I try to set the key I am getting error message from the nova side. * > *** > > Do I need pick to any changes from nova side to make it work? I can send > you my sample code and error message privately or put it on the mailing > list if that helps. > > ** ** > > Vinay > > ** ** > > On Sat, Sep 8, 2012 at 6:42 AM, Jiang, Yunhong > wrote: > > The extra_specs do have the RESTful interface as > “/flavors/flavor_type/os-extra_specs”. You can refer to > https://review.openstack.org/#/c/10768/ for some changes. (I didn’t > update the patch because I’m recently busy on another task, and will > restore that patch when I finish current task). > > > > Thanks > > --jyh > > > > *From:* Dugger, Donald D > *Sent:* Saturday, September 08, 2012 4:28 AM > *To:* Vinay Bannai; Patrick Petit; Jiang, Yunhong > *Cc:* openstack@lists.launchpad.net (openstack@lists.launchpad.net) > *Subject:* RE: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > > > Well, Yunhong added the API to allow you to update the extra specs table > so he should be able to give you the details on that (he’s in China, he > might not get back to you until next week). > > > > Also, make sure you add a scope (where scope is a string followed by a `:’ > at the beginning of the key) to whatever key you are adding to the extra > specs table, otherwise your key will create problems with some of the > scheduler filters. > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > *From:* Vinay Bannai [mailto:vban...@gmail.com] > *Sent:* Friday, September 07, 2012 2:20 PM > *To:* Patrick Petit > *Cc:* Dugger, Donald D; openstack@lists.launchpad.net ( > openstack@lists.launchpad.net) > *Subject:* Re: [Openstack] [Nova] Instance Type Extra Specs clarifications > > > > > Hello all, > > > > I am part of the SF south bay meetup group and trying to add a Disk I/O > QoS feature which is based on the blkiotune in libvirt. > > We would like to add flavor types in which we specify the blkiotune in the > create flavor screen. After reviewing the discussions and some emails it > appears that it makes sense to use the "instance_type_extra_specs" to add > the blkiotune as a key/value pair instead of extending the "instance_type" > table in nova db. > > > > I am able to use nova-manage to create instance type and use "set_key" to > add extra specs. The set_key seems to make a direct call to the db to > insert the keys whereas the instance_type create takes the more traditional > path through the flavomanage controller. However I notice that there is no > documentation on how to add the extra_specs keys using a RESTful api. Is > this something still in discussions? > > > > Thanks > > Vinay > > > > On Tu
Re: [Openstack] 回复： Can openstack guarantee each VM network bandwidth
Hello Willfu, We are working on a feature to add to flavor types that allows the administrator to specify the disk i/o operations. You get to specify the weight for the blkiotune parameter (from 100 to 1000) for the flavor that you created. This information would get stored as part of the instance type extra specs table. In the first step of our feature development, you get to create a instance type with this parameter. In the second part of our developoment we will allow VM creation based on the flavor type and take into consideration the blkiotune weight that is associated with the flavor type. We have not created a blueprint at this stage. Maybe we should. This is a group effort as part of the openstack hackathon that meets regularly at Yahoo in SF south bay. Vinay On Tue, Sep 11, 2012 at 1:40 AM, 延生 付 wrote: > This one seems to be a monitor component(correct me if wrong). > My point is controller, which can guarantee resources, > and make each vm issolation and fairness to use low level resources. > > Regards, > willfu > *发件人：* Ray Sun > *收件人：* 延生 付 > *抄送：* "openstack@lists.launchpad.net" > *发送日期：* 2012年9月11日, 星期二, 下午 4:17 > *主题:* Re: [Openstack] Can openstack guarantee each VM network bandwidth > > I don't think so. Sina has an open source project about this: > https://github.com/zyluo/kanyun > > - Ray > Yours faithfully, Kind regards. > > CIeNET Technologies (Beijing) Co., Ltd > Email: qsun01...@cienet.com.cn > Mobile Phone: 86-18901118291 > > > > On Tue, Sep 11, 2012 at 1:22 PM, 延生 付 wrote: > > > Hi stacker, > > I tried openstack several times, and there is a question always in there. > Can openstack issolate the low level resource usages for each VM instance? > such as network bandwith, diskio, cpu frequency etc. > Is there any api? > > Regards, > > willfu > > ___ > 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 > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] Use of MAC addresses in Openstack VMs
I was talking to Nachi and Gary during the Quantum design session about the need to have a proper MAC OUI allocation scheme for Openstack development folks. They suggested that I send it out for wider discussion on the mailing list. It turns out that it would be useful for the Openstack foundation to apply for a MAC OUI from IEEE that can be used for development purposes and testing. This way we don't unwittingly use someone else MAC allocation. Here are the details http://standards.ieee.org/develop/regauth/oui/index.html The cost to get a OUI allocation is around $2000 dollars. Remember if we use random MAC OUI, the actual owners can assert their legal claim on the MAC address in the event of a conflict now that we have support for more sophisticated tunnels that allow connections from public and private clouds. Comments welcome. Vinay ___ 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] Use of MAC addresses in Openstack VMs
Hi Salvatore, I agree with your suggestion that if we were all diligent and used locally administered OUI then it is not an issue. My concern now is that we are enabling pretty sophisticated tunneling mechanism in Quantum (as you know being a Quantum key contributor), there are more ways for the public and private clouds to be connected which leads to potential MAC conflicts. I am not sure if that is even possible and maybe my concerns are little too specific, but I figured someone will have a better insight that I do. As far your other comment about the service providers, you are right, they should use their own OUI for deploying VM's and network devices. My suggestion for the Openstack Foundation is to get an allocation that can be safely used by the growing community of developers and testers in Openstack without having to worry about any potential conflicts. This would be owned by Openstack Foundation and would not be used by Service Providers for deployment. Vinay On Sat, Oct 20, 2012 at 10:19 AM, Salvatore Orlando wrote: > Hi Vinay, > > I understand your concerns about conflicts with already assigned OUIs. > It is however my opinion that it is not up to the Openstack Foundation, > but to entities deploying Openstack, to buy MAC OUIs. > As regards Quantum, we should ensure the default MAC range we use is > locally assigned; unfortunately I do not know enough about nova-network. > Also, it is my opinion that a locally-assigned OUI would be sufficient for > many use cases, without the need for a globally assigned one. > > Regards, > Salvatore > > On 20 October 2012 04:05, Vinay Bannai wrote: > >> I was talking to Nachi and Gary during the Quantum design session about >> the need to have a proper MAC OUI allocation scheme for Openstack >> development folks. They suggested that I send it out for wider discussion >> on the mailing list. >> >> It turns out that it would be useful for the Openstack foundation to >> apply for a MAC OUI from IEEE that can be used for development purposes and >> testing. This way we don't unwittingly use someone else MAC allocation. >> Here are the details >> >> http://standards.ieee.org/develop/regauth/oui/index.html >> >> The cost to get a OUI allocation is around $2000 dollars. Remember if we >> use random MAC OUI, the actual owners can assert their legal claim on the >> MAC address in the event of a conflict now that we have support for more >> sophisticated tunnels that allow connections from public and private >> clouds. >> >> Comments welcome. >> >> Vinay >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] Use of MAC addresses in Openstack VMs
+1 from my end. This was basically what we discussed at the quantum design session. I think you put it more eloquently. Sent from my iPhone On Oct 23, 2012, at 1:36 AM, Thierry Carrez wrote: > Nachi Ueno wrote: >> My proposal is the default OUI value should be owned by OpenStack >> foundation if $2000 isn't concern for OpenStack foundation. > > To summarize the discussion so far, it is suggested that the OpenStack > Foundation could buy a OUI that we'd use as the default value, rather > than a random one that may be used by someone else. That one would be > used for development, while all serious deployers are encouraged to get > their own. > > The issue reported with that is that it creates a smaller space for > collision amongst OpenStack users. Encouraging people to use > locally-assigned OUI or buy their own might therefore be a better strategy. > > More thoughts ? > > -- > Thierry Carrez (ttx) > > > ___ > 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] Why OpenStack use openvpn?
Hao, I think Thierry and Nachi captured it well in their email responses to the thread. The Openstack foundation would (should) get a MAC OUI allocation from IEEE RAC that will be used as default instead of using the current default locally administered base_mac of fa:16:3e:00:00:00. Nothing more complicated than that. Vinay On Thu, Oct 25, 2012 at 7:26 AM, Hao Wang wrote: > Yep, I agree with you, Vish. My 2 cents, for the thread mentioning MAC > OUI, it's about site-to-site connection. It's not implemented yet by > cloudpipe. That probably is a feature in next version. Vinay, is what I > am guessing correct? > > Thanks, > Howard > > > On Wed, Oct 24, 2012 at 6:31 AM, Vishvananda Ishaya > wrote: > >> >> On Oct 22, 2012, at 5:06 PM, Hao Wang wrote: >> >> >> First, why we use openvpn? I know it's kind of arch question, like how to >> choose a right opensource software. On the other way, please let me know >> your point why we don't choose IPSEC or other VPNs. >> >> >> It was somewhat arbitrary based on the fact that it is easy to setup on >> linux and there were clients on all platforms that did not require root >> access to install. >> >> >> Vish >> > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] [quantum] Relationship between br-int and physical bridge mapping in OVS plugin
I have a multi node setup. The CC controller doubles up as the quantum server and also has the l3 agent and DHCP. I have configured OVS as my L2 plugin with vlan tunneling. On the compute nodes, I see that in addition to having the integration bridge (br-int) you will also need the ovs physical bridge (br-th1) with the physical ether port eth1 as a member. I am wondering about the relationship between br-int and br-eth1 bridges. Wouldn't it make sense to add eth1 port to the integration mode. Why have two bridges on the compute node for VMs to talk to other VMs in the same tenancy over the physical network? I am sure I am missing something in my understanding so would appreciate any comments or explanations. Thanks Vinay ___ 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] [quantum] Relationship between br-int and physical bridge mapping in OVS plugin
Yes, that makes sense. I was not thinking about multiple physical nics in the provider network space. I am trying to get a better understanding of how the vif plugins in the br-int and the bridge providing external connectivity interact. The quantum vif plug-in will do the work to configure the br-ext for tunneling (whether it is vlan or gre). In my two node setup (controller node and compute node), I am able to all my VM's instantiated properly. The controller also has n-cpu running so I get an even distribution of the vm's between the controller node and the compute nodes. The DHCP IP address is allocated fine. However when I try to vnc or ping the VM's, I am only able to get to the VM's on the controller node. I am not able to ping the instances created on the compute node. I am thinking that there is problem in my phsynet connectivity as the instances I am not able to get to are on the compute node. I have vlan tunneling enabled and here is my snippet of the ovs_quantum_plugin.ini file on the compute and controller node. Any pointers on where to look? [OVS] bridge_mappings = physnet1:br-eth2 network_vlan_ranges = physnet1:1:4094 tenant_network_type = vlan Thanks Vinay On Sun, Nov 4, 2012 at 10:44 PM, Dan Wendlandt wrote: > > > > On Sun, Nov 4, 2012 at 9:57 PM, Vinay Bannai wrote: > >> I have a multi node setup. The CC controller doubles up as the quantum >> server and also has the l3 agent and DHCP. I have configured OVS as my >> L2 plugin with vlan tunneling. On the compute nodes, I see that in >> addition to having the integration bridge (br-int) you will also need >> the ovs physical bridge (br-th1) with the physical ether port eth1 as >> a member. I am wondering about the relationship between br-int and >> br-eth1 bridges. Wouldn't it make sense to add eth1 port to the >> integration mode. > > > you might have quantum networks that use vlans on different on different > physical NICs (e.g., eth0 and eth1), so adding each NIC directly to br-int > wouldn't make sense. Similarly, you might have some quantum networks that > also use tunneling. Hence, all vNICs are just plugged into br-int, and the > plugin is responsible for doing the right thing with the traffic. > > Dan > > > > >> Why have two bridges on the compute node for VMs to >> talk to other VMs in the same tenancy over the physical network? >> I am sure I am missing something in my understanding so would >> appreciate any comments or explanations. >> >> Thanks >> Vinay >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > ~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~ > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] [quantum] Relationship between br-int and physical bridge mapping in OVS plugin
Thanks Dennis. I don't have a switch in-between the two nodes so I don't have the default native VLAN issue. The two nodes are connected back to back. I managed to console into the VM's on the compute node and saw that they don't have the IP address. The VM's on the controller node (also where the dhcp agent and quantum server are located) seem to get the IP address. To test the hypothesis, I created a separate network with the command that you mention below for the "demo" tenant and was able to spawn the VM's. I see the same problem on the compute node VM's not getting the IP address assigned. Has anyone who has been able to setup the VLAN tunnels successfully share their config files? Thanks Vinay On Mon, Nov 5, 2012 at 10:37 AM, Qin, Xiaohong wrote: > Hi Vinay, > > ** ** > > I have sent the following email out a while ago, > > ** ** > > --- > > In the following quantum command, > > ** ** > > quantum net-create --tenant-id $TENANT_ID net1 --provider:network_type > vlan --provider:physical_network physnet1 --provider:segmentation_id 1024* > *** > > ** ** > > provider:segmentation_id is actually a VLAN id which is used in the > network for controller and compute nodes. This same VLAN id is also passed > to the physical switch that interconnects controller and compute nodes. Try > to avoid use VLAN id 1 since some physical switches do not forward VLAN 1 > frames by default. > > -- > > ** ** > > This is the problem we were running into when setting up multi node > deployment. Not sure if it helps or not. > > ** ** > > Dennis Qin > > ** ** > > ** ** > > *From:* openstack-bounces+xiaohong.qin=emc@lists.launchpad.net[mailto: > openstack-bounces+xiaohong.qin=emc@lists.launchpad.net] *On Behalf Of > *Vinay Bannai > *Sent:* Monday, November 05, 2012 10:05 AM > *To:* Dan Wendlandt > *Cc:* Openstack > *Subject:* Re: [Openstack] [quantum] Relationship between br-int and > physical bridge mapping in OVS plugin > > ** ** > > Yes, that makes sense. I was not thinking about multiple physical nics in > the provider network space. > > ** ** > > I am trying to get a better understanding of how the vif plugins in the > br-int and the bridge providing external connectivity interact. > > The quantum vif plug-in will do the work to configure the br-ext for > tunneling (whether it is vlan or gre). > > ** ** > > In my two node setup (controller node and compute node), I am able to all > my VM's instantiated properly. The controller also has n-cpu running so I > get an even distribution of the vm's between the controller node and the > compute nodes. The DHCP IP address is allocated fine. However when I try to > vnc or ping the VM's, I am only able to get to the VM's on the controller > node. I am not able to ping the instances created on the compute node. I am > thinking that there is problem in my phsynet connectivity as the instances > I am not able to get to are on the compute node. > > I have vlan tunneling enabled and here is my snippet of the > ovs_quantum_plugin.ini file on the compute and controller node. Any > pointers on where to look? > > ** ** > > [OVS]**** > > bridge_mappings = physnet1:br-eth2 > > network_vlan_ranges = physnet1:1:4094 > > tenant_network_type = vlan > > ** ** > > ** ** > > Thanks > > Vinay > > On Sun, Nov 4, 2012 at 10:44 PM, Dan Wendlandt wrote: > > ** ** > > ** ** > > On Sun, Nov 4, 2012 at 9:57 PM, Vinay Bannai wrote:*** > * > > I have a multi node setup. The CC controller doubles up as the quantum > server and also has the l3 agent and DHCP. I have configured OVS as my > L2 plugin with vlan tunneling. On the compute nodes, I see that in > addition to having the integration bridge (br-int) you will also need > the ovs physical bridge (br-th1) with the physical ether port eth1 as > a member. I am wondering about the relationship between br-int and > br-eth1 bridges. Wouldn't it make sense to add eth1 port to the > integration mode. > > ** ** > > you might have quantum networks that use vlans on different on different > physical NICs (e.g., eth0 and eth1), so adding each NIC directly to br-int > wouldn't make sense. Similarly, you might have some quantum networks that > also use tunneling. Hence, all vNICs are just plugged into br-int, and the > plugin is responsible for doing the right thing with the traffic. > > ** ** > > Dan > > ** ** > > ** ** > > > > Why have two bridges o
Re: [Openstack] how to use extra_specs??
The simplest way would be to create key/value pairs for flavor types (instance types). This information would be associated in a separate table in nova db (instance_type_extra_specs) and would go along with the instance type. Once it is in the database, you can use this information to customize all kinds of things like the nova scheduler, additional data that can be passed to the instance at the time of the creation. This is the high level overview. If you search the mailing list archives you will find some additional discussion about this topic. Vinay On Mon, Nov 5, 2012 at 5:57 PM, Mauch, Viktor (SCC) wrote: > Hi guys, > > ** ** > > can anyone tell me (with an example) how to use the extra_specs variable > for an instance_type?? > > ** ** > > Best Regards > > ** ** > > Viktor > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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] [Nova] use the wrong deleted flavor when boot an instance after creating flavor with same flavorid as the deleted one
Look at the following bugs for context https://bugs.launchpad.net/nova/+bug/981263 https://bugs.launchpad.net/horizon/+bug/1057799 On Nov 8, 2012, at 7:36 PM, Wangpan wrote: Hi all, I use the folsom openstack recently. I found a problem that when I delete a flavor by using 'nova-manage flavor delete', and then I create a new one which use the same "flavorid" as the "DELETED" flavor a moment ago, then I check the instance_types table in nova DB, there have two records with the SAME "flavorid", and the "DELETED" one is marked as 'deleted=1'. The issue is when I use nova boot --flavor "flavorid or name be created" to create an instance, it uses the "DELETED" one, not the one I create! is this a bug or my misoperation? Thanks in advance! 2012-11-09 -- Wangpan ___ 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
[Openstack] [Quantum} using network id for booting a vm
I see that when booting a vm using nova cli command, the "--nic net-id" option takes a network id. What is the rationale behind that? Why is not a subnet-id? -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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][quantum] stuck subnet
I don't know of any elegant solution but one option may be to database and delete the individual records along with the all the interconnected records. On Thu, Apr 25, 2013 at 12:13 PM, Steve Heistand wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > so I had a tenant that was assigned a floating IP. I deleted the project > before > I freed up the floating IP. Now I cant clean up a subnet as it still thinks > there is an IP attached to it. > any ideas how to get rid of a subnet when it thinks there is a float > assigned to it that is owned by a tenant that doesnt exist? > > thanks > s > > - -- > > Steve Heistand NASA Ames Research Center > email: steve.heist...@nasa.gov Steve Heistand/Mail Stop 258-6 > ph: (650) 604-4369 Bldg. 258, Rm. 232-5 > Scientific & HPC ApplicationP.O. Box 1 > Development/OptimizationMoffett Field, CA 94035-0001 > > "Any opinions expressed are those of our alien overlords, not my own." > > # For Remedy# > #Action: Resolve# > #Resolution: Resolved # > #Reason: No Further Action Required # > #Tier1: User Code # > #Tier2: Other # > #Tier3: Assistance # > #Notification: None # > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEARECAAYFAlF5gEQACgkQoBCTJSAkVrHFOgCg6rIHRsD2BAoi5xrq5eM553qD > accAoOcRHeSXdmJ8HlDAYGgHRpKYuEXm > =zq/V > -END PGP SIGNATURE- > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
