openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Feb 16, 2011 at 12:16 PM, Ed Leafe <ed@xxxxxxxxx> wrote:
> On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:
>>>        Isn't the instance name usually supplied by the user/originator?
>>
>> [Sorry, yes the instance name is passed in on the request, but the instance ID is what's needed (assuming of course instance ID is unique across zones.)]
>
>        The ID is determined early in the process; well before the request to create an instance is cast onto the queue, and is returned immediately.

The instance ID is constructed in nova.compute.api.API.create(), which
is called by nova.api.openstack.servers.Controller.create().

AFAICT, Sandy is referring to actions that must happen *before* the
instance is created in the database, no? I mean, the top-level API
node receives a request containing a number of requirements for the
creation of an instance. One of those requirements may be a zone, or a
set of policy attributes for the zone that the eventual instance will
be created in.

In other words, Sandy needs to find an appropriate zone to place an
instance in. Clearly, this logic must happen before the instance is
created in the database.

>>>>   Q2. If I do "instance-list", do I have to search all zones again?
>>>
>>>        If the db is not centralized/replicated, yes. Caching could certainly be an option, especially in situations where instances tend to persist for long periods.
>>
>> [The db is not centralized. One per Zone.]
>
>        I know that. I'm just stating that this is a natural consequence of the decision not to use a centralized db.

The data set queried in the database used for a zone only contains
information necessary for the scheduler workers in that zone to make a
decision, and nothing more.

>>>> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query operations.
>>>
>>>        I don't really like this approach. It requires the requester to know too much about the implementation of the service: e.g, that there are zones, and that an instance will be placed in a particular zone. I would prefer something more along the lines of:
>>>
>>> a. User issues a create-instance request, supplying the name of the instance to be created.
>>> b. The top-level zone that receives the request does a zone-best-match and/or host-best-match call to determine where the instance will be created.
>>> c. The top-level zone then passes the create-instance request to the selected zone/host.

Why are we assuming a requester doesn't know much about the
implementation of the service? I mean, the requester is going to be an
application like the Cloud Servers console, not just some random user.
 Of course the requester knows something about the implementation of
the service, and if they don't, the work Sandy did in the first phase
of this blueprint allows the requester to query the admin API for
information about the zones...

>> [But what about subsequent actions ... the same zone-search would have be performed for each of them, no?]
>
>
>        This was one of the issues we discussed during the sprint planning. I believe (check with cyn) that the consensus was to use a caching strategy akin to DNS: e.g., if zone A got a request for instance ID=12345, it would check to see if it had id 12345 in its cache. If not, it would ask all of its child nodes if they knew about that instance. That would repeat until the instance was found, at which point every upstream server would now know about where to reach 12345.

Agreed. Each "level" or zone in the overall architecture would cache
(in our case, cache means a record in the zone's database) information
about its subordinate nodes (nodes being instances or other zones,
depending on the "level" of the zone in the overall architecture).

So, just like DNS.

-jay