Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Stig Telfer]

Sorry for arriving late on this, the last Scientific WG discussion on Blazar 
was here:

http://eavesdrop.openstack.org/meetings/scientific_wg/2016/scientific_wg.2016-07-06-09.00.log.html#l-115
 


Although there was more substance on OPIE in previous meetings.

Best wishes,
Stig


> On 4 Aug 2016, at 04:51, Blair Bethwaite  wrote:
> 
> We discussed Blazar fairly extensively in a couple of recent
> scientific-wg meetings. I'm having trouble searching out right the irc
> log to support this but IIRC the problem with Blazar as is for the
> typical virtualised cloud (non-Ironic) use-case is that it uses an
> old/deprecated Nova API extension in order to reserve capacity for a
> lease (I think it was something to do with shelve-offload, but I could
> have my wires crossed). Whereas with Ironic it manipulates
> host-aggregates.
> 
> I like the idea of the positive, "yes I'm still using this",
> confirmation, but it needs a tie into the dashboard. For those of us
> using identity federations to bootstrap users this would also help
> with account cleanup, as users who no longer have access (e.g., left
> the sector) to the dashboard would not be able to extend resource
> usage (without talking to support etc).
> 
> Cheers,
> 
> On 4 August 2016 at 03:23, Tim Bell  wrote:
>> 
>> When I last looked, Blazar allows you to reserve instances for a given time. 
>> An example would be
>> 
>> - We are organizing a user training session for 100 physicists from Monday 
>> to Friday
>> - We need that each user is able to create 2 VMs within a single shared 
>> project (as the images etc. are set up before)
>> - OpenStack should ensure that these resources would be available (or reject 
>> the request) and schedule other Blazar requests around it
>> 
>> This does need other functionality though which is currently not there
>> 
>> - Spot instances, i.e. give me the resources if they are available but kill 
>> when you have a reservation. Alvaro is proposing a talk for some work done 
>> in Indigo Datacloud project for this at the summit (votes welcome).
>> - Impending shutdown notification .. save what you want quickly because 
>> you’re going to be deleted
>> 
>> We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ 
>> use. This gives a good onboarding experience but the problem is that our 
>> users forget they asked for resources. Something where we can define a 
>> default lifetime for a VM (ideally, a project) and users need to positively 
>> confirm they want to extend the lifetime would help identify these forgotten 
>> VMs.
>> 
>> I think a good first step would be
>> 
>> - An agreed metadata structure for a VM with an expiry date
>> - An agreed project metadata giving the default length of the VM
>> - An OSops script which finds those VMs exceeding the agreed period and goes 
>> through a ‘suspend’ for N days followed by a delete M days afterwards (to 
>> catch the accidents)
>> 
>> I think this can be done in Nova as is if this is not felt to be a 
>> ‘standard’ function but we should agree on the names/concepts.
>> 
>> Some of the needs are covered in 
>> https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html
>> 
>> Tim
>> 
>> 
>> On 03/08/16 18:47, "Jonathan D. Proulx"  wrote:
>> 
>>Hi All,
>> 
>>As a private cloud operatior who doesn't charge internal users, I'd
>>really like a way to force users to set an exiration time on their
>>instances so if they forget about them they go away.
>> 
>>I'd though Blazar was the thing to look at and Chameleoncloud.org
>>seems to be using it (any of you around here?) but it also doesn't
>>look like it's seen substantive work in a long time.
>> 
>>Anyone have operational exprience with blazar to share or other
>>solutions?
>> 
>>-Jon
>> 
>>___
>>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
> 
> 
> 
> -- 
> Cheers,
> ~Blairo
> 
> ___
> 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] Blazar? (Reservations and/or scheduled termination)

[Matt Riedemann]

On 8/5/2016 8:27 PM, Matt Riedemann wrote:

On 8/3/2016 11:47 AM, Jonathan D. Proulx wrote:

Hi All,

As a private cloud operatior who doesn't charge internal users, I'd
really like a way to force users to set an exiration time on their
instances so if they forget about them they go away.

