Re: [Openstack] Devstack +XCP/XenServer Kernel Panic
I've never seen that kernel panic before. If you're building on an NFS share though, that often screws up the permissions. You could have root-squashing turned on, and then every file that's supposed to be owned by root is owned by an unprivileged user instead. It wouldn't surprise me that this freaks out the init process. I'd try building somewhere else and see if that helps. Or see whether you've got root-squashing or some other permission-modifying option turned on. Cheers, Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Kieran Evans Sent: Saturday, March 17, 2012 9:38 AM To: openstack@lists.launchpad.net Subject: [Openstack] Devstack +XCP/XenServer Kernel Panic Hi all, I'm not sure if this is the right place for this (and if not, can anyone point out where). I've used the devstack scripts to try to set up Openstack on both XenServer 6.0 and XCP 1.5 using the following guides: http://wiki.xen.org/wiki/XCP_DevStack https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md Wether on XenServer or XCP, I always seem to hit the same issue. When the ALLINONE VM is fired up, it shuts down after a few seconds with a kernel panic ( as seen here: http://imgur.com/i85fC). The same issue occurs with the domU_multi scripts too. A note, in case it may affect the build scripts somehow, For external storage, rather than using a different machine, or external USB, I've mounted /root to an NFS share before running prepare_dom0.sh. We've currently got a Diablo Openstack installation up and running using StackOps, but I'm currently trying out essex on some spare machines (both to get to know it, and an attempt to see if running with Xen is of any advantage to us). Thanks /Kieran ___ 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] Being pedantic about pedanticism: HACKING styleguide
.rst is ReStructured Text. It's the markup language being used. Cheers, Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Andrew Bogott Sent: Thursday, March 22, 2012 9:22 AM To: openstack@lists.launchpad.net Subject: [Openstack] Being pedantic about pedanticism: HACKING styleguide Just now I set out to merge a recent style guide change from python-novaclient into the hacking docs of other OpenStack projects. My patch didn't apply, though, because each project has subtly diverging HACKING files. Rather than contribute to this divergence, I've now read and compared the style guides from Nova, Glance, Keystone, python- keystoneclient, and python-novaclient. From these diffs I've created a file (attached) that encompasses the total of all guidelines from all projects. Remarkably, this merge produced only minor disagreements, described below under the heading FLAMEBAIT. I propose that this unified style guide be copied into each of the above projects, with a mandate to maintain consistency henceforth. Any objections? -Andrew FLAMEBAIT (docstring format): The only explicit contradiction I came across is regarding docstring formatting. Glance says this: **DO NOT** leave an extra newline before the closing triple-double- quote. Nova, this: A docstring ends with an empty line before the closing quotations. I propose that we just pick one or the other, or remove both prescriptions. FLAMEBAIT (filename): Some projects have a HACKING file, and some have a HACKING.rst file. Doesn't .rst generally indicate a REST API definition? I propose that the file be called HACKING. ___ 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] Devstack +XCP/XenServer Kernel Panic
6.0.0 will work fine. 6.0.2 will be back in the next few hours, too. (It was withdrawn because of a severe bug in the handling of fragmented IPv6 packets inside Windows VMs. That's been fixed now.) A completely vanilla install would be fine (preferable, even). Then pick one of the guides that John referenced earlier, and you should be good to go. The only thing to do at install time is to make sure you select ext local storage rather than LVHD. It might also be known as XenDesktop-optimized or Intellicache depending on where you're looking. We realized the other day that we forgot to document that step and I don't know if John's done it yet. Cheers, Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Kieran Evans Sent: Thursday, March 22, 2012 2:49 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Devstack +XCP/XenServer Kernel Panic In hindsight, that makes sense (though I swear I disabled root-squashing). I've been having other issues now, so quick question; Most guides referer/specify XenServer 6.0.2, should 6.0 work (due to 6.0.2 being temporarily unavailable?). I'm going to try now with XenServer 6.0 and build remotely. Another quick question: Should this all work on a completely vanilla install of XenServer or XCP or is there any prep-work not mentioned anywhere, or any steps a complete Xen newb may miss? /Kieran On 21 Mar 2012, at 20:11, Ewan Mellor wrote: I've never seen that kernel panic before. If you're building on an NFS share though, that often screws up the permissions. You could have root-squashing turned on, and then every file that's supposed to be owned by root is owned by an unprivileged user instead. It wouldn't surprise me that this freaks out the init process. I'd try building somewhere else and see if that helps. Or see whether you've got root-squashing or some other permission-modifying option turned on. Cheers, Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.netmailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.netmailto:citrix@lists.launchpad.net] On Behalf Of Kieran Evans Sent: Saturday, March 17, 2012 9:38 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Devstack +XCP/XenServer Kernel Panic Hi all, I'm not sure if this is the right place for this (and if not, can anyone point out where). I've used the devstack scripts to try to set up Openstack on both XenServer 6.0 and XCP 1.5 using the following guides: http://wiki.xen.org/wiki/XCP_DevStack https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md Wether on XenServer or XCP, I always seem to hit the same issue. When the ALLINONE VM is fired up, it shuts down after a few seconds with a kernel panic ( as seen here: http://imgur.com/i85fC). The same issue occurs with the domU_multi scripts too. A note, in case it may affect the build scripts somehow, For external storage, rather than using a different machine, or external USB, I've mounted /root to an NFS share before running prepare_dom0.sh. We've currently got a Diablo Openstack installation up and running using StackOps, but I'm currently trying out essex on some spare machines (both to get to know it, and an attempt to see if running with Xen is of any advantage to us). Thanks /Kieran ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] Xen Hypervisor
It looks like you're hitting a recently introduced bug (maybe). I haven't run the code, but from reading through, it looks like the xenhost.host_data plugin command is going to barf if it is not passed a host_uuid parameter. It used to gracefully handle that case, but since 37a392dc it's not doing so any more. The plugin is being called with no arguments from nova.virt.xenapi.host. Cc'd John Garbutt, who wrote that bit of code. Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Alexandre Leites Sent: 23 March 2012 10:46 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack] Xen Hypervisor Hi folks, Sorry for late reply, i was trying to install this without following any ready-to-use scripts ( but i used one :( ) to understand how things are made. So i installed XCP 1.4.90 from DVD and configured it from installation screen. Execute the following commands on dom0 --- Dom 0 Extra Config cd /etc/xapi.d/plugins/ wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/xenhost wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/xenstore.py wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/pluginlib_nova.py wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/migration wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/agent chmod 777 * service xapi restart --- After that i downloaded XenCenter and created a VM from Ubuntu Server 11.10 CD... (all from below is on guest) After this, i did updated all the system with command apt-get update apt-get upgrade -y apt-get dist-upgrade -y and rebooted the machine. When you do this, you'll boot on newer kernel (3.0.0-16-server, check with uname -a command)... and unsinstall the old kernel (apt-get purge linux-image-3.0.0-12-server). After this, i did installed the virtual kernel (3.0.0-16-virtual) and rebooted the machine. Check if you rebooted in this kernel via uname -a and unsinstall the old kernel. After this, execute on dom0 again: --- Dom 0 Extra Config cd ~ wget http://94.212.78.134/res/xenserver/makepv.sh chmod +x makepv.sh ./makepv.sh YOUR-XEN-GUEST-NAME --- After this, you can do apt-get install -y cracklib-runtime curl wget ssh openssh-server tcpdump ethtool python-pip git vim-nox sudo and pip install xenapi wget http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb -O xe-guest-utilities_5.6.100-651_amd64.deb dpkg -i xe-guest-utilities_5.6.100-651_amd64.deb update-rc.d -f xe-linux-distribution remove update-rc.d xe-linux-distribution defaults mkdir -p /usr/share/cracklib echo a | cracklib-packer pwconv echo root:password | chpasswd rm -f /etc/localtime groupadd libvirtd useradd stack -s /bin/bash -d /opt/stack -G libvirtd echo stack:password | chpasswd echo stack ALL=(ALL) NOPASSWD: ALL etc/sudoers mkdir -p /opt/stack chown -R stack /opt/stack After all this, you can install nova-compute , copy nova.conf from your controller and configure the following vars: --connection_type=xenapi --xenapi_connection_username=root --xenapi_connection_password=password --xenapi_connection_url=http://XENDOM0IP and restart your nova-compute service. You can test your XenAPI configuration using sudo nova-manage shell python and after pasting this import XenAPI import nova.virt.xenapi_conn nova.virt.xenapi_conn.XenAPI = XenAPI x = nova.virt.xenapi_conn.XenAPIConnection(http://XENDOM0IP,root,password) x.list_instances() -- After all this things, i got Xen working, but i have a error with bridge now, as trace below: 2012-03-23 16:30:00,116 DEBUG nova.virt.xenapi [-] Updating host stats from (pid=23556) update_status /usr/lib/python2.7/dist-packages/nova/virt/xenapi_conn.py:488 2012-03-23 16:30:00,988 WARNING nova.virt.xenapi [-] Task [Async.host.call_plugin] OpaqueRef:d7a9f0df-0c7c-a760-6b76-3e985c747b1d status: failure['XENAPI_PLUGIN_FAILURE', 'host_data', 'KeyError', 'host_uuid'] 2012-03-23 16:30:00,992 WARNING nova.compute.manager [-] Error during report_driver_status(): ['XENAPI_PLUGIN_FAILURE', 'host_data', 'KeyError', 'host_uuid'] 2 And yes, my permissions are 777 to all plugins. From: todd.desh...@xen.org Date: Wed, 21 Mar 2012 11:04:19 -0400 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack] Xen Hypervisor Just realized my reply was accidentally not sent to the list. On Tue, Mar 20, 2012 at 2:03 PM, Todd Deshane todd.desh...@xen.org wrote: Please post specific error messages. Some general suggestions inline. On Tue, Mar 20,
Re: [Openstack] [OpenStack] Xen Hypervisor
Yes, I'd missed the code change in xenapi_conn. Alexandre, are you sure you have a matched pair of nova-compute and the nova plugins? If so, then please trace through xenapi_conn.call_plugin to find out why your host_uuid isn't getting set. It looks like it should to me, even on XCP. Thanks, Ewan. From: John Garbutt Sent: 26 March 2012 01:36 To: Ewan Mellor; Alexandre Leites; openstack@lists.launchpad.net Subject: RE: [Openstack] [OpenStack] Xen Hypervisor I certainly changed the plugin so it always required the host_uuid, but I also changed the call_plugin code in xenapi_conn to ensure we always pass the host_uuid. Indeed it looks like in the code path below, that you should get the host_uuid passed all the way though. I have not tested with XCP myself, only with XenServer 6. I am afraid I will not get chance to try this out till Wednesday (currently on holiday). One other useful log will be from XCP where it logs the parameters passed into the plugin (on XenSever it is /var/log/xensource.log, it could be /var/log/xcp.log? or xapi.log, can't remember I am afraid) You should be able to track the host_uuid to ensure it gets from nova-xapi client-xapi server-plugin If you want to move on with your deployment a work around is to add this into the xenhost plugin: Change: host_uuid=arg_dict['host_uuid'] Into: host_uuid=_run_command(xe host-list | grep uuid).split(:)[-1].strip() The above does not work in all cases, but it should work for your particular case (no pools). If you could raise a nova bug for this, mentioning the version of XCP you are using, that would be great. I hope that helps, John From: Ewan Mellor Sent: 25 March 2012 19:56 To: Alexandre Leites; openstack@lists.launchpad.net Cc: John Garbutt Subject: RE: [Openstack] [OpenStack] Xen Hypervisor It looks like you're hitting a recently introduced bug (maybe). I haven't run the code, but from reading through, it looks like the xenhost.host_data plugin command is going to barf if it is not passed a host_uuid parameter. It used to gracefully handle that case, but since 37a392dc it's not doing so any more. The plugin is being called with no arguments from nova.virt.xenapi.host. Cc'd John Garbutt, who wrote that bit of code. Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Alexandre Leites Sent: 23 March 2012 10:46 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack] Xen Hypervisor Hi folks, Sorry for late reply, i was trying to install this without following any ready-to-use scripts ( but i used one :( ) to understand how things are made. So i installed XCP 1.4.90 from DVD and configured it from installation screen. Execute the following commands on dom0 --- Dom 0 Extra Config cd /etc/xapi.d/plugins/ wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/xenhost wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/xenstore.py wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/pluginlib_nova.py wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/migration wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance wget -q https://raw.github.com/openstack/nova/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/agent chmod 777 * service xapi restart --- After that i downloaded XenCenter and created a VM from Ubuntu Server 11.10 CD... (all from below is on guest) After this, i did updated all the system with command apt-get update apt-get upgrade -y apt-get dist-upgrade -y and rebooted the machine. When you do this, you'll boot on newer kernel (3.0.0-16-server, check with uname -a command)... and unsinstall the old kernel (apt-get purge linux-image-3.0.0-12-server). After this, i did installed the virtual kernel (3.0.0-16-virtual) and rebooted the machine. Check if you rebooted in this kernel via uname -a and unsinstall the old kernel. After this, execute on dom0 again: --- Dom 0 Extra Config cd ~ wget http://94.212.78.134/res/xenserver/makepv.sh chmod +x makepv.sh ./makepv.sh YOUR-XEN-GUEST-NAME --- After this, you can do apt-get install -y cracklib-runtime curl wget ssh openssh-server tcpdump ethtool python-pip git vim-nox sudo and pip install xenapi wget http://images.ansolabs.com/xen/xe-guest-utilities_5.6.100-651_amd64.deb -O xe-guest-utilities_5.6.100-651_amd64.deb dpkg -i xe-guest-utilities_5.6.100-651_amd64.deb update-rc.d -f xe-linux-distribution remove update-rc.d xe-linux-distribution defaults mkdir -p /usr/share/cracklib echo a | cracklib-packer pwconv echo root:password | chpasswd rm -f /etc/localtime groupadd libvirtd useradd
Re: [Openstack] [OpenStack] Xen Hypervisor
-Original Message- From: Thomas Goirand [mailto:tho...@goirand.fr] Sent: 26 March 2012 13:56 To: John Garbutt Cc: Ewan Mellor; Alexandre Leites; openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack] Xen Hypervisor On 03/26/2012 04:35 PM, John Garbutt wrote: I certainly changed the plugin so it always required the host_uuid, but I also changed the call_plugin code in xenapi_conn to ensure we always pass the host_uuid. Indeed it looks like in the code path below, that you should get the host_uuid passed all the way though. I have not tested with XCP myself, only with XenServer 6. I am afraid I will not get chance to try this out till Wednesday (currently on holiday). One other useful log will be from XCP where it logs the parameters passed into the plugin (on XenSever it is /var/log/xensource.log, it could be /var/log/xcp.log? or xapi.log, can't remember I am afraid) You should be able to track the host_uuid to ensure it gets from nova-xapi client-xapi server-plugin If you want to move on with your deployment a work around is to add this into the xenhost plugin: Change: host_uuid=arg_dict['host_uuid'] Into: host_uuid=_run_command(xe host-list | grep uuid).split(:)[-1].strip() Hi John, Why not using: xe host-list --minimal instead of the grep, split, strip code, which adds useless complexity? Also, this piece of code doesn't seem to be resistant to having more than one host as reply (in which case the UUID would be separated by a coma, if I'm not mistaking). Using --minimal would be preferable, I agree. John did say that this code only works in the non-pool case though -- it's obviously not going to get committed in this form. Cheers, Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack:Volume] Block Storage Naming Poll
Lego and Jenga are both trademarks. I know why they would make good nicknames, but please let's not go there. Cinder FTW. Ewan. On Apr 19, 2012, at 8:10 AM, John Griffith john.griff...@solidfire.com wrote: On Wed, Apr 18, 2012 at 11:53 PM, john.griffi...@gmail.com wrote: If you have trouble viewing or submitting this form, you can fill it out online: https://docs.google.com/spreadsheet/viewform?formkey=dG5hOVpKZ3lFY3RTcE4yU0lxa1I3VkE6MQ Block Storage Naming Poll Suggested names are listed below, cast your vote. We'll take the top results and find the one that isn't already associated with an existing project. If you have other suggestions you'd like to add to this list add them or shoot me an email. I'd like to close out this process in the next day or so if possible. Name for the new block storage service cinder decibel eleven litre arcade ensemble fount reservoir lego jenga volterre severance bolide corona Sample Question 2 Powered by Google Docs Report Abuse - Terms of Service - Additional Terms ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp It looks like we have a pretty clear winner With 10 votes cinder was the leading choice with the closest alternative being lego at 4 votes. Based on a total of 25 votes I think it's safe to say the majority of folks have had an opportunity to vote. So... we have a project name! I talked with Thierry last nigh regarding official repos, process etc and will keep moving to get that all set up. I'll keep everyone updated via email, it shouldn't take long to get an official repo at least. Also in the meantime I'll create a cinder project on my own personal github account (https://github.com/j-griffith/). Might be a bit busy today, but hope to have something to work off of next week. Thanks, John ___ 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] Does openstack support XCP or Xenserver if I use xen Hypervisor?
Yes. See http://wiki.openstack.org/XenServer/XenXCPAndXenServer. Cheers, Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of livemoon Sent: Friday, April 20, 2012 6:49 AM To: openstack@lists.launchpad.net Subject: [Openstack] Does openstack support XCP or Xenserver if I use xen Hypervisor? hi, all If I use xen and libvirt , can it work wll in openstack? Is it possible to install XAPI to manage xen in centos or suse and work well in 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] SmokeStack: xenserver tests offline :(
-Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Dan Prince Sent: Thursday, May 03, 2012 11:31 AM To: openstack Subject: [Openstack] SmokeStack: xenserver tests offline :( Several people asked me on IRC about SmokeStack being down. I'm having some issues with the image snapshot I used to spin up server groups for XenServer testing... so until I get a couple hours to go have a look at either creating a new snapshot or fixing the existing snapshot the XenServer SmokeStack tests are broken. In the meantime I made a slight adjustment to Bellows so that he will continue to post unit test, and libvirt results to merge proposals. Not giving up on the XenServer testing... its just going to take a bit longer to fix this one. Need any help, Dan? I may be able to find someone who knows a little something about XenServer... Ewan. ___ 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] MySQL / MariaDB security vulnerability
Anyone who is using OpenStack with MySQL / MariaDB, please see this _extremely_ dangerous security vulnerability, announced on Saturday: https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql Ewan. ___ 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-poc] Meeting today
Goddamn it. I've just entered the channel at 21:00 UTC on the dot. I obviously missed the time change. What did I miss? And are we sticking with 20:00 UTC from now on? In particular, US clocks move this weekend for DST. Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: 10 March 2011 16:26 To: openstack-poc@lists.launchpad.net Subject: [Openstack-poc] Meeting today We're scheduled for a meeting today at 20:00 UTC/2:00 PM CST. Who's going to be able to make it? I know several of you are traveling. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] PPB Meeting
I don't have anything for the agenda -- happy to skip it. Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: 24 March 2011 14:59 To: openstack-poc@lists.launchpad.net Subject: [Openstack-poc] PPB Meeting Hi guys, I'm traveling and got my days confused. I didn't realize it was Thursday until Chuck emailed me a few minutes ago. Vish is traveling too and I don't think either of us would be able to make the meeting today. I'm happy to have someone else run the meeting or to reschedule. Whichever you guys prefer. Just let me know. Sorry for dropping the ball on it! Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] PPB Meeting tomorrow
Fine by me. Thanks, Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: 07 April 2011 19:47 To: openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] PPB Meeting tomorrow So no one has had anything they wanted to discuss. I propose we skip this week's meeting and let everyone have a productive hour back. Any objections? Jonathan. On Apr 6, 2011, at 12:47 PM, Jonathan Bryce wrote: Anyone have any agenda items for tomorrow? Thierry has scheduled a session at the design summit to talk releases which was a pending item. I don't have anything else to discuss right now. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] PPB Tuesday Meeting
I think that we should separate these two concerns. Vulnerability management should be in strict confidence until the appropriate fixes are known and hotfixes are ready. The other security champion work should be vocal and publicly visible. I think that it only confuses things to overlap these two activities, and I would separate them entirely. (That's not to say that the same people couldn't be on both groups, of course.) Thanks for doing this though, Jarret. This is massively important work, and I'm very glad that someone is pushing this forward so strongly. Cheers, Ewan. On 8/17/11 3:16 AM, Jarret Raim jarret.r...@rackspace.com wrote: Soren, I see the Group handling vulnerability tracking in addition to the larger role of being the security champions inside the OpenStack community. This might include documentation, examples, coordinating paid testing from companies like Rackspace, etc. I agree that for just vulnerability management, there isn't a need for a large group, and we could certainly create multiple groups to handle the individual tasks rather than one big group. I figured the people likely to be interested in contributing to these various security oriented tasks would overlap quite a bit, hence the larger group. I also wanted to avoid the appearance of the Group being beholden to a single entity. By including non-Rackspace members and even non-OpenStack members, I thought we could get a good cross section of interests to ensure that we don't get tunnel vision. Maybe we could start with a single Group, then break it up if we get enough interest in the other sections? I think there is some value in having some names from the security community be involved. For example, Matt Tesauro is an OWASP board member and is willing to come help out. That means that OpenStack could get more exposure at conferences like AppSec USA and other OWASP events and possibly collaborate with the OWASP community on projects like AppSensor support. Just long range thoughts, but that was part of my desire to include some people from the security sector. There are also lots of vendors interested in integrating with OpenStack including WAF vendors like Imperva and application analysis companies like VeraCode. I could see a role for the Group in facilitating that work to get more tooling that works with OpenStack out of the box. Thanks, Jarret From: Soren Hansen [so...@linux2go.dk] Sent: Tuesday, August 16, 2011 2:41 PM To: Jarret Raim Cc: Jay Pipes; Jonathan Bryce; openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] PPB Tuesday Meeting 2011/8/16 Jarret Raim jarret.r...@rackspace.com: I changed the text for the initial group membership to limit it to 8. I'm happy to lower it if that seems to high. I wonder what your motivations are for such a large group? These are not people doing security auditing or anything like that. I see this as a very small group of responsible people with experience in dealing with security particularly in open source software. A group focusing on penetration testing and auditing and whatnot would be *fantastic*, and while there might be overlap between these two groups, I don't think they should be the same. The basic goal was to start with a group of diverse people (commercial open source, Rackspace and not, security contractors and not, etc.) If we just want to start out with a couple of Rackers and one or two interested parties, I'm fine with that. I just wanted to make sure we have a good set of opinions to get going with the initial work. I don't see this as the sort of thing were wide representation is required (or even desirable). The smaller the group, the better. If there's an actual vulnerability, you want as few people to know about it as possible until it's been addressed. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] API compatibility
-Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, September 07, 2011 9:28 AM To: Paul Voccio Cc: Ewan Mellor; openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] API compatibility On Wed, Sep 7, 2011 at 12:16 PM, Paul Voccio openst...@substation9.com wrote: Wouldn't this mean that versions of the API for projects would then have a version that is reflective of the release and not a spec number? Version 1.1 doesn't mean anything in Diablo if it doesn't adhere to the 1.1 guide? The api would be versioned for diablo and we would start a new version for essex? Perhaps I wasn't specific enough... sorry about that. I mean that we guarantee that whatever latest version of an API a project supports for a release, clients that communicate on that API can be assured that the servers built in the next release series will at a minimum support that API version, along with any new API versions that might have been added in the new release series. For instance, if Compute API 1.1 is what is supported in the Diablo release series for Nova, then we make the guarantee that all the server code in the Essex release series supports the 1.1 API, even if during the Essex release series, a new Compute 2.0, 2.1, and 2.2 API comes out. Yes, that's what I meant. Thanks Jay. I would also add that if we claim that Diablo implements OpenStack API 1.1, and there's a doc that calls itself OpenStack API 1.1, then if those two things don't match by the time we ship we don't deserve to call ourselves professionals and we should all go home. I'm not going to get into arguments about designing the API up front vs driving the API from the capabilities of the platform. I don't care why the two things are skewed at the moment. However, they absolutely 100% have to be lined up by the time Diablo is released. Ewan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] Meeting tomorrow
I've added a minor rant to that Etherpad. Other than that, I just desperately want us to get to a point that we're happy declaring Diablo's APIs as supported, stable, and future-compatible. Ewan. From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: 18 September 2011 09:31 To: openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] Meeting tomorrow Here is a link to an Etherpad to use as a scratchpad for the RFC on API guidelines: http://etherpad.openstack.org/RFC-API-Guidelines Please provide input and one of us (jbryce?) can put out the eventual RFC to the ML. Anyone else have any additional initial feedback on this etherpad before I send out to the full OpenStack list? Jorge also put some samples in the wiki: http://wiki.openstack.org/Governance/Proposed/APIManagement-sampleGuidelines . I told him we were going to use the etherpad as the RFC to the list. I plan on sending out a note later today. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] Design Summit attendance/registration
Following on from the IRC discussion today: I agree with Josh that an events committee is a good idea. That way, we can discuss registration rules broadly, because obviously a lot of people want to have input. This is particularly true if Thierry doesn't actually want to organize registration. I expect that he's got enough on his plate getting Essex out the door in good shape, so we should give this (frankly thankless) task to other people, and save Thierry the heartache. Let's get ~5 people to put together a committee, and they can get this aired and resolved. Cheers, Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: Monday, February 20, 2012 8:51 AM To: openstack-poc@lists.launchpad.net Cc: Stefano Maffulli Subject: [Openstack-poc] Design Summit attendance/registration We've heard some concerns about the registration process for the Design Summit in April (too exclusive, invite-only, too Rackspace controlled, not enough inclusion of non-coders who have proposals or feedback). We've got a couple of simple FAQs on the website, but perhaps a more full explanation of the process and size limitations would be good to publish as we get more questions--I didn't find anything really detailed anywhere. Josh, I know you've gotten some questions as well, so feel free to chime in. Since the Design Summit is organized and scheduled by the release manager and the PTLs and you're all on the PPB, I thought it might be worth discussing. We can talk about it in tomorrow's meeting or just on the list. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] Topics for tomorrow?
I'd like to see a list of global bug day events, and who's going to be online when, so that we can publicize widely. It would be great to be able to say something like: o Monty Taylor, CI and QA expert, will be on-site at HP in Austin and online between 11am and 5pm Central. o Vish Ishaya, Nova PTL, will be on-site at RCB in San Francisco etc and so on. Is this something that the PPB could / should co-ordinate? I would love for the bug day to be a really public visible event, make it clear to everyone that Essex is going to be awesome. Thanks, Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: Monday, February 27, 2012 8:58 AM To: openstack-poc@lists.launchpad.net Subject: [Openstack-poc] Topics for tomorrow? Anyone have anything to talk about for tomorrow? ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack-poc] PPB meeting today
Having raised the subject of the global hack-in day for discussion by the PPB today, I've realised that I can't actually make the meeting. My apologies. I've cc'd Renuka and Vijay. Between them, one will attend the IRC meeting today (noon our time). They'll be able to discuss any details of Citrix's involvement in the global hack-in day (we'll be at Yahoo in Sunnyvale). Cheers, Ewan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-xenapi] Minor nit... getting XenAPI.py in PyPI?
Done, thanks for the suggestion, Monsyne. Ewan. -Original Message- From: openstack-xenapi- bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack- xenapi-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Monsyne Dragon Sent: 31 January 2011 23:49 To: openstack-xenapi@lists.launchpad.net Subject: [Openstack-xenapi] Minor nit... getting XenAPI.py in PyPI? I was wondering... is there any plans to put a XenAPI.py package up on PyPI? It would simplify nova installation if we could just do: pip install xenapi -- -- -Monsyne Dragon work: 210-312-4190 mobile210-441-0965 google voice: 210-338-0336 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-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
Re: [Openstack-xenapi] Glance Plugin/DomU access to SR?
Just for summary, the advantages of having the streaming inside a domU are: 1. You move the network receive and the image decompression / decryption (if you're using that) off dom0's CPU and onto the domU's. Dom0 CPU is a scarce resource, even in the new release of XenServer with 4 CPUs in domain 0. This avoids hurting customer workloads by contending inside domain 0. 2. You can easily apply network and CPU QoS to the operations above. This also avoids hurting customer workloads, by simply capping the maximum amount of work that the OpenStack domU can do. 3. You can use Python 2.6 for OpenStack, even though XenServer dom0 is stuck on CentOS 5.5 (Python 2.4). 4. You get a minor security improvement, because you get to keep a network-facing service out of domain 0. So, this is all fine if you're streaming direct to disk, but as you say, if you want to stream VHD files you have a problem, because the VHD needs to go into a filesystem mounted in domain 0. It's not possible to write from a domU into a dom0-owned filesystem, without some trickery. Here are the options as I see them: Option A: Stream in two stages, one from Glance to domU, then from domU to dom0. The stream from domU to dom0 could just be a really simple network put, and would just fit on the end of the current pipeline. You lose a bit of dom0 CPU, because of the incoming stream, and it's less efficient overall, because of the two hops. It's primary advantage is that you can do most of the work inside the domU still, so if you are intending to decompress and/or decrypt locally, then this would likely be a win. Option B: Stream from Glance directly into dom0. This would be a xapi plugin acting as a Glance client. This is the simplest solution, but loses all the benefits above. I think it's the one that you're suggesting below. This leaves you with similar performance problems to the ones that you suffer today on your existing architecture. The advantage here is simplicity, and it's certainly worth considering. Option C: Run an NFS server in domain 0, and mount that inside the domU. You can then write direct to dom0's filesystem from the domU. This sounds plausible, but I don't think that I recommend it. The load on dom0 of doing this is probably no better than Options A or B, which would mean that the complexity wasn't worth it. Option D: Unpack the VHD file inside the domU, and write it through the PV path. This is probably the option that you haven't considered yet. The same VHD parsing code that we use in domain 0 is also available in an easily consumable form (called libvhdio). This can be used to take a VHD file from the network and parse it, so that you can write the allocated blocks directly to the VDI. This would have all the advantages above, but it adds yet another moving part to the pipeline. Also, this is going to be pretty simple if you're just using VHDs as a way to handle sparseness. If you're expecting to stream a whole tree of snapshots as multiple files, and then expect all the relationships between the files to get wired up correctly, then this is not the solution you're looking for. It's technically doable, but it's very fiddly. So, in summary: Option A: Two hops. Ideal if you're worried about the cost of decompressing / decrypting on the host. Option B: Direct to dom0. Ideal if you want the simplest solution. Option D: Parse the VHD. Probably best performance. Fiddly development work required. Not a good idea if you want to work with trees of VHDs. Where do you think you stand? I can advise in more detail about the implementation, if you have a particular option that you prefer. Cheers. Ewan. From: openstack-xenapi-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-xenapi-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Rick Harris Sent: 11 February 2011 22:13 To: openstack-xenapi@lists.launchpad.net Subject: [Openstack-xenapi] Glance Plugin/DomU access to SR? We recently moved to running the compute-worker within a domU instance. We could make this move because domU can access VBDs in dom0-space by performing a VBD.plug. The problem is that we'd like to deal deal with whole VHDs rather than kernel, ramdisk, and partitioning (the impetus of the unified-images BP). So, for snapshots we stream the base copy VHD held in the SR into Glance, and, likewise, for restores, we stream the snapshot VHD from Glance into the SR, rescan, and then spin up the instance. The problem is: now that we're running the compute-worker in domU, how can we access the SR? Is there a way we can map it into domU space (a la VBD.plug)? The way we solved this for snapshots was by using the Glance plugin and performing these operations in dom0. So, my questions are: 1. Are SR operations something we need to use the Glance plugin for? 2. If we must use a dom0 plugin for this method of restore, does it
[Openstack-xenapi] OpenStack API CLI
What is the plan for CLI tools that use the OpenStack API? I see novatools on github. Is that something that we're taking forward? And if so, will they be moving to Launchpad? If not, what's the alternative? Thanks, Ewan. ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme
Yes, fine by me. This is the convention that I normally use, but I don’t think that I have mentioned that to other people, so we might not all be sticking to this. I do use _rec for a record, if I feel that it needs distinguishing explicitly. I’d prefer that we allowed vm or vm_rec for a record (that would give us less to fix up, apart from anything else!) Cheers, Ewan. From: openstack-xenapi-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-xenapi-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Chris Behrens Sent: 06 March 2011 04:43 To: Rick Harris Cc: openstack-xenapi@lists.launchpad.net Subject: Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme Totally agree. On Mar 5, 2011, at 8:26 PM, Rick Harris rick.har...@rackspace.commailto:rick.har...@rackspace.com wrote: Reading through the XenAPI virt-layer code, I've noticed there is some inconsistency in how we name variables, in particular, how we distinguish between the three kinds of object references that XenAPI exposes: 1. Opaque references 2. UUIDs 3. Records In some of the code, 'vm' means that we're working with a VM record object; in others, it means we're working with an opaque reference. For our own sanity, I propose that we adopt the following convention (which currently is used by some--perhaps most-- of the code): 1. Opaque references should be suffixed with _ref. e.g.: vdi_ref or vm_ref 2. UUIDs should be suffixed with _uuid. e.g.: vbd_uuid or sr_uuid 3. Records should not have a suffix[1]. e.g.: vm or vdi If there is general agreement to this plan, we should create a bug in Launchpad to rename all of the currently mis-named variables to use the new naming scheme. Ordinarily I would have made this change without appealing to the list (since it doesn't seem controversial), but, in the interest of having this convention well-known/maintained, it's probably be better to get explicit buy in from everyone who works with the code. Thoughts? [1] An alternative is to use _rec (vm_rec). That's very explicit, which is good, but, not necessary since refs and uuid cases are qualified. 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.commailto:ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.netmailto:openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming-Scheme
-Original Message- From: Ed Leafe [mailto:ed.le...@rackspace.com] Sent: 07 March 2011 16:28 To: Ewan Mellor Cc: Chris Behrens; Rick Harris; openstack-xenapi@lists.launchpad.net Subject: Re: [Openstack-xenapi] XenAPI virt-layer Variable Naming- Scheme On Mar 6, 2011, at 8:29 AM, Ewan Mellor wrote: I do use _rec for a record, if I feel that it needs distinguishing explicitly. I'd prefer that we allowed vm or vm_rec for a record (that would give us less to fix up, apart from anything else!) In most of the code, the convention is to refer to a modeled object using the singular form of the table name; in this case, it should probably be 'instance'. As we're using 'vm' as an alias for instance, it would seem that either 'instance' or 'vm' would be consistent. I don't know of any other modeled object referred to with the '*_rec' name. _rec is used a lot in lp:nova/plugins/xenserver/xenapi/etc/xapi.d/plugins. Ewan. ___ Mailing list: https://launchpad.net/~openstack-xenapi Post to : openstack-xenapi@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-xenapi More help : https://help.launchpad.net/ListHelp
