VM Age and Expiration

Administration
, ,
1

Currently, we are not using the Pricing component of Morpheus (long discussion, some of which relates to organizational politics, the need to keep cost structure from general visibility, et al. I won’t go into that here).

We have a lot of group users launching VMs that they are not paying for. As we got into the discussion about that, my manager asked me if there was a report to see, by Group, a list of VMs with either the launch date, or the age. It doesn’t appear that there is such a report, which I informed him of.

The other question he asked me, was whether you could put an Expiration Date (like a gallon of milk) on the VMs (Sandbox he called it), and then kill the VM after that date. I am not particularly a fan of just killing VMs like cattle when I don’t know what they’re actually doing or their potential importance to our organization. It’s a good way to lose friends and, perhaps, make some enemies along the way.

I think it makes sense to have a job that runs, and nags the user x number of times before deleting the VM. At least that way, we can say, “well, we warned you!”.

But in order to pull this off, the VM has to have some kind of a state that I can check. For example, maybe the VM can run for 30 or so days in Introductory mode, and a job will run that will email them that their Intro period is ending at, say, 20 days). After that, the state turns to “unbilled” (for lack of a better term). If it sits in “unbilled” state for tunable length of time (X weeks, a warning once or twice per week), the VM would get deleted. But I need a way to flip that flag manually, if a manager notifies us that they settled up with [ the people who handle cost transfers ].

We do have some ServiceNow integration that is starting to integrate with Morpheus, and at some point down the road might get involved with these cost transfer aspects, but right now, their scope is only initial onboarding (API calls to set up Groups, Roles, Role Mapping, and assignment of Clouds to the groups). So I need some kind of a solution to this problem. Maybe there is one that I am unaware of!?

2

Checkout delayed delete policies in Morpheus. (There’s also the harsher expiration policies.)
That and a creative combination of perhaps provisioning workflows (see the stage for shutdown) and jobs (with email tasks) could be a good way to send a notification to a user and save relationships while getting the right cleanups done.

3

The delayed delete is kind of what we wanted, I think. But, I like the idea of being able to extend the instance in certain scenarios. I just tested the expiration policy and it expired and deleted the VM after the 1 day policy I set. I have also just extended one. But - I don’t want the user to be able to extend ad infinitum. Is there a way I can hook up an Approval process to this extension? And, perhaps limit the number of extensions if I want to so that the user doesn’t just keep extending themselves?

4

I tested the Expiration Policy. I would have like to have seen, in Activity, an event that “VM XXXX Expired” rather than “VM XXXXX was deleted by user yyyyyyy”. It makes it look like the user went in and manually deleted the VM, rather than it being deleted due to expiration.

Also, I found that I could extend. But, if we allow auto extensions such that the VM owner can just keep clicking a button to extend his VM for a specified length of time (e.g. a day), I guess they could just keep doing that ad infinitum, and I see no way for anyone to actually “see” that it has been extended umpteen times - let alone prevent that.

I think we need a way to approve the Extension. Ideally, we would let them extend once, then force it into some kind of approval. But I guess it isn’t working that way currently that I can see.

5

This seems like a really good post for the ideas section of the forum. I would certainly upvote that.
I know that might be a bit redundant, but you can just link this post over there and then others can vote as well.

I think the Morpheus team has already taken a few top voted ideas from there into development.

1 Like
6

Actually, I just realized that if you uncheck “Allow Auto Extensions”, there is an approval process tied into this feature. We might have the desired functionality. Let me test this some more.