I'd though Blazar was the thing to look at and Chameleoncloud.org
seems to be using it (any of you around here?) but it also doesn't
look like it's seen substantive work in a long time.

Anyone have operational exprience with blazar to share or other
solutions?

-Jon

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



There was team at IBM that was working on expiration policies in
Mistral, they presented at the Vancouver summit:

https://www.openstack.org/videos/video/using-openstack-to-clean-up-after-itself-automatically-run-mistral-workflows-in-response-to-openstack-notifications




Oops, s/Vancouver/Austin/.

--

Thanks,

Matt Riedemann


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

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Matt Riedemann]

On 8/3/2016 11:47 AM, Jonathan D. Proulx wrote:

Hi All,

As a private cloud operatior who doesn't charge internal users, I'd
really like a way to force users to set an exiration time on their
instances so if they forget about them they go away.

I'd though Blazar was the thing to look at and Chameleoncloud.org
seems to be using it (any of you around here?) but it also doesn't
look like it's seen substantive work in a long time.

Anyone have operational exprience with blazar to share or other
solutions?

-Jon

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



There was team at IBM that was working on expiration policies in 
Mistral, they presented at the Vancouver summit:


https://www.openstack.org/videos/video/using-openstack-to-clean-up-after-itself-automatically-run-mistral-workflows-in-response-to-openstack-notifications

--

Thanks,

Matt Riedemann


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

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Jonathan Proulx]

On Thu, Aug 04, 2016 at 09:59:15AM +0200, Álvaro López García wrote:

:For the record, we proposed a spec [1] on this long ago (actually, 1
:year ago).
:
:[1] https://review.openstack.org/#/c/104883/
:
:Your input is much welcome!

Thanks for the pointer, actually looks like you put in patch set one
on this over 2 years ago!

-Jon

:
:Cheers,
:-- 
:Álvaro López García  al...@ifca.unican.es
:Instituto de Física de Cantabria http://alvarolopez.github.io
:Ed. Juan Jordá, Campus UC  tel: (+34) 942 200 969
:Avda. de los Castros s/nskype: aloga.csic
:39005 Santander (SPAIN)



-- 


signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Pedro Sousa]

Take a look on manageiq.

Em 03/08/2016 17:50, "Jonathan D. Proulx"  escreveu:

> Hi All,
>
> As a private cloud operatior who doesn't charge internal users, I'd
> really like a way to force users to set an exiration time on their
> instances so if they forget about them they go away.
>
> I'd though Blazar was the thing to look at and Chameleoncloud.org
> seems to be using it (any of you around here?) but it also doesn't
> look like it's seen substantive work in a long time.
>
> Anyone have operational exprience with blazar to share or other
> solutions?
>
> -Jon
>
> ___
> 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] Blazar? (Reservations and/or scheduled termination)

[Álvaro López García]

On 03 Aug 2016 (17:23), Tim Bell wrote:
> 
> When I last looked, Blazar allows you to reserve instances for a given time. 
> An example would be
> 
> - We are organizing a user training session for 100 physicists from Monday to 
> Friday
> - We need that each user is able to create 2 VMs within a single shared 
> project (as the images etc. are set up before)
> - OpenStack should ensure that these resources would be available (or reject 
> the request) and schedule other Blazar requests around it
> 
> This does need other functionality though which is currently not there
> 
> - Spot instances, i.e. give me the resources if they are available but
> kill when you have a reservation. Alvaro is proposing a talk for some
> work done in Indigo Datacloud project for this at the summit (votes
> welcome).

For the record, we proposed a spec [1] on this long ago (actually, 1
year ago).

[1] https://review.openstack.org/#/c/104883/

Your input is much welcome!

Cheers,
-- 
Álvaro López García  al...@ifca.unican.es
Instituto de Física de Cantabria http://alvarolopez.github.io
Ed. Juan Jordá, Campus UC  tel: (+34) 942 200 969
Avda. de los Castros s/nskype: aloga.csic
39005 Santander (SPAIN)


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Kris G. Lindgren]

