[Openstack-operators] Setting IOthreads on a Nova Instance
Hi list, I need some expert opinion on some problem I am facing with OpenStack+Ceph environment. I running a 3+ node cluster with OpenStack Juno. It is using ceph RBDs as cinder volumes. Functionally setup is working fine. However my expectation are related to block performance of RBDs inside a VM. I am observing a throttling effect in 100%- 4K RR iops after a point. Lots of CPU cycles got wasted in iowait. I suspect a single iothread per VM is causing this.I came to know about few tuning parameter that libvirt provides. It looks pretty straight forward to set these parameter in domain xml . However I am not able to do so. I didn't find any way to pass these parameter form nova directly, and when I edit domain.xml directly using 'virsh edit' the changes vanish even after saving the xml properly.(I know it is not a clean way to this, but a hack) It could be validation problem:- #virsh dumpxml instance-00c5 > vm.xml #virt-xml-validate vm.xml Relax-NG validity error : Extra element cpu in interleave vm.xml:1: element domain: Relax-NG validity error : Element domain failed to validate content vm.xml fails to validate ## Second approach I took was to setting QoS in volumes types. But there is no option to set iothreads per volume, there are parameters related to max_read/wrirte ops/bytes. Thirdly, editing Nova flavor and proving extra specs like hw:cpu_socket/thread/core, can change guest CPU topology however again no way to set iothread. It does accept hw_disk_iothreads(no type check in place, i believe ), but can not pass the same in domain.xml. Please suggest me a way to set the same. -- -Pushpesh ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [Glance] [glance_store] Feedback requested from users of the HTTP Store
Hey all, For the Liberty development cycle, I've proposed a specification for a refactor of Glance's HTTP Store - https://review.openstack.org/#/c/189537/. In short, currently Glance's HTTP Store driver does not verify HTTPS connections. This allows for a couple of attacks of varying severity. We had a short discussion in our meeting yesterday (http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.0 0.log.html) and one person suggested that the new configuration options being proposed should default to insecure. If we decide to make them insecure as a default this will make upgrades much easier on operators but will mean that protection against the attacks described will be opt-in, at least for one cycle. So, I'm asking for your feedback because this is really intended to benefit you. Are you using the HTTP store? Are you serving your images over HTTPS? Would you be in favor of turning HTTPS verification on by default? Why or why not? Cheers, Ian ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
haha, you are right. Should this also be changed so you don't end up with "admin" privileges on all tenants? From: "admin_or_owner": "is_admin:True or project_id:%(project_id)s", To: "admin_or_owner": "role:admin or project_id:%(project_id)s", Note: I'm trying to find a temporary way to no have to wait for Nova to remove all occurrences of "if not context.is_admin". Mathieu On 2015-06-11 6:13 PM, Sławek Kapłoński wrote: > Hello, > > But AFAIK this will add someone with role "special_role" same priviliges as > someone who has got "admin" role, right? > > -- > Pozdrawiam / Best regards > Sławek Kapłoński > sla...@kaplonski.pl > > Dnia czwartek, 11 czerwca 2015 18:08:38 Mathieu Gagné pisze: >> You can add your new role to this policy: >> >> "context_is_admin": "role:admin or role:special_role", >> >> It will set "is_admin" to True in the context. I'm not sure of the >> side-effect to be honest. Use at your own risk... >> >> Mathieu >> >> On 2015-06-11 4:59 PM, George Shuklin wrote: >>> Thank you! >>> >>> You saved me a day of the work. Well, we'll move a script to admin user >>> instead of normal user with the special role. >>> >>> PS And thanks for filling a bugreport too. >>> >>> On 06/11/2015 10:40 PM, Sławek Kapłoński wrote: Hello, I don't think it is possible because in nova/db/sqlalchemy/api.py in function instance_get_all_by_filters You have something like: if not context.is_admin: # If we're not admin context, add appropriate filter.. if context.project_id: filters['project_id'] = context.project_id else: filters['user_id'] = context.user_id This is from Juno, but in Kilo it is the same. So in fact even if You will set proper policy.json rules it will still require admin context to search instances from different tenants. Maybe I'm wrong and this is in some other place possible and maybe someone will show me where because I was also looking for it last time :) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia czwartek, 11 czerwca 2015 21:06:31 George Shuklin pisze: > Hello. > > I'm trying to allow a user with special role to see all instances of all > tenants without giving him admin privileges. > > My initial attempt was to change policy.json for nova to > "compute:get_all_tenants": "role:special_role or is_admin:True". > > But it didn't work well. > > The command (nova list --all-tenants) is not failing anymore (no 'ERROR > (Forbidden): Policy doesn't allow compute:get_all_tenants to be > performed.'), but the returned list is empty: > > nova list --all-tenants > ++--+++-+--+ > > | ID | Name | Status | Task State | Power State | Networks | > > ++--+++-+--+ > ++--+++-+--+ > > > Any ideas how to allow a user without admin privileges to see all > instances? > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> ___ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> ___ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
Hello, But AFAIK this will add someone with role "special_role" same priviliges as someone who has got "admin" role, right? -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia czwartek, 11 czerwca 2015 18:08:38 Mathieu Gagné pisze: > You can add your new role to this policy: > > "context_is_admin": "role:admin or role:special_role", > > It will set "is_admin" to True in the context. I'm not sure of the > side-effect to be honest. Use at your own risk... > > Mathieu > > On 2015-06-11 4:59 PM, George Shuklin wrote: > > Thank you! > > > > You saved me a day of the work. Well, we'll move a script to admin user > > instead of normal user with the special role. > > > > PS And thanks for filling a bugreport too. > > > > On 06/11/2015 10:40 PM, Sławek Kapłoński wrote: > >> Hello, > >> > >> I don't think it is possible because in nova/db/sqlalchemy/api.py in > >> function instance_get_all_by_filters You have something like: > >> > >> if not context.is_admin: > >> # If we're not admin context, add appropriate filter.. > >> > >> if context.project_id: > >> filters['project_id'] = context.project_id > >> > >> else: > >> filters['user_id'] = context.user_id > >> > >> This is from Juno, but in Kilo it is the same. So in fact even if You > >> will set proper policy.json rules it will still require admin context to > >> search instances from different tenants. Maybe I'm wrong and this is in > >> some other place possible and maybe someone will show me where because I > >> was also looking for it last time :) > >> > >> -- > >> Pozdrawiam / Best regards > >> Sławek Kapłoński > >> sla...@kaplonski.pl > >> > >> Dnia czwartek, 11 czerwca 2015 21:06:31 George Shuklin pisze: > >>> Hello. > >>> > >>> I'm trying to allow a user with special role to see all instances of all > >>> tenants without giving him admin privileges. > >>> > >>> My initial attempt was to change policy.json for nova to > >>> "compute:get_all_tenants": "role:special_role or is_admin:True". > >>> > >>> But it didn't work well. > >>> > >>> The command (nova list --all-tenants) is not failing anymore (no 'ERROR > >>> (Forbidden): Policy doesn't allow compute:get_all_tenants to be > >>> performed.'), but the returned list is empty: > >>> > >>> nova list --all-tenants > >>> ++--+++-+--+ > >>> > >>> | ID | Name | Status | Task State | Power State | Networks | > >>> > >>> ++--+++-+--+ > >>> ++--+++-+--+ > >>> > >>> > >>> Any ideas how to allow a user without admin privileges to see all > >>> instances? > >>> > >>> > >>> > >>> ___ > >>> OpenStack-operators mailing list > >>> OpenStack-operators@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >>> > >>> > >>> ___ > >>> OpenStack-operators mailing list > >>> OpenStack-operators@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > ___ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
You can add your new role to this policy: "context_is_admin": "role:admin or role:special_role", It will set "is_admin" to True in the context. I'm not sure of the side-effect to be honest. Use at your own risk... Mathieu On 2015-06-11 4:59 PM, George Shuklin wrote: > Thank you! > > You saved me a day of the work. Well, we'll move a script to admin user > instead of normal user with the special role. > > PS And thanks for filling a bugreport too. > > On 06/11/2015 10:40 PM, Sławek Kapłoński wrote: >> Hello, >> >> I don't think it is possible because in nova/db/sqlalchemy/api.py in >> function >> instance_get_all_by_filters You have something like: >> >> if not context.is_admin: >> # If we're not admin context, add appropriate filter.. >> if context.project_id: >> filters['project_id'] = context.project_id >> else: >> filters['user_id'] = context.user_id >> >> This is from Juno, but in Kilo it is the same. So in fact even if You will >> set >> proper policy.json rules it will still require admin context to search >> instances from different tenants. Maybe I'm wrong and this is in some other >> place possible and maybe someone will show me where because I was also >> looking >> for it last time :) >> >> -- >> Pozdrawiam / Best regards >> Sławek Kapłoński >> sla...@kaplonski.pl >> >> Dnia czwartek, 11 czerwca 2015 21:06:31 George Shuklin pisze: >>> Hello. >>> >>> I'm trying to allow a user with special role to see all instances of all >>> tenants without giving him admin privileges. >>> >>> My initial attempt was to change policy.json for nova to >>> "compute:get_all_tenants": "role:special_role or is_admin:True". >>> >>> But it didn't work well. >>> >>> The command (nova list --all-tenants) is not failing anymore (no 'ERROR >>> (Forbidden): Policy doesn't allow compute:get_all_tenants to be >>> performed.'), but the returned list is empty: >>> >>> nova list --all-tenants >>> ++--+++-+--+ >>> >>> | ID | Name | Status | Task State | Power State | Networks | >>> >>> ++--+++-+--+ >>> ++--+++-+--+ >>> >>> >>> Any ideas how to allow a user without admin privileges to see all instances? >>> >>> >>> >>> ___ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> >>> ___ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [Neutron][L3] Modular L3 Discussion
Hi all, Cross posting to openstack-dev and openstack-operators We discussed supporting multiple types of routers within a Neutron in the L3 meeting this morning [1]. The team would like more feedback from the community in order to refine use cases and also to consider possible approaches to achieved these use cases. The team would like to gather feedback on an etherpad [2] created for this purpose. If this is something that you have been yearning for or thinking about trying to implement, please provide your feedback. This is still early in the discussion, the best time for your feedback to matter. Paul Carver and Isaku Yamahata are two contacts you could approach directly if you would like to have a discussion before capturing your feedback on the etherpad. They are also welcome to follow up to this email if I missed any important point here. Carl [1] http://eavesdrop.openstack.org/meetings/neutron_l3/2015/neutron_l3.2015-06-11-15.04.log.html#l-23 [2] https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
Thank you! You saved me a day of the work. Well, we'll move a script to admin user instead of normal user with the special role. PS And thanks for filling a bugreport too. On 06/11/2015 10:40 PM, Sławek Kapłoński wrote: Hello, I don't think it is possible because in nova/db/sqlalchemy/api.py in function instance_get_all_by_filters You have something like: if not context.is_admin: # If we're not admin context, add appropriate filter.. if context.project_id: filters['project_id'] = context.project_id else: filters['user_id'] = context.user_id This is from Juno, but in Kilo it is the same. So in fact even if You will set proper policy.json rules it will still require admin context to search instances from different tenants. Maybe I'm wrong and this is in some other place possible and maybe someone will show me where because I was also looking for it last time :) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia czwartek, 11 czerwca 2015 21:06:31 George Shuklin pisze: Hello. I'm trying to allow a user with special role to see all instances of all tenants without giving him admin privileges. My initial attempt was to change policy.json for nova to "compute:get_all_tenants": "role:special_role or is_admin:True". But it didn't work well. The command (nova list --all-tenants) is not failing anymore (no 'ERROR (Forbidden): Policy doesn't allow compute:get_all_tenants to be performed.'), but the returned list is empty: nova list --all-tenants ++--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | ++--+++-+--+ ++--+++-+--+ Any ideas how to allow a user without admin privileges to see all instances? ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] nova-no-nd-relfection error
Hi Can Somebody help me with this please When I start the instance I get the following error ERROR nova.compute.manage Error: operation failed: filter 'nova-no-nd-reflection' already exists with uuid 875067c3-84df-46b2-a8ea-b8996c06e8e7 I am using legacy nova-network , The bridge that got created is pingable ( My steup is all in one and I am using legacy nova-network) I tried to reinstall all openstack packages but no luck, I tried manully creating an instance in the KVM using virt-install it works. Please find attached the nova-compute log for the same. Any help would be highly appreciated. Thanks, Dev On Tue, Jun 9, 2015 at 2:56 PM, pra devOPS wrote: > Hi > > My setup was workign earlier but when I launch the instance i get the > error > > No valid host found on UI. I checked the nova logs I foud the below error: > > ERROR nova.compute.manager [req-9067a648-b77b-47c9-baa5-e10d3352f81d > 4ca4e46cf5564ce5b158bf2eef161618 6341291002db49b8ae6baa6e6c6455f3] > [instance: bcadbe39-c63c-4439-b397-a86c13da2c47] Error: operation failed: > filter 'nova-no-nd-reflection' already exists with uuid > 875067c3-84df-46b2-a8ea-b8996c06e8e7 > > > my libvirtd version is 1.2.8 > > > I checked the ram_allocatoin_size in the nova.conf it is 1.5 > > > I have kvm, RHEL 7 with Icehouse, this was working before . all of sudden > iam seeing this error. > > Any inputs would help > > Thanks, > DEVP > > > ins.log Description: Binary data ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
Hello, I thought so but I was not sure :) I just made bug report for that: https://bugs.launchpad.net/nova/+bug/1464381 -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia czwartek, 11 czerwca 2015 13:02:16 Clint Byrum pisze: > Excerpts from Sławek Kapłoński's message of 2015-06-11 12:40:36 -0700: > > Hello, > > > > I don't think it is possible because in nova/db/sqlalchemy/api.py in > > function instance_get_all_by_filters You have something like: > > > > if not context.is_admin: > > # If we're not admin context, add appropriate filter.. > > > > if context.project_id: > > filters['project_id'] = context.project_id > > > > else: > > filters['user_id'] = context.user_id > > > > This is from Juno, but in Kilo it is the same. So in fact even if You will > > set proper policy.json rules it will still require admin context to > > search instances from different tenants. Maybe I'm wrong and this is in > > some other place possible and maybe someone will show me where because I > > was also looking for it last time :) > > Looks like a bug to me. The check should just enforce that there is one > of those filters if not context.is_admin. > > https://launchpad.net/nova/+filebug > > I'd suggest referencing this mailing list thread. > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators signature.asc Description: This is a digitally signed message part. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
Excerpts from Sławek Kapłoński's message of 2015-06-11 12:40:36 -0700: > Hello, > > I don't think it is possible because in nova/db/sqlalchemy/api.py in function > instance_get_all_by_filters You have something like: > > if not context.is_admin: > # If we're not admin context, add appropriate filter.. > if context.project_id: > filters['project_id'] = context.project_id > else: > filters['user_id'] = context.user_id > > This is from Juno, but in Kilo it is the same. So in fact even if You will > set > proper policy.json rules it will still require admin context to search > instances from different tenants. Maybe I'm wrong and this is in some other > place possible and maybe someone will show me where because I was also > looking > for it last time :) > Looks like a bug to me. The check should just enforce that there is one of those filters if not context.is_admin. https://launchpad.net/nova/+filebug I'd suggest referencing this mailing list thread. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Allow user to see instances of other users
Hello, I don't think it is possible because in nova/db/sqlalchemy/api.py in function instance_get_all_by_filters You have something like: if not context.is_admin: # If we're not admin context, add appropriate filter.. if context.project_id: filters['project_id'] = context.project_id else: filters['user_id'] = context.user_id This is from Juno, but in Kilo it is the same. So in fact even if You will set proper policy.json rules it will still require admin context to search instances from different tenants. Maybe I'm wrong and this is in some other place possible and maybe someone will show me where because I was also looking for it last time :) -- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia czwartek, 11 czerwca 2015 21:06:31 George Shuklin pisze: > Hello. > > I'm trying to allow a user with special role to see all instances of all > tenants without giving him admin privileges. > > My initial attempt was to change policy.json for nova to > "compute:get_all_tenants": "role:special_role or is_admin:True". > > But it didn't work well. > > The command (nova list --all-tenants) is not failing anymore (no 'ERROR > (Forbidden): Policy doesn't allow compute:get_all_tenants to be > performed.'), but the returned list is empty: > > nova list --all-tenants > ++--+++-+--+ > > | ID | Name | Status | Task State | Power State | Networks | > > ++--+++-+--+ > ++--+++-+--+ > > > Any ideas how to allow a user without admin privileges to see all instances? > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators signature.asc Description: This is a digitally signed message part. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Allow user to see instances of other users
Hello. I'm trying to allow a user with special role to see all instances of all tenants without giving him admin privileges. My initial attempt was to change policy.json for nova to "compute:get_all_tenants": "role:special_role or is_admin:True". But it didn't work well. The command (nova list --all-tenants) is not failing anymore (no 'ERROR (Forbidden): Policy doesn't allow compute:get_all_tenants to be performed.'), but the returned list is empty: nova list --all-tenants ++--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | ++--+++-+--+ ++--+++-+--+ Any ideas how to allow a user without admin privileges to see all instances? ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Gentoo image availability
On 06/11/2015 04:11 AM, Eren Türkay wrote: > On 10-06-2015 02:14, George Shuklin wrote: >> Aw. Don't discriminate DHCP. It has many nice features (for example, if you >> add >> new interface to existing VM, cloud-init with static config will ignore it, >> but >> DHCP will works like magic). >> >> I don't know how it works in Gentoo, but in Debian 'allow-hotplug' for all >> interfaces but eth0 allows to support most of the future interfaces. Same for >> CentOS - you can add few eth scripts to network configuration and they will >> works as soon as new interface appears. > > I want to add to this comment. I believe this hot-plug feature for ethernet > devices is essential in the cloud environment. Short time ago I needed to move > port from one instance to another while keeping the internal IP address same. > I > achieved it by removing a port from the old instance, re-creating the port > with > the same ip address, and pluging it to the new instance. > > The downtime was minimal as the instance supported hot-plug (ubuntu 14.04) and > the ip addresses were distributed using DHCP. When the interface was > re-plugged, dhclient requested an ip address and the DHCP server gave the > internal address of the port which I specified. > > So, it would be really great if you can support hot-plugging for ethernet > devices and DHCP. I find them very useful and I believe many people would > expect this feature from Gentoo image. > > Regards, > > > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ya, it's probably the number one thing I want to see as well and the next thing I'm working on. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] SSH to a VM instance created
On 11-06-2015 12:32, Abhishek Talwar wrote: > Now I want to SSH the VM's created and install some application on it. My > doubit > is how to SSH the VM's as I don't have a dashboard and therefore don't have a > console for the VM's created. Hello, Normally, you add an ssh key and instruct VM to boot with that SSH key. When VM is booted, cloud-init gets the metadata information about the vm (including the SSH key you specify) add the ssh key to the user's .ssh/authorized_keys file. You can look at the page below for managing ssh key via CLI tools. It would be easier for you to manage them if you had dashboard. I would suggest you to install it. It's as easy as installing other components of Openstack and it makes management easier. http://www.rackspace.com/knowledge_center/article/manage-ssh-key-pairs-for-cloud-servers-with-python-novaclient Please make sure that your networking components are working properly and you have metadata proxy running. Otherwise, the VM will not be able to get your ssh key and it will boot with empty ssh key. The usernames for the cloud images can vary. For ubuntu, you need to login as "ubuntu" user, not "root". Regards, -- Eren Türkay, System Administrator https://skyatlas.com/ | +90 850 885 0357 Yildiz Teknik Universitesi Davutpasa Kampusu Teknopark Bolgesi, D2 Blok No:107 Esenler, Istanbul Pk.34220 signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] SSH to a VM instance created
Hi Folks, I have an OpenStack Kilo multinode setup witha controller, network and 2 compute nodes. I am able to boot VM instances and they are going to active state. Now I want to SSH the VM's created and install some application on it. My doubit is how to SSH the VM's as I don't have a dashboard and therefore don't have a console for the VM's created. So I need to get the consoles for the VM's created and install ssh client on it. Kindly provide some information regarding this. Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Gentoo image availability
On 10-06-2015 02:14, George Shuklin wrote: > Aw. Don't discriminate DHCP. It has many nice features (for example, if you > add > new interface to existing VM, cloud-init with static config will ignore it, > but > DHCP will works like magic). > > I don't know how it works in Gentoo, but in Debian 'allow-hotplug' for all > interfaces but eth0 allows to support most of the future interfaces. Same for > CentOS - you can add few eth scripts to network configuration and they will > works as soon as new interface appears. I want to add to this comment. I believe this hot-plug feature for ethernet devices is essential in the cloud environment. Short time ago I needed to move port from one instance to another while keeping the internal IP address same. I achieved it by removing a port from the old instance, re-creating the port with the same ip address, and pluging it to the new instance. The downtime was minimal as the instance supported hot-plug (ubuntu 14.04) and the ip addresses were distributed using DHCP. When the interface was re-plugged, dhclient requested an ip address and the DHCP server gave the internal address of the port which I specified. So, it would be really great if you can support hot-plugging for ethernet devices and DHCP. I find them very useful and I believe many people would expect this feature from Gentoo image. Regards, -- Eren Türkay, System Administrator https://skyatlas.com/ | +90 850 885 0357 Yildiz Teknik Universitesi Davutpasa Kampusu Teknopark Bolgesi, D2 Blok No:107 Esenler, Istanbul Pk.34220 signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Small Operators
On 09-06-2015 21:16, Brendan Johnson wrote: > I am looking for other small OpenStack operators with whom to share > experiences, configurations and discuss issues. Paragus Strategic IT, the > company I work for, recently went live with a small OpenStack based cloud > which we are using to provide IaaS to our clients. Hello Brendan, We operate medium sized openstack cluster as well. It is good to meet new people in the community to share experience. I am mostly doing neutron/swift related work but I also get my hands dirty with other components (ceilometer, nova, cinder, and glance). Since we are small group of people, it is always needed to touch every component when needed. I believe openstack-operator list is where you can get help and share experience. You can join local user group related with openstack, if it doesn't exist, you can create one! :) Nice to meet you and happy hacking, Eren -- Eren Türkay, System Administrator https://skyatlas.com/ | +90 850 885 0357 Yildiz Teknik Universitesi Davutpasa Kampusu Teknopark Bolgesi, D2 Blok No:107 Esenler, Istanbul Pk.34220 signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [ops][tags][packaging] ops:packaging tag - a little common sense, please
Jay Pipes wrote: > [...] > = Packaging tags should be release-specific, or they will be wrong = > > For these packaging tags, the release must be part of the tag itself, > otherwise the information it denotes would be indeterminate. > > As an example, suppose you have a tag that looks like this: > > ops:packaged:centos:good > > And in the tag definition you say that the tag is applied to projects > that have CentOS RPM packages available "within the last 6 months". > Well, as you all know, packages are published for a *particular release > of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in, > say, August 2015, the tag would ostensibly be saying that packages exist > for Nova in Kilo. However, once November rolls around, and packages for > Liberty don't (yet) exist, are you going to remove this > "ops:packaged:centos:good" tag from Nova or (worse) change it to > "ops:pacakged:centos:no"? > > Instead, have the tag be specific to a release of OpenStack: > > packaged:centos:kilo There is a provision in the tag framework for (secondary) attributes. So far we only used it to track the "since when" information on the "integrated-release" legacy tag. If packaging basically carries over, the only interesting bit of information is "what is the first release cycle the packaging appeared in", so you could actually have: - repo: openstack/nova tags: - name: packaged:centos since: diablo I think it's easier and simpler to maintain. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Live-migration multinode Kilo
Hi Folks,I have a multinode openStack kilo installation with a controller, network and 2 compute nodes. I am trying live-migration of an instance, the migration happens successfully but the instance still appears to be on the same host.What can be the reason ? How to proceed further to encounter this problem.RegardsAbhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
