[Openstack] Reminder: OpenStack team meeting - 21:00 UTC
Hello everyone, Our weekly team meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. Check out how that time translates for *your* timezone: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110510T21 See the meeting agenda, edit the wiki to add new topics for discussion: http://wiki.openstack.org/Meetings Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Install openstack in single PC with virtualbox
Diego: Thank you for tell me this information. I download the ISO file and burn to CD disk, also use the CD disk success install into my PC, I can login to the system use root/stackops as username/password. I read the docs on http://docs.stackops.org/display/documentation/Install+and+Configure+the+Distro When I try to Configure to Single Node, I find the topological diagram show the single node direct connect to the Internet ? But the PC in the LAN, connect to Internet by gateway server and have only internal IP address: 192.168.2.228, and the pc just have on NIC -- Minimum Configuration says one NIC is also can meet the requirement ? First time configure, I register a username and use this username configure the single node, but when this time attempt fail, I can not use this username again to configure ? So, I use anonymous installation mode --- hardware NameSpeed Cores Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 19981 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 19981 Virtualization true RAM Size4119052288 Device SizeUsedMount Point /dev/sda500107862016-1 /dev/sda1 48038042828825514176512 / /dev/sda2 1024-1 /dev/sda5 12064915456 -1 Interface TypeName eth0 RTL8111/8168B PCI Express Gigabit Ethernet controller dummy0 Ethernet interface --- software Operating System (uname) Linux/nova-controller/2.6.32-28-server/#55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011/x86_64/0.2-b89-d20110420 Hostnamenova-controller DNS 1 8.8.8.8 DNS 2 8.8.4.4 NameAddress Netmask Gateway DHCP Client eth0192.168.2.228 255.255.255.0 192.168.2.1 false --- Network Topology (controller,compute,network,volume) management + storage + public eth0=192.168.2.228 --- Global Services Change to Basic database username root password nova host 192.168.2.228 port 3306 schema nova ec2 hostname 192.168.2.228 dmz 192.168.2.228 rabbitmq hostname 192.168.2.228 s3 hostname 192.168.2.228 dmz 192.168.2.228 authentication driver nova.auth.dbdriver.DbDriver use_project_ca selected generic nodaemon selected verbose Yes No -- yes lock_path /tmp logs dir /var/log/nova network type nova.network.manager.FlatDHCPManager fixed_range 10.0.0.0/12 network_size 64 floating_range how to fill this I use 192.168.2.64/28 is correct? state path /var/lib/nova monitoring collectd_listener 192.168.2.228 --- network Change to Advanced dhcpbridge process /var/lib/nova/bin/nova-dhcpbridge file /etc/nova/nova-network.conf interfaces routing_source_ip 192.168.2.228 flat_interface dummy0 public_interface eth0 flat_injected Yes No -- is No --- volume Change to Advanced iscsi lvm_device /dev/sda use_local_volumes Yes No -- is yes --- compute Change to Advanced libvirt type kvm interfaces flat_interface dummy0 iscsi ip_prefix 192.168.2.228 num_targets 100 storage-hostname nova-controller --- But I get this error info : ERROR: Unexpected error while running command. Command: vgremove -ff nova-volumes; pvcreate -ffy /dev/sda Exit code: 5 Stdout: '' Stderr: ' Volume group nova-volumes not found\n Device /dev/sda not found (or ignored by filtering).\n' How can I do for next ? Thanks Alex On Sat, May 7, 2011 at 4:28 PM, Diego Parrilla diego.parri...@stackops.com wrote: tianyi, sorry for this rather impersonal email. We (Stackops) have a free Openstack Nova Distro you can install in VirtualBox. Check our .org site: http://www.stackops.org and follow the instructions. You will have a running Nova installation in your Virtualbox instance in a Breeze. Regards Diego -- Diego Parrilla CEO www.stackops.com | diego.parri...@stackops.com | +34 649 94 43 29 | skype:diegoparrilla ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya
Re: [Openstack] Network Service meeting
Hi Rick, Wednesday 22:00 UTC would be fine for me. Salvatore -Original Message- From: Rick Clark [mailto:r...@openstack.org] Sent: 10 May 2011 10:12 To: Josh Wilmes Cc: Dan Wendlandt; James Urquhart; Erik Carlin; Salvatore Orlando; radur...@cisco.com; Ewan Mellor; Youcef Laribi; Armando Migliaccio; Troy Toman; Bradley McConnell; openst...@lab.ntt.co.jp; Hisaharu Ishii; r...@midokura.jp; Jamey Meredith; Somik Behera; Lew Tucker (letucker); Michael Smith (michsmit); openstack@lists.launchpad.net Subject: Network Service meeting We had planned to have a network Service meeting after the release meeting today, but the PTL's have a conflicting meeting in the same channel. I suggest we move it to tomorrow at the same time. Would that be ok for everyone? Rick Clark ___ 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] Reminder: OpenStack team meeting - 21:00 UTC
On 05/10/2011 04:05 PM, Thierry Carrez wrote: Hello everyone, Our weekly team meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. Each weeks, it's at that time. Here, that makes it 5am, and I don't really wana wake up just to chat on IRC, but still would like to be there, especially because I couldn't attend the design summit, and that I'm currently trying to get up-to-speed to what's going on. Would it be possible to not schedule it always at the same time? If that's only an issue for me, and that it's perfect time for others, then I'd understand to not change the time though... But as much as I can tell, even in California, that's 2pm, which is quite late already. Cheers, Thomas ___ 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] KVM Block Migration
Hi, Is there any progress on KVM block migration? I'd like to test it and possibly make some changes to nova to support block devices, but don't want to reinventing the wheel. Thanks, 2011/4/12 Masanori ITOH itou...@nttdata.co.jp Hi, Vish also mentioned that we should support the KVM block migration feature instead of stability which I mentioned because it's very much useful. I agree with Vish of course. :) Actually, we discussed inclusion of block migration feature at San Antonio. :) I've also seen the page Hisaki mentioned. My point is that the page explains interacting qemu monitor but we need to invoke the feature through libvirt layer not the qemu monitor directly. Here, A colleague of mine mentioned that --copy-storage-all option of virsh looked like not-supported yet in Ubuntu 10.10 at least. Hisaki, do you have any information if it's enabled in Ubuntu 11.04 libvirt? I mean using virsh, did you succeed invoking block live migration something like the following? $ virsh migrate --live --copy-storage-all DOMID DESTURL Unfortunately, we haven't been able to make enough time trying Natty alpha because of our schedule delay caused by the earthquake in Northeastern Japan. :( At least, libvirt(virsh) included in RHEL6 does not support the feature. But, anyway I will talk about the issue with Kei and Muneyuki before going to the Design Summit. :) Regards, Masanori From: igoigo246 igoigo...@gmail.com Subject: Re: [Openstack] KVM Block Migration Date: Tue, 12 Apr 2011 09:28:38 +0900 Hi, I look Japanease Site. http://www.cuspy.org/blog/archives/917 This site wrote. image file vda.qcow sending host qemu --enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio,boot=on \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio receive host touch vda.qcow qemu -enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio \ -incoming tcp:0: sending host migrate -d -b tcp:wasabi: (qemu) info migrate Migration status: active transferred ram: 48 kbytes remaining ram: 147792 kbytes total ram: 147840 kbytes transferred disk: 206848 kbytes remaining disk: 10278912 kbytes total disk: 10485760 kbytes Thanks, -- Hisashi Ikari 2011-04-11 (月) の 16:50 +0900 に Masanori ITOH さんは書きました: Hi, We are considering if it's possible to support KVM block migration as the next step of live migration. Actually, our main issue at this moment is if that kvm feature is enough stable or not because we got several errors during our try of it using Ubuntu 10.10 code base. Especially, I'm not sure if the feature is enabled or not in the qemu-kvm bundled in Ubuntu/RHEL. Do you have any information about stability? Thanks, Masanori --- Masanori ITOH RD Headquarters, NTT DATA CORPORATION e-mail: itou...@nttdata.co.jp From: igoigo246 igoigo...@gmail.com Subject: [Openstack] (no subject) Date: Mon, 11 Apr 2011 14:41:20 +0900 hi all KVM Block Migration is wonderful function. http://www.linux-kvm.com/content/qemu-kvm-012-adds-block-migration-feature this allow that live migration do without shared storage. When KVM Block migration Support ? Thanks for reading. -- Hisashi Ikari ___ 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 -- Mike Scherbakov www.mirantis.com ___ 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] Testing
Hello Vish. I would like to support testing effort. I wrote an example very basic unit test doc and some tips how to use pudb and nose-pudb. http://etherpad.openstack.org/diablo-testing Regards Nachi Ueno NTT ___ 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] Network Service meeting
Works for me . -Original Message- From: openstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Rick Clark Sent: Tuesday, May 10, 2011 2:12 AM To: Josh Wilmes (jwilmes) Cc: Jamey Meredith; Lew Tucker (letucker); openstack@lists.launchpad.net; Michael Smith (michsmit); openst...@lab.ntt.co.jp; Somik Behera; Ewan Mellor; Youcef Laribi Subject: [Openstack] Network Service meeting We had planned to have a network Service meeting after the release meeting today, but the PTL's have a conflicting meeting in the same channel. I suggest we move it to tomorrow at the same time. Would that be ok for everyone? Rick Clark ___ 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] Network Service meeting
Fine by me. -Original Message- From: openstack-bounces+alex=mellanox@lists.launchpad.net [mailto:openstack-bounces+alex=mellanox@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Tuesday, May 10, 2011 5:13 AM To: Rick Clark; Josh Wilmes Cc: Jamey Meredith; LewTucker (letucker); openstack@lists.launchpad.net; Michael Smith (michsmit); openst...@lab.ntt.co.jp; Somik Behera; Ewan Mellor; Youcef Laribi Subject: Re: [Openstack] Network Service meeting Hi Rick, Wednesday 22:00 UTC would be fine for me. Salvatore -Original Message- From: Rick Clark [mailto:r...@openstack.org] Sent: 10 May 2011 10:12 To: Josh Wilmes Cc: Dan Wendlandt; James Urquhart; Erik Carlin; Salvatore Orlando; radur...@cisco.com; Ewan Mellor; Youcef Laribi; Armando Migliaccio; Troy Toman; Bradley McConnell; openst...@lab.ntt.co.jp; Hisaharu Ishii; r...@midokura.jp; Jamey Meredith; Somik Behera; Lew Tucker (letucker); Michael Smith (michsmit); openstack@lists.launchpad.net Subject: Network Service meeting We had planned to have a network Service meeting after the release meeting today, but the PTL's have a conflicting meeting in the same channel. I suggest we move it to tomorrow at the same time. Would that be ok for everyone? Rick Clark ___ 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] [SPAM] Testing
Vish, this is good stuff. We should pick this up in glance and swift, either sharing a common effort with nova or specifying for each project the same documentation that Vish is suggesting. Heads up for other projects that are looking to be affiliated or incubated projects, it will save time and effort to conform to a common schema for testing that is being laid out. Thanks, John From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Monday, May 09, 2011 4:58 PM To: openstack@lists.launchpad.net Subject: [SPAM] [Openstack] Testing Hello Again, When we had the discussion about Testing, I requested help in creating some documentation and examples of good unit testing practice. I mentioned I would send out an email requesting volunteers to help with this. This is that email! I would ultimately like to have: example very basic unit test example use of stubs example use of mox documentation on what should go into a unit test vs functional test Once we have the examples and documentation laid out, I'd also like to kick-off an effort to clean up all of our existing unittests to match that style. I'd like to collect a few volunteers to work on this. If someone feels like thy would like to head-up this effort, please let me know. I've created an initial blueprint here: https://blueprints.launchpad.net/nova/+spec/unittest-examples ___ 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] Network Service meeting
It would be better for me, actually. James Urquhart Market Manager, SPSU Cisco Systems, Inc. w: 408 525 4741 c: 510 908 1224 Sent from my Windows Phone -Original Message- From: Rick Clark Sent: Tuesday, May 10, 2011 2:11 AM To: Josh Wilmes Cc: Dan Wendlandt; James Urquhart; Erik Carlin; Salvatore Orlando; radur...@cisco.com; Ewan Mellor; Youcef Laribi; Armando Migliaccio; Troy Toman; Bradley McConnell; openst...@lab.ntt.co.jp; Hisaharu Ishii; r...@midokura.jp; Jamey Meredith; Somik Behera; Lew Tucker (letucker); Michael Smith (michsmit); openstack@lists.launchpad.net Subject: Network Service meeting We had planned to have a network Service meeting after the release meeting today, but the PTL's have a conflicting meeting in the same channel. I suggest we move it to tomorrow at the same time. Would that be ok for everyone? Rick Clark ___ 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] Notifications proposal
On May 10, 2011, at 11:07 AM, Matt Dietz wrote: Alright, I'll buy it. Simply adding a UUID would be trivial Cool. Regarding categories, I tend to agree with Jay on this. I think it would be treacherous to try to account for any number of possibilities, and I also think that we need to keep this as simple as possible. Okay fair enough, the external publisher may create categories as needed. On 5/10/11 10:35 AM, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: On Mon, May 9, 2011 at 11:58 PM, Jorge Williams jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com wrote: On May 9, 2011, at 6:39 PM, Matt Dietz wrote: Jorge, Thanks for the feedback! Regarding the message format, we actually don't need the unique id in the generic event format because that's implementation specific. The external publisher I've implemented actually does all of the pubsubhubbub specific heavy lifting for you. The idea behind keeping this system simple at the nova layer is allowing people to implement anything they'd like, such as emails or paging. I guess, I'm not seeing the whole picture. So these are internal messages? Will they cross service boundaries / zones? I'm sorry I missed the conversation at the summit :-) Is there a blueprint I should be reading? On this particular point, I agree with Jorge. A unique identifier should be attached to a message *before* it leaves Nova via the publisher. Otherwise, subscribers will not be able to distinguish between different messages if more than one publisher is publishing the message and tacking on their own unique identifier. For instance, if a Rabbit publisher and email publisher are both enabled, and both attach a unique identifier in a different way, there's no good way to determine two messages are the same. For categories, were you considering this to be a list? Could you give an example of an event that would span multiple categories? From an Atom perspective, I suppose anything a client might want to key in on or subscribe to may be a category. So create may be a category -- a billing layer may key in on all create messages and ignore others. compute may also be a category -- you can aggregate messages from other services so It'd be nice for messages from compute to have their own category. To my knowledge, atom doesn't have the concept of priority so WARN may also be a category. I suppose if these are internal messages an external publisher can split the event_type and priority into individual categories. I disagree with this assessment, Jorge, for this reason: attempting to identify all the possible categories that an organization may wish to assign to a particular event may be near impossible, and in all likelihood, different deployers will have different categories for events. I think a solution of codifying the event_type in the message to a singular set of strings, with a single dotted group notation (like instance.create or something like that) is the best we can do. The subscriber of messages can later act as a translation or aggregator based on the business rules in place at the deployer. For example, let's say a deployer wanted to aggregate messages with event_type of instance.create into two categories instance and create. A custom-written subscriber could either do the aggregation itself, or modify the message payload to include these custom deployer-specific categories. Hope that makes sense. -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] Notifications proposal
George,
Unless I'm completely mistaken, I think our proposal satisfies this suggestion.
What you have here looks like a slight variation on PSHB. Our stuff is coded
such that the responsibility of any heavy lifting falls outside of Nova. In our
case, we'll be implementing the PubSub publisher externally; I.e. I don't think
any of the infrastructure for making PSHB work belongs in Nova. We can then
follow all of the other rules of PSHB(feed discovery and subscriptions,
callbacks etc.)
Does this make sense?
Matt
From: George Reese
george.re...@enstratus.commailto:george.re...@enstratus.com
Date: Mon, 9 May 2011 23:17:29 -0500
To: Jorge Williams
jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com
Cc: Matt Dietz matt.di...@rackspace.commailto:matt.di...@rackspace.com,
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Notifications proposal
I think notifications need to be kept really simple. I put out a proposal a few
months ago at:
http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html
Let the subscribers do any heavy lifting. Just provide them enough information
that they can make the right requests.
-George
On May 9, 2011, at 10:58 PM, Jorge Williams wrote:
On May 9, 2011, at 6:39 PM, Matt Dietz wrote:
Jorge,
Thanks for the feedback!
Regarding the message format, we actually don't need the unique id in the
generic event format because that's implementation specific. The external
publisher I've implemented actually does all of the pubsubhubbub specific heavy
lifting for you. The idea behind keeping this system simple at the nova layer
is allowing people to implement anything they'd like, such as emails or paging.
I guess, I'm not seeing the whole picture. So these are internal messages?
Will they cross service boundaries / zones? I'm sorry I missed the
conversation at the summit :-) Is there a blueprint I should be reading?
For categories, were you considering this to be a list? Could you give an
example of an event that would span multiple categories?
From an Atom perspective, I suppose anything a client might want to key in on
or subscribe to may be a category. So create may be a category -- a billing
layer may key in on all create messages and ignore others. compute may also
be a category -- you can aggregate messages from other services so It'd be
nice for messages from compute to have their own category. To my knowledge,
atom doesn't have the concept of priority so WARN may also be a category. I
suppose if these are internal messages an external publisher can split the
event_type and priority into individual categories.
Finally, I can make the changes to the timestamp. This as just a hypothetical
example, anyway.
Okay cool, thanks Matt.
On May 9, 2011, at 6:13 PM, Jorge Williams
jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com wrote:
On May 9, 2011, at 5:20 PM, Matt Dietz wrote:
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot of concern voiced over messages backing up in any of the
queueing implementations, as well as the intended priority of one message over
another. There are couple of immediately obvious solutions to this. We think
the simplest solution is to implement N queues, where N is equal the number of
priorities. Afterwards, consuming those queues is implementation specific and
dependent on the solution that works best for the user.
The current plan for the Rackspace specific implementation is to use
PubSubHubBub, with a dedicated worker consuming the notification queues and
providing the glue necessary to work with a standard Hub implementation. I have
a very immature worker implementation at https://github.com/Cerberus98/yagi
https://github.com/Cerberus98/yagi if you're interested in checking that out.
Some thoughts:
In order to support PubSubHubBub you'll also need each message to also contain
a globally unique ID. It would also be nice if you had the concept of
categories. I realize you kinda get that with the event type
compute.create_instance but there are always going to be messages that may
belong to multiple categories. Also, ISO timestamps with a T :
2011-05-09T22:00:14.621831 are way more interoperable -- I would also include
a timezone designator Z for standard time 2011-05-09T22:00:14.621831Z --
otherwise some implementation assume the local timezone.
-jOrGe W.
___
Mailing list: https://launchpad.net/~openstack
Post to :
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
George
Re: [Openstack] Notifications proposal
These all sound perfect to me. I'm hoping our PSHB implementation solves that
problem. More specifically, the publisher worker that I linked to earlier I
think solves most of what you're referring to, and works well with the Google
reference hub. There's a lot more work to be done, but I think it's on target
with what you're suggesting
Thanks!
From: George Reese
george.re...@enstratus.commailto:george.re...@enstratus.com
Date: Tue, 10 May 2011 12:07:22 -0500
To: Matt Dietz matt.di...@rackspace.commailto:matt.di...@rackspace.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Notifications proposal
I came into the conversation late and it struck me this proposal was a bit
heavier than what I was proposing.
I agree with letting something outside of Nova do the heavy lifting. Much more
scaleable. The base things I would like to see are:
a) the minimal amount of information to let a subscriber know that there was a
change (not the details of the change)
b) only information that is safe to deliver over a public network to an
untrusted target
c) that the subscriber be able to be a programmatic endpoint (not simply
email/SMS)
d) the subscriber should not assume anything about the message, including its
authenticity (it should use its credentials to verify the truth of the message
and details of change with provider)
-George
On May 10, 2011, at 12:01 PM, Matt Dietz wrote:
George,
Unless I'm completely mistaken, I think our proposal satisfies this suggestion.
What you have here looks like a slight variation on PSHB. Our stuff is coded
such that the responsibility of any heavy lifting falls outside of Nova. In our
case, we'll be implementing the PubSub publisher externally; I.e. I don't think
any of the infrastructure for making PSHB work belongs in Nova. We can then
follow all of the other rules of PSHB(feed discovery and subscriptions,
callbacks etc.)
Does this make sense?
Matt
From: George Reese
george.re...@enstratus.commailto:george.re...@enstratus.com
Date: Mon, 9 May 2011 23:17:29 -0500
To: Jorge Williams
jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com
Cc: Matt Dietz matt.di...@rackspace.commailto:matt.di...@rackspace.com,
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] Notifications proposal
I think notifications need to be kept really simple. I put out a proposal a few
months ago at:
http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html
Let the subscribers do any heavy lifting. Just provide them enough information
that they can make the right requests.
-George
On May 9, 2011, at 10:58 PM, Jorge Williams wrote:
On May 9, 2011, at 6:39 PM, Matt Dietz wrote:
Jorge,
Thanks for the feedback!
Regarding the message format, we actually don't need the unique id in the
generic event format because that's implementation specific. The external
publisher I've implemented actually does all of the pubsubhubbub specific heavy
lifting for you. The idea behind keeping this system simple at the nova layer
is allowing people to implement anything they'd like, such as emails or paging.
I guess, I'm not seeing the whole picture. So these are internal messages?
Will they cross service boundaries / zones? I'm sorry I missed the
conversation at the summit :-) Is there a blueprint I should be reading?
For categories, were you considering this to be a list? Could you give an
example of an event that would span multiple categories?
From an Atom perspective, I suppose anything a client might want to key in on
or subscribe to may be a category. So create may be a category -- a billing
layer may key in on all create messages and ignore others. compute may also
be a category -- you can aggregate messages from other services so It'd be
nice for messages from compute to have their own category. To my knowledge,
atom doesn't have the concept of priority so WARN may also be a category. I
suppose if these are internal messages an external publisher can split the
event_type and priority into individual categories.
Finally, I can make the changes to the timestamp. This as just a hypothetical
example, anyway.
Okay cool, thanks Matt.
On May 9, 2011, at 6:13 PM, Jorge Williams
jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com wrote:
On May 9, 2011, at 5:20 PM, Matt Dietz wrote:
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot of concern voiced over messages backing up in any of the
queueing implementations, as well as the intended priority of one message over
another. There are couple of
Re: [Openstack] KVM Block Migration
I don't know if anyone has started work on this feature. Someone should file a blueprint. Vish On May 10, 2011, at 3:35 AM, Mikhail Shcherbakov wrote: Hi, Is there any progress on KVM block migration? I'd like to test it and possibly make some changes to nova to support block devices, but don't want to reinventing the wheel. Thanks, 2011/4/12 Masanori ITOH itou...@nttdata.co.jp Hi, Vish also mentioned that we should support the KVM block migration feature instead of stability which I mentioned because it's very much useful. I agree with Vish of course. :) Actually, we discussed inclusion of block migration feature at San Antonio. :) I've also seen the page Hisaki mentioned. My point is that the page explains interacting qemu monitor but we need to invoke the feature through libvirt layer not the qemu monitor directly. Here, A colleague of mine mentioned that --copy-storage-all option of virsh looked like not-supported yet in Ubuntu 10.10 at least. Hisaki, do you have any information if it's enabled in Ubuntu 11.04 libvirt? I mean using virsh, did you succeed invoking block live migration something like the following? $ virsh migrate --live --copy-storage-all DOMID DESTURL Unfortunately, we haven't been able to make enough time trying Natty alpha because of our schedule delay caused by the earthquake in Northeastern Japan. :( At least, libvirt(virsh) included in RHEL6 does not support the feature. But, anyway I will talk about the issue with Kei and Muneyuki before going to the Design Summit. :) Regards, Masanori From: igoigo246 igoigo...@gmail.com Subject: Re: [Openstack] KVM Block Migration Date: Tue, 12 Apr 2011 09:28:38 +0900 Hi, I look Japanease Site. http://www.cuspy.org/blog/archives/917 This site wrote. image file vda.qcow sending host qemu --enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio,boot=on \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio receive host touch vda.qcow qemu -enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio \ -incoming tcp:0: sending host migrate -d -b tcp:wasabi: (qemu) info migrate Migration status: active transferred ram: 48 kbytes remaining ram: 147792 kbytes total ram: 147840 kbytes transferred disk: 206848 kbytes remaining disk: 10278912 kbytes total disk: 10485760 kbytes Thanks, -- Hisashi Ikari 2011-04-11 (月) の 16:50 +0900 に Masanori ITOH さんは書きました: Hi, We are considering if it's possible to support KVM block migration as the next step of live migration. Actually, our main issue at this moment is if that kvm feature is enough stable or not because we got several errors during our try of it using Ubuntu 10.10 code base. Especially, I'm not sure if the feature is enabled or not in the qemu-kvm bundled in Ubuntu/RHEL. Do you have any information about stability? Thanks, Masanori --- Masanori ITOH RD Headquarters, NTT DATA CORPORATION e-mail: itou...@nttdata.co.jp From: igoigo246 igoigo...@gmail.com Subject: [Openstack] (no subject) Date: Mon, 11 Apr 2011 14:41:20 +0900 hi all KVM Block Migration is wonderful function. http://www.linux-kvm.com/content/qemu-kvm-012-adds-block-migration-feature this allow that live migration do without shared storage. When KVM Block migration Support ? Thanks for reading. -- Hisashi Ikari ___ 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 -- Mike Scherbakov www.mirantis.com ___ 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] Notifications proposal
Hi George,
Understood, but burrow can act as both. At the core, the difference
between SQS and SNS are notification workers and a lower default
message TTL. Matt mentioned that Nova will push to RabbitMQ or some
other MQ and workers pull from the queue to translate into PuSH, email,
sms, etc. If this intermediate message queue is burrow, clients could
also subscribe directly to the notification queue with their OpenStack
credentials and see messages along with the other workers. It's simply
opening up the data pipe at another level if thats more convenient
or efficient for the event consumers.
If we're going through the trouble of building a scalable message
queue/notification service for general use, I'm not sure why we
wouldn't use it over maintaining other MQ systems. If we don't want to
use burrow when it's ready, I should probably reevaluate the purpose
of Burrow as this was one of the example use cases. :)
-Eric
On Tue, May 10, 2011 at 02:17:46PM -0500, George Reese wrote:
This isn't a message queue, it's a push system.
In other words, consumers don't pull info from a queue, the info is pushed
out to any number of subscribers as the message is generated.
Amazon SNS vs. SQS, except this isn't a cloud service but a mechanism for
notifying interested party of cloud changes.
-George
On May 10, 2011, at 1:49 PM, Eric Day wrote:
We may also want to put in some kind version or self-documenting URL
so it's easier to accommodate message format changes later on.
As for the issue of things getting backed up in the queues for other
non-PuSH mechanisms (and fanout), burrow has fanout functionality
that depends on messages to expire (every message is inserted with
a TTL). This would allow multiple readers to see the same message
and for it to disappear after say an hour. This allows deployments,
third party tools, and clients to write workers to act on events from
the raw queue.
With burrow, it will also be possible for clients to pull raw messages
directly from the queue via a REST API in a secure fashion using
the same account credentials as other OpenStack service (whatever
keystone is configured for). So while an email notification will want
to strip any sensitive information, a direct queue client could see
more details.
-Eric
On Mon, May 09, 2011 at 10:20:04PM +, Matt Dietz wrote:
Hey guys,
Monsyne Dragon and myself are proposing an implementation for
notifications going forward. Currently my branch exists
under https://code.launchpad.net/~cerberus/nova/nova_notifications.
you'll
see that's it been proposed for merge, but we're currently refactoring it
around changes proposed at the summit during the notifications
discussion,
which you can see at http://etherpad.openstack.org/notifications
At the heart of the above branch is the idea that, because nova is about
compute, we get notifications away from Nova as quickly as possible. As
such, we've implemented a simple modular driver system which merely
pushes
messages out. The two sample drivers are for pushing messages into
Rabbit, or doing nothing at all. There's been talk about adding Burrow as
a third possible driver, which I don't think would be an issue.
One of the proposals is to have priority levels for each notification.
What we're proposing is emulating the standard Python logging module and
providing levels like WARN' and CRITICAL in the notification.
Additionally, the message format we're proposing will be a JSON
dictionary
containing the following attributes:
publisher_id - the source worker_type.host of the message.
timestamp - the GMT timestamp the notification was sent at
event_type - the literal type of event (ex. Instance Creation)
priority - patterned after the enumeration of Python logging levels in
the set (DEBUG, WARN, INFO, ERROR, CRITICAL)
payload - A python dictionary of attributes
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot of concern voiced over messages backing up in any of the
queueing implementations, as well as the intended priority of one message
over another. There are couple of immediately obvious solutions to this.
We think the simplest solution is to implement N queues, where N is equal
the number of priorities. Afterwards, consuming those queues is
implementation specific and dependent on the solution that works best for
the user.
The current plan for the Rackspace specific implementation is to use
PubSubHubBub, with a dedicated worker consuming the notification queues
and providing the glue necessary to work with a standard Hub
implementation. I have a very immature worker
Re: [Openstack] Notifications proposal
For the record, I should also say I think RabbitMQ is awesome and
should be used for deployments where it makes sense. Keeping it
modular and also allowing burrow to be an option will make more sense
for some deployments.
-Eric
On Tue, May 10, 2011 at 07:52:55PM +, Matt Dietz wrote:
For the record, I like the idea of using Burrow at this level. I certainly
don't expect everyone to go to the trouble of setting up something like
PSHB to get their notifications. I can look at adding another driver for
Burrow in addition to Rabbit so there are plenty of options.
On 5/10/11 2:30 PM, Eric Day e...@oddments.org wrote:
Hi George,
Understood, but burrow can act as both. At the core, the difference
between SQS and SNS are notification workers and a lower default
message TTL. Matt mentioned that Nova will push to RabbitMQ or some
other MQ and workers pull from the queue to translate into PuSH, email,
sms, etc. If this intermediate message queue is burrow, clients could
also subscribe directly to the notification queue with their OpenStack
credentials and see messages along with the other workers. It's simply
opening up the data pipe at another level if thats more convenient
or efficient for the event consumers.
If we're going through the trouble of building a scalable message
queue/notification service for general use, I'm not sure why we
wouldn't use it over maintaining other MQ systems. If we don't want to
use burrow when it's ready, I should probably reevaluate the purpose
of Burrow as this was one of the example use cases. :)
-Eric
On Tue, May 10, 2011 at 02:17:46PM -0500, George Reese wrote:
This isn't a message queue, it's a push system.
In other words, consumers don't pull info from a queue, the info is
pushed out to any number of subscribers as the message is generated.
Amazon SNS vs. SQS, except this isn't a cloud service but a mechanism
for notifying interested party of cloud changes.
-George
On May 10, 2011, at 1:49 PM, Eric Day wrote:
We may also want to put in some kind version or self-documenting URL
so it's easier to accommodate message format changes later on.
As for the issue of things getting backed up in the queues for other
non-PuSH mechanisms (and fanout), burrow has fanout functionality
that depends on messages to expire (every message is inserted with
a TTL). This would allow multiple readers to see the same message
and for it to disappear after say an hour. This allows deployments,
third party tools, and clients to write workers to act on events from
the raw queue.
With burrow, it will also be possible for clients to pull raw messages
directly from the queue via a REST API in a secure fashion using
the same account credentials as other OpenStack service (whatever
keystone is configured for). So while an email notification will want
to strip any sensitive information, a direct queue client could see
more details.
-Eric
On Mon, May 09, 2011 at 10:20:04PM +, Matt Dietz wrote:
Hey guys,
Monsyne Dragon and myself are proposing an implementation for
notifications going forward. Currently my branch exists
under
https://code.launchpad.net/~cerberus/nova/nova_notifications. you'll
see that's it been proposed for merge, but we're currently
refactoring it
around changes proposed at the summit during the notifications
discussion,
which you can see at http://etherpad.openstack.org/notifications
At the heart of the above branch is the idea that, because nova is
about
compute, we get notifications away from Nova as quickly as
possible. As
such, we've implemented a simple modular driver system which
merely pushes
messages out. The two sample drivers are for pushing messages
into
Rabbit, or doing nothing at all. There's been talk about adding
Burrow as
a third possible driver, which I don't think would be an issue.
One of the proposals is to have priority levels for each
notification.
What we're proposing is emulating the standard Python logging
module and
providing levels like WARN' and CRITICAL in the notification.
Additionally, the message format we're proposing will be a JSON
dictionary
containing the following attributes:
publisher_id - the source worker_type.host of the message.
timestamp - the GMT timestamp the notification was sent at
event_type - the literal type of event (ex. Instance Creation)
priority - patterned after the enumeration of Python logging
levels in
the set (DEBUG, WARN, INFO, ERROR, CRITICAL)
payload - A python dictionary of attributes
Message example:
{ 'publisher_id': 'compute.host1',
'timestamp': '2011-05-09 22:00:14.621831',
'priority': 'WARN',
'event_type': 'compute.create_instance',
'payload': {'instance_id': 12, ... }}
There was a lot
Re: [Openstack] Proposal for Nova Core
+1 On Tue, May 10, 2011 at 4:13 PM, Paul Voccio paul.voc...@rackspace.com wrote: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Thanks, pvo Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Nova Core
+1 On Tue, May 10, 2011 at 4:13 PM, Paul Voccio paul.voc...@rackspace.com wrote: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince ) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Thanks, pvo Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for Nova Core
+1 On May 10, 2011, at 1:25 PM, Josh Kearney wrote: +1 On Tue, May 10, 2011 at 4:13 PM, Paul Voccio paul.voc...@rackspace.com wrote: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Thanks, pvo 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 ___ 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] Proposal for Nova Core
+1 On 5/10/11 3:20 PM, Jay Pipes jaypi...@gmail.com wrote: +1 On Tue, May 10, 2011 at 4:13 PM, Paul Voccio paul.voc...@rackspace.com wrote: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Thanks, pvo 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
[Openstack] nova install from source code
Hi, Which is the best method on installing nova from source code or any direction to move over this hurdle is appreciated! We have followed http://wiki.openstack.org/InstallFromSource to install latest trunk or Cactus.tgz, but it always gets me to following error and leaving vm stuck in scheduling mode with scheduler.log showing (nova): TRACE: NoValidHost: Scheduler was unable to locate a host for this request. Is the appropriate service running? and mysql locked up and can't be log-in to check compute-nodes status. Googled to find it would need nova-compute/nova-network to start, so apt-get installed but still no help since it can't locate libvirt.xqemu.xml.template. Through the way, we also need to change mysql access from root@% to root@localhost to keep nova-manage db sync happy. We had also followed http://wiki.openstack.org/NovaInstall/Bexar to install Bexar release ok, but the same process to install Cactus or latest trunk turns out to pull in a lot of packages manually and not quite successfully. If we follow http://wiki.openstack.org/InstallFromSource do we need to run setup.py build install, or any extra steps to be aware? I suspect it can take the nove-compute tools comes with the source code. Thanks, -Fred ___ 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 IRC Channels
As discussed on the mailing list and the #openstack-meeting, the general consensus was that we create a new development channel. The new IRC channels on FreeNode are: #openstack - to be used for Help, Support, Bug reporting, etc #openstack-dev - to be used as the primary development channel for all Openstack projects Everyone is welcome in either channel, we just wanted to split up some of the crosstalk a bit. Thanks, antonym 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] Proposal for Nova Core
2011/5/10 Paul Voccio paul.voc...@rackspace.com: All, I would like to nominate Dan Prince (https://launchpad.net/~dan-prince) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. Absolutely +1 If noone protests by Monday morning, I'll make it so. Best regards, Soren. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Glance] New Glance API changes .. feedback needed
Hey all, We've been working to improve the Glance API. The first step to improving the API, however, is to add versioning to it. We've gotten a lot of the work done on this versioning of the API (see https://code.launchpad.net/~jaypipes/glance/api-version/+merge/60130). However, there is an issue that remains unresolved that we would like some community input on. We have a choice of using the following two API URIs: /v1/images /v1.0/images I coded the latter (/v1.0/images) because I was copying the way that swauth and Nova's OpenStack API do it, but Brian Waldon brought up the fact that major versions of APIs should never break clients written to that major version of the API, so there is no real reason to specify the minor version in the URLs. I would prefer the shorter /v1/images API, myself. What do others think? Feedback appreciated. -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] [Glance] New Glance API changes .. feedback needed
Would adding new fields into a response bump the minor version number and not the major? In that case, knowing the exact version would be nice. In all honesty though, I'm for integer version numbers for APIs anyway, so every set of changes bumps the revno, and you always have good documentation specific to exactly what you are querying against and tool authors don't get lost sifting through fine print. On Tue, May 10, 2011 at 6:52 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, We've been working to improve the Glance API. The first step to improving the API, however, is to add versioning to it. We've gotten a lot of the work done on this versioning of the API (see https://code.launchpad.net/~jaypipes/glance/api-version/+merge/60130). However, there is an issue that remains unresolved that we would like some community input on. We have a choice of using the following two API URIs: /v1/images /v1.0/images I coded the latter (/v1.0/images) because I was copying the way that swauth and Nova's OpenStack API do it, but Brian Waldon brought up the fact that major versions of APIs should never break clients written to that major version of the API, so there is no real reason to specify the minor version in the URLs. I would prefer the shorter /v1/images API, myself. What do others think? Feedback appreciated. -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] A question about FT/HA/LB of Openstack,thanks!
Hi, I have a question about the FT/HA/LB features of the Openstack. Which seems similar to this question: https://answers.launchpad.net/nova/+question/154515 I have know that there is a project named Loadbalance as a service which is now under develping, but I also learn from some friends that this project only concern about LB of instances(VM), and without regard to LB of the applications that running on the vms. can someone tell me something about that. Thank you very much for your attention and reply. Best wishes. Zhi fengcai. ___ 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] Proposal for Nova Core
+1 from me too :) On May 10, 2011, at 6:21 PM, Ed Leafe wrote: On May 10, 2011, at 4:13 PM, Paul Voccio wrote: I would like to nominate Dan Prince (https://launchpad.net/~dan-prince) for nova-core. He has been a solid contributor in terms of code, reviews and discussions during the summit. +1 from me. -- Ed Leafe Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] PREROUTING 169.254.169.254 rule shoud not on Compute node.......
For what it's worth, we're running in a configuration similar to the one in the attached diagram using VlanManager. When we moved the nova-network service off of the machine with nova-api, we needed to add an additional prerouting rule on the network server that prevented the traffic from being sent out via NAT (which caused the source address to be lost, resulting in a metadata resolution error). Once the packets arrive at the api service with the correct source address, they need a route back, via the nova-network server in order to get the response packets onto the correct vlan. With a single nova-network server, a static route will do. With multiple nova-network instances on different systems, things get a little more complicated. We ended up setting up route distribution via quagga between the nova-api server, and the nova-network servers. This ensures that nova-api knows which nova-network instance to use to reach any particular project network. -nld On Tue, May 10, 2011 at 9:08 PM, 郭耀謙 tonyt...@gmail.com wrote: Hello , guys There's a problem while separate instance's network and nova-management network. EX. Nova management network : 192.168.1.0/24 eth0 Instance network : 10.0.0.0/12 eth1 bridge to br100 During cloud-setup : Instance try to retrieve metadata from 169.254.169.254. Instances(10.0.0.0/12) request 169.254.169.254 PREROUTING from gateway(nova-network). But If PREROUTING rule is already been set on nova-Compute node, instance request will be redirected on VM host instead of nova-network host. So If your topology is like A diadram from StackOps , Plz Check iptables rule on Compute nodes. -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:8773 And del this rule , your instance will get metadata correctly ___ 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] [Glance] New Glance API changes .. feedback needed
On May 10, 2011, at 5:52 PM, Jay Pipes wrote: Hey all, We've been working to improve the Glance API. The first step to improving the API, however, is to add versioning to it. We've gotten a lot of the work done on this versioning of the API (see https://code.launchpad.net/~jaypipes/glance/api-version/+merge/60130). However, there is an issue that remains unresolved that we would like some community input on. We have a choice of using the following two API URIs: /v1/images /v1.0/images I coded the latter (/v1.0/images) because I was copying the way that swauth and Nova's OpenStack API do it, but Brian Waldon brought up the fact that major versions of APIs should never break clients written to that major version of the API, so there is no real reason to specify the minor version in the URLs. Whether or not you use a .0 at the end of the URI version is at your digression -- it may still be useful to have it denote that the API hasn't changed radically from one version to the next. Thus the 1.1 compute API has only minor additions and subtractions but no dramatic changes. That said, in Rackspace, we consider the entire version in the URI (v1.0, v1.1) a major version number -- I know that's confusing. There's nothing saying you can't start with v1 and move to v1.5 or v2 if need be. The important thing to consider is that the whole things is major version number. We do use minor version numbers for other aspects of the service. Here are the rules that we're considering at least internally at Rackspace: WADLs major and minor version number, minor revision changes are backward compatible. XSD major and minor version numbers, with minor revisions denoting backward compatible changes. Media Types -- major number only XML Namespaces -- major number only Version URIs -- major number only Backward compatible changes with the Media Type, the XML Namespace, and the Version URI always fall within the same major version number. There's really no benefit, for example, in having a separate URI if we have backward compatible changes. I would prefer the shorter /v1/images API, myself. This is what we're considering at Rackspace as a standard :-) Fair warning though, there may be non-technical (i.e. marketing) reasons for using a pseudo-minor version number in the future. -jOrGe W. 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] PREROUTING 169.254.169.254 rule shoud not on Compute node.......
*#iptables -t nat -A nova-network-POSTROUTING -s 10.0.0.0/12 -d 192.168.1.0/24 -j ACCEPT* * * ***That's what I did on nova-network host .* * * *btw , I always isolate nova-network.* *I'm interesting about **quagga in your environment.* 2011/5/11 Narayan Desai narayan.de...@gmail.com For what it's worth, we're running in a configuration similar to the one in the attached diagram using VlanManager. When we moved the nova-network service off of the machine with nova-api, we needed to add an additional prerouting rule on the network server that prevented the traffic from being sent out via NAT (which caused the source address to be lost, resulting in a metadata resolution error). Once the packets arrive at the api service with the correct source address, they need a route back, via the nova-network server in order to get the response packets onto the correct vlan. With a single nova-network server, a static route will do. With multiple nova-network instances on different systems, things get a little more complicated. We ended up setting up route distribution via quagga between the nova-api server, and the nova-network servers. This ensures that nova-api knows which nova-network instance to use to reach any particular project network. -nld On Tue, May 10, 2011 at 9:08 PM, 郭耀謙 tonyt...@gmail.com wrote: Hello , guys There's a problem while separate instance's network and nova-management network. EX. Nova management network : 192.168.1.0/24 eth0 Instance network : 10.0.0.0/12 eth1 bridge to br100 During cloud-setup : Instance try to retrieve metadata from 169.254.169.254. Instances(10.0.0.0/12) request 169.254.169.254 PREROUTING from gateway(nova-network). But If PREROUTING rule is already been set on nova-Compute node, instance request will be redirected on VM host instead of nova-network host. So If your topology is like A diadram from StackOps , Plz Check iptables rule on Compute nodes. -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:8773 And del this rule , your instance will get metadata correctly ___ 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] KVM Block Migration
Hi, OK. I'll create the block migration bluprint and a spec. page today (in Japan). Regards, Masanori From: Vishvananda Ishaya vishvana...@gmail.com Subject: Re: [Openstack] KVM Block Migration Date: Wed, 11 May 2011 03:57:47 +0900 I don't know if anyone has started work on this feature. Someone should file a blueprint. Vish On May 10, 2011, at 3:35 AM, Mikhail Shcherbakov wrote: Hi, Is there any progress on KVM block migration? I'd like to test it and possibly make some changes to nova to support block devices, but don't want to reinventing the wheel. Thanks, 2011/4/12 Masanori ITOH itou...@nttdata.co.jpmailto:itou...@nttdata.co.jp Hi, Vish also mentioned that we should support the KVM block migration feature instead of stability which I mentioned because it's very much useful. I agree with Vish of course. :) Actually, we discussed inclusion of block migration feature at San Antonio. :) I've also seen the page Hisaki mentioned. My point is that the page explains interacting qemu monitor but we need to invoke the feature through libvirt layer not the qemu monitor directly. Here, A colleague of mine mentioned that --copy-storage-all option of virsh looked like not-supported yet in Ubuntu 10.10 at least. Hisaki, do you have any information if it's enabled in Ubuntu 11.04 libvirt? I mean using virsh, did you succeed invoking block live migration something like the following? $ virsh migrate --live --copy-storage-all DOMID DESTURL Unfortunately, we haven't been able to make enough time trying Natty alpha because of our schedule delay caused by the earthquake in Northeastern Japan. :( At least, libvirt(virsh) included in RHEL6 does not support the feature. But, anyway I will talk about the issue with Kei and Muneyuki before going to the Design Summit. :) Regards, Masanori From: igoigo246 igoigo...@gmail.commailto:igoigo...@gmail.com Subject: Re: [Openstack] KVM Block Migration Date: Tue, 12 Apr 2011 09:28:38 +0900 Hi, I look Japanease Site. http://www.cuspy.org/blog/archives/917 This site wrote. image file vda.qcow sending host qemu --enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio,boot=on \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio receive host touch vda.qcow qemu -enable-kvm -m 512 \ -drive file=vda.qcow,if=virtio \ -net nic,macaddr=00:16:3E:00:FF:32,model=virtio \ -incoming tcp:0: sending host migrate -d -b tcp:wasabi: (qemu) info migrate Migration status: active transferred ram: 48 kbytes remaining ram: 147792 kbytes total ram: 147840 kbytes transferred disk: 206848 kbytes remaining disk: 10278912 kbytes total disk: 10485760 kbytes Thanks, -- Hisashi Ikari 2011-04-11 (月) の 16:50 +0900 に Masanori ITOH さんは書きました: Hi, We are considering if it's possible to support KVM block migration as the next step of live migration. Actually, our main issue at this moment is if that kvm feature is enough stable or not because we got several errors during our try of it using Ubuntu 10.10 code base. Especially, I'm not sure if the feature is enabled or not in the qemu-kvm bundled in Ubuntu/RHEL. Do you have any information about stability? Thanks, Masanori --- Masanori ITOH RD Headquarters, NTT DATA CORPORATION e-mail: itou...@nttdata.co.jpmailto:itou...@nttdata.co.jp From: igoigo246 igoigo...@gmail.commailto:igoigo...@gmail.com Subject: [Openstack] (no subject) Date: Mon, 11 Apr 2011 14:41:20 +0900 hi all KVM Block Migration is wonderful function. http://www.linux-kvm.com/content/qemu-kvm-012-adds-block-migration-feature this allow that live migration do without shared storage. When KVM Block migration Support ? Thanks for reading. -- Hisashi Ikari ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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.netmailto: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.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mike Scherbakov www.mirantis.comhttp://www.mirantis.com/ ___ Mailing list: https://launchpad.net/~openstack Post to