See inline.

Sent from my iPad

> On Aug 3, 2016, at 8:49 PM, Sam Morrison  wrote:
> 
> 
>> On 4 Aug 2016, at 3:12 AM, Kris G. Lindgren  wrote:
>> 
>> We do something similar.  We give everyone in the company an account on the 
>> internal cloud.  By default they have a user- project.  We have a 
>> Jenkins job that adds metadata to all vm’s that are in user- projects.  We 
>> then have additional jobs that read that metadata and determine when the VM 
>> has been alive for x period of time.  At 45 days we send an email saying 
>> that we will remove the vm in 15 days, and they can request a 30 day 
>> extension (which really just resets some metadata information on the vm).  
>> On day 60 the vm is shut down and removed.  For non user- projects, people 
>> are allowed to have their vm’s created as long as they want.
> 
> What stops a user modifying the metadata? Do you have novas policy.json set 
> up so they can’t?
> 
> Sam
> 

Technically nothing.  Most users don't know about metadata and they don't look 
at their vm's very hard.  For us it help clean up the cruft.  But if someone is 
willing to update the metadata on their vm every 15 days, imho they can keep it 
running in their user- project.  We are mainly trying to auto cleanup cruft 
that users did for testing and then forgot about.


> 
>> 
>> I believe I remember seeing something presented in the paris(?) time frame 
>> by overstock(?) that would treat vm’s more as a lease.  IE You get an env 
>> for 90 days, it goes away at the end of that.
>> 
>> 
>> ___
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy
>> 
>> On 8/3/16, 10:47 AM, "Jonathan D. Proulx"  wrote:
>> 
>>   Hi All,
>> 
>>   As a private cloud operatior who doesn't charge internal users, I'd
>>   really like a way to force users to set an exiration time on their
>>   instances so if they forget about them they go away.
>> 
>>   I'd though Blazar was the thing to look at and Chameleoncloud.org
>>   seems to be using it (any of you around here?) but it also doesn't
>>   look like it's seen substantive work in a long time.
>> 
>>   Anyone have operational exprience with blazar to share or other
>>   solutions?
>> 
>>   -Jon
>> 
>>   ___
>>   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] Blazar? (Reservations and/or scheduled termination)

[Mike Smith]

Yes, at Overstock our users don't provision instances directly out of horizon 
or nova.  They use an orchestration tool we wrote in Django which among other 
things tracks a lease time, warns users about expiration, allows them to extend 
etc.  Works great for us, but the same approach may not work for others. 

> On Aug 3, 2016, at 11:19 AM, Kris G. Lindgren  wrote:
> 
> We do something similar.  We give everyone in the company an account on the 
> internal cloud.  By default they have a user- project.  We have a 
> Jenkins job that adds metadata to all vm’s that are in user- projects.  We 
> then have additional jobs that read that metadata and determine when the VM 
> has been alive for x period of time.  At 45 days we send an email saying that 
> we will remove the vm in 15 days, and they can request a 30 day extension 
> (which really just resets some metadata information on the vm).  On day 60 
> the vm is shut down and removed.  For non user- projects, people are allowed 
> to have their vm’s created as long as they want.
> 
> I believe I remember seeing something presented in the paris(?) time frame by 
> overstock(?) that would treat vm’s more as a lease.  IE You get an env for 90 
> days, it goes away at the end of that.
> 
> 
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
> 
> On 8/3/16, 10:47 AM, "Jonathan D. Proulx"  wrote:
> 
>Hi All,
> 
>As a private cloud operatior who doesn't charge internal users, I'd
>really like a way to force users to set an exiration time on their
>instances so if they forget about them they go away.
> 
>I'd though Blazar was the thing to look at and Chameleoncloud.org
>seems to be using it (any of you around here?) but it also doesn't
>look like it's seen substantive work in a long time.
> 
>Anyone have operational exprience with blazar to share or other
>solutions?
> 
>-Jon
> 
>___
>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] Blazar? (Reservations and/or scheduled termination)

