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
[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] 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
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] 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
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
[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
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
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
[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
[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] [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
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
