Re: [Openstack] [Trove] Integrating trove and phpmyadmin
Reposting with [Trove] Designation Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper On 4/28/14, 19:30, Cotton Tenney codercot...@me.com wrote: Have you had any luck on this? This is something I'd like to do. Sent from my iPad On Apr 26, 2014, at 1:59 PM, Ali Nazemian alinazem...@gmail.com wrote: Hi, I am going to integrate phpmyadmin with my trove. I was wondering how I can integrate phpmyadmin (on client side) and trove (on server side). I am able to connect to phpmyadmin panel via root user but it is not possible with the users that I created via horizon dashboard. Would you please help me through this? Best regards. -- A.Nazemian ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
Aaron, This is true adding this to disk image builder element would not be an issue, I just did not know it was a required step. Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Aaron Rosen aaronoro...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, April 21, 2014 at 22:11 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working Hi, I'm guessing the scripts inside your guest is only setup to configure dhcp on the first interface. See /etc/network/interfaces Best, Aaron On Mon, Apr 21, 2014 at 4:59 PM, Hopper, Justin justin.hop...@hp.com wrote: They are on separate Networks. Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Kevin Benton blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, April 21, 2014 at 16:54 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working Are the two NICs on the same or different networks? Currently there is a limitation of Nova that does not permit two NICs to be attached to the same Neutron network. -- Kevin Benton On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.com wrote: So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
They are on separate Networks. Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Kevin Benton blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, April 21, 2014 at 16:54 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working Are the two NICs on the same or different networks? Currently there is a limitation of Nova that does not permit two NICs to be attached to the same Neutron network. -- Kevin Benton On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.com wrote: So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
Phil, I am reviewing the existing “check_instance_lock” implementation to see how it might be leveraged. Off the cuff, it looks pretty much what we need. I need to look into the permissions to better understand how one can “lock” and instance. Thanks for the guidance. Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper On 4/7/14, 10:01, Day, Phil philip@hp.com wrote: I can see the case for Trove being to create an instance within a customer's tenant (if nothing else it would make adding it onto their Neutron network a lot easier), but I'm wondering why it really needs to be hidden from them ? If the instances have a name that makes it pretty obvious that Trove created them, and the user presumably knows that did this from Trove, why hide them ?I'd of thought that would lead to a whole bunch of confusion and support calls when they try to work out why they are out of quota and can only see subset of the instances being counted by the system. If the need is to stop the users doing something with those instances then maybe we need an extension to the lock mechanism such that a lock can be made by a specific user (so the trove user in the same tenant could lock the instance so that a non-trove user in that tenant couldn’t unlock ). We already have this to an extent, in that an instance locked by an admin can' t be unlocked by the owner, so I don’t think it would be too hard to build on that. Feels like that would be a lot more transparent than trying to obfuscate the instances themselves. -Original Message- From: Hopper, Justin Sent: 06 April 2014 01:37 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature Russell, Thanks for the quick reply. If I understand what you are suggesting it is that there would be one Trove-Service Tenant/User that owns all instances from the perspective of Nova. This was one option proposed during our discussions. However, what we thought would be best is to continue to use the user credentials so that Nova has the correct association. We wanted a more substantial and deliberate relationship between Nova and a dependent service. In this relationship, Nova would acknowledge which instances are being managed by which Services and while ownership was still to that of the User, management/manipulation of said Instance would be solely done by the Service. At this point the guard that Nova needs to provide around the instance does not need to be complex. It would even suffice to keep those instances hidden from such operations as ³nova list² when invoked by directly by the user. Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper On 4/5/14, 14:20, Russell Bryant rbry...@redhat.com wrote: On 04/04/2014 08:12 PM, Hopper, Justin wrote: Greetings, I am trying to address an issue from certain perspectives and I think some support from Nova may be needed. _Problem_ Services like Trove use run in Nova Compute Instances. These Services try to provide an integrated and stable platform for which the ³service² can run in a predictable manner. Such elements include configuration of the service, networking, installed packages, etc. In today¹s world, when Trove spins up an Instance to deploy a database on, it creates that Instance with the Users Credentials. Thus, to Nova, the User has full access to that Instance through Nova¹s API. This access can be used in ways which unintentionally compromise the service. _Solution_ A proposal is being formed that would put such Instances in a read-only or invisible mode from the perspective of Nova. That is, the Instance can only be managed from the Service from which it was created. At this point, we do not need any granular controls. A simple lock-down of the Nova API for these Instances would suffice. However, Trove would still need to interact with this Instance via Nova API. The basic requirements for Nova would beŠ A way to identify a request originating from a Service vs coming directly from an end-user A way to Identify which instances are being managed by a Service A way to prevent some or all access to the Instance unless the Service ID in the request matches that attached to the Instance Any feedback on this would be appreciated. The use case makes sense to me. I'm thinking we should expect an identity to be created in Keystone for trove and have trove use that for managing all of its instances. If that is sufficient, trove would need some changes to use its service credentials instead of the user credentials. I don't think any changes are needed in Nova. Is there anything missing to support your use case using that approach? -- Russell Bryant
Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
Hi Phil, I spent some time this afternoon looking this over and testing it out. Currently Trove does have “admim” role in Nova (per Devstack) and there is a Trove-Admin API that currently requires this. I suppose this level of authority may be overreaching in certain deployments. If so then a new Role with hierarchy would be necessary. It looks like it would only complicate “check_instance_lock” slightly more than it is today. First by also accessing the “locked_by” attribute in Instance and secondly by checking the context token role to see if it meets or exceeds the current “locked_by” level. This is looking very promising for our use case. So much that we would like to see it extended to Security Groups :) Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper On 4/8/14, 3:40, Day, Phil philip@hp.com wrote: Hi Justin, Glad you like the idea of using lock ;-) I still think you need some more granularity that user or admin - currently for Trove to lock the users VMs as admin it would need an account that has admin rights across the board in Nova, and I don't think folks would want to delegate that much power to Trove. Also the folks who genuinely need to enforce an admin level lock on a VM (normally if there is some security issue with the VM) wouldn’t want Trove to be able to unlock it. So I think we're on the right lines, but needs more thinking about how to get a bit more granularity - I'm thinking of some other variant of lock that fits somewhere between the current user and admin locks, and is controlled via policy by a specific role, so you have something like: User without AppLock role - can apply/remove user lock to instance. Cannot perform operations is any lock is set on the instance User with AppLock role - can apply/remove application lock to instance. Cannot perform operations on the instance if the admin lock is set User with Admin role - can apply/remove admin lock. Can perform any operations on the instance Phil -Original Message- From: Hopper, Justin Sent: 07 April 2014 19:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature Phil, I think you “lock” concept is more along the lines of what we are looking for. Hiding them is not a requirement. Preventing the user from using Nova directly on those Instances is. So locking it with an “Admin” user so that they could not snapshot, resize it directly in Nova would be great. When they use the Trove API, Trove, as Admin, could “unlock” those Instances, make the modification and then “lock” them after it is complete. Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper On 4/7/14, 10:01, Day, Phil philip@hp.com wrote: I can see the case for Trove being to create an instance within a customer's tenant (if nothing else it would make adding it onto their Neutron network a lot easier), but I'm wondering why it really needs to be hidden from them ? If the instances have a name that makes it pretty obvious that Trove created them, and the user presumably knows that did this from Trove, why hide them ?I'd of thought that would lead to a whole bunch of confusion and support calls when they try to work out why they are out of quota and can only see subset of the instances being counted by the system. If the need is to stop the users doing something with those instances then maybe we need an extension to the lock mechanism such that a lock can be made by a specific user (so the trove user in the same tenant could lock the instance so that a non-trove user in that tenant couldn’t unlock ). We already have this to an extent, in that an instance locked by an admin can' t be unlocked by the owner, so I don’t think it would be too hard to build on that. Feels like that would be a lot more transparent than trying to obfuscate the instances themselves. -Original Message- From: Hopper, Justin Sent: 06 April 2014 01:37 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature Russell, Thanks for the quick reply. If I understand what you are suggesting it is that there would be one Trove-Service Tenant/User that owns all instances from the perspective of Nova. This was one option proposed during our discussions. However, what we thought would be best is to continue to use the user credentials so that Nova has the correct association. We wanted a more substantial and deliberate relationship between Nova and a dependent service. In this relationship, Nova would acknowledge which instances are being managed by which Services and while ownership was still to that of the User, management/manipulation of said Instance would be solely done by the Service. At this point
Re: [Openstack] [Trove] Trove interface
Ali, Please let us know what where you see opportunities for improvement with Trove documentation. Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Ali Nazemian alinazem...@gmail.com Date: Wednesday, April 2, 2014 at 9:37 To: Akihiro Motoki amot...@gmail.com Cc: openstack openstack@lists.openstack.org Subject: Re: [Openstack] Trove interface Thank you very much but why the documentation for trove is so poor? On Mon, Mar 31, 2014 at 5:50 PM, Akihiro Motoki amot...@gmail.com wrote: Hi Ali, Horizon Icehouse release which is coming soon support Trove. If keystone has Trove endpoint, Trove support in Horizon will be enabled automatically. On Sun, Mar 30, 2014 at 5:35 AM, Ali Nazemian alinazem...@gmail.com wrote: Hi, I recently got familiar with trove, I want to know that is there any interface (web interface) available for using trove or just the trove command line is considered for this purpose? Regards. -- A.Nazemian ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- A.Nazemian smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
