[Openstack] XEN non-VT based compute workers
Hi, From requirements of nova-compute it seems that it cannot be run on non-VT based processors. Why it is like that ? In case of Opennebula i am running it on old non-VT processors with XEN . IMHO Nova-Compute should not care about underlying HW of Virtual manager .. all it needs some interface to invoke VM lifecycle.. any comment ? -- -- Regards Zeeshan Ali Shah System Administrator PDC-Center for High Performance Computing CSC School of Computer Science and Communication KTH-Royal Institute of Technology , Sweden +46 8 790 9115 ___ 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] XEN non-VT based compute workers
2011/7/12 Zeeshan Ali Shah zas...@pdc.kth.se: Hi, From requirements of nova-compute it seems that it cannot be run on non-VT based processors. Where are you seeing this? -- 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
Re: [Openstack] nova-manage network modifications feedback request
On Mon, 2011-07-11 at 19:33 -0700, Dan Wendlandt wrote: Given that we're reworking the commands (and potentially breaking peoples' scripts), it might make sense to add a type field to the network create command to provide future flexibility to introducing different types of networks that can be created by nova-manage, particularly Quantum networks. Nova's existing model of L2 networking is very specific to Linux bridging and fields like [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] don't really make sense, but other fields will. I would think that type would be inferred by which network_manager is running, but I'm not opposed to adding it. I could see it being useful to trigger a separate subcommand for arguments something like: nova-manage network create TYPE [...] Then depending on type the rest of the flags would change so we would have: nova-manage network create nova [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] and nova-manage network create quantum [QUANTUM_SPECIFIC_OPTION, ...] The only thing I'm concerned about then is the divergence of the api entry to the network_manager(s) and ending up with overloaded command structures like we currently have. I would really like to see the network_management functions completely removed from nova proper and the current network_managers repackaged as a reference implementation. Interaction with the network_manager to/from nova should only occur over the rpc mechanism through a defined protocol. In this situation, I think each network_management implementation would have its own command set. It would be great to coordinate these changes. Do you know when you expect your branch ( https://code.launchpad.net/~jason-koelker/nova/separate_networks, I believe?) to hit? I have a little bit more cleaning up to do, mainly just the commands, then some testing, hopefully by the end of the week or early next week I'll be ready to merge-prop it. Happy Hacking! 7-11 -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? ___ 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-manage network modifications feedback request
Thanks Jason, we're definitely on the same page. A few comments in line. Dan On Tue, Jul 12, 2011 at 8:52 AM, Jason Kölker jkoel...@rackspace.comwrote: On Mon, 2011-07-11 at 19:33 -0700, Dan Wendlandt wrote: Given that we're reworking the commands (and potentially breaking peoples' scripts), it might make sense to add a type field to the network create command to provide future flexibility to introducing different types of networks that can be created by nova-manage, particularly Quantum networks. Nova's existing model of L2 networking is very specific to Linux bridging and fields like [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] don't really make sense, but other fields will. I would think that type would be inferred by which network_manager is running, but I'm not opposed to adding it. I could see it being useful to trigger a separate subcommand for arguments something like: nova-manage network create TYPE [...] Then depending on type the rest of the flags would change so we would have: nova-manage network create nova [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] and nova-manage network create quantum [QUANTUM_SPECIFIC_OPTION, ...] Yup, that was my main motivation. I agree that the network manager could try to infer, but it seems cleaner to be able to cleanly separate out the commands. If we decide to keep network creation in the main nova-manage command long-term, this seems like the right approach. The only thing I'm concerned about then is the divergence of the api entry to the network_manager(s) and ending up with overloaded command structures like we currently have. I would really like to see the network_management functions completely removed from nova proper and the current network_managers repackaged as a reference implementation. Interaction with the network_manager to/from nova should only occur over the rpc mechanism through a defined protocol. In this situation, I think each network_management implementation would have its own command set. I completely agree. Glad to hear you see the world that way as well :) I'm in the process of putting together some materials that describe this proposal and would love to get your thoughts when I'm done. If you have anything written up on this already, please let me know. It would be great to coordinate these changes. Do you know when you expect your branch ( https://code.launchpad.net/~jason-koelker/nova/separate_networks, I believe?) to hit? I have a little bit more cleaning up to do, mainly just the commands, then some testing, hopefully by the end of the week or early next week I'll be ready to merge-prop it. Happy Hacking! 7-11 -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~ ___ 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] Hardware failure - nova reboot / rescue
Reboot should really allow you to reboot a non-running vm as well. This has worked at various times, so if it doesn't currently it should be filed as a bug. As a workaround, you may be able to update the state in of the vm to shutdown manually in the db and execute a reboot command. You can also go to the compute host and manually do a virsh define /path/to/libvirt.xml followed by a virsh start instance- Vish On Jul 12, 2011, at 12:24 PM, Leandro Reox wrote: Hi all, In case of hardware failure, is there a way to restart the instances that have died on the crashed node on another node, without scripting (manual or automatic), any native function in nova cactus ? nova-reboot only restart domains in shutdown mode, on the same node after a reboot. And my domains if the node crash forever due hardware issue the VMs still in running state on db, cant issue nova-reboot either. Is there any method or i have to wait till diable rescue feature ? Regards Lele ___ 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] [Swift] How to mark a container as publicly accessible (no auth required)
Does anyone know how one would go about setting a Swift container as public (as in no auth required to snag objects stored within it). Based on some of the documentation I've read it seems like maybe one would have to set the X-Container-Read ACLs to some sort of wildcard and then use a custom authorization handler in order to bypass the normal auth scheme. I'm not really sure if that's the desired way to go about it or if there's an easier way that doesn't involve writing custom authorization handlers. Any insight would be appreciated! -Mike. ___ 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] [Swift] How to mark a container as publicly accessible (no auth required)
Michael, You want something like this: swift -A https://swift.auth.url/auth/v1.0 -U account:user -K key post -r .r:* container Then you can access the files using your AUTH id, for example: https://swift.auth.url/v1/AUTH_511636fe-30f6-411c-974d-caf3760b4bc4/container/object On Tue, Jul 12, 2011 at 5:14 PM, Michael Szilagyi mszila...@gmail.com wrote: Does anyone know how one would go about setting a Swift container as public (as in no auth required to snag objects stored within it). Based on some of the documentation I've read it seems like maybe one would have to set the X-Container-Read ACLs to some sort of wildcard and then use a custom authorization handler in order to bypass the normal auth scheme. I'm not really sure if that's the desired way to go about it or if there's an easier way that doesn't involve writing custom authorization handlers. Any insight would be appreciated! -Mike. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Jeff Kramer jeffkra...@gmail.com http://www.jeffkramer.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] can't access my running instance through ssh
I've installed all nova services and components successfully, and the instance is running but I can't access it through ssh. I've followed the docs carefully, and published the sample image and ran the instance, and the nova-compute logs shows that the key is injected into the instance. I also made the following steps: euca-authorize -P icmp -t -1:-1 default euca-authorize -P tcp -p 22 default And when I try to access the ssh ubuntu@myip, I get the following message: ssh: connect to host myip port 22: Connection refused which might indicate that the openssh-server is not installed or running on my instance. Any clue here? ___ 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] can't access my running instance through ssh
Are you able to view the console output with euca-get-console-output? If so, are there any indications that something went wrong during bootup that might prevent the SSH server from starting inside the instance? Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Jul 12, 2011, at 11:25 PM, fujiang zhou wrote: I've installed all nova services and components successfully, and the instance is running but I can't access it through ssh. I've followed the docs carefully, and published the sample image and ran the instance, and the nova-compute logs shows that the key is injected into the instance. I also made the following steps: euca-authorize -P icmp -t -1:-1 default euca-authorize -P tcp -p 22 default And when I try to access the ssh ubuntu@myip, I get the following message: ssh: connect to host myip port 22: Connection refused which might indicate that the openssh-server is not installed or running on my instance. Any clue here? ___ 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] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 6:19 PM, Ewan Mellor wrote: [Snip summary] The only question that needs to be considered is where do we move from here? Do we accept the limitation that the EC2 API and any tool which relies upon that will be only available for single-zone deployments, and if you want distributed zones, you must use the OS API? Up to now, I have assumed that zones would be used as the construct that isolated different service offerings, e.g. VMware vs XenServer or 10G networking versus 1G, or whatever. Zones therefore play two roles: they give you the architecture for large-scale deployments, and they also allow for distinguished service offerings. Are you thinking along these lines? Note that we aren't using zones this way: we're assuming that there can be different kinds of service offerings within a single zone (For example, we have a single zone that contains multiple machine architectures). Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ 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] Keystone tenants vs. Nova projects
Our goal is to support Nova use cases right now. You can provide access to multiple tenants using a role assignment (assigning a user a role on a specific tenant effectively binds them to that tenant). However, this raises the issue of what the 'implied' role of a user is when they are bound to their default tenant. So we're considering how to alter the model to clean that up. No great solution yet. Any suggestions are welcome…. Ziad From: Yuriy Taraday yorik@gmail.commailto:yorik@gmail.com Date: Tue, 28 Jun 2011 16:59:08 +0400 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Keystone tenants vs. Nova projects Currently Keystone model assumes that user is bound to exactly one tenant. It conflicts with the fact that in Nova user can have access to several projects. Which way will it be? Kind regards, Yuriy. ___ 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 This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
