Actions :: UUID vs. Tag on command line

[Gustavo Niemeyer]

I doubt this would work. There's no way in the transaction package for you
to generate an id and reference that same id in other fields in one go.

In other cases that's not an issue, but having a sequence of numbered
actions where 10 is applied before 9 would be awkward.


On Fri Oct 24 2014 at 4:10:30 PM John Weldon <johnweldon4 at gmail.com> wrote:

> That's a good question; The sequence relies on the same mechanism in state
> that is used to generate other sequences.  I believe it's done in a
> transaction using the provided key (in this case the id of the unit).
>
> Cheers,
>
> --
> John Weldon
>
> On Fri, Oct 24, 2014 at 11:07 AM, Gustavo Niemeyer <
> gustavo.niemeyer at canonical.com> wrote:
>
>> That might be okay, but is the sequence really respected?  In other
>> words, what happens if two independent clients attempt to submit an action
>> for the same service? Will the two generated sequences reflect the order in
>> which the actions are submitted to the units at the end of the pipeline?
>>
>>
>> On Fri Oct 24 2014 at 4:05:03 PM John Weldon <johnweldon4 at gmail.com>
>> wrote:
>>
>>> Sure, that makes sense.  Right now the Tag encodes a legitimate
>>> sequence.  We should probably just clean up the representation so it
>>> doesn't expose the internals and just exposes the unit and action sequence
>>> number.
>>>
>>>
>>> --
>>> John Weldon
>>>
>>> On Fri, Oct 24, 2014 at 10:58 AM, Gustavo Niemeyer <
>>> gustavo.niemeyer at canonical.com> wrote:
>>>
>>>> It was my mistake to call it a hash.. it may be just a random id, in
>>>> hex form. Alternatively, use a service-specific sequence number so it's
>>>> better suited to humans. In the latter case, the sequence number must
>>>> realistically reflect the sequence in which the actions are submitted to
>>>> units, otherwise it would be confusing.
>>>>
>>>> On Fri Oct 24 2014 at 3:51:04 PM John Weldon <johnweldon4 at gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Gustavo;
>>>>>
>>>>> I think a hash would be good too.  I'll see what I can find in the
>>>>> juju code base around hash representations of id's, or come up with
>>>>> something.
>>>>> Any suggestions on how to generate and translate the hash are welcome
>>>>> too.
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>> --
>>>>> John Weldon
>>>>>
>>>>> On Fri, Oct 24, 2014 at 10:41 AM, Gustavo Niemeyer <
>>>>> gustavo.niemeyer at canonical.com> wrote:
>>>>>
>>>>>> The "tag" (which might be better named "internal id") looks like an
>>>>>> implementation detail which doesn't seem right to expose. I'd suggest
>>>>>> either giving it a proper representation that the user can understand (a
>>>>>> sequential action number, for example), or use a hash. I'd also not use a
>>>>>> UUID, btw, but rather just a unique hash.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri Oct 24 2014 at 2:55:45 PM John Weldon <johnweldon4 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi;
>>>>>>>
>>>>>>> The current actions spec
>>>>>>> <https://docs.google.com/a/canonical.com/document/d/14W1-QqB1pXZxyZW5QzFFoDwxxeQXBUzgj8IUkLId6cc/edit?usp=sharing>
>>>>>>> indicates that the actions command line should return a UUID as the
>>>>>>> identifier for an action once it's been en-queued using 'juju do <action>'.
>>>>>>>
>>>>>>>
>>>>>>> Is there a compelling reason to use UUID's to identify actions,
>>>>>>> versus using the string representation of the Tag?
>>>>>>>
>>>>>>>
>>>>>>> A UUID would require a command something like:
>>>>>>>   juju status action:9e1e5aa0-5b9d-11e4-8ed6-0800200c9a66
>>>>>>>
>>>>>>> which maybe we could shorten to:
>>>>>>>   juju status action:9e1e5aa0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would prefer something like:
>>>>>>>   juju status action:mysq/0_a_3
>>>>>>>
>>>>>>> which would be the string representation of the actions Tag.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is there a compelling reason to use UUID?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> --
>>>>>>> John Weldon
>>>>>>>  --
>>>>>>> Juju-dev mailing list
>>>>>>> Juju-dev at lists.ubuntu.com
>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>>>>>> mailman/listinfo/juju-dev
>>>>>>>
>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141024/5613dd5b/attachment.html>