Re: [Openstack] Novatools ...
OK, let's try to summarize this long thread. there are two sides, the long-term plan and the short-term plan. For the long-term plan, there seems to be agreement on: * a set of project-oriented client tools (nova, glance...) that allow xe-like commands (nova vm-create) * a superset tool that reflects commands into the project-oriented tools (openstack compute vm-create) * support for interactive shell mode (nova show instances) * lowercase names That's for Diablo and should be further refined at the design summit. For the short term, we need some openstack-api client tool released and packaged, in particular because it is being used in the zones test, but also to start promoting the openstack API. * python-cloudservers is not under our control, so not easily extended * We have a python-novatools fork currently using novatools as the CLI tool * Sandy proposes * rename novatools CLI to nova * Add copyright headers and dual BSD/Apache licensing * Push python-novatools in nova itself under nova/clients/python/oscompute * Objections from Andy on the need to fork python-cloudservers and the perceived non-responsiveness of JKM I think we didn't discuss this part enough to make such a definitive move. I'll add a separate reply with my own remarks. -- 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] [Nova] 2011.1.1 release candidate up for testing
Hello everyone, As you probably know we need to release a Nova 2011.1.1 version due to missing elements in the 2011.1 tarball. We also targeted a few high-impact low-regression-risk fixes, see: https://launchpad.net/nova/+milestone/2011.1.1 We now have a 2011.1.1 release candidate tarball available at: http://nova.openstack.org/tarballs/nova-2011.1.1~bzr653.tar.gz If no regression is found over the next days, we'll ship this one as the 2011.1.1 release. We'll specifically check that all the targeted bugs have been indeed fixed, but some general testing to catch a weird regression (compared to Bexar 2011.1 release) would be welcome as well. Obviously you will miss all the other nice changes we pushed to Cactus, so testing this will feel a bit backward and unproductive, but that's the price to pay to do point releases on a fast-moving project... To help with that testing, I posted some packages for Ubuntu 10.10 (Maverick). They should build in a few hours, check the following URL for status: https://launchpad.net/~ttx/+archive/nova-bexar-updates/+buildjob/2285981 Once they are built and published, you can install them by enabling both the nova-core/release and the ttx/nova-bexar-updates PPAs: $ sudo apt-get install python-software-properties $ sudo add-apt-repository ppa:nova-core/release $ sudo add-apt-repository ppa:ttx/nova-bexar-updates $ sudo apt-get update The candidate version to test is 2011.1.1~bzr653-0ubuntu1~ppa1. If you want to test but need packages up for Natty or 10.04 LTS (Lucid), just let me know. Final release decision will be taken during next week release meeting. In the mean time, happy testing :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Decoupling of Network and Compute services for the new Network Service design
On Feb 24, 2011, at 2:02 PM, Eric Day wrote: I agree with Vish, I think the correct approach is 3. I have some ideas on terminology and how to think about this. A scheduler should not be it's own top-level service. It should instead be a plugin point (more like auth or db). It would plug into new service called kernel. Another way to look at it is s/scheduler/kernel/ and expand kernel. As I've been reading this thread, it did strike me that the terminology was being used differently by various people. Let me see if I can explain the way we've been using the terms in the development currently underway among the Ozone team. Given an Openstack deployment with several nested zones, most external API requests to interact with a VM will need to be routed to the appropriate compute node. The top-level API will know nothing about the VM, and so some sort of communication must be established to handle resolving these calls. This is what we have been calling the scheduler, and what you seem to be referring to as the kernel. Example: a request to pause a VM will have to be routed through the zone structure to find the host for that VM in order to pause it. The method used to efficiently locate the host is currently the focus of much discussion. One other such task (and probably the most involved) will be the creation of a new VM. This will require determining which hosts can accommodate the proposed instance, and a way of weighting or otherwise choosing the host from among all that are available. It will also require additional actions, such as establishing the network configuration, but let's keep this discussion focused. The process of selecting the host to receive the new VM is something we don't have a catchy name for, but we have been referring to best match, since that's the current term used in the Slicehost codebase. We have assumed that this will be pluggable, with the default being the current random selector, so that the way Rackspace allocates its VMs can be customized to their needs, while still allowing everyone else to create their own selection criteria. I hope that this clarifies some of what we have been talking about. BTW, I understand your choice of the term kernel, but I would prefer something that might be less confusing, since kernel already has a common meaning in computing. -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Steps that can help stabilize Nova's trunk
:) On Thu, Feb 24, 2011 at 7:36 PM, Jay Pipes jaypi...@gmail.com wrote: All done, and waiting to be almost immediately out of date. :) Cheers, jay On Thu, Feb 24, 2011 at 7:06 PM, Andy Smith andys...@gmail.com wrote: Please summarize these on the wiki and add your information the wiki, that is what the wiki page was made to do and what I asked you to do. --andy On Thu, Feb 24, 2011 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: Andy has listed a few things on the wiki. I'll summarize the known efforts here: * Anso has created some Vagrant scripts that test multi-node functionality of the EC2 API, libvirt + KVM, and nova-objectstore * Vishy/Devin have been refactored Nova's existing smoketests/ and updated to include netadmin tests. Still only testing EC2 API * Trey has been volunteered to write an OpenStack API smoketest for XenServer functionality (https://bugs.launchpad.net/nova/+bug/720941) * Jordan Rinke has been working on a 10-machine test cluster for testing deployments and running smoketests on * Other rackers (Pvo, Ant?) have been working on getting a much larger production-level test cluster for running longer, more complex tests on Stuff we need to do: * Create a staging/testing branch, have Openstack Hudson LP user own it * Get the test cluster machines entered into Hudson * On each merge proposal into trunk, have Tarmac pull the branch, run unit tests automatically, fire off smoketests/ against the test machines automatically, and notify the merge proposal that tests pass or don't pass. * For merge proposals that pass the merge into staging and all tests that also have 2 Approves from core devs, have Tarmac merge into trunk * Create long-running functional tests that are essentially re-playing large Apache/nginx log files of existing Nebula and Cloud Servers API nodes against Nova staging branch with various configurations -jay On Thu, Feb 24, 2011 at 3:49 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Jay, Nice to see this issue being addressed ... it's a big deal. From reading this (long) thread, my biggest source of confusion was so many we're doing something on this front too ... messages. Would it be possible to get a summary of the various integration testing efforts underway so we can find out where the commonality/biggest-bang-for-the-buck/overlap is? Perhaps a wiki page already exists for this? Thx, -S From: a cast of thousands ... delete Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Decoupling of Network and Compute services for the new Network Service design
There can be reconfiguration of the network, just not adding/removing of
vifs. The addition of a new vif would generally only be done if an
additional nic or bridge was added to the host. I figure this to be a rare
occurrence. You can add or remove IPs to/from an instance by configuring
aliases on existing vifs (which the agent will do). Biggest case I can think
of where dhcp is not appropriate: service providers.
On Thu, Feb 24, 2011 at 6:49 PM, Dan Mihai Dumitriu dm...@cornell.eduwrote:
So in cases where static injection into the image is used, it seems there
can be no dynamic reconfiguration of the network, ie cannot plug a vNic into
a network after the VM is started.
Just so we're all on the same page, in what cases is dhcp/ra not
appropriate?
Cheers,
Dan
On Feb 25, 2011 7:11 AM, Trey Morris trey.mor...@rackspace.com wrote:
definitely not fine to use dhcp in all cases.
On Thu, Feb 24, 2011 at 3:28 AM, Dan Mihai Dumitriu dm...@cornell.edu
wrote:
If we can dynamically plug (and presumably unplug) a vNIC into a
vPort, and assign the IP at that time, does that imply that we cannot
use the IP injection into the VM image? Is it fine to use DHCP or RA
in all cases?
On Wed, Feb 23, 2011 at 22:29, Ishimoto, Ryu r...@midokura.jp wrote:
Hi everyone,
I have been following the discussion regarding the new 'pluggable'
network
service design, and wanted to drop in my 2 cents ;-)
Looking at the current implementation of Nova, there seems to be a
very
strong coupling between compute and network services. That is, tasks
that
are done by the network service are executed at the time of VM
instantiation, making the compute code dependent on the network
service,
and
vice versa. This dependency seems undesirable to me as it adds
restrictions
to implementing 'pluggable' network services, which can vary, with
many
ways
to implement them.
Would anyone be opposed to completely separating out the network
service
logic from compute? I don't think it's too difficult to accomplish
this,
but to do so, it will require that the network service tasks, such as
IP
allocation, be executed by the user prior to instantiating the VM.
In the new network design(from what I've read up so far), there are
concepts
of vNICs, and vPorts, where vNICs are network interfaces that are
associated
with the VMs, and vPorts are logical ports that vNICs are plugged into
for
network connectivity. If we are to decouple network and compute
services,
the steps required for FlatManager networking service would look
something
like:
1. Create ports for a network. Each port is associated with an IP
address
in this particular case, since it's an IP-based network.
2. Create a vNIC
3. Plug a vNIC into an avaiable vPort. In this case it just means
mapping
this vNIC to an unused IP address.
4. Start a VM with this vNIC. vNIC is already mapped to an IP address,
so
compute does not have to ask the network service to do any IP
allocation.
In this simple example, by removing the request for IP allocation from
compute, the network service is no longer needed during the VM
instantiation. While it may require more steps for the network setup
in
more complex cases, it would still hold true that, once the vNIC and
vPort
are mapped, compute service would not require any network service
during
the
VM instantiation.
IF there is still a need for the compute to access the network
service,
there is another way. Currently, the setup of the network
environment(bridge, vlan, etc) is all done by the compute service.
With
the
new network model, these tasks should either be separated out into a
standalone service('network agent') or at least be separated out into
modules with generic APIs that the network plugin providers can
implement.
By doing so, and if we can agree on a rule that the compute service
must
always go through the network agent to access the network service, we
can
still achieve the separation of compute from network services. Network
agents should have full access to the network service as they are both
implemented by the same plugin provider. Compute would not be aware of
the
network agent accessing the network service.
With this design, the network service is only tied to the network REST
API
and the network agent, both of which are implemented by the plugin
providers. This would allow them to implement their network service
without
worrying about the details of the compute service.
Please let me know if all this made any sense. :-) Would love to get
some
feedbacks.
Regards,
Ryu Ishimoto
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help :
Re: [Openstack] Novatools ...
+1 for long term plan discussion at the summit +1 for having this in the diablo release +1 for short term goal: tool being under our control via fork I don't think JKM will keep up (nothing against JKM, it's just a lot of work). On Fri, Feb 25, 2011 at 3:20 AM, Thierry Carrez thie...@openstack.orgwrote: Thierry Carrez wrote: For the short term, we need some openstack-api client tool released and packaged, in particular because it is being used in the zones test, but also to start promoting the openstack API. * python-cloudservers is not under our control, so not easily extended * We have a python-novatools fork currently using novatools as the CLI tool * Sandy proposes * rename novatools CLI to nova * Add copyright headers and dual BSD/Apache licensing * Push python-novatools in nova itself under nova/clients/python/oscompute * Objections from Andy on the need to fork python-cloudservers and the perceived non-responsiveness of JKM That's three separate issues. (1) do we need a fork, (2) last changes to python-novatools before making them packageable (rename tool and file header fixes), and (3) make it part of lp:nova or not (and where) On (1) I think we need to be able to control the code, which leaves two options: (1a) JKM gives ownership to us, renames package to something more less cloudservers-branded or (1b) Let python-cloudservers live and fork our own nova-branded tool. Since (1b) is kinda already done and given our time contraints, I tend to lean in (1b) direction. (2) must be done in all cases since that's a bit of prerequisite for proper packaging. On (2)/(3) I think we should rename the tool to nova and move the python-novatools code in nova codebase *only if* it can be reused in the long-term plan: if we plan to drop it and replace the nova CLI tool by something completely different that does not support the same commands, then I think it should rather live outside the nova source tree. Do we think the current tool can be reused as-is in the long-term plan ? Also note that (3) creates a contraint of keeping the client code up to date with the rest of nova and prevents it to change after a release, but maybe that's a good thing :) -- 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 Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Working on fixing code after a review? Please mark merge proposal Work In Progress!
Hey all, The backlog on code reviews continues to mount: https://code.launchpad.net/nova/+activereviews One thing that would REALLY help reviewers is the following: If you receive one or more reviews that have asked for fixes to your branch (Needs Fixing), and you agree to these fixes, please do the following: * Write a quick comment on the merge proposal acknowledging the review and stating you are working on fixing the branch * Set the merge proposal status to Work In Progress When you do this, your branch gets removed from the list of merge proposals that reviewers need to review (the link above), which helps reviewers to identify which branches are truly in need of review and which branches are actually being worked on after reviews. After you make the changes to your branch, please do the following: * bzr push your changes to Launchpad * Go to your merge proposal and set the status back to Needs Review This will trigger: * Launchpad to regenerate the diff that is displayed for your branch * Launchpad to email all prior reviewers to let them know they need to re-review your branch Doing these simple steps will make reviewing dramatically easier; the side-effect of that is reviews will be quicker and we can get through this backlog. Thanks for listening, 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] Working on fixing code after a review? Please mark merge proposal Work In Progress!
On Fri, Feb 25, 2011 at 1:16 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Good call Jay - I'll do my best to remember to do this! Why are branches with unmerged pre-reqs showing up in that list? If reviewers are working from that list, that just seems to be creating extra work, which you probably don't need! That's just how Launchpad is, unfortunately. I know of no way to keep LP from displaying branches with merge proposals having pre-requisite branches that are unmerged :( -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] Working on fixing code after a review? Please mark merge proposal Work In Progress!
Is there at least a way for not showing branches which are not proposed for merge into lp:nova? Salvatore -Original Message- From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Jay Pipes Sent: 25 February 2011 18:21 To: Justin Santa Barbara Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Working on fixing code after a review? Please mark merge proposal Work In Progress! On Fri, Feb 25, 2011 at 1:16 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Good call Jay - I'll do my best to remember to do this! Why are branches with unmerged pre-reqs showing up in that list? If reviewers are working from that list, that just seems to be creating extra work, which you probably don't need! That's just how Launchpad is, unfortunately. I know of no way to keep LP from displaying branches with merge proposals having pre-requisite branches that are unmerged :( -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 ___ 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] Working on fixing code after a review? Please mark merge proposal Work In Progress!
I realized my previous mail was a bit unclear... I meant to say can we avoid showing branches which are proposed to merge into something different than lp:nova? -Original Message- From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: 25 February 2011 18:23 To: Jay Pipes; Justin Santa Barbara Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Working on fixing code after a review? Please mark merge proposal Work In Progress! Is there at least a way for not showing branches which are not proposed for merge into lp:nova? Salvatore -Original Message- From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf Of Jay Pipes Sent: 25 February 2011 18:21 To: Justin Santa Barbara Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Working on fixing code after a review? Please mark merge proposal Work In Progress! On Fri, Feb 25, 2011 at 1:16 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Good call Jay - I'll do my best to remember to do this! Why are branches with unmerged pre-reqs showing up in that list? If reviewers are working from that list, that just seems to be creating extra work, which you probably don't need! That's just how Launchpad is, unfortunately. I know of no way to keep LP from displaying branches with merge proposals having pre-requisite branches that are unmerged :( -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 ___ 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] Working on fixing code after a review? Please mark merge proposal Work In Progress!
On Fri, Feb 25, 2011 at 1:23 PM, Salvatore Orlando salvatore.orla...@eu.citrix.com wrote: Is there at least a way for not showing branches which are not proposed for merge into lp:nova? Another excellent question. And unfortunately, no, there isn't :( I'll file it as a wishlist bug on Launchpad. Cheers, 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
[Openstack] Availability of RHEL build of Bexar release of OpenStack Nova
Hello! Grid Dynamics is proud to announce public availability of OpenStack Nova RHEL 6.0 build. At the moment we have RPMs for Bexar release. It was tested using KVM hypervisor on real hardware in multi-node mode. Here are instructions to install run our build: http://wiki.openstack.org/NovaInstall/RHEL6Notes Differences between usual setup and our build: - we have packages and dependencies (instead of installing nova manually in /usr/local/bla and doing easy_install for missing modules) - qcow2 support was enabled utilizing libguestfs instead of missing NBD - start-stop-daemon used as daemon management library due removed python-daemon module from Nova - Nova's logs are located in /var/log/nova and properly logrotated - network injection code was patched for RHEL path (/etc/sysconfig/network-scripts) and RHEL template - all dependencies are located in separate repository. Enjoy and please contribute all packaging bugs to me! All porting work are on GitHub: https://github.com/abrindeyev/openstack-nova-rhel6 Grid Dynamics Team: Andrey Brindeyev, Eldar Nugaev, Ilya Alekseyev ___ 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] Working on fixing code after a review? Please mark merge proposal Work In Progress!
I have filed a bug with Launchpad that asks for enhancements for both of your issues: https://bugs.launchpad.net/launchpad/+bug/725163 Cheers! jay On Fri, Feb 25, 2011 at 1:25 PM, Jay Pipes jaypi...@gmail.com wrote: On Fri, Feb 25, 2011 at 1:23 PM, Salvatore Orlando salvatore.orla...@eu.citrix.com wrote: Is there at least a way for not showing branches which are not proposed for merge into lp:nova? Another excellent question. And unfortunately, no, there isn't :( I'll file it as a wishlist bug on Launchpad. Cheers, 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] Availability of RHEL build of Bexar release of OpenStack Nova
Good work folks! Do we understand what the dependencies/deltas are to support RHEL5 series releases? Has anybody done this? John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Andrey Brindeyev Sent: Friday, February 25, 2011 12:32 PM To: openstack@lists.launchpad.net Subject: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova Hello! Grid Dynamics is proud to announce public availability of OpenStack Nova RHEL 6.0 build. At the moment we have RPMs for Bexar release. It was tested using KVM hypervisor on real hardware in multi-node mode. Here are instructions to install run our build: http://wiki.openstack.org/NovaInstall/RHEL6Notes Differences between usual setup and our build: - we have packages and dependencies (instead of installing nova manually in /usr/local/bla and doing easy_install for missing modules) - qcow2 support was enabled utilizing libguestfs instead of missing NBD - start-stop-daemon used as daemon management library due removed python-daemon module from Nova - Nova's logs are located in /var/log/nova and properly logrotated - network injection code was patched for RHEL path (/etc/sysconfig/network-scripts) and RHEL template - all dependencies are located in separate repository. Enjoy and please contribute all packaging bugs to me! All porting work are on GitHub: https://github.com/abrindeyev/openstack-nova-rhel6 Grid Dynamics Team: Andrey Brindeyev, Eldar Nugaev, Ilya Alekseyev ___ 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] Decoupling of Network and Compute services for the new Network Service design
Hi Ed, So it sounds like we're all talking about the same thing, we just need to start a Nova glossary so we're all on the smae page of what terms mean. :) So it sounds like from my last email, kernel == scheduler, and scheduler == best match. I'm not too concerned about naming of things as long as they are accurate. I thought scheduler was being a bit overloaded, as it was originally only supposed to be the best match functionality you describe. I think it would be fine to use kernel though, as the same terms are used in many different contexts in computing, and this is certainly a different context. Having said that, it doesn't really matter as long as it works and folks can understand what it's doing with a brief look. :) As for the best way to locate the host when routing requests for existing instances, the most straightforward way is to keep a lookup table (probably another SQLite table would be easiest). This table can stay up to date by registering callbacks with child zones, and the child needs to have an API call for the parent zone to be able to say give me all changes after time X for the initial sync (time=0) or after a long outage (time=last update before going down). -Eric On Fri, Feb 25, 2011 at 08:27:24AM -0600, Ed Leafe wrote: On Feb 24, 2011, at 2:02 PM, Eric Day wrote: I agree with Vish, I think the correct approach is 3. I have some ideas on terminology and how to think about this. A scheduler should not be it's own top-level service. It should instead be a plugin point (more like auth or db). It would plug into new service called kernel. Another way to look at it is s/scheduler/kernel/ and expand kernel. As I've been reading this thread, it did strike me that the terminology was being used differently by various people. Let me see if I can explain the way we've been using the terms in the development currently underway among the Ozone team. Given an Openstack deployment with several nested zones, most external API requests to interact with a VM will need to be routed to the appropriate compute node. The top-level API will know nothing about the VM, and so some sort of communication must be established to handle resolving these calls. This is what we have been calling the scheduler, and what you seem to be referring to as the kernel. Example: a request to pause a VM will have to be routed through the zone structure to find the host for that VM in order to pause it. The method used to efficiently locate the host is currently the focus of much discussion. One other such task (and probably the most involved) will be the creation of a new VM. This will require determining which hosts can accommodate the proposed instance, and a way of weighting or otherwise choosing the host from among all that are available. It will also require additional actions, such as establishing the network configuration, but let's keep this discussion focused. The process of selecting the host to receive the new VM is something we don't have a catchy name for, but we have been referring to best match, since that's the current term used in the Slicehost codebase. We have assumed that this will be pluggable, with the default being the current random selector, so that the way Rackspace allocates its VMs can be customized to their needs, while still allowing everyone else to create their own selection criteria. I hope that this clarifies some of what we have been talking about. BTW, I understand your choice of the term kernel, but I would prefer something that might be less confusing, since kernel already has a common meaning in computing. -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova
Our developers here at USC-ISI have been working the SUSE 11.1 side for our GPU and UltraViolet machines. There are some dependencies I'll try to get our internal wiki pages pushed out so we can compare notes. I suspect the kernel/kvm and other tools are of the same enterprise vintage as RHEL. We had to hack Python 2.6.6 onto our boxes as a temporary measure, because 2.6.0 is what ships. Brian --- Brian Schott, Project Leader USC Information Sciences Institute http://www.east.isi.edu/~bschott ph: 703-812-3722 fx: 703-812-3712 On Feb 25, 2011, at 1:55 PM, John Purrier wrote: Good work folks! Do we understand what the dependencies/deltas are to support RHEL5 series releases? Has anybody done this? John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Andrey Brindeyev Sent: Friday, February 25, 2011 12:32 PM To: openstack@lists.launchpad.net Subject: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova Hello! Grid Dynamics is proud to announce public availability of OpenStack Nova RHEL 6.0 build. At the moment we have RPMs for Bexar release. It was tested using KVM hypervisor on real hardware in multi-node mode. Here are instructions to install run our build: http://wiki.openstack.org/NovaInstall/RHEL6Notes Differences between usual setup and our build: - we have packages and dependencies (instead of installing nova manually in /usr/local/bla and doing easy_install for missing modules) - qcow2 support was enabled utilizing libguestfs instead of missing NBD - start-stop-daemon used as daemon management library due removed python-daemon module from Nova - Nova's logs are located in /var/log/nova and properly logrotated - network injection code was patched for RHEL path (/etc/sysconfig/network-scripts) and RHEL template - all dependencies are located in separate repository. Enjoy and please contribute all packaging bugs to me! All porting work are on GitHub: https://github.com/abrindeyev/openstack-nova-rhel6 Grid Dynamics Team: Andrey Brindeyev, Eldar Nugaev, Ilya Alekseyev ___ 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 PGP.sig Description: This is a digitally signed message part ___ 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] Availability of RHEL build of Bexar release of OpenStack Nova
Great work! Vishy and termie got jenkins launching ubuntu+kvm and running smoke tests. There are a few isssues left but I'm excited to increase coverage. We'd like to add coverage for rhel 5/6 and suse. http://ansolabs.no-ip.org:9000/ We'll write an email about how it works so others can run or contribute improvements. Jesse On Feb 25, 2011 11:14 AM, Brian Schott bsch...@isi.edu wrote: ___ 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] Availability of RHEL build of Bexar release of OpenStack Nova
I'm assuming we're adding this to the openstack.org Hudson setup? -jay On Fri, Feb 25, 2011 at 2:22 PM, Jesse Andrews anotherje...@gmail.com wrote: Great work! Vishy and termie got jenkins launching ubuntu+kvm and running smoke tests. There are a few isssues left but I'm excited to increase coverage. We'd like to add coverage for rhel 5/6 and suse. http://ansolabs.no-ip.org:9000/ We'll write an email about how it works so others can run or contribute improvements. Jesse On Feb 25, 2011 11:14 AM, Brian Schott bsch...@isi.edu wrote: ___ 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] UPDATE on Active reviews - filtered by target branch
Hi all, especially Salvatore and Armando, The Launchpad team responded to my feature request. You can see active reviews for a specific branch using the following: https://code.launchpad.net/BRANCH/+activereviews Therefore, to see only the active reviews for the Nova trunk, you can use this: https://code.launchpad.net/~hudson-openstack/nova/trunk/+activereviews likewise, to see active reviews for branches proposed to merge into, say, the Citrix peer-review branch, you'd go here: https://code.launchpad.net/~citrix-openstack/nova/peer-review/+activereviews The other request from Justin Santa Barbara is being addressed in this bug: https://bugs.launchpad.net/launchpad/+bug/725163 Cheers, 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] UPDATE on Active reviews - filtered by target branch
Possibly a feature request and possibly just a launchpad help request, is there a way to sort my open merge proposals by most recent activity? Last modified seems to only apply to changes pushed to the branch, not comments made on the merge prop. --andy On Fri, Feb 25, 2011 at 12:50 PM, Jay Pipes jaypi...@gmail.com wrote: Hi all, especially Salvatore and Armando, The Launchpad team responded to my feature request. You can see active reviews for a specific branch using the following: https://code.launchpad.net/BRANCH/+activereviews Therefore, to see only the active reviews for the Nova trunk, you can use this: https://code.launchpad.net/~hudson-openstack/nova/trunk/+activereviews likewise, to see active reviews for branches proposed to merge into, say, the Citrix peer-review branch, you'd go here: https://code.launchpad.net/~citrix-openstack/nova/peer-review/+activereviews The other request from Justin Santa Barbara is being addressed in this bug: https://bugs.launchpad.net/launchpad/+bug/725163 Cheers, 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 ___ 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] test dir in trunk
Looks like anne's doc branch added a dir called test to trunk with a whole bunch of stuff in it. Was this added on purpose? Vish ___ 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] UPDATE on Active reviews - filtered by target branch
Another good feature suggestion. I don't think there is a way in the current screen to sort. :( Feel free to add a bug to the Launchpad project. I don't want them to get sick of me adding feature requests! ;) -jay On Fri, Feb 25, 2011 at 5:28 PM, Andy Smith andys...@gmail.com wrote: Possibly a feature request and possibly just a launchpad help request, is there a way to sort my open merge proposals by most recent activity? Last modified seems to only apply to changes pushed to the branch, not comments made on the merge prop. --andy On Fri, Feb 25, 2011 at 12:50 PM, Jay Pipes jaypi...@gmail.com wrote: Hi all, especially Salvatore and Armando, The Launchpad team responded to my feature request. You can see active reviews for a specific branch using the following: https://code.launchpad.net/BRANCH/+activereviews Therefore, to see only the active reviews for the Nova trunk, you can use this: https://code.launchpad.net/~hudson-openstack/nova/trunk/+activereviews likewise, to see active reviews for branches proposed to merge into, say, the Citrix peer-review branch, you'd go here: https://code.launchpad.net/~citrix-openstack/nova/peer-review/+activereviews The other request from Justin Santa Barbara is being addressed in this bug: https://bugs.launchpad.net/launchpad/+bug/725163 Cheers, 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 ___ 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] multi_nic and mac addresses
Tracking mac addresses is going to have to change for multi-nic. Instances are going to have more than one mac address. It's been proposed that we don't need to track the mac address(es) but I think it's necessary in order to determine whether a mac is unique or not. Mac addresses don't need to be unique across a whole implementation but they do need to be unique as far as layer 2 networking is concerned. It will be quite a while before we run out of mac addresses across the whole implementation so allowing duplicate macs but preventing duplicates within a network layer two zone (not sure the terminology at this point) can be handled later. I propose making a new table for storing instance id mac address relationships. I'm also considering randomly generating mac addresses using instance uuid as salt. Thoughts? -tr3buchet Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova
We (Citrix) are installing it on CentOS 5.5 at the moment, so it is possible. (I won't bore you with the train of thought that lead to that act of masochism.) The main problem is that you need to have parallel Python 2.4 and 2.6 installations, because yum breaks if you try to make 2.6 the primary, but 2.4 is no good for Nova. This means that you end up doing loads of tedious repackaging. Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Andrey Brindeyev Sent: 25 February 2011 13:06 To: John Purrier Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova John, There is a page on Wiki for running Nova on CentOS/RHEL 5: http://wiki.openstack.org/NovaInstall/CentOSNotes Andrey. 25.02.2011, в 21:55, John Purrier написал(а): Good work folks! Do we understand what the dependencies/deltas are to support RHEL5 series releases? Has anybody done this? John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Andrey Brindeyev Sent: Friday, February 25, 2011 12:32 PM To: openstack@lists.launchpad.net Subject: [Openstack] Availability of RHEL build of Bexar release of OpenStack Nova Hello! Grid Dynamics is proud to announce public availability of OpenStack Nova RHEL 6.0 build. At the moment we have RPMs for Bexar release. It was tested using KVM hypervisor on real hardware in multi-node mode. Here are instructions to install run our build: http://wiki.openstack.org/NovaInstall/RHEL6Notes Differences between usual setup and our build: - we have packages and dependencies (instead of installing nova manually in /usr/local/bla and doing easy_install for missing modules) - qcow2 support was enabled utilizing libguestfs instead of missing NBD - start-stop-daemon used as daemon management library due removed python-daemon module from Nova - Nova's logs are located in /var/log/nova and properly logrotated - network injection code was patched for RHEL path (/etc/sysconfig/network-scripts) and RHEL template - all dependencies are located in separate repository. Enjoy and please contribute all packaging bugs to me! All porting work are on GitHub: https://github.com/abrindeyev/openstack-nova-rhel6 Grid Dynamics Team: Andrey Brindeyev, Eldar Nugaev, Ilya Alekseyev ___ 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
