Re: [openstack-dev] [Openstack-operators] [nova] [openstack-operators] Tools to move instances between projects?

2015-12-03 Thread Andrew Laski 

On 12/02/15 at 10:30pm, Clint Byrum wrote:

Excerpts from Kris G. Lindgren's message of 2015-12-02 15:43:13 -0800:

I can describe our specific uses cases, not sure our same limitations apply to 
everyone.

Every developer in our company has a project created for them (user-username) 
they are allowed to spinup 5 vm's in this project to do dev/test/POC whatever.  
These projects are not tied into show back or usage that is done internally for 
orgs.  It's simply done to allow any dev to have immediate access to servers so 
that they cant test out ideas/try something ect ect.  Actual applications/teams 
create projects.  Resources used in these projects are done as show back model 
to allow us to move fake money around to help purchase capacity for the cloud.  
We are moving to a lease model for for user- projects, where we we 
automatically, unless action is taken by the user, reclaiming those resources 
after x number of days.  Additionally, every so often we cleanup projects that 
are tied to users that are no longer with the company.  It's during these 
actions that we usually find people asking if we can transfer vm's from one 
project to another project.  Only the employee has access to the

i

r user- project within openstack.


For us - we don't allow snapshots in our private cloud.  We encourage all of 
our devs to be able to rebuild any vm that is running in cloud at any time.  
Which is the line we have been toting for these requests.  However, we would 
still like to be able to support their requests.  Additionally, all of our vm's 
are joined to a domain (both linux and windows), taking a snapshot of the 
server and trying to spin it up a replacement is problematic with servers 
joined to the domain - specifically windows.  It also doesn't take care of 
floating ip's or applied security group rules, volumes that are mapped ect ect.

Taking a snapshot of the vm, making it public, booting another vm from that 
snapshot, deleting the old vm and the snapshot is pretty heavy handed... when 
we really just need to update in nova with which project the vm falls under.



I know it seems counter-intuitive, but I think having to consider the
project ID as being dynamic throughout Nova is quite a bit more heavy
handed than the process you outline above. Try and figure out how many
caches will have to be invalidated, and how complicated the accounting
process will be to transfer quota usage.


Not just Nova but every project that provides resources for the 
instance.  And then there's the question of what to do with resources 
generated by the instance that aren't tied to the instance, like volume 
and image snapshots.


This request comes up enough that ultimately I do think it will be worth 
tackling, but to me it feels like we're a long way off from being able 
to accomplish it in anything close to a reliable way.





We have also had people who didn't pay attention to which project they created 
vm's under and asked us later if we could move the vm from tenant x to tenant y.

We try to have cattle, but people, apparently, really like cows as pets.



One way to convince people to have cattle is to make pets expensive. If
they use good orchestration for resource allocation, config automation,
and save/restore state to/from object storage, then their VM doesn't have
to be moved, they just need to spin up new ones in their new project.
Otherwise, they have to wait for the snapshot transfer process.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] [openstack-operators] Tools to move instances between projects?

2015-12-02 Thread Matt Riedemann 



On 12/2/2015 2:52 PM, Kris G. Lindgren wrote:

Hello,

I was wondering if someone has a set of tools/code to work allow admins
to move vm's from one tenant to another?  We get asked this fairly
frequently in our internal cloud (atleast once a week, more when we
start going through and cleaning up resources for people who are no
longer with the company).   I have searched and I was able to find
anything externally.

Matt Riedemann pointed me to an older spec for nova :
https://review.openstack.org/#/c/105367/ for nova.  I realize that this
will most likely need to be a cross projects effort.  Since vm's consume
resources for multiple other projects, and to move a VM between projects
would also require that those other resources get updated as well.

Is anyone aware of a cross project spec to handle this – or of specs in
other projects?
___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



I think we need a good understanding of what the use case is first. I 
have to assume that these are pets and that's why we can't just snapshot 
an instance and then the new user/project can boot an instance from that.


Quotas are going to be a big issue here I'd think, along with any 
orchestration that nova would need to do with other services like 
cinder/glance/neutron to transfer ownership of volumes or network 
resources (ports), and those projects also have their own quota frameworks.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] [openstack-operators] Tools to move instances between projects?

2015-12-02 Thread Clint Byrum 
Excerpts from Kris G. Lindgren's message of 2015-12-02 15:43:13 -0800:
> I can describe our specific uses cases, not sure our same limitations apply 
> to everyone.
> 
> Every developer in our company has a project created for them (user-username) 
> they are allowed to spinup 5 vm's in this project to do dev/test/POC 
> whatever.  These projects are not tied into show back or usage that is done 
> internally for orgs.  It's simply done to allow any dev to have immediate 
> access to servers so that they cant test out ideas/try something ect ect.  
> Actual applications/teams create projects.  Resources used in these projects 
> are done as show back model to allow us to move fake money around to help 
> purchase capacity for the cloud.  We are moving to a lease model for for 
> user- projects, where we we automatically, unless action is taken by the 
> user, reclaiming those resources after x number of days.  Additionally, every 
> so often we cleanup projects that are tied to users that are no longer with 
> the company.  It's during these actions that we usually find people asking if 
> we can transfer vm's from one project to another project.  Only the employee 
> has access to thei
 r user- project within openstack.
