[openstack-dev] [TripleO] Support for Type-1 Hypervisors
Hi Stackers, First of all: I am not a TripleO/baremetal expert. I am looking at ways how to fit Type 1 hypervisors to TripleO. I am not sure how other such hypervisors integrate with OS, but in my case - XenServer - ,I have a VM that runs nova - let's call it domU - , and that's talking to the hypervisor. When it comes to deployment, I see two tasks: - Being able to install the hypervisor from an image For this, the hypervisor has to be able to behave like a good cloud guest. - How to put a VM on top of that hypervisor We can't provision the VM with the hypervisor's nova driver, as the domU is not yet installed, so let's fake that the domU is a physical entity. The idea is that once the hypervisor is installed, we would treat it as a baremetal pool, so that we can install the domU - as if it were a baremetal node. The sequence would look like this: 1.) install seed VM 2.) seed VM is talking to Bare Metal, provisioning a machine 3.) seed VM installs an image that contains the hypervisor 4.) seed VM can use that hypervisor as if it were a baremetal Rack - We would have a hypervisor-baremetal interface that would provide an IPMI interface. 5.) seed VM can install a nova image on domU 6.) Life goes on... This is a really rough workflow, and I am really interested in what you guys think about it. Thanks, Mate -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] EC2 Compatibility metadata on config drive, fixed IP info
Hi, We are looking at config drive use cases, and saw this in the official docs: Do not rely on the presence of the EC2 metadata present in the config drive (i.e., files under the ec2 directory), as this content may be removed in a future release. http://docs.openstack.org/user-guide/content/config-drive.html Do we have any information on when will that EC2 metadata be dropped? I would like to get the fixed ip from the metadata, and I only found it in the EC2 section. Are there any plans to include the IP info in the OS metadata? Thanks, Mate -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Openstack Folsom + Quantum + XenServer 6.1.0 + Windows VM
Hi Dbarros, Could you look at this blog post: http://blogs.citrix.com/2013/06/14/openstack-networking-quantum-on-xenserver-from-notworking-to-networking/ I would not expect Grizzly to work with XenServer + Quantum without some extra patches. Let me know if you have further questions: Mate On Mon, Sep 02, 2013 at 04:41:00PM -0300, Dbarros wrote: Hi, I'm having a network problem when spawn windows vm into xenserver. A 'tap' and 'vif' interface are created until the boot is completed, after that interface 'tap' is removed and interface 'vif' loses id tag From what i searched, because of this Windows VM cant configure network correctly. ps; I can see the DHCP requests on the host, but them arent being sent to the network node by gre tunnel. It's been weeks trying to find for a solution with no success. Can someone please help me on this issue? I've followed the link below to configure xenserver to openstack https://github.com/openstack/nova/blob/master/plugins/xenserver/doc/networking.rst Thanks in advance -- Dbarros 5585 9919 6279 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Create a tar.gz stream from a block device
Hi Stackers, I would like to create a readable tar.gz stream, inside that stream I want to see only one file, and that file's content should be read from a device. The virtual disk is attached to domU as a block device (/dev/xvdb) I would like to produce a tar.gz, that contains the contents of /dev/xvdb, file name inside the tar.gz does not matter. Here is my current solution: https://review.openstack.org/41651 The main problem is, that tarfile does not support adding content incrementaly, it only has a addfile method: http://docs.python.org/2/library/tarfile.html tfile = tarfile.open(fileobj=output, mode='w|gz') ... tfile.addfile(tinfo, fileobj=input_file) And for the glance client, I need to provide a readable file-like: image_service.update(self.context, image_id, metadata, image_stream, purge_props=False) The change is solving the issue by creating a separate process to create the targz stream, and give that process' output stream to glance. Any other ideas? Many thanks, -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
Hi, What about saying that you are not restricted to use H302 in test code test_*.py ? On Mon, Aug 05, 2013 at 08:03:26PM -0700, Clint Byrum wrote: Excerpts from Robert Collins's message of 2013-08-05 19:26:20 -0700: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are designed to be used as a dsl: self.assertThat(foo, Or(Equals(1), Equals(2))) rather than what H302 enforces: self.assertThat(foo, matchers.Or(matchers.Equals(1), matchers.Equals(2))) Further, conflicting module names become harder to manage, when one could import just the thing. Some arguments for requiring imports of modules: - makes the source of symbols obvious - Actually, it has no impact on that as the import is still present and clear in the file. import * would obfuscate things, but I'm not arguing for that. - and package/module names can (and are!) still ambiguous. Like 'test.' - whats that? - consult the imports. - makes mocking more reliable - This is arguably the case, but it's a mirage: it isn't a complete solution because modules still need to be mocked at every place they are dereferenced : only import modules helps to the extent that one never mocks modules. Either way this failure mode of mocking is usually very obvious IME : but keeping the rule as a recommendation, *particularly* when crossing layers to static resources is a good idea. - It's in the Google Python style guide (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports) - shrug :) What I'd like us to do is weaken it from a MUST to a MAY, unless noone cares about it at all, in which case lets just turn it off entirely. You've convinced me. Monty's point about the complexity of making sure what is imported in code is actually a module makes it expensive without much benefit. I say remove it entirely. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Propose to add copying the reference images when creating a volume
Hi, I just proposed a patch for the boot_from_volume_exercise.sh to get rid of --image. To be honest, I did not look at the various execution paths. My initial thought is that boot from volume means you boot from volume. If you only have a kernel + ramdisk image, I simply assumed that you can't do it. I would not do any magic. Boot from volume should boot from volume. If you only have 3 part images, you need to find another way to prepare your bootable volume. btw, here is my change: https://review.openstack.org/34761 Cheers, Mate On Mon, Jul 01, 2013 at 01:25:23AM -0400, Sheng Bo Hou wrote: Hi Cinder folks, I am currently fixing the bugs related to booting the instance from the volume. I found there are bugs both in Nova and Cinder. Cinder: https://bugs.launchpad.net/cinder/+bug/1159824 Nova: https://bugs.launchpad.net/nova/+bug/1191069 For the volumes created from the image, I propose to copy the reference image during the creation of the main image. For example, an image may refer to a kernel image and a ramdisk image. When we create a volume from this image, we only copied this one to the volume. The kernel and ramdisk images are still in glance, and the volume still refers to the kernel and ramdisk images. I think if an image has other reference images, the reference images also need to be copied to the volumes(kernel volume and ramdisk volume), and then set the volume referring to the kernel volume and the ramdisk volume. This feature will make booting from a volume completely independent of the existence of the glance image. Do you think we can firstly add this feature to cinder? Do folks have any comments on it? Thanks. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag
Hi, I guess, the splitting point is defined by the hypervisor, so I guess that's a +1 for the config option. Does any other hypervisor have such a limit? If so, it would make sense to set it to the minimum of all those limits. Mate On Thu, Jun 20, 2013 at 06:02:44PM +0100, John Garbutt wrote: Hi, I have had some discussions about if I should add a config flag in this change: https://review.openstack.org/#/c/32760/ I am looking to support adding a large amount of ephemeral disk space to a VM, but the VHD format has a limit of around 2TB per disk. To work around this in XenServer, I plan to add several smaller disks to make up the full ephemeral disk space. To me it seems worth adding a configuration flag (in this case), because there is no easy way to guess the correct value, and there doesn't seem to be a great value to hardcode it to. Having said that, I suspect the default value will be all most people need, whether or not they have very large ephemeral disk space in their flavors. I am curious about what people think (in general, and in this case) about the tradeoff between: hardcode, magic heuristic calculation, add config John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
