settingsLogin | Registersettings

[Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

0 votes

Hi all,

The below was suggested for a Forum session but we don't yet have a
submission or name to chair/moderate. I, for one, would certainly be
interested in providing input. Do we have any owners out there?

Resource reservation requirements:
==
The Blazar project [https://wiki.openstack.org/wiki/Blazar] has been
revived following Barcelona and will soon release a new version. Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar

In particular, support for pre-emptible instances could be combined
with resource reservation to maximize utilization on unreserved
resources.+1

Is Blazar the right project to discuss reservations of finite
consumable resources like software licenses?

Blazar would like to ultimately support many different kinds of
resources (volumes, floating IPs, etc.). Software licenses can be
another type.
==
(https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg)

Cheers,

--
Blair Bethwaite
Senior HPC Consultant

Monash eResearch Centre
Monash University
Room G26, 15 Innovation Walk, Clayton Campus
Clayton VIC 3800
Australia
Mobile: 0439-545-002
Office: +61 3-9903-2800


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked Sep 21, 2017 in openstack-operators by blair.bethwaite_at_m (460 points)   1

17 Responses

0 votes

On 4/1/2017 8:36 AM, Blair Bethwaite wrote:
Hi all,

The below was suggested for a Forum session but we don't yet have a
submission or name to chair/moderate. I, for one, would certainly be
interested in providing input. Do we have any owners out there?

Resource reservation requirements:
==
The Blazar project [https://wiki.openstack.org/wiki/Blazar] has been
revived following Barcelona and will soon release a new version. Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar

In particular, support for pre-emptible instances could be combined
with resource reservation to maximize utilization on unreserved
resources.+1

Regarding resource reservation, please see this older Nova spec which is
related:

https://review.openstack.org/#/c/389216/

And see the points that Jay Pipes makes in that review. Before spending
a lot of time reviving the project, I'd encourage people to read and
digest the points made in that review and if there responses or other
use cases then let's discuss them before bringing a service back from
the dead and assume it will be integrated into the other projects.

Is Blazar the right project to discuss reservations of finite
consumable resources like software licenses?

Blazar would like to ultimately support many different kinds of
resources (volumes, floating IPs, etc.). Software licenses can be
another type.
==
(https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg)

Cheers,

John Garbutt also has a WIP backlog spec in Nova related to pre-emtiple
instances:

https://review.openstack.org/#/c/438640/

--

Thanks,

Matt


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Apr 1, 2017 by mriedemos_at_gmail.c (15,720 points)   2 4 7
0 votes

On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann mriedemos@gmail.com wrote:

On 4/1/2017 8:36 AM, Blair Bethwaite wrote:

Hi all,

The below was suggested for a Forum session but we don't yet have a
submission or name to chair/moderate. I, for one, would certainly be
interested in providing input. Do we have any owners out there?

Resource reservation requirements:
==
The Blazar project [https://wiki.openstack.org/wiki/Blazar] has been
revived following Barcelona and will soon release a new version. Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar

In particular, support for pre-emptible instances could be combined
with resource reservation to maximize utilization on unreserved
resources.+1

Regarding resource reservation, please see this older Nova spec which is
related:

https://review.openstack.org/#/c/389216/

And see the points that Jay Pipes makes in that review. Before spending a
lot of time reviving the project, I'd encourage people to read and digest
the points made in that review and if there responses or other use cases
then let's discuss them before bringing a service back from the dead and
assume it will be integrated into the other projects.

This is appreciated. I'll describe the way I've seen Blazar used and I
believe it's quite different than the above slot reservation as well as
spot instance support, but please let me know if I am incorrect or if there
have been other discussions about this use-case elsewhere:

A research group has a finite amount of specialized hardware and there are
more people wanting to use this hardware than what's currently available.
Let's use high performance GPUs as an example. The group is OK with
publishing the amount of hardware they have available (normally this is
hidden as best as possible). By doing this, a researcher can use Blazar as
sort of a community calendar, see that there are 3 GPU nodes available for
the week of April 3, and reserve them for that time period.

Is Blazar the right project to discuss reservations of finite
consumable resources like software licenses?

Blazar would like to ultimately support many different kinds of
resources (volumes, floating IPs, etc.). Software licenses can be
another type.
==
(https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg)

Cheers,

John Garbutt also has a WIP backlog spec in Nova related to pre-emtiple
instances:

https://review.openstack.org/#/c/438640/

--

Thanks,

Matt


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
responded Apr 2, 2017 by Joe_Topjian (5,780 points)   1 4 7
0 votes

Hi all,

So I've proposed a Forum session to discuss some of these issues and
use-cases: http://forumtopics.openstack.org/cfp/details/124 - there
would seem to be value in getting Nova, Blazar and OPIE folks together
to talk about advanced scheduling use-cases. In particular it looks
like there is a need (and gap?) for Nova's scheduler to model and
support (either directly or through extension/pluggability) more than
just on-demand scheduling workflows.

However, I'm not an active dev and am somewhat ignorant on the state
of nova-scheduler and related components now, so would appreciate
someone who knows what they are talking about to help chair this
session and provide some updates to the proposal that include
background reading etc.

Cheers,

On 2 April 2017 at 09:21, Matt Riedemann mriedemos@gmail.com wrote:
On 4/1/2017 8:36 AM, Blair Bethwaite wrote:

Hi all,

The below was suggested for a Forum session but we don't yet have a
submission or name to chair/moderate. I, for one, would certainly be
interested in providing input. Do we have any owners out there?

Resource reservation requirements:
==
The Blazar project [https://wiki.openstack.org/wiki/Blazar] has been
revived following Barcelona and will soon release a new version. Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar

In particular, support for pre-emptible instances could be combined
with resource reservation to maximize utilization on unreserved
resources.+1

Regarding resource reservation, please see this older Nova spec which is
related:

https://review.openstack.org/#/c/389216/

And see the points that Jay Pipes makes in that review. Before spending a
lot of time reviving the project, I'd encourage people to read and digest
the points made in that review and if there responses or other use cases
then let's discuss them before bringing a service back from the dead and
assume it will be integrated into the other projects.

Is Blazar the right project to discuss reservations of finite
consumable resources like software licenses?

Blazar would like to ultimately support many different kinds of
resources (volumes, floating IPs, etc.). Software licenses can be
another type.
==
(https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg)

Cheers,

John Garbutt also has a WIP backlog spec in Nova related to pre-emtiple
instances:

https://review.openstack.org/#/c/438640/

--

Thanks,

Matt


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
responded Apr 3, 2017 by Blair_Bethwaite (4,080 points)   1 3 5
0 votes

On 04/01/2017 08:32 PM, Joe Topjian wrote:
On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <mriedemos@gmail.com
mriedemos@gmail.com> wrote:

On 4/1/2017 8:36 AM, Blair Bethwaite wrote:

    Hi all,

    The below was suggested for a Forum session but we don't yet have a
    submission or name to chair/moderate. I, for one, would certainly be
    interested in providing input. Do we have any owners out there?

    Resource reservation requirements:
    ==
    The Blazar project [https://wiki.openstack.org/wiki/Blazar
    <https://wiki.openstack.org/wiki/Blazar>] has been
    revived following Barcelona and will soon release a new version. Now
    is a good time to get involved and share requirements with the
    community. Our development priorities are described through
    Blueprints
    on Launchpad: https://blueprints.launchpad.net/blazar
    <https://blueprints.launchpad.net/blazar>

    In particular, support for pre-emptible instances could be combined
    with resource reservation to maximize utilization on unreserved
    resources.+1


Regarding resource reservation, please see this older Nova spec
which is related:

https://review.openstack.org/#/c/389216/
<https://review.openstack.org/#/c/389216/>

And see the points that Jay Pipes makes in that review. Before
spending a lot of time reviving the project, I'd encourage people to
read and digest the points made in that review and if there
responses or other use cases then let's discuss them *before*
bringing a service back from the dead and assume it will be
integrated into the other projects.

This is appreciated. I'll describe the way I've seen Blazar used and I
believe it's quite different than the above slot reservation as well as
spot instance support, but please let me know if I am incorrect or if
there have been other discussions about this use-case elsewhere:

A research group has a finite amount of specialized hardware and there
are more people wanting to use this hardware than what's currently
available. Let's use high performance GPUs as an example. The group is
OK with publishing the amount of hardware they have available (normally
this is hidden as best as possible). By doing this, a researcher can use
Blazar as sort of a community calendar, see that there are 3 GPU nodes
available for the week of April 3, and reserve them for that time period.

Yeah, I totally understand this use case.

However, implementing the above in any useful fashion requires that
Blazar be placed above Nova and essentially that the cloud operator
turns off access to Nova's POST /servers API call for regular users.
Because if not, the information that Blazar acts upon can be simply
circumvented by any user at any time.

In other words, your "3 GPU nodes available for the week of April 3" can
change at any time by a user that goes and launches instances that
consumes those 3 GPU nodes.

If you have a certain type of OpenStack deployment that isn't multi-user
and where the only thing that launches instances is an
automation/orchestration tool (in other words, an NFV MANO system), the
reservation concepts works great -- because you don't have pesky users
that can sidestep the system and actually launch instances that would
impact reserved consumables.

However, if you do have normal users of your cloud -- as most
scientific deployments must have -- then I'm afraid the only way to make
this work is to have users only use the Blazar API to reserve
instances and essentially shut off the normal Nova POST /servers API.

Does that make sense?

Best,
-jay


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Apr 3, 2017 by Jay_Pipes (59,760 points)   3 10 14
0 votes

On Mon, Apr 3, 2017 at 8:20 AM, Jay Pipes jaypipes@gmail.com wrote:

On 04/01/2017 08:32 PM, Joe Topjian wrote:

On Sat, Apr 1, 2017 at 5:21 PM, Matt Riedemann <mriedemos@gmail.com
mriedemos@gmail.com> wrote:

On 4/1/2017 8:36 AM, Blair Bethwaite wrote:

    Hi all,

    The below was suggested for a Forum session but we don't yet have

a
submission or name to chair/moderate. I, for one, would certainly
be
interested in providing input. Do we have any owners out there?

    Resource reservation requirements:
    ==
    The Blazar project [https://wiki.openstack.org/wiki/Blazar
    <https://wiki.openstack.org/wiki/Blazar>] has been
    revived following Barcelona and will soon release a new version.

Now
is a good time to get involved and share requirements with the
community. Our development priorities are described through
Blueprints
on Launchpad: https://blueprints.launchpad.net/blazar
https://blueprints.launchpad.net/blazar

    In particular, support for pre-emptible instances could be

combined
with resource reservation to maximize utilization on unreserved
resources.+1

Regarding resource reservation, please see this older Nova spec
which is related:

https://review.openstack.org/#/c/389216/
<https://review.openstack.org/#/c/389216/>

And see the points that Jay Pipes makes in that review. Before
spending a lot of time reviving the project, I'd encourage people to
read and digest the points made in that review and if there
responses or other use cases then let's discuss them *before*
bringing a service back from the dead and assume it will be
integrated into the other projects.

This is appreciated. I'll describe the way I've seen Blazar used and I
believe it's quite different than the above slot reservation as well as
spot instance support, but please let me know if I am incorrect or if
there have been other discussions about this use-case elsewhere:

A research group has a finite amount of specialized hardware and there
are more people wanting to use this hardware than what's currently
available. Let's use high performance GPUs as an example. The group is
OK with publishing the amount of hardware they have available (normally
this is hidden as best as possible). By doing this, a researcher can use
Blazar as sort of a community calendar, see that there are 3 GPU nodes
available for the week of April 3, and reserve them for that time period.

Yeah, I totally understand this use case.

However, implementing the above in any useful fashion requires that Blazar
be placed above Nova and essentially that the cloud operator turns off
access to Nova's POST /servers API call for regular users. Because if not,
the information that Blazar acts upon can be simply circumvented by any
user at any time.

In other words, your "3 GPU nodes available for the week of April 3" can
change at any time by a user that goes and launches instances that consumes
those 3 GPU nodes.

If you have a certain type of OpenStack deployment that isn't multi-user
and where the only thing that launches instances is an
automation/orchestration tool (in other words, an NFV MANO system), the
reservation concepts works great -- because you don't have pesky users that
can sidestep the system and actually launch instances that would impact
reserved consumables.

However, if you do have normal users of your cloud -- as most scientific
deployments must have -- then I'm afraid the only way to make this work is
to have users only use the Blazar API to reserve instances and
essentially shut off the normal Nova POST /servers API.

Does that make sense?

Ah, yes, indeed it does. Thanks, Jay.


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Apr 3, 2017 by Joe_Topjian (5,780 points)   1 4 7
0 votes

Hi Jay,

On 4 April 2017 at 00:20, Jay Pipes jaypipes@gmail.com wrote:
However, implementing the above in any useful fashion requires that Blazar
be placed above Nova and essentially that the cloud operator turns off
access to Nova's POST /servers API call for regular users. Because if not,
the information that Blazar acts upon can be simply circumvented by any user
at any time.

That's something of an oversimplification. A reservation system
outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses
this approach), and it's not much of a jump to imagine operators being
able to twiddle the available reserved capacity in a finite cloud so
that reserved capacity can be offered to the subset of users/projects
that need (or perhaps have paid for) it. Such a reservation system
would even be able to backfill capacity between reservations. At the
end of the reservation the system cleans-up any remaining instances
and preps for the next reservation.

The are a couple of problems with putting this outside of Nova though.
The main issue is that pre-emptible/spot type instances can't be
accommodated within the on-demand cloud capacity. You could have the
reservation system implementing this feature, but that would then put
other scheduling constraints on the cloud in order to be effective
(e.g., there would need to be automation changing the size of the
on-demand capacity so that the maximum pre-emptible capacity was
always available). The other issue (admittedly minor, but still a
consideration) is that it's another service - personally I'd love to
see Nova support these advanced use-cases directly.

--
Cheers,
~Blairo


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Apr 3, 2017 by Blair_Bethwaite (4,080 points)   1 3 5
0 votes

Hi!
Did someone mention automation changing the spot instance capacity? I did an article in 2013 that proposes exactly that. The model forecasts the workload curve of the majority traffic, which is presumed to be interactive, and the rest may be used for batch traffic. The forecast used is SARIMA and is usable up to a few days in advance. Would anybody be interested in trying the forecast on data from their cloud?
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.671.7397&rep=rep1&type=pdf¨
Tomas Vondra, dept. of Cybernetics, CTU FEE

-----Original Message-----
From: Blair Bethwaite [mailto:blair.bethwaite@gmail.com]
Sent: Tuesday, April 04, 2017 12:08 AM
To: Jay Pipes
Cc: openstack-oper.
Subject: Re: [Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

Hi Jay,

On 4 April 2017 at 00:20, Jay Pipes jaypipes@gmail.com wrote:
However, implementing the above in any useful fashion requires that
Blazar be placed above Nova and essentially that the cloud operator
turns off access to Nova's POST /servers API call for regular users.
Because if not, the information that Blazar acts upon can be simply
circumvented by any user at any time.

That's something of an oversimplification. A reservation system outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses this approach), and it's not much of a jump to imagine operators being able to twiddle the available reserved capacity in a finite cloud so that reserved capacity can be offered to the subset of users/projects that need (or perhaps have paid for) it. Such a reservation system would even be able to backfill capacity between reservations. At the end of the reservation the system cleans-up any remaining instances and preps for the next reservation.

The are a couple of problems with putting this outside of Nova though.
The main issue is that pre-emptible/spot type instances can't be accommodated within the on-demand cloud capacity. You could have the reservation system implementing this feature, but that would then put other scheduling constraints on the cloud in order to be effective (e.g., there would need to be automation changing the size of the on-demand capacity so that the maximum pre-emptible capacity was always available). The other issue (admittedly minor, but still a
consideration) is that it's another service - personally I'd love to see Nova support these advanced use-cases directly.

--
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
responded Apr 4, 2017 by vondra_at_homeatclou (780 points)  
0 votes

On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
Hi Jay,

On 4 April 2017 at 00:20, Jay Pipes jaypipes@gmail.com wrote:

However, implementing the above in any useful fashion requires that Blazar
be placed above Nova and essentially that the cloud operator turns off
access to Nova's POST /servers API call for regular users. Because if not,
the information that Blazar acts upon can be simply circumvented by any user
at any time.

That's something of an oversimplification. A reservation system
outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses
this approach), and it's not much of a jump to imagine operators being
able to twiddle the available reserved capacity in a finite cloud so
that reserved capacity can be offered to the subset of users/projects
that need (or perhaps have paid for) it.

Sure, I'm following you up until here.

Such a reservation system would even be able to backfill capacity
between reservations. At the end of the reservation the system
cleans-up any remaining instances and preps for the next
reservation.

By "backfill capacity between reservations", do you mean consume
resources on the compute hosts that are "reserved" by this paying
customer at some date in the future? i.e. Spot instances that can be
killed off as necessary by the reservation system to free resources to
meet its reservation schedule?

The are a couple of problems with putting this outside of Nova though.
The main issue is that pre-emptible/spot type instances can't be
accommodated within the on-demand cloud capacity.

Correct. The reservation system needs complete control over a subset of
resource providers to be used for these spot instances. It would be like
a hotel reservation system being used for a motel where cars could
simply pull up to a room with a vacant sign outside the door. The
reservation system would never be able to work on accurate data unless
some part of the motel's rooms were carved out for reservation system to
use and cars to not pull up and take.

You could have the
reservation system implementing this feature, but that would then put
other scheduling constraints on the cloud in order to be effective
(e.g., there would need to be automation changing the size of the
on-demand capacity so that the maximum pre-emptible capacity was
always available). The other issue (admittedly minor, but still a
consideration) is that it's another service - personally I'd love to
see Nova support these advanced use-cases directly.

Welcome to the world of microservices. :)

-jay


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Apr 4, 2017 by Jay_Pipes (59,760 points)   3 10 14
0 votes

Some combination of spot/OPIE and Blazar would seem doable as long as the resource provider reserves capacity appropriately (i.e. spot resources>>blazar committed along with no non-spot requests for the same aggregate).

Is this feasible?

Tim

On 04.04.17, 19:21, "Jay Pipes" jaypipes@gmail.com wrote:

On 04/03/2017 06:07 PM, Blair Bethwaite wrote:

Hi Jay,

On 4 April 2017 at 00:20, Jay Pipes jaypipes@gmail.com wrote:

However, implementing the above in any useful fashion requires that Blazar
be placed above Nova and essentially that the cloud operator turns off
access to Nova's POST /servers API call for regular users. Because if not,
the information that Blazar acts upon can be simply circumvented by any user
at any time.

That's something of an oversimplification. A reservation system
outside of Nova could manipulate Nova host-aggregates to "cordon off"
infrastructure from on-demand access (I believe Blazar already uses
this approach), and it's not much of a jump to imagine operators being
able to twiddle the available reserved capacity in a finite cloud so
that reserved capacity can be offered to the subset of users/projects
that need (or perhaps have paid for) it.

Sure, I'm following you up until here.
> Such a reservation system would even be able to backfill capacity
> between reservations. At the end of the reservation the system
> cleans-up any remaining instances and preps for the next
> reservation.
By "backfill capacity between reservations", do you mean consume 
resources on the compute hosts that are "reserved" by this paying 
customer at some date in the future? i.e. Spot instances that can be 
killed off as necessary by the reservation system to free resources to 
meet its reservation schedule?
> The are a couple of problems with putting this outside of Nova though.
> The main issue is that pre-emptible/spot type instances can't be
> accommodated within the on-demand cloud capacity.
Correct. The reservation system needs complete control over a subset of 
resource providers to be used for these spot instances. It would be like 
a hotel reservation system being used for a motel where cars could 
simply pull up to a room with a vacant sign outside the door. The 
reservation system would never be able to work on accurate data unless 
some part of the motel's rooms were carved out for reservation system to 
use and cars to not pull up and take.
 >  You could have the
> reservation system implementing this feature, but that would then put
> other scheduling constraints on the cloud in order to be effective
> (e.g., there would need to be automation changing the size of the
> on-demand capacity so that the maximum pre-emptible capacity was
> always available). The other issue (admittedly minor, but still a
> consideration) is that it's another service - personally I'd love to
> see Nova support these advanced use-cases directly.
Welcome to the world of microservices. :)

-jay

_______________________________________________
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
responded Apr 4, 2017 by Tim_Bell (16,440 points)   1 5 10
0 votes

On 04/04/2017 02:48 PM, Tim Bell wrote:
Some combination of spot/OPIE

What is OPIE?

and Blazar would seem doable as long as the resource provider
reserves capacity appropriately (i.e. spot resources>>blazar
committed along with no non-spot requests for the same aggregate).
Is this feasible?

I'm not sure how the above is different from the constraints I mention
below about having separate sets of resource providers for preemptible
instances than for non-preemptible instances?

Best,
-jay

Tim

On 04.04.17, 19:21, "Jay Pipes" jaypipes@gmail.com wrote:

On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
> Hi Jay,
>
> On 4 April 2017 at 00:20, Jay Pipes <jaypipes@gmail.com> wrote:
>> However, implementing the above in any useful fashion requires that Blazar
>> be placed *above* Nova and essentially that the cloud operator turns off
>> access to Nova's  POST /servers API call for regular users. Because if not,
>> the information that Blazar acts upon can be simply circumvented by any user
>> at any time.
>
> That's something of an oversimplification. A reservation system
> outside of Nova could manipulate Nova host-aggregates to "cordon off"
> infrastructure from on-demand access (I believe Blazar already uses
> this approach), and it's not much of a jump to imagine operators being
> able to twiddle the available reserved capacity in a finite cloud so
> that reserved capacity can be offered to the subset of users/projects
> that need (or perhaps have paid for) it.

Sure, I'm following you up until here.

> Such a reservation system would even be able to backfill capacity
> between reservations. At the end of the reservation the system
> cleans-up any remaining instances and preps for the next
> reservation.

By "backfill capacity between reservations", do you mean consume
resources on the compute hosts that are "reserved" by this paying
customer at some date in the future? i.e. Spot instances that can be
killed off as necessary by the reservation system to free resources to
meet its reservation schedule?

> The are a couple of problems with putting this outside of Nova though.
> The main issue is that pre-emptible/spot type instances can't be
> accommodated within the on-demand cloud capacity.

Correct. The reservation system needs complete control over a subset of
resource providers to be used for these spot instances. It would be like
a hotel reservation system being used for a motel where cars could
simply pull up to a room with a vacant sign outside the door. The
reservation system would never be able to work on accurate data unless
some part of the motel's rooms were carved out for reservation system to
use and cars to not pull up and take.

 >  You could have the
> reservation system implementing this feature, but that would then put
> other scheduling constraints on the cloud in order to be effective
> (e.g., there would need to be automation changing the size of the
> on-demand capacity so that the maximum pre-emptible capacity was
> always available). The other issue (admittedly minor, but still a
> consideration) is that it's another service - personally I'd love to
> see Nova support these advanced use-cases directly.

Welcome to the world of microservices. :)

-jay

_______________________________________________
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
responded Apr 4, 2017 by Jay_Pipes (59,760 points)   3 10 14
...