Rundeck Rundeck Development → Rundeck 1.3

Comments and changes to this ticket

• 

  Greg Schueler June 10th, 2011 @ 06:18 PM

  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?

• You flagged this item as spam.
  

  Deleted User June 10th, 2011 @ 07:18 PM

  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:

• 

  Greg Schueler June 14th, 2011 @ 11:25 AM

  • State changed from “new” to “open”
  • Assigned user set to “Greg Schueler”

  Ok, here are a few cases i'd like feedback on:

  1. If your job def contains extID, and you upload to rundeck but no extID matches, does it fall back on the group+name+project matching to identify duplicate jobs, or is this matching no longer used?

  2. how should xml/yaml formats look? is "extid" a good name?... e.g. <job> <extid>myid</extid>...</job>

  3. if your extID matches, it should change name,group & project for the job that matches, correct?

  4. are extIDs to be used for e.g. API access, CLI tool "run -i ", etc?

  5. should all jobs be given a random/generated extID?

  6. if the extID field is freeform (that is, user-specified), what if you want to change the extID? would that require deleting the existing job and uploading the new job definition? or would it require modifying the extID via the GUI?

  there may be more questions later...

• You flagged this item as spam.
  

  Deleted User June 14th, 2011 @ 12:13 PM

  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.

• 

  Greg Schueler June 22nd, 2011 @ 12:29 PM

  Addressing #4, 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

• 

  Greg Schueler June 22nd, 2011 @ 02:19 PM

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

• 

  Greg Schueler June 22nd, 2011 @ 03:17 PM

  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) ?

• 

  Greg Schueler June 22nd, 2011 @ 04:04 PM

  • 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?)

• You flagged this item as spam.
  

  Deleted User June 23rd, 2011 @ 09:34 AM

  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 :)

• 

  Greg Schueler June 23rd, 2011 @ 09:38 AM

  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'

• You flagged this item as spam.
  

  Charles Scott June 23rd, 2011 @ 09:47 AM

  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

• You flagged this item as spam.
  

  Deleted User June 23rd, 2011 @ 10:08 AM

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

• 

  Greg Schueler June 23rd, 2011 @ 10:48 AM

  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

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

• 

  Greg Schueler June 23rd, 2011 @ 11:17 AM

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

• You flagged this item as spam.
  

  Deleted User June 23rd, 2011 @ 11:40 AM

  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.

• You flagged this item as spam.
  

  Deleted User June 23rd, 2011 @ 12:15 PM

  • State changed from “open” to “needs_verification”

  (from [08baf91644549fe7bb1330f51ecf0cec55df78b5]) Initial UUID support [#332 state:needs_verification] https://github.com/dtolabs/rundeck/commit/08baf91644549fe7bb1330f51...

• You flagged this item as spam.
  

  Deleted User June 24th, 2011 @ 01:27 PM

  (from [9db75112106f58a3cb8e9865c6239e4b8698dee3]) CLI tool fixes [#332] [#274] https://github.com/dtolabs/rundeck/commit/9db75112106f58a3cb8e9865c...

• 

  Alex-SF July 8th, 2011 @ 11:37 AM

  • State changed from “needs_verification” to “open”

  If an existing ticket (ie, pre UUID) is imported the job editor should present the UUID textfield (like it does for job create) enabling a user to create the UUID value.

• You flagged this item as spam.
  

  Deleted User July 8th, 2011 @ 02:23 PM

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

• You flagged this item as spam.
  

  Deleted User July 8th, 2011 @ 03:33 PM

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

• 

  Alex-SF July 8th, 2011 @ 04:11 PM

  • State changed from “open” to “resolved”
  • Milestone order changed from “44” to “0”

  Pre-1.3/existing jobs now allow a UUID to be added.