[Blair Bethwaite]

We discussed Blazar fairly extensively in a couple of recent
scientific-wg meetings. I'm having trouble searching out right the irc
log to support this but IIRC the problem with Blazar as is for the
typical virtualised cloud (non-Ironic) use-case is that it uses an
old/deprecated Nova API extension in order to reserve capacity for a
lease (I think it was something to do with shelve-offload, but I could
have my wires crossed). Whereas with Ironic it manipulates
host-aggregates.

I like the idea of the positive, "yes I'm still using this",
confirmation, but it needs a tie into the dashboard. For those of us
using identity federations to bootstrap users this would also help
with account cleanup, as users who no longer have access (e.g., left
the sector) to the dashboard would not be able to extend resource
usage (without talking to support etc).

Cheers,

On 4 August 2016 at 03:23, Tim Bell  wrote:
>
> When I last looked, Blazar allows you to reserve instances for a given time. 
> An example would be
>
> - We are organizing a user training session for 100 physicists from Monday to 
> Friday
> - We need that each user is able to create 2 VMs within a single shared 
> project (as the images etc. are set up before)
> - OpenStack should ensure that these resources would be available (or reject 
> the request) and schedule other Blazar requests around it
>
> This does need other functionality though which is currently not there
>
> - Spot instances, i.e. give me the resources if they are available but kill 
> when you have a reservation. Alvaro is proposing a talk for some work done in 
> Indigo Datacloud project for this at the summit (votes welcome).
> - Impending shutdown notification .. save what you want quickly because 
> you’re going to be deleted
>
> We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ 
> use. This gives a good onboarding experience but the problem is that our 
> users forget they asked for resources. Something where we can define a 
> default lifetime for a VM (ideally, a project) and users need to positively 
> confirm they want to extend the lifetime would help identify these forgotten 
> VMs.
>
> I think a good first step would be
>
> - An agreed metadata structure for a VM with an expiry date
> - An agreed project metadata giving the default length of the VM
> - An OSops script which finds those VMs exceeding the agreed period and goes 
> through a ‘suspend’ for N days followed by a delete M days afterwards (to 
> catch the accidents)
>
> I think this can be done in Nova as is if this is not felt to be a ‘standard’ 
> function but we should agree on the names/concepts.
>
> Some of the needs are covered in 
> https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html
>
> Tim
>
>
> On 03/08/16 18:47, "Jonathan D. Proulx"  wrote:
>
> Hi All,
>
> As a private cloud operatior who doesn't charge internal users, I'd
> really like a way to force users to set an exiration time on their
> instances so if they forget about them they go away.
>
> I'd though Blazar was the thing to look at and Chameleoncloud.org
> seems to be using it (any of you around here?) but it also doesn't
> look like it's seen substantive work in a long time.
>
> Anyone have operational exprience with blazar to share or other
> solutions?
>
> -Jon
>
> ___
> 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



-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Blair Bethwaite]

On 4 August 2016 at 12:48, Sam Morrison  wrote:
>
>> On 4 Aug 2016, at 3:12 AM, Kris G. Lindgren  wrote:
>>
>> We do something similar.  We give everyone in the company an account on the 
>> internal cloud.  By default they have a user- project.  We have a 
>> Jenkins job that adds metadata to all vm’s that are in user- projects.  We 
>> then have additional jobs that read that metadata and determine when the VM 
>> has been alive for x period of time.  At 45 days we send an email saying 
>> that we will remove the vm in 15 days, and they can request a 30 day 
>> extension (which really just resets some metadata information on the vm).  
>> On day 60 the vm is shut down and removed.  For non user- projects, people 
>> are allowed to have their vm’s created as long as they want.
>
> What stops a user modifying the metadata? Do you have novas policy.json set 
> up so they can’t?

System-metadata?

-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

[Sam Morrison]

