On Tue, Sep 22, 2009 at 10:29 AM, Iustin Pop <[email protected]> wrote:
> On Tue, Sep 22, 2009 at 10:24:23AM +0100, Guido Trotter wrote:
>> On Tue, Sep 22, 2009 at 10:19 AM, Iustin Pop <[email protected]> wrote:
>> >
>> > On Tue, Sep 22, 2009 at 10:09:30AM +0100, Michael Hanselmann wrote:
>> >> 2009/9/22 Iustin Pop <[email protected]>:
>> >> > Here's the interdiff (with a realisation that an FQDN cannot be an 
>> >> > UUID, so no
>> >> > issue about namespace conflicts):
>> >>
>> >> Except that Ganeti allows the user to specify only the part before the
>> >> first, second, third, etc dot. Anyway LGTM.
>> >
>> > Hmm... I was only thinking about RAPI, and I was under the wrong 
>> > impression it
>> > requires FQDNs.
>> >
>> > Hmm, we are under the same issue as having two instances, one named
>> > instance1.example and the other instance1.example.com, which ganeti allows 
>> > at
>> > create time but it completely breaks:
>> >
>> >>>> from ganeti.utils import MatchNameComponent
>> >>>> MatchNameComponent("a", ["a", "a.b"])
>> >>>> MatchNameComponent("a.b", ["a", "a.b"])
>> > 'a.b'
>> >
>>
>> Does it break? It seems to be the correct behavior! (if you can't
>> decide which one is it, decide there is no match).
>
> No, it's not the correct behaviour (IMHO). "a" is a full match for "a",
> but here it fails.
>

Ah, yeah, true, it is! If it would be a.b and a.c it wouldn't! Sorry,
was confused! :)

>> > So here we would: a) ignore it the same way we ignore today's breakage, or 
>> > b)
>> > fix MatchNameComponent at which point the UUID (by itself) would select the
>> > UUID and the UUID.domain would select the instance.
>> >
>>
>> Well, then we don't need to touch MatchNameComponent (as uuid lookup
>> would probably come first, and only if there is no match we could move
>> to matching).
>
> No, we always pass things through MatchNameCompoent (via Expand*Name).
> So unless we fix MatchNameComponent, we need to short-cut it.
>

But currently we only can pass in a name. We could change it that if
there is an exact match (name nowadays, since the object are called by
name, and UUID in the future) there's no need for matching!

> The reason I didn't propose this is because then we have to interpret
> instance names (i.e. split them and warn if the first component up to a
> dot is an UUID), which we don't do today. I would just fix
> MatchNameComponent and add this as a warning to the admin guide.

Or just have a name_starts_with_uuid regexp that matches UUID_PATTERN.*
We don't do it today but it would be easy enough, wouldn't it?

Thanks,

Guido

Reply via email to