[Openstack] [Nova] Last day for diablo-3 feature merges -- please review !
Hi everyone, Today is the last day for diablo-3 feature merges in Nova, as I will cut the milestone branch early Tuesday morning. We have several features that are very close to making it, and it would be great to have them in the milestone so that they get wider testing... So please spend some time today reviewing, in descending order of priority: Network refactoring (Essential) https://code.launchpad.net/~midokura/nova/network-refactoring-l2/+merge/68840 This one already got two positive non-nova-core reviews, so it might just need some more attention from core dudes ! Boot from volumes (High) https://code.launchpad.net/~yamahata/nova/boot-from-volume-2/+merge/68496 This one got a first round of comments that were addressed, so it might also not be far away ! Give it some love :) https://code.launchpad.net/~tamura-yoshiaki/nova/boot-from-volume-os-api/+merge/66742 This complementary one was recently refreshed, and it would make a nice bundle with the first one. Block migration (Low) https://code.launchpad.net/~nttdata/nova/block-migration/+merge/64662 This one is WIP but might just need the final roundtrip, so I hope it can make it, if Vish and Kei Masumoto can resolve the last issue ;) Additionally, we need to merge the updated translations in trunk before the milestone branch is cut tomorrow, so please doublecheck and ack: https://code.launchpad.net/~ttx/nova/d3-translations/+merge/69036 The others seem a bit farther, but they could use reviews as well ! As always, see http://wiki.openstack.org/reviewslist/ for an up-to-date, sorted priority review list. 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
[Openstack] Quotas for nonexistent projects
Hi! I have noticed that project quotas in nova could be stored and retrieved even if the project doesn't exist. Indeed, nova database has no restrictions, and the quotas' table could store quotas for projects with arbitrary names even if there are no such projects in the projects' table. Is it a bug or a feature? For example, let us see quotas for nonexistent "fgh" project, set "cores" quota, verify that it is stored, and check that there is still no "fgh" project. # nova-manage project quota fgh metadata_items: 128 instances: 10 injected_file_content_bytes: 10240 injected_files: 5 volumes: 10 gigabytes: 1000 cores: 20 ram: 51200 floating_ips: 10 # nova-manage project quota fgh cores 16 metadata_items: 128 instances: 10 injected_file_content_bytes: 10240 injected_files: 5 volumes: 10 gigabytes: 1000 cores: 16 ram: 51200 floating_ips: 10 # nova-manage project quota fgh metadata_items: 128 instances: 10 injected_file_content_bytes: 10240 injected_files: 5 volumes: 10 gigabytes: 1000 cores: 16 ram: 51200 floating_ips: 10 # nova-manage project list 1234 aproject -- Alessio Ababilov Software Engineer Grid Dynamics ___ 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] Quotas for nonexistent projects
Alessio Ababilov wrote: > I have noticed that project quotas in nova could be stored and retrieved > even if the project doesn't exist. Indeed, nova database has no > restrictions, and the quotas' table could store quotas for projects with > arbitrary names even if there are no such projects in the projects' table. > Is it a bug or a feature? Sounds like a bug to me. Please file :) -- 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
[Openstack] How to set a project to network?
Hi everyone. nova-manage /*** 日本電信電話株式会社 NTT情報流通プラットフォーム研究所 情報流通プラットフォーム推進プロジェクト プラットフォーム方式ＤＰ 田上 啓介 Tel (0422)59-6269FAX (0422)59-5652 〒180-8585 東京都武蔵野市緑町3-9-11 ***/ ___ 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] Ubuntu Cloud Days today, 16:00-UTC #ubuntu-classroom
Hi everyone, Ubuntu is running Ubuntu Cloud Days (UCD) event *today* starting 16:00-UTC. This is a great way to learn about new development happening in the server and cloud space for Ubuntu, as well as to ask questions, connect to developers and make some more friends. Technologies that will be touched upon include: Ensemble, Orchestra, Cloud-init, Eucalyptus, OpenStack and others Here is the schedule for today *16.00 UTC*Getting started with Ensemble -- kim0 *17.00 UTC*Introduction to Cloudinit -- koolhead17 *18.00 UTC*Orchestra and Ensemble (part1) -- smoser *19.00 UTC*Orchestra and Ensemble (part2) -- RoakSoax *20.00 UTC*Eucalyptus 3: cloud HA and ID management -- nurmi You can find more information on how to connect as well as tomorrow's schedule at https://wiki.ubuntu.com/UbuntuCloudDays/ Enjoy, regards ___ 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] about vlan and switch
Hi Rangababu, On Sat, Jul 23, 2011 at 12:58 PM, Rangababu Chakravarthula < rb...@hexagrid.com> wrote: > Couple of questions > a) How can we address the max 4096 vlan's problem if each user want's a > VLAN tagged network? > Currently, the notion of a VLAN is pretty central to the nova networking code. Removing this restriction and enabling more scalable network isolation mechanisms is one of the motivations for the Quantum virtual network service (see: http://wiki.openstack.org/Quantum). > b) Docs says for each VLAN network, a dhcp server is started. How does it > work when we do livemigrate? > Before and after the live migrate, the VM interface should be plugged into the same ethernet broadcast domain, so everything will continue to work (i.e., addresses from old DHCP lease remains valid, future DHCP requests will go to the same DHCP server). Dan > > thanks > > > On Wed, Jul 20, 2011 at 11:56 PM, Thor Wolpert wrote: > >> That was a great explanation, thanks! >> >> There is also a limit of 12 bits in the 802.1Q protocol, effectively >> setting the max to 4096 vlans >> >> I so look forward to having that kind of problem :)! >> >> >> On Wed, Jul 20, 2011 at 9:26 PM, Jeff Kramer wrote: >> >>> As I understand it, you can setup the tags in the switch first if you >>> want, but you don't need to. You will create VLAN tags in the Nova >>> database as you create networks with 'nova-manage network create ...', >>> and those will be assigned to users on a first-come first-serve basis. >>> When a user creates their first node nova assigns them an unused >>> network which has a unique VLAN tag. This tag is passed to >>> nova-compute when your instance is started, and it feeds that VLAN tag >>> into KVM which uses it for all network traffic in a way that's >>> transparent to the guest OS. When the guest talks to the network it >>> uses that VLAN tag, which the nova-network node is also listening on. >>> >>> As long as your switch supports host-tagged VLANs (802.1Q), you don't >>> have to create the tags in the switch before you use them. You could >>> setup all your VLANs before, someone else may have more experience >>> with that. >>> >>> One wrinkle is that many switches have a set number of tagged VLANs >>> they can support, for instance the HP V1810-24G switch that I'm using >>> supports 64 tagged VLANs, which means my Nova cluster can only have 64 >>> different networks (or 64 different users). The next model up >>> supports 256, etc. I assume that if you go over this number your >>> network traffic will start dropping and weird things will happen. >>> >>> Your switch's management IPs should probably be in an address space >>> that doesn't conflict with what you're assigning with nova. If you're >>> using 10.x.x.x for Nova you could put the switch on 192.168.x.x. You >>> probably shouldn't be touching the switch from a Nova guest, since the >>> time you'll want to be fiddling with it will be when your Nova cluster >>> is crashing or otherwise broken. >>> >>> >>> On Wed, Jul 20, 2011 at 10:43 PM, tianyi wang >>> wrote: >>> > Hi, all >>> > >>> > >>> > If use VLAN mode, it's need setting VLAN in switch's NOS first? >>> > And then the setting VLAN in nova controller node? >>> > >>> > Now, the switch's IP is 192.168.0.234 and the gateway ip address is >>> > 192.168.0.1 ( in switch web management interface), should I change the >>> > switch IP and gateway to 10.0.0.x ? >>> > >>> > In VLAN mode, what's the relationship tween the controller node's VLAN >>> > management and switch's NOS VLAN management? >>> > >>> > thanks >>> > >>> > >>> > alex >>> > >>> > ___ >>> > Mailing list: https://launchpad.net/~openstack >>> > Post to : openstack@lists.launchpad.net >>> > Unsubscribe : https://launchpad.net/~openstack >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >>> >>> >>> -- >>> Jeff Kramer >>> jeffkra...@gmail.com >>> http://www.jeffkramer.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 >>> >> >> >> ___ >> 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 > > -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~ ___ Mailing
[Openstack] [Glance] New local image cache functionality - Priority Code Review for D3 Milestone
All, Rick Harris has produced some excellent code that adds functionality for a local filesystem cache on Glance API nodes. I'd really like to get this functionality into the D3 milestone release scheduled for later this week. We need to cut the milestone release branch tomorrow, and that means that I need code reviews ASAP on this branch. https://code.launchpad.net/~rconradharris/glance/cached-images-middleware/+merge/69126 If you have 30 minutes, I would really appreciate it if you could give Rick feedback on this branch. Thanks much! 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 Common
I don't see it as multiple projects, just as a set of modules: openstack.common.config openstack.common.deployment openstack.common.logging ... etc. These are purely modules which help you create you're own OpenStack-compatible project...all available through a single openstack-common project. -Original Message- From: "Glen Campbell" Sent: Monday, July 25, 2011 1:20pm To: "Brian Lamar" , "openstack@lists.launchpad.net" Subject: Re: [Openstack] OpenStack Common Would it better to break it down even further? I.e., instead of trying to put ALL the common code into one project, create mini projects for common-logging, common-configuration, etc. That would permit other projects to adopt what they need, when they need it, rather than trying to integrate the entire common project at once. For example, we're working on converting Glance to use the logging/notification mechanism defined by Nova. The first step in the project was, however, "cut and paste notification code" from one to the other. That's disturbing to me, because it doubles the amount of effort required to implement changes to the notification system in the future. It would be much better IMHO to have a refactored common-logging module that could be included by multiple projects, with a standard interface each project could rely upon. There's no requirement, then, to implement common-rpc when you integrate common-logging, which lowers the barrier to entry for each project. On 7/25/11 12:11 PM, "Brian Lamar" wrote: >All, > >I love the idea of having an openstack-common project. However, the >prospect of creating such a project is daunting and quite difficult. > >It's my belief that standardizing/collecting common logic into a single >module will be beneficial to our current code-base and allow for future >projects to be created more quickly/easily. > >Currently the behemoth in the room is OpenStack Compute (aka Nova). The >Compute project contains much more code than all other OpenStack projects >(combined), and rightly so...virtualization is a pretty darn complex >thing to do in a flexible way. This might be why other projects have been >spawned to take away some of the logic from a single massive project and >place that logic into smaller, more focused projects. > >However, I would argue that the barrier of entry is too high for this >strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >suffer from the lack of a single cohesive strategy in the following areas: > >-Logging >-Configuration >-WSGI >-RPC >-Database >-Testing >-Deployment/Distribution of code > >These are the building blocks which most projects will require, yet every >project has to create their own implementations? Sure, it's not going to >be easy, and maybe some categories I've labeled won't make the final cut, >but I would like to start a conversation with the community as to the >feasibility of such an endeavor. > >This is not the first time such a project has been brought up. Much >earlier in the year, a number of people suggested moving "lazy loading" >code into a common project. I would like to think that project died due >to complexity rather than the community rejecting the idea. > >To create a common library of this nature requires a bit of pushing aside >one's partisan blinders and the abandonment of ideological >entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >argparse flame-war. > >TLDR: No > >* - Shamelessly stolen from The West Wing (tm) > > > > >___ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ 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 Common
Would it better to break it down even further? I.e., instead of trying to put ALL the common code into one project, create mini projects for common-logging, common-configuration, etc. That would permit other projects to adopt what they need, when they need it, rather than trying to integrate the entire common project at once. For example, we're working on converting Glance to use the logging/notification mechanism defined by Nova. The first step in the project was, however, "cut and paste notification code" from one to the other. That's disturbing to me, because it doubles the amount of effort required to implement changes to the notification system in the future. It would be much better IMHO to have a refactored common-logging module that could be included by multiple projects, with a standard interface each project could rely upon. There's no requirement, then, to implement common-rpc when you integrate common-logging, which lowers the barrier to entry for each project. On 7/25/11 12:11 PM, "Brian Lamar" wrote: >All, > >I love the idea of having an openstack-common project. However, the >prospect of creating such a project is daunting and quite difficult. > >It's my belief that standardizing/collecting common logic into a single >module will be beneficial to our current code-base and allow for future >projects to be created more quickly/easily. > >Currently the behemoth in the room is OpenStack Compute (aka Nova). The >Compute project contains much more code than all other OpenStack projects >(combined), and rightly so...virtualization is a pretty darn complex >thing to do in a flexible way. This might be why other projects have been >spawned to take away some of the logic from a single massive project and >place that logic into smaller, more focused projects. > >However, I would argue that the barrier of entry is too high for this >strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >suffer from the lack of a single cohesive strategy in the following areas: > >-Logging >-Configuration >-WSGI >-RPC >-Database >-Testing >-Deployment/Distribution of code > >These are the building blocks which most projects will require, yet every >project has to create their own implementations? Sure, it's not going to >be easy, and maybe some categories I've labeled won't make the final cut, >but I would like to start a conversation with the community as to the >feasibility of such an endeavor. > >This is not the first time such a project has been brought up. Much >earlier in the year, a number of people suggested moving "lazy loading" >code into a common project. I would like to think that project died due >to complexity rather than the community rejecting the idea. > >To create a common library of this nature requires a bit of pushing aside >one's partisan blinders and the abandonment of ideological >entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >argparse flame-war. > >TLDR: No > >* - Shamelessly stolen from The West Wing (tm) > > > > >___ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ 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] OpenStack Common
All, I love the idea of having an openstack-common project. However, the prospect of creating such a project is daunting and quite difficult. It's my belief that standardizing/collecting common logic into a single module will be beneficial to our current code-base and allow for future projects to be created more quickly/easily. Currently the behemoth in the room is OpenStack Compute (aka Nova). The Compute project contains much more code than all other OpenStack projects (combined), and rightly so...virtualization is a pretty darn complex thing to do in a flexible way. This might be why other projects have been spawned to take away some of the logic from a single massive project and place that logic into smaller, more focused projects. However, I would argue that the barrier of entry is too high for this strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone suffer from the lack of a single cohesive strategy in the following areas: -Logging -Configuration -WSGI -RPC -Database -Testing -Deployment/Distribution of code These are the building blocks which most projects will require, yet every project has to create their own implementations? Sure, it's not going to be easy, and maybe some categories I've labeled won't make the final cut, but I would like to start a conversation with the community as to the feasibility of such an endeavor. This is not the first time such a project has been brought up. Much earlier in the year, a number of people suggested moving "lazy loading" code into a common project. I would like to think that project died due to complexity rather than the community rejecting the idea. To create a common library of this nature requires a bit of pushing aside one's partisan blinders and the abandonment of ideological entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. argparse flame-war. TLDR: No * - Shamelessly stolen from The West Wing (tm) ___ 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 Common
Thats a better direction. Another way to think about this is to consider this an extensible service framework. If we agree on lightweight code wrappers (apis/modules) first with whatever "backend" each project uses, and then migrate each of those areas to a common implementation, we can inject uniformity and expected levels of instrumentation/capabilities across the projects. Example: log4j extender model... Jan On Jul 25, 2011, at 10:27 AM, "Brian Lamar" wrote: > I don't see it as multiple projects, just as a set of modules: > > openstack.common.config > openstack.common.deployment > openstack.common.logging > ... > etc. > > These are purely modules which help you create you're own > OpenStack-compatible project...all available through a single > openstack-common project. > > -Original Message- > From: "Glen Campbell" > Sent: Monday, July 25, 2011 1:20pm > To: "Brian Lamar" , > "openstack@lists.launchpad.net" > Subject: Re: [Openstack] OpenStack Common > > Would it better to break it down even further? I.e., instead of trying to > put ALL the common code into one project, create mini projects for > common-logging, common-configuration, etc. That would permit other > projects to adopt what they need, when they need it, rather than trying to > integrate the entire common project at once. > > For example, we're working on converting Glance to use the > logging/notification mechanism defined by Nova. The first step in the > project was, however, "cut and paste notification code" from one to the > other. That's disturbing to me, because it doubles the amount of effort > required to implement changes to the notification system in the future. It > would be much better IMHO to have a refactored common-logging module that > could be included by multiple projects, with a standard interface each > project could rely upon. > > There's no requirement, then, to implement common-rpc when you integrate > common-logging, which lowers the barrier to entry for each project. > > > > > > > On 7/25/11 12:11 PM, "Brian Lamar" wrote: > >> All, >> >> I love the idea of having an openstack-common project. However, the >> prospect of creating such a project is daunting and quite difficult. >> >> It's my belief that standardizing/collecting common logic into a single >> module will be beneficial to our current code-base and allow for future >> projects to be created more quickly/easily. >> >> Currently the behemoth in the room is OpenStack Compute (aka Nova). The >> Compute project contains much more code than all other OpenStack projects >> (combined), and rightly so...virtualization is a pretty darn complex >> thing to do in a flexible way. This might be why other projects have been >> spawned to take away some of the logic from a single massive project and >> place that logic into smaller, more focused projects. >> >> However, I would argue that the barrier of entry is too high for this >> strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >> suffer from the lack of a single cohesive strategy in the following areas: >> >> -Logging >> -Configuration >> -WSGI >> -RPC >> -Database >> -Testing >> -Deployment/Distribution of code >> >> These are the building blocks which most projects will require, yet every >> project has to create their own implementations? Sure, it's not going to >> be easy, and maybe some categories I've labeled won't make the final cut, >> but I would like to start a conversation with the community as to the >> feasibility of such an endeavor. >> >> This is not the first time such a project has been brought up. Much >> earlier in the year, a number of people suggested moving "lazy loading" >> code into a common project. I would like to think that project died due >> to complexity rather than the community rejecting the idea. >> >> To create a common library of this nature requires a bit of pushing aside >> one's partisan blinders and the abandonment of ideological >> entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >> argparse flame-war. >> >> TLDR: No >> >> * - Shamelessly stolen from The West Wing (tm) >> >> >> >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in error, > please delete it. > > > > > ___ > 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 : ht
Re: [Openstack] OpenStack Common
If by mini-projects you mean small and separate projects, then I don't think that makes sense. All we need for this is a single project that contains submodules that don't contain unnecessary dependencies on other submodules within the common project. So lots of bite size pieces that can be used or not used. Devin On Jul 25, 2011, at 10:20 AM, Glen Campbell wrote: > Would it better to break it down even further? I.e., instead of trying to > put ALL the common code into one project, create mini projects for > common-logging, common-configuration, etc. That would permit other > projects to adopt what they need, when they need it, rather than trying to > integrate the entire common project at once. > > For example, we're working on converting Glance to use the > logging/notification mechanism defined by Nova. The first step in the > project was, however, "cut and paste notification code" from one to the > other. That's disturbing to me, because it doubles the amount of effort > required to implement changes to the notification system in the future. It > would be much better IMHO to have a refactored common-logging module that > could be included by multiple projects, with a standard interface each > project could rely upon. > > There's no requirement, then, to implement common-rpc when you integrate > common-logging, which lowers the barrier to entry for each project. > > > > > > > On 7/25/11 12:11 PM, "Brian Lamar" wrote: > >> All, >> >> I love the idea of having an openstack-common project. However, the >> prospect of creating such a project is daunting and quite difficult. >> >> It's my belief that standardizing/collecting common logic into a single >> module will be beneficial to our current code-base and allow for future >> projects to be created more quickly/easily. >> >> Currently the behemoth in the room is OpenStack Compute (aka Nova). The >> Compute project contains much more code than all other OpenStack projects >> (combined), and rightly so...virtualization is a pretty darn complex >> thing to do in a flexible way. This might be why other projects have been >> spawned to take away some of the logic from a single massive project and >> place that logic into smaller, more focused projects. >> >> However, I would argue that the barrier of entry is too high for this >> strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >> suffer from the lack of a single cohesive strategy in the following areas: >> >> -Logging >> -Configuration >> -WSGI >> -RPC >> -Database >> -Testing >> -Deployment/Distribution of code >> >> These are the building blocks which most projects will require, yet every >> project has to create their own implementations? Sure, it's not going to >> be easy, and maybe some categories I've labeled won't make the final cut, >> but I would like to start a conversation with the community as to the >> feasibility of such an endeavor. >> >> This is not the first time such a project has been brought up. Much >> earlier in the year, a number of people suggested moving "lazy loading" >> code into a common project. I would like to think that project died due >> to complexity rather than the community rejecting the idea. >> >> To create a common library of this nature requires a bit of pushing aside >> one's partisan blinders and the abandonment of ideological >> entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >> argparse flame-war. >> >> TLDR: No >> >> * - Shamelessly stolen from The West Wing (tm) >> >> >> >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in error, > please delete it. > > > ___ > 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] Quotas for nonexistent projects
I'm not sure if there is a fixable bug at this point. Projects are moving into keystone, so there won't be any useful way for nova to verify whether a project exists before creating a quota for it. As long as we are maintaining quotas in nova, this will be the case. It may be that quotas eventually move into keystone as well, at which point some more robust verification could be done. Vish On Jul 25, 2011, at 4:56 AM, Thierry Carrez wrote: > Alessio Ababilov wrote: >> I have noticed that project quotas in nova could be stored and retrieved >> even if the project doesn't exist. Indeed, nova database has no >> restrictions, and the quotas' table could store quotas for projects with >> arbitrary names even if there are no such projects in the projects' table. >> Is it a bug or a feature? > > Sounds like a bug to me. Please file :) > > -- > 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 ___ 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 Common
+1 On Jul 25, 2011, at 11:59 AM, Devin Carlen wrote: > If by mini-projects you mean small and separate projects, then I don't think > that makes sense. > > All we need for this is a single project that contains submodules that don't > contain unnecessary dependencies on other submodules within the common > project. So lots of bite size pieces that can be used or not used. > > Devin > > On Jul 25, 2011, at 10:20 AM, Glen Campbell wrote: > >> Would it better to break it down even further? I.e., instead of trying to >> put ALL the common code into one project, create mini projects for >> common-logging, common-configuration, etc. That would permit other >> projects to adopt what they need, when they need it, rather than trying to >> integrate the entire common project at once. >> >> For example, we're working on converting Glance to use the >> logging/notification mechanism defined by Nova. The first step in the >> project was, however, "cut and paste notification code" from one to the >> other. That's disturbing to me, because it doubles the amount of effort >> required to implement changes to the notification system in the future. It >> would be much better IMHO to have a refactored common-logging module that >> could be included by multiple projects, with a standard interface each >> project could rely upon. >> >> There's no requirement, then, to implement common-rpc when you integrate >> common-logging, which lowers the barrier to entry for each project. >> >> >> >> >> >> >> On 7/25/11 12:11 PM, "Brian Lamar" wrote: >> >>> All, >>> >>> I love the idea of having an openstack-common project. However, the >>> prospect of creating such a project is daunting and quite difficult. >>> >>> It's my belief that standardizing/collecting common logic into a single >>> module will be beneficial to our current code-base and allow for future >>> projects to be created more quickly/easily. >>> >>> Currently the behemoth in the room is OpenStack Compute (aka Nova). The >>> Compute project contains much more code than all other OpenStack projects >>> (combined), and rightly so...virtualization is a pretty darn complex >>> thing to do in a flexible way. This might be why other projects have been >>> spawned to take away some of the logic from a single massive project and >>> place that logic into smaller, more focused projects. >>> >>> However, I would argue that the barrier of entry is too high for this >>> strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >>> suffer from the lack of a single cohesive strategy in the following areas: >>> >>> -Logging >>> -Configuration >>> -WSGI >>> -RPC >>> -Database >>> -Testing >>> -Deployment/Distribution of code >>> >>> These are the building blocks which most projects will require, yet every >>> project has to create their own implementations? Sure, it's not going to >>> be easy, and maybe some categories I've labeled won't make the final cut, >>> but I would like to start a conversation with the community as to the >>> feasibility of such an endeavor. >>> >>> This is not the first time such a project has been brought up. Much >>> earlier in the year, a number of people suggested moving "lazy loading" >>> code into a common project. I would like to think that project died due >>> to complexity rather than the community rejecting the idea. >>> >>> To create a common library of this nature requires a bit of pushing aside >>> one's partisan blinders and the abandonment of ideological >>> entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >>> argparse flame-war. >>> >>> TLDR: No >>> >>> * - Shamelessly stolen from The West Wing (tm) >>> >>> >>> >>> >>> ___ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> This email may include confidential information. If you received it in >> error, please delete it. >> >> >> ___ >> 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 Common
One thing that might be added would be dynamic module and class loading. This has implications for flags/options and help output as well. It is something nova does, and I suspect keystone and others will need to do as well. On Mon, Jul 25, 2011 at 2:59 PM, Devin Carlen wrote: > If by mini-projects you mean small and separate projects, then I don't think > that makes sense. > > All we need for this is a single project that contains submodules that don't > contain unnecessary dependencies on other submodules within the common > project. So lots of bite size pieces that can be used or not used. > > Devin > > On Jul 25, 2011, at 10:20 AM, Glen Campbell wrote: > >> Would it better to break it down even further? I.e., instead of trying to >> put ALL the common code into one project, create mini projects for >> common-logging, common-configuration, etc. That would permit other >> projects to adopt what they need, when they need it, rather than trying to >> integrate the entire common project at once. >> >> For example, we're working on converting Glance to use the >> logging/notification mechanism defined by Nova. The first step in the >> project was, however, "cut and paste notification code" from one to the >> other. That's disturbing to me, because it doubles the amount of effort >> required to implement changes to the notification system in the future. It >> would be much better IMHO to have a refactored common-logging module that >> could be included by multiple projects, with a standard interface each >> project could rely upon. >> >> There's no requirement, then, to implement common-rpc when you integrate >> common-logging, which lowers the barrier to entry for each project. >> >> >> >> >> >> >> On 7/25/11 12:11 PM, "Brian Lamar" wrote: >> >>> All, >>> >>> I love the idea of having an openstack-common project. However, the >>> prospect of creating such a project is daunting and quite difficult. >>> >>> It's my belief that standardizing/collecting common logic into a single >>> module will be beneficial to our current code-base and allow for future >>> projects to be created more quickly/easily. >>> >>> Currently the behemoth in the room is OpenStack Compute (aka Nova). The >>> Compute project contains much more code than all other OpenStack projects >>> (combined), and rightly so...virtualization is a pretty darn complex >>> thing to do in a flexible way. This might be why other projects have been >>> spawned to take away some of the logic from a single massive project and >>> place that logic into smaller, more focused projects. >>> >>> However, I would argue that the barrier of entry is too high for this >>> strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone >>> suffer from the lack of a single cohesive strategy in the following areas: >>> >>> -Logging >>> -Configuration >>> -WSGI >>> -RPC >>> -Database >>> -Testing >>> -Deployment/Distribution of code >>> >>> These are the building blocks which most projects will require, yet every >>> project has to create their own implementations? Sure, it's not going to >>> be easy, and maybe some categories I've labeled won't make the final cut, >>> but I would like to start a conversation with the community as to the >>> feasibility of such an endeavor. >>> >>> This is not the first time such a project has been brought up. Much >>> earlier in the year, a number of people suggested moving "lazy loading" >>> code into a common project. I would like to think that project died due >>> to complexity rather than the community rejecting the idea. >>> >>> To create a common library of this nature requires a bit of pushing aside >>> one's partisan blinders and the abandonment of ideological >>> entrenchments*, so hopefully this won't deteriorate into a FLAGS vs. >>> argparse flame-war. >>> >>> TLDR: No >>> >>> * - Shamelessly stolen from The West Wing (tm) >>> >>> >>> >>> >>> ___ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> This email may include confidential information. If you received it in >> error, please delete it. >> >> >> ___ >> 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.launchpa
Re: [Openstack] about vlan and switch
Thank you Dan. Response below. On Mon, Jul 25, 2011 at 11:36 AM, Dan Wendlandt wrote: > Hi Rangababu, > > On Sat, Jul 23, 2011 at 12:58 PM, Rangababu Chakravarthula < > rb...@hexagrid.com> wrote: > >> Couple of questions >> a) How can we address the max 4096 vlan's problem if each user want's a >> VLAN tagged network? >> > > Currently, the notion of a VLAN is pretty central to the nova networking > code. > > Removing this restriction and enabling more scalable network isolation > mechanisms is one of the motivations for the Quantum virtual network service > (see: http://wiki.openstack.org/Quantum). > > > >> b) Docs says for each VLAN network, a dhcp server is started. How does it >> work when we do livemigrate? >> > > Before and after the live migrate, the VM interface should be plugged into > the same ethernet broadcast domain, so everything will continue to work > (i.e., addresses from old DHCP lease remains valid, future DHCP requests > will go to the same DHCP server). > > That answers my question. However if the host on which dnsmasq is running needs to go down for maintenance, it should hand over the dhcp responsibility to another compute node. Am I right? > Dan > > > > >> >> thanks >> >> >> On Wed, Jul 20, 2011 at 11:56 PM, Thor Wolpert wrote: >> >>> That was a great explanation, thanks! >>> >>> There is also a limit of 12 bits in the 802.1Q protocol, effectively >>> setting the max to 4096 vlans >>> >>> I so look forward to having that kind of problem :)! >>> >>> >>> On Wed, Jul 20, 2011 at 9:26 PM, Jeff Kramer wrote: >>> As I understand it, you can setup the tags in the switch first if you want, but you don't need to. You will create VLAN tags in the Nova database as you create networks with 'nova-manage network create ...', and those will be assigned to users on a first-come first-serve basis. When a user creates their first node nova assigns them an unused network which has a unique VLAN tag. This tag is passed to nova-compute when your instance is started, and it feeds that VLAN tag into KVM which uses it for all network traffic in a way that's transparent to the guest OS. When the guest talks to the network it uses that VLAN tag, which the nova-network node is also listening on. As long as your switch supports host-tagged VLANs (802.1Q), you don't have to create the tags in the switch before you use them. You could setup all your VLANs before, someone else may have more experience with that. One wrinkle is that many switches have a set number of tagged VLANs they can support, for instance the HP V1810-24G switch that I'm using supports 64 tagged VLANs, which means my Nova cluster can only have 64 different networks (or 64 different users). The next model up supports 256, etc. I assume that if you go over this number your network traffic will start dropping and weird things will happen. Your switch's management IPs should probably be in an address space that doesn't conflict with what you're assigning with nova. If you're using 10.x.x.x for Nova you could put the switch on 192.168.x.x. You probably shouldn't be touching the switch from a Nova guest, since the time you'll want to be fiddling with it will be when your Nova cluster is crashing or otherwise broken. On Wed, Jul 20, 2011 at 10:43 PM, tianyi wang wrote: > Hi, all > > > If use VLAN mode, it's need setting VLAN in switch's NOS first? > And then the setting VLAN in nova controller node? > > Now, the switch's IP is 192.168.0.234 and the gateway ip address is > 192.168.0.1 ( in switch web management interface), should I change the > switch IP and gateway to 10.0.0.x ? > > In VLAN mode, what's the relationship tween the controller node's VLAN > management and switch's NOS VLAN management? > > thanks > > > alex > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > -- Jeff Kramer jeffkra...@gmail.com http://www.jeffkramer.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 >>> >>> >>> ___ >>> 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] about vlan and switch
On Mon, Jul 25, 2011 at 3:08 PM, Rangababu Chakravarthula < rb...@hexagrid.com> wrote: > Thank you Dan. Response below. > > On Mon, Jul 25, 2011 at 11:36 AM, Dan Wendlandt wrote: > >> Hi Rangababu, >> >> On Sat, Jul 23, 2011 at 12:58 PM, Rangababu Chakravarthula < >> rb...@hexagrid.com> wrote: >> >>> Couple of questions >>> a) How can we address the max 4096 vlan's problem if each user want's a >>> VLAN tagged network? >>> >> >> Currently, the notion of a VLAN is pretty central to the nova networking >> code. >> >> Removing this restriction and enabling more scalable network isolation >> mechanisms is one of the motivations for the Quantum virtual network service >> (see: http://wiki.openstack.org/Quantum). >> >> > >> >>> b) Docs says for each VLAN network, a dhcp server is started. How does it >>> work when we do livemigrate? >>> >> >> Before and after the live migrate, the VM interface should be plugged into >> the same ethernet broadcast domain, so everything will continue to work >> (i.e., addresses from old DHCP lease remains valid, future DHCP requests >> will go to the same DHCP server). >> >> That answers my question. However if the host on which dnsmasq is > running needs to go down for maintenance, it should hand over the dhcp > responsibility to another compute node. Am I right? > Vish actually did a great write-up on this recently: http://unchainyourbrain.com/openstack/13-networking-in-nova > > >> Dan >> >> >> >> >>> >>> thanks >>> >>> >>> On Wed, Jul 20, 2011 at 11:56 PM, Thor Wolpert wrote: >>> That was a great explanation, thanks! There is also a limit of 12 bits in the 802.1Q protocol, effectively setting the max to 4096 vlans I so look forward to having that kind of problem :)! On Wed, Jul 20, 2011 at 9:26 PM, Jeff Kramer wrote: > As I understand it, you can setup the tags in the switch first if you > want, but you don't need to. You will create VLAN tags in the Nova > database as you create networks with 'nova-manage network create ...', > and those will be assigned to users on a first-come first-serve basis. > When a user creates their first node nova assigns them an unused > network which has a unique VLAN tag. This tag is passed to > nova-compute when your instance is started, and it feeds that VLAN tag > into KVM which uses it for all network traffic in a way that's > transparent to the guest OS. When the guest talks to the network it > uses that VLAN tag, which the nova-network node is also listening on. > > As long as your switch supports host-tagged VLANs (802.1Q), you don't > have to create the tags in the switch before you use them. You could > setup all your VLANs before, someone else may have more experience > with that. > > One wrinkle is that many switches have a set number of tagged VLANs > they can support, for instance the HP V1810-24G switch that I'm using > supports 64 tagged VLANs, which means my Nova cluster can only have 64 > different networks (or 64 different users). The next model up > supports 256, etc. I assume that if you go over this number your > network traffic will start dropping and weird things will happen. > > Your switch's management IPs should probably be in an address space > that doesn't conflict with what you're assigning with nova. If you're > using 10.x.x.x for Nova you could put the switch on 192.168.x.x. You > probably shouldn't be touching the switch from a Nova guest, since the > time you'll want to be fiddling with it will be when your Nova cluster > is crashing or otherwise broken. > > > On Wed, Jul 20, 2011 at 10:43 PM, tianyi wang > wrote: > > Hi, all > > > > > > If use VLAN mode, it's need setting VLAN in switch's NOS first? > > And then the setting VLAN in nova controller node? > > > > Now, the switch's IP is 192.168.0.234 and the gateway ip address is > > 192.168.0.1 ( in switch web management interface), should I change > the > > switch IP and gateway to 10.0.0.x ? > > > > In VLAN mode, what's the relationship tween the controller node's > VLAN > > management and switch's NOS VLAN management? > > > > thanks > > > > > > alex > > > > ___ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Jeff Kramer > jeffkra...@gmail.com > http://www.jeffkramer.org/ > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.