> On 4 Aug 2016, at 3:12 AM, Kris G. Lindgren  wrote:
> 
> We do something similar.  We give everyone in the company an account on the 
> internal cloud.  By default they have a user- project.  We have a 
> Jenkins job that adds metadata to all vm’s that are in user- projects.  We 
> then have additional jobs that read that metadata and determine when the VM 
> has been alive for x period of time.  At 45 days we send an email saying that 
> we will remove the vm in 15 days, and they can request a 30 day extension 
> (which really just resets some metadata information on the vm).  On day 60 
> the vm is shut down and removed.  For non user- projects, people are allowed 
> to have their vm’s created as long as they want.

What stops a user modifying the metadata? Do you have novas policy.json set up 
so they can’t?

Sam


> 
> I believe I remember seeing something presented in the paris(?) time frame by 
> overstock(?) that would treat vm’s more as a lease.  IE You get an env for 90 
> days, it goes away at the end of that.
> 
> 
> ___
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy
> 
> On 8/3/16, 10:47 AM, "Jonathan D. Proulx"  wrote:
> 
>Hi All,
> 
>As a private cloud operatior who doesn't charge internal users, I'd
>really like a way to force users to set an exiration time on their
>instances so if they forget about them they go away.
> 
>I'd though Blazar was the thing to look at and Chameleoncloud.org
>seems to be using it (any of you around here?) but it also doesn't
>look like it's seen substantive work in a long time.
> 
>Anyone have operational exprience with blazar to share or other
>solutions?
> 
>-Jon
> 
>___
>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] Blazar? (Reservations and/or scheduled termination)

[Gangur, Hrushikesh]

Resource reservation is one of the key requirements OPNFV is driving for Telco 
NFV usecases. Today it is staged within "Promise" project as a shim layer, but 
the intention is to get a native support through OpenStack core services like 
nova, neutron, cinder. Here are some urls where the requirements are captured 
very well:
Requirement document: 
http://artifacts.opnfv.org/promise/docs/requirements/requirements.pdf
Website: https://github.com/opnfv/promise

There are some traction in the community in this area, specifically reignite 
blazar and/or drive low-level requirements at individual service level.  

Regards~Hrushi

-Original Message-
From: Jonathan D. Proulx [mailto:j...@csail.mit.edu] 
Sent: Wednesday, August 03, 2016 12:22 PM
To: Tim Bell 
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Blazar? (Reservations and/or scheduled 
termination)

On Wed, Aug 03, 2016 at 05:23:23PM +, Tim Bell wrote:
:
:When I last looked, Blazar allows you to reserve instances for a given time. 
An example would be
:
:- We are organizing a user training session for 100 physicists from Monday to 
Friday
:- We need that each user is able to create 2 VMs within a single shared 
project (as the images etc. are set up before)
:- OpenStack should ensure that these resources would be available (or reject 
the request) and schedule other Blazar requests around it
:
:This does need other functionality though which is currently not there
:
:- Spot instances, i.e. give me the resources if they are available but kill 
when you have a reservation. Alvaro is proposing a talk for some work done in 
Indigo Datacloud project for this at the summit (votes welcome).
:- Impending shutdown notification .. save what you want quickly because you’re 
going to be deleted

