On 01/11/2011 08:28 AM, Dmitri Pal wrote:
Perry Myers wrote:
> On 01/10/2011 10:40 AM, Carl Trieloff wrote:
>
>> On 01/07/2011 11:26 AM, Perry Myers wrote:
>>
>>> On 01/06/2011 12:12 PM, Carl Trieloff wrote:
>>>
>>>> On 01/05/2011 06:27 PM, Andrew Beekhof wrote:
>>>>
>>>>> On Wed, Jan 5, 2011 at 11:24 PM, Carl
>>>>> Trieloff<cctrieloff(a)redhat.com> wrote:
>>>>>
>>>>>>> On 01/05/2011 04:24 PM, Andrew Beekhof wrote:
>>>>>>>
>>>>>>>>> 4) wait for someone to call one of our methods:
update_config
>>>>>>>>> and
>>>>>>>>> possibly erase_config
>>>>>>>>>
>>>>>>> This is part of the problem, we don't know the IP or
address of
>>>>>>> the agent,
>>>>>>>
>>>>> Why would we need to?
>>>>> The console now has the UUID, it can query for a Postboot object
with
>>>>> that value.
>>>>>
>>>>> Or are you saying that the IP is needed to generate the xml_config?
>>>>> In that case we can include it in the event (or add it back to the
>>>>> Postboot object).
>>>>>
>>>>>
>>>> It might be worth looking at the design mail I sent to the list
>>>> originally.
>>>>
>>>> Note that the UUID I'm using here has nothing to do with machine
>>>> identity. It is
>>>> an ID that is generated by the remote configuration to be able to
>>>> identify a
>>>> configuration to be sent to the machine. We can only use a single
>>>> UUID if we
>>>> set the machine's UUID to the one passed in for config. I did not
want
>>>> to make
>>>> this assumption as that would mess with some of the other Matahari work,
>>>> but
>>>> if we can/want to do that it is a minor tweak.
>>>>
>>>> I.e generic sequence is basically.
>>>>
>>>> - request an instance to launch - generic image and pass UUID on launch.
>>>> - now, based on that UUID, pull my TAD and incarnate the specific config
>>>> based on the UUID (config definition)
>>>> - return the IP, params etc generically to the requester.
>>>>
>>> Right, but as Andrew has pointed out there is an alternate flow here
>>> that keeps consistent with the general architecture of Matahari being
>>> only Agents on the guests.
>>>
>>> - request a new instance to launch - generic image and pass UUID on
>>> launch
>>> - guest sends a 'firstboot event' out to the qpid bus which contains
the
>>> UUID
>>> - Console server listening for firstboot events sees the event and
>>> incarnates the specific config based on the UUID (config definition)
>>> - Console server knows the host object that sent out the event, since
>>> that would be provided by the QMF infrastructure
>>> - Console server (if it needs it) can get the IP address of the guest by
>>> simply calling the standard API function on the Network Agent on the
>>> guest in question.
>>> - Console server calls config function on the QMF object that sent out
>>> the event, providing as one of the arguments the config definition
>>>
>>> This provides the exact same semantics as your flow, and doesn't make
>>> the config/post-boot inclusion into matahari break the notion that
>>> "All Matahari has are dumb agents that send out events and have
>>> functions to call"
>>>
>>> It also maintains the notion that the external 'servers' are all QMF
>>> Consoles.
>>>
>>> So this is how we'll implement this flow. Please rework your patches
>>> to follow this architectural model, and then we will get them
>>> committed to the git tree.
>>>
>>> Thanks,
>>>
>>> Perry
>>>
>> we had discussed that on an earlier thread when I posted the initial
>> design.
>>
>> Questions is, what is better,
>>
>> a.) Broadcasting my UUID& IP& secrete
>> or,
>> b.) Directly addressing my UUID& IP
>>
> How is it a broadcast if you're sending an event, and the ONLY Consoles
> that have access to receive events on the bus are those that have the
> right credentials to access them?
>
> The whole premise of Matahari is that you give every guest auth
> credentials to act as an Agent, but you restrict Console connections to
> only those places that are trusted: i.e. the QMF Console running as a
> cache or as part of the Aeolus infrastructure. So you're not broadcasting
> your UUID and IP address, you're directing it to a set of trusted consoles.
>
> And why are we still discussing IP here? Please re-read the above flow.
> The IP address doesn't need to be sent as part of the initial event. In
> fact, neither does the UUID or secret.
>
> The initial event can be just a 'here I am!' event. Then the QMF console
> receiving that event can directly call a method on the same QMF object
> that sent the event, to request the IP address, secret and UUID. No need
> to put any of that in an event at all.
>
> Please differentiate the following for me:
> 1. guest runs a console which calls a function on the remote agent which
> acts as a cache
> 2. guest runs an agent which sends out an "I'm alive" event which
> triggers the cache (running as a remote console) to then call a
> function on the agent which sent the event
>
> Both mechanisms provide the same security and level of information
> distribution. One breaks the Matahari model of only having Agents, the
> other does not.
>
> Perry
>
I agree with Perry but AFAIU the first "I'm alive" will already be done
over the kerberos authenticated channel (see the whole bootstrapping
sequence I created slides last week) so there is no need to pass
anything else other than UUID.
So the message will be something like : "Here is agent with UUID=X, I am
ready to get what you have for me."
Matahari has two premises.
a.) only server.
b.) no control calls to the server, only instrumentation data out,
affects no changes.
The above flow breaks (b). Unfortunately, fundamentally to make the use
case work work we need
to break either a or b. take your pick --
Having a cache call every instance is breaking (b) {enacting a change} I
fundamentally believe
is less scalable and the worse option. Given it is already kerb
authenticated, and in it's domain-ed
I don't see the advantage of switching the flow. I may be wrong, but I
don't see it. However, as I
have said if we want to it, it is trivial to do so and does not affect
the higher layer that will use the service.
To make the above flow robust it would need to b more like this...
add
{
- call pre-register on the cache with UUID and config.
}
- request a new instance to launch - generic image and pass UUID on
launch
{& secrete for Kerb -- needed for kerb }
- guest sends a 'firstboot event' out to the qpid bus which contains the
UUID
{This event would either need to be persistent, with ttl, or would need
to be resent at an interval with ttl until state change occurs}
- Console server listening for firstboot events sees the event and
incarnates the specific config based on the UUID (config definition)
{
I don't understand this statement.
More like -- get first boot event, and call the node with config being passed in
which is later in flow (three points down)
}
- Console server knows the host object that sent out the event, since
that would be provided by the QMF infrastructure
- Console server (if it needs it) can get the IP address of the guest by
simply calling the standard API function on the Network Agent on the
guest in question.
{Not sure about this this, as in some clouds there could be more than on interface,
some are private to the cloud, and some public. The point of adding the IP in this
service
is so that we can say, use 'this' interface so that we hide the logic of which IP
to use
from any of the other layers that use the server.
I think we should make is stupidly simple and hide any cloud differences.
}
- Console server calls config function on the QMF object that sent out
the event, providing as one of the arguments the config definition
{
This is the step I'm move concerns about, as the cache now needs to
active in starting each server, In the flow I implemented the cache is
entirely passive.
The main difference is that with the passive approach the cache is symmetrical
and fully federated. the cache can live inside EC2 for example or just have
a federated broker in EC2, and be federated back to a DMZ if needed. We could
probably still do this with the cache being active
}
add
-- now send status events back with IP.
add
-- update cache with status and IP.
So flow in summary
1.--call pre-register on the cache with UUID and config.
2.--request a new instance to launch - generic image and pass UUID &
secrete on launch
3.--issue first boot events back to cache (until I get called back)
4.--call instance with config update
5.--issue status updates back to cache with status and IP.
6.--update cache.
Step (4) violates no control calls to the server, only instrumentation
data out, affect no changes on host
The current impl.
1.--call pre-register on the cache with UUID and config.
2.--request a new instance to launch - generic image and pass UUID &
secrete on launch
3.--instance looks up config from cache with UUID
4.--instance issues status updates back to cache with status and IP.
5.--update cache.
Step (3) violates no use of console API in the service.
Note that in the first flow, the instance is creating an event with the
cache then uses to call
the cache back on. So in basically is it just using 3 messages to create
an RPC call where
where the current impl uses 2. Fundamentally the security of the two
flows is exactly the
same.
Carl.