Open Stack

Hi all,

I'm late to the discussion.

Some of members in Blazar's team have an interest from NFV side for the 
resource reservation.  So we have one usecase that telecom operators 
want to reserve instance slots at a specific time window because of 
expected workload increasing.

I'm thinking the challenge of current Blazar is how to realize two 
demands, one from scientific group and another from NFV, for the 
resource reservation.

On 2017/04/05 2:21, Jay Pipes wrote:
 > On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
 >> Hi Jay,
 >>
 >> On 4 April 2017 at 00:20, Jay Pipes <jaypipes at 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.
I agree the reservation system looks like hotel reservation system. But 
Blazar provides a reservation system like a block reservation. Operators 
defines a pool used for the future reservation requests. Then they give 
id or something to an user when the user requests a reservation. The 
user creates their resource with the id and it could be located inside 
of the block reservation only if the user consumes the reservation in 
the specified time window.

Of course, as you mentioned above, regular users could creates a 
resource and it could violate the reservation assumptions.  IIRC, 
however, same situation could happen in other projects, for instance 
Heat's stack.

What Blazar does is creating/configuring aggregations or other things 
that drive resources of regular users to be scheduled to outside of the 
block reservation.  Or regular users can create their resources with a 
special flag and the resources could be located inside of the block 
reservation. But operators can't ensure the resources remains until the 
users say 'delete the resources' because Blazar could clean-up the 
resources before others reservation starts.

 >
 >>  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

best regards,
Masahito