I hadn't looked in ages (untill today) and that does seem to be both what I 
remember and what seems to be current best I can tell (still hoping someone 
will correct me and tell me I'm just looking in the worng place, but...)

:We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ 
use. This gives a good onboarding experience but the problem is that our users 
forget they asked for resources. Something where we can define a default 
lifetime for a VM (ideally, a project) and users need to positively confirm 
they want to extend the lifetime would help identify these forgotten VMs.

We have similar onboarding user sandboxes, it would be nice to auto limit lives 
there.  My current pain seems to come from peopel who've setup virtual clusters 
and then not taken them down.  Not sure it they've forgotten or if they're 
squatting to ensure they have resources later.

:I think a good first step would be
:
:- An agreed metadata structure for a VM with an expiry date
:- An agreed project metadata giving the default length of the VM
:- An OSops script which finds those VMs exceeding the agreed period and goes 
through a ‘suspend’ for N days followed by a delete M days afterwards (to catch 
the accidents)

:I think this can be done in Nova as is if this is not felt to be a ‘standard’ 
function but we should agree on the names/concepts.

Kris (above) seems to have rigged up a similar system using Jenkins.
I'd prefer not to drag in yet another thing since I'm not running Jenkins 
(yet?), but conceptually the metadata path seems resonable to me.

:Some of the needs are covered in
https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html

Ah yes, I was at the Summit session you reference there.  Reminds me I do need 
to get mroe involved with Scientific Working Group (at least enough to follow 
the ongoing discussions)

Thanks,
-Jon

:
:Tim
:
:
:On 03/08/16 18:47, "Jonathan D. Proulx"  wrote:
:
:Hi All,
:
:As a private cloud operatior who doesn't charge internal users, I'd
:really like a way to force users to set an exiration time on their
:instances so if they forget about them they go away.
:
:I'd though Blazar was the thing to look at and Chameleoncloud.org
:seems to be using it (any of you around here?) but it also doesn't
:look like it's seen substantive work in a long time.
:
:Anyone have operational exprience with blazar to share or other
:solutions?
:
:-Jon
:
:___
: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] Blazar? (Reservations and/or scheduled termination)

[Jonathan D. Proulx]

On Wed, Aug 03, 2016 at 05:23:23PM +, Tim Bell wrote:
:
:When I last looked, Blazar allows you to reserve instances for a given time. 
An example would be
:
:- We are organizing a user training session for 100 physicists from Monday to 
Friday
:- We need that each user is able to create 2 VMs within a single shared 
project (as the images etc. are set up before)
:- OpenStack should ensure that these resources would be available (or reject 
the request) and schedule other Blazar requests around it
:
:This does need other functionality though which is currently not there
:
:- Spot instances, i.e. give me the resources if they are available but kill 
when you have a reservation. Alvaro is proposing a talk for some work done in 
Indigo Datacloud project for this at the summit (votes welcome).
:- Impending shutdown notification .. save what you want quickly because you’re 
going to be deleted

I hadn't looked in ages (untill today) and that does seem to be both
what I remember and what seems to be current best I can tell (still
hoping someone will correct me and tell me I'm just looking in the
worng place, but...)

:We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ 
use. This gives a good onboarding experience but the problem is that our users 
forget they asked for resources. Something where we can define a default 
lifetime for a VM (ideally, a project) and users need to positively confirm 
they want to extend the lifetime would help identify these forgotten VMs.

We have similar onboarding user sandboxes, it would be nice to auto
limit lives there.  My current pain seems to come from peopel who've
setup virtual clusters and then not taken them down.  Not sure it
they've forgotten or if they're squatting to ensure they have
resources later.

:I think a good first step would be
:
:- An agreed metadata structure for a VM with an expiry date
:- An agreed project metadata giving the default length of the VM
:- An OSops script which finds those VMs exceeding the agreed period and goes 
through a ‘suspend’ for N days followed by a delete M days afterwards (to catch 
the accidents)

:I think this can be done in Nova as is if this is not felt to be a ‘standard’ 
function but we should agree on the names/concepts.

Kris (above) seems to have rigged up a similar system using Jenkins.
I'd prefer not to drag in yet another thing since I'm not running
Jenkins (yet?), but conceptually the metadata path seems resonable to
me.

:Some of the needs are covered in
https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html

Ah yes, I was at the Summit session you reference there.  Reminds me I
do need to get mroe involved with Scientific Working Group (at least
enough to follow the ongoing discussions)

Thanks,
-Jon

:
:Tim
:
:
:On 03/08/16 18:47, "Jonathan D. Proulx"  wrote:
:
:Hi All,
:
:As a private cloud operatior who doesn't charge internal users, I'd
:really like a way to force users to set an exiration time on their
:instances so if they forget about them they go away.
:
:I'd though Blazar was the thing to look at and Chameleoncloud.org
:seems to be using it (any of you around here?) but it also doesn't
:look like it's seen substantive work in a long time.
:
:Anyone have operational exprience with blazar to share or other
:solutions?
:
:-Jon
:
:___
: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] Blazar? (Reservations and/or scheduled termination)

