Re: [Openstack-doc-core] inviting Ying Chun Guo to join openstack-doc-core
Thank you for your invitation, Anne. I'd love to ! I will try my best to work for openstack documents. My English may be not as good as Chinese. But I have good experience in programming. Besides translation and bug fixing, I also can contribute to doc tools development. For example, I plan to work with CI team to automate document publishing process and translation process as much as possible. Regards Ying Chun Guo (Daisy) annegen...@justwriteclick.com wrote on 07/28/2012 03:08:38 AM: Anne Gentle a...@openstack.org Sent by: annegen...@justwriteclick.com 07/28/2012 03:08 AM To openstack-doc-core@lists.launchpad.net, Ying Chun Guo/China/IBM@IBMCN, cc Subject inviting Ying Chun Guo to join openstack-doc-core Hi all - I'd like to invite Ying Chun Guo (Daisy) to join our team, she has worked both on doc bugs and on a process for translating documentation. Hi Daisy - I hope you'll accept the invitation to join openstack-doc-core. Your contributions have been extremely helpful. Thanks, Anne -- Mailing list: https://launchpad.net/~openstack-doc-core Post to : openstack-doc-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-doc-core More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Qcow2 Details on base images
On 28/07/12 05:42, Gaurab Basu wrote: Hi, I am trying to figure out the technology that openstack uses when multiple VM's having the*same *base image (OS) are provisioned on a physical server. Does it use as many copy as the number of VM's or does it use the same base image and then copy on write. I need to understand the complete details. Can anybody share some details or point me to some place where I can find the details. Its pretty hard to provide a complete description of what happens, because the code keeps changing. However, assuming you have copy on write turned on (which is the default IIRC), and assuming that all of the instances have the same disk size, then you end up with: - the image as fetched from glance, with possible format conversion - that image resized to the size the instance requested - a cow on write layer for each instance that is using that sized image The first should be smallish, the second can be quite large, and the third will really depend on how much writing the instances are doing. Note that this all falls apart if instances are migrated, because as part of the migration the copy on write layer is transformed into a full disk image, which is what is shipped over to the new machine. Hope this helps, Mikal ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] proposal to provide project specific instance type
unicell, I've also wanted the same functionality. I think it's an important feature for private cloud deployments. Thanks, Nate On Jul 28, 2012 1:15 AM, unicell unic...@gmail.com wrote: Hi, In our use case, there is a need to provide project-specific instance type. Meaning that this instance type is only visible and available for several projects. It's an idea kind of like private image concept for Glance project. Has this proposal been discussed before somewhere? Any comments? I'll be willing to fire a blueprint and work on patches if this concept is workable. Thanks! -- unicell ___ 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] Nomination records
Jonathan, Can you please post all BoD nominations at your earliest convenience? (Including affiliation of the nominator). Based on recent activities, I've recommended to the rest of the corporate sponsors that we suspend and restart the BoD election, pending better tools and an investigation into allegations of… well, IAMAL, but at the very least, gratuitous violations of the Code of Conduct. Hopefully I can submit a more detailed plan for that this afternoon, including some suggestions of neutral third parties who could oversee the election. Cheers, -- Joshua McKenty, CEO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (650) 283-6846 http://www.pistoncloud.com Oh, Westley, we'll never survive! Nonsense. You're only saying that because no one ever has.___ 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] Qcow2 Details on base images
On 07/28/2012 11:10 AM, Gaurab Basu wrote: Another thing I would like to know is whether it uses snapshot mechanism over time. What is it you are referring to above? Are you asking whether Nova automatically takes snapshots of images over time? If so, no, it does not. If a user requests a snapshot of a launched instance, then Nova will issue snapshot commands -- in the case of the libvirt driver, these commands would be qemu-img snapshot -c SNAPSHOT_NAME IMAGE_PATH. I mean how does the copy on write functionality works. Does it keep the diff snapshots over time ( or something else ). Not sure here whether you are asking how QEMU's copy on write operations work or whether Nova keeps the base images separate from any VM images. If you are asking about the latter, the answer is that Nova will create the virtual machine images by creating a COW image based on the base image it pulls from Glance -- after making a resized copy of the base image if it needs to do so to meet the needs of the requested image size of the VM. Snapshots that are taken of virtual machine images on a host are stored by Nova in Glance. And does the diff work at the level of file or block level? AFAIK, CoW and snapshot actions with QEMU are block-level. What is the format that the image is converted to after it is fetched from glance. There may be no conversion needed at all... it depends on what the format of the original base image that was stored in Glance. Conversion between raw/iso and QCOW2 and vice versa is what you see in the code, and is what is done during migration as Mikal mentioned below. I am fairly new to openstack. Can you point me to the specific files in the code where all these things are coded. I want to know the details of the present state. grep for qemu-img in the nova/ directory. You'll see all the files that call qemu-img commands and then you can go look in those files. Best, -jay Thanks again for your help. Regards, Gaurab On Sat, Jul 28, 2012 at 11:52 AM, Michael Still michael.st...@canonical.com mailto:michael.st...@canonical.com wrote: On 28/07/12 05:42, Gaurab Basu wrote: Hi, I am trying to figure out the technology that openstack uses when multiple VM's having the*same *base image (OS) are provisioned on a physical server. Does it use as many copy as the number of VM's or does it use the same base image and then copy on write. I need to understand the complete details. Can anybody share some details or point me to some place where I can find the details. Its pretty hard to provide a complete description of what happens, because the code keeps changing. However, assuming you have copy on write turned on (which is the default IIRC), and assuming that all of the instances have the same disk size, then you end up with: - the image as fetched from glance, with possible format conversion - that image resized to the size the instance requested - a cow on write layer for each instance that is using that sized image The first should be smallish, the second can be quite large, and the third will really depend on how much writing the instances are doing. Note that this all falls apart if instances are migrated, because as part of the migration the copy on write layer is transformed into a full disk image, which is what is shipped over to the new machine. Hope this helps, Mikal ___ 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] [Nova] proposal to provide project specific instance type
On 07/28/2012 01:10 AM, unicell wrote: Hi, In our use case, there is a need to provide project-specific instance type. Meaning that this instance type is only visible and available for several projects. It's an idea kind of like private image concept for Glance project. Has this proposal been discussed before somewhere? Any comments? I'll be willing to fire a blueprint and work on patches if this concept is workable. Thanks! I'd love to see this functionality. It would definitely make putting the clamps down on abusive tenants a bit easier... :) I know folks have started (finished?) work on the per-user quota functionality. This would be a natural complement to that work IMHO. -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] qpid_heartbeat...doesn't?
On 07/29/2012 03:24 AM, Lars Kellogg-Stedman wrote: Our environment has connection-tracking firewalls that drop idle connections after an hour. There is a connection between nova-compute and our qpidd server that appears to be idle for long periods of time. When the firewall drops this connection, the participating hosts are unaware of that fact and ultimately stop communicating with each other until we restart nova-compute. I was hoping that the qpid_heartbeat parameter would avoid this problem by keeping the connection active, but despite having qpid_heartbeat set explicitly in our configuration... # This is supposed to be the default qpid_heartbeat = 5 ...there is no traffic across this connection I can deal with this problem by forcing (via libkeepalive, http://libkeepalive.sourceforge.net) SO_KEEPALIVE on the AMQ sockets (and tuning the net.ipv4.tcp_keepalive_time sysctl to be the firewall connection timeout), but that seems a bit of a hack. It's also possible to work around this by disabling idle connection timeouts on the firewall, so we're not completely stymied... ...but I would like to understand why setting qpid_heartbeat does not, in fact, result in the regular transmission of heartbeat packets across the connection. We're running openstack-nova-2012.1.1-0.20120615.13614 from EPEL (and qpid 0.14). Looks like a typo. Could you try this. cheers, Pádraig. diff --git a/nova/rpc/impl_qpid.py b/nova/rpc/impl_qpid.py index 289f21b..e19079e 100644 --- a/nova/rpc/impl_qpid.py +++ b/nova/rpc/impl_qpid.py @@ -317,7 +317,7 @@ class Connection(object): FLAGS.qpid_reconnect_interval_min) if FLAGS.qpid_reconnect_interval: self.connection.reconnect_interval = FLAGS.qpid_reconnect_interval -self.connection.hearbeat = FLAGS.qpid_heartbeat +self.connection.heartbeat = FLAGS.qpid_heartbeat self.connection.protocol = FLAGS.qpid_protocol self.connection.tcp_nodelay = FLAGS.qpid_tcp_nodelay ___ 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] Keyring support in openstack
Team, As per patch https://review.openstack.org/#/c/9497/ we are adding keyring support for openstack client. If password is not specified in command line or environment variable, the user is prompted to enter password. During this time, the password is stored in keyring. During next time, the password is read from keyring, instead of prompt. It is true, if password is not specified in command line or environment variable. This behavior is documented in this wiki page: http://wiki.openstack.org/KeyringSupport If you have any comments, please let us know. Thank you, -- Regards, Bhuvaneswaran A www.livecipher.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
