Actions :: UUID vs. Tag on command line

Hi; The current actions spec 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 '. Is there a compe

Re: Actions :: UUID vs. Tag on command line

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

Re: Actions :: UUID vs. Tag on command line

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,

Re: Actions :: UUID vs. Tag on command line

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

Re: Actions :: UUID vs. Tag on command line

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

Re: Actions :: UUID vs. Tag on command line

On Fri, Oct 24, 2014 at 8:04 PM, John Weldon 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. Yeah, that works for me.

Re: Actions :: UUID vs. Tag on command line

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:

Re: Actions :: UUID vs. Tag on command line

As a side note, and a bikeshed-prone rant which I won't embrace, naming it "tag" feels like a mistake. On Fri Oct 24 2014 at 4:13:14 PM William Reade wrote: > On Fri, Oct 24, 2014 at 8:04 PM, John Weldon > wrote: > > Sure, that makes sense. Right now the Tag encodes a legitimate sequence. > >

Fwd: Actions :: UUID vs. Tag on command line

Forgot to reply-all -- Forwarded message -- From: John Weldon Date: Fri, Oct 24, 2014 at 11:19 AM Subject: Re: Actions :: UUID vs. Tag on command line To: Gustavo Niemeyer On Fri, Oct 24, 2014 at 11:14 AM, Gustavo Niemeyer < gustavo.nieme...@canonical.com> wrote: >

Re: Actions :: UUID vs. Tag on command line

y the numbers. On Fri Oct 24 2014 at 4:21:30 PM John Weldon wrote: > Forgot to reply-all > > -- Forwarded message -- > From: John Weldon > Date: Fri, Oct 24, 2014 at 11:19 AM > Subject: Re: Actions :: UUID vs. Tag on command line > To: Gustavo Niemeyer > >

Re: Actions :: UUID vs. Tag on command line

On Fri, Oct 24, 2014 at 11:23 AM, Gustavo Niemeyer wrote: > Both of these assumptions are incorrect. Please do not assume there's a > single person managing an environment, and the fact the sequence is > generated outside of the transaction that adds the action is a proof that > actions will be a

Re: Actions :: UUID vs. Tag on command line

On Fri Oct 24 2014 at 4:30:38 PM John Weldon wrote: > Ordered execution wasn't addressed in the spec, and we haven't had much > discussion about it. > I'm not even sure how to enforce ordered execution unless we rely on the > creation timestamp. > Specifications are guidelines. If there are open

Re: Actions :: UUID vs. Tag on command line

Agreed completely; My take away - 1. Actions en-queued by the same client MUST execute in the order en-queued. 2. Actions en-queued by different clients SHOULD execute in timestamp order? 3. Action IDs should not mislead users by implying sequence that does not exist. 4. ergo Action id's will pro

Re: Actions :: UUID vs. Tag on command line

For 2, it doesn't matter much if the timestamp is taken into account. The server may simply enqueue the action as it receives it and respond back only afterwards. This will guarantee read-your-writes consistency, and thus proper ordering assuming the server does use a queue rather than an unordered

Re: Actions :: UUID vs. Tag on command line

Hmm; makes sense, but this will require some refactoring, because the watcher collects and returns the id's of new actions as an unordered set, as it stands today. I'll start working on this. -- John Weldon On Fri, Oct 24, 2014 at 11:48 AM, Gustavo Niemeyer wrote: > For 2, it doesn't matter mu

Re: Actions :: UUID vs. Tag on command line

That feels like a pretty relevant bug. Glad we talked about it. On Fri Oct 24 2014 at 4:56:26 PM John Weldon wrote: > Hmm; makes sense, but this will require some refactoring, because the > watcher collects and returns the id's of new actions as an unordered set, > as it stands today. > > I'll s