[Tim Bell]

When I last looked, Blazar allows you to reserve instances for a given time. An 
example would be

- We are organizing a user training session for 100 physicists from Monday to 
Friday
- We need that each user is able to create 2 VMs within a single shared project 
(as the images etc. are set up before)
- OpenStack should ensure that these resources would be available (or reject 
the request) and schedule other Blazar requests around it

This does need other functionality though which is currently not there

- Spot instances, i.e. give me the resources if they are available but kill 
when you have a reservation. Alvaro is proposing a talk for some work done in 
Indigo Datacloud project for this at the summit (votes welcome).
- Impending shutdown notification .. save what you want quickly because you’re 
going to be deleted

We have a use case where we offer each user a quota of 2 VMs for ‘Personal’ 
use. This gives a good onboarding experience but the problem is that our users 
forget they asked for resources. Something where we can define a default 
lifetime for a VM (ideally, a project) and users need to positively confirm 
they want to extend the lifetime would help identify these forgotten VMs.

I think a good first step would be

- An agreed metadata structure for a VM with an expiry date
- An agreed project metadata giving the default length of the VM
- An OSops script which finds those VMs exceeding the agreed period and goes 
through a ‘suspend’ for N days followed by a delete M days afterwards (to catch 
the accidents)

I think this can be done in Nova as is if this is not felt to be a ‘standard’ 
function but we should agree on the names/concepts.

Some of the needs are covered in 
https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html

Tim


On 03/08/16 18:47, "Jonathan D. Proulx"  wrote:

Hi All,

As a private cloud operatior who doesn't charge internal users, I'd
really like a way to force users to set an exiration time on their
instances so if they forget about them they go away.

I'd though Blazar was the thing to look at and Chameleoncloud.org
seems to be using it (any of you around here?) but it also doesn't
look like it's seen substantive work in a long time.

Anyone have operational exprience with blazar to share or other
solutions?

-Jon

___
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] Blazar? (Reservations and/or scheduled termination)

[Kris G. Lindgren]

We do something similar.  We give everyone in the company an account on the 
internal cloud.  By default they have a user- project.  We have a 
Jenkins job that adds metadata to all vm’s that are in user- projects.  We then 
have additional jobs that read that metadata and determine when the VM has been 
alive for x period of time.  At 45 days we send an email saying that we will 
remove the vm in 15 days, and they can request a 30 day extension (which really 
just resets some metadata information on the vm).  On day 60 the vm is shut 
down and removed.  For non user- projects, people are allowed to have their 
vm’s created as long as they want.

I believe I remember seeing something presented in the paris(?) time frame by 
overstock(?) that would treat vm’s more as a lease.  IE You get an env for 90 
days, it goes away at the end of that.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

On 8/3/16, 10:47 AM, "Jonathan D. Proulx"  wrote:

Hi All,

As a private cloud operatior who doesn't charge internal users, I'd
really like a way to force users to set an exiration time on their
instances so if they forget about them they go away.

I'd though Blazar was the thing to look at and Chameleoncloud.org
seems to be using it (any of you around here?) but it also doesn't
look like it's seen substantive work in a long time.

Anyone have operational exprience with blazar to share or other
solutions?

-Jon

___
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] Blazar? (Reservations and/or scheduled termination)

[Jonathan D. Proulx]

Hi All,

As a private cloud operatior who doesn't charge internal users, I'd
really like a way to force users to set an exiration time on their
instances so if they forget about them they go away.

I'd though Blazar was the thing to look at and Chameleoncloud.org
seems to be using it (any of you around here?) but it also doesn't
look like it's seen substantive work in a long time.

Anyone have operational exprience with blazar to share or other
solutions?

-Jon

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