> 
> For us - we don't allow snapshots in our private cloud.  We encourage all of 
> our devs to be able to rebuild any vm that is running in cloud at any time.  
> Which is the line we have been toting for these requests.  However, we would 
> still like to be able to support their requests.  Additionally, all of our 
> vm's are joined to a domain (both linux and windows), taking a snapshot of 
> the server and trying to spin it up a replacement is problematic with servers 
> joined to the domain - specifically windows.  It also doesn't take care of 
> floating ip's or applied security group rules, volumes that are mapped ect 
> ect.
> 
> Taking a snapshot of the vm, making it public, booting another vm from that 
> snapshot, deleting the old vm and the snapshot is pretty heavy handed... when 
> we really just need to update in nova with which project the vm falls under.
> 

I know it seems counter-intuitive, but I think having to consider the
project ID as being dynamic throughout Nova is quite a bit more heavy
handed than the process you outline above. Try and figure out how many
caches will have to be invalidated, and how complicated the accounting
process will be to transfer quota usage.

> We have also had people who didn't pay attention to which project they 
> created vm's under and asked us later if we could move the vm from tenant x 
> to tenant y.
> 
> We try to have cattle, but people, apparently, really like cows as pets.
> 

One way to convince people to have cattle is to make pets expensive. If
they use good orchestration for resource allocation, config automation,
and save/restore state to/from object storage, then their VM doesn't have
to be moved, they just need to spin up new ones in their new project.
Otherwise, they have to wait for the snapshot transfer process.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] [openstack-operators] Tools to move instances between projects?

2015-12-02 Thread Kris G. Lindgren 
I can describe our specific uses cases, not sure our same limitations apply to 
everyone.

Every developer in our company has a project created for them (user-username) 
they are allowed to spinup 5 vm's in this project to do dev/test/POC whatever.  
These projects are not tied into show back or usage that is done internally for 
orgs.  It's simply done to allow any dev to have immediate access to servers so 
that they cant test out ideas/try something ect ect.  Actual applications/teams 
create projects.  Resources used in these projects are done as show back model 
to allow us to move fake money around to help purchase capacity for the cloud.  
We are moving to a lease model for for user- projects, where we we 
automatically, unless action is taken by the user, reclaiming those resources 
after x number of days.  Additionally, every so often we cleanup projects that 
are tied to users that are no longer with the company.  It's during these 
actions that we usually find people asking if we can transfer vm's from one 
project to another project.  Only the employee has access to their 
user- project within openstack.

For us - we don't allow snapshots in our private cloud.  We encourage all of 
our devs to be able to rebuild any vm that is running in cloud at any time.  
Which is the line we have been toting for these requests.  However, we would 
still like to be able to support their requests.  Additionally, all of our vm's 
are joined to a domain (both linux and windows), taking a snapshot of the 
server and trying to spin it up a replacement is problematic with servers 
joined to the domain - specifically windows.  It also doesn't take care of 
floating ip's or applied security group rules, volumes that are mapped ect ect.

Taking a snapshot of the vm, making it public, booting another vm from that 
snapshot, deleting the old vm and the snapshot is pretty heavy handed... when 
we really just need to update in nova with which project the vm falls under.

We have also had people who didn't pay attention to which project they created 
vm's under and asked us later if we could move the vm from tenant x to tenant y.

We try to have cattle, but people, apparently, really like cows as pets.

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy






On 12/2/15, 3:50 PM, "Matt Riedemann"  wrote:

>
>
>On 12/2/2015 2:52 PM, Kris G. Lindgren wrote:
>> Hello,
>>
>> I was wondering if someone has a set of tools/code to work allow admins
>> to move vm's from one tenant to another?  We get asked this fairly
>> frequently in our internal cloud (atleast once a week, more when we
>> start going through and cleaning up resources for people who are no
>> longer with the company).   I have searched and I was able to find
>> anything externally.
>>
>> Matt Riedemann pointed me to an older spec for nova :
>> https://review.openstack.org/#/c/105367/ for nova.  I realize that this
>> will most likely need to be a cross projects effort.  Since vm's consume
>> resources for multiple other projects, and to move a VM between projects
>> would also require that those other resources get updated as well.
>>
>> Is anyone aware of a cross project spec to handle this – or of specs in
>> other projects?
>> ___
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy
>>
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>I think we need a good understanding of what the use case is first. I 
>have to assume that these are pets and that's why we can't just snapshot 
>an instance and then the new user/project can boot an instance from that.
>
>Quotas are going to be a big issue here I'd think, along with any 
>orchestration that nova would need to do with other services like 
>cinder/glance/neutron to transfer ownership of volumes or network 
>resources (ports), and those projects also have their own quota frameworks.
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>___
>OpenStack-operators mailing list
>openstack-operat...@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev