Job definitions should support an external ID

what is the purpose of the external ids? and how does the internal ID not suffice?

i.e. what is the desired effect that isn't working right now?

Internal ids are not portable between instances.

Sent from my iPhone

On Jun 10, 2011, at 6:18 PM, "Lighthouse" <no-reply@lighthouseapp.com>
wrote:

1. In my opinion no, but I could go either way.

2. uuid

3. Yes

4. That would be awesome

5. Yeah. UUID would be perfect.

6. Delete and upload the new job definition. If the GUI provides the ability to change it, it should do the same underneath.

Addressing #4 Allow tags to be modified on resources, there could be a conflict if a job's UUID looks like an internal ID (ie. a valid long integer)

I'm going to implement this such that it tries to find the internal ID if it is a valid long integer prior to finding a UUID, but it could be the other way around.

alternately, it could be an error if it finds both

otherwise, we can restrict uuid strings so they can't look like simple integers

i think item 6 needs more consideration.

what if we just allow uuid changing in the GUI with some warning text? is there a reason the gui would have to "do the same underneath" (delete the job and create a new copy) ?

• Should the UUID be exposed in place of "id" in e.g. API results, links to job pages, logging, etc.?

• how should it be shown in the GUI on job/exec view pages? (i guess a bit like old Mapref URIs were shown for objects?)

I like that UUID be exposed in place of the "id"

I'm not sure how Mapref URI were shown. Take a stab at it...I'm sure those in the cheap seats will have their opinions :)

So would that mean that job.xml/yaml would not have a 'uuid' entry, instead use the uuid as 'id'? this seems slightly odd...

maybe we should deprecate/remove the 'id' from job definitions, and only support 'uuid'

Is the end goal here to make sure that there is a user friendly way to reference a job w/o being burdened with an id number? For example:

i do not send e-mail to:

foobar@[74.125.224.151]

I would rather send it to:

foobar@gmail.com

I think this analogy holds with respect to referring to another job from an api consumer outside of rundeck or internally with respect to a jobref.

I think the only thing one should worry about is a path that make the job unique which I believe are:

project/group/name

"maybe we should deprecate/remove the 'id' from job definitions, and only support 'uuid'" +1

chuck: yes it ties into Job ref, as well as unique project/group/name. With UUID I think we could change the way Job Refs work so they use UUID instead of name/group.

it also is not very useful I think to allow duplicate name/group, this is already filed as an issue #267 enforce unique job name & group for jobs within a project

the intent of UUID is universal identifier which will function across RunDeck servers as well

ok i have changed exported job defs to include uuid only (if it is set)

also, current implementation just doesn't allow changing UUID of a job once it is set...

I can live with that constraint of not changing a UUID once it's set. Lets see if folks need that ability to change it.

(from [9db75112106f58a3cb8e9865c6239e4b8698dee3]) CLI tool fixes [#332 Job definitions should support an external ID] [#274 upgrade CLI tools to use webapi v1] https://github.com/dtolabs/rundeck/commit/9db75112106f58a3cb8e9865c...

(from [ce03212ffa19f7f2f896b22dd74794e623471550]) Use uuid in place of id in more places (redirects, options logging, execution data context) [#332 Job definitions should support an external ID] https://github.com/dtolabs/rundeck/commit/ce03212ffa19f7f2f896b22dd...

(from [669b46bcee4aff394dfd4eacb5b56ae9c5cafd9d]) UUID can be set during job edit for existing jobs. internal ID logged in job changes log [#332 Job definitions should support an external ID] https://github.com/dtolabs/rundeck/commit/669b46bcee4aff394dfd4eacb...