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-<employee> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
