Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Add node state attribute to resource model definition

#34

Define an attribute for the Node type that represents if the Node is "active" and therefore commands can be executed on it. Optionally, an attribute can be defined to represent other states a system can hold (active, parked, allocated, free, decommissioned, etc.)

Reported by Alex-SF · October 11th, 2010 @ 02:21 PM

State: resolved
Milestone: Rundeck 1.3
Assigned to: nobody

Activity

  1. Alex-SF
    Alex-SF
    • Milestone changed from Rundeck 1.0 to Rundeck 1.1
    • Milestone order changed from 6 to 0

    November 2nd, 2010 @ 03:20 PM

  2. Alex-SF
    Alex-SF
    • Milestone cleared.
    • Milestone order changed from 1 to 0

    December 17th, 2010 @ 08:22 AM

  3. Alex-SF
    Alex-SF
    • Milestone set to Rundeck 1.2
    • Milestone order changed from 12 to 0

    January 14th, 2011 @ 07:27 AM

  4. Alex-SF
    Alex-SF
    • Milestone changed from Rundeck 1.2 to Rundeck 1.3
    • Milestone order changed from 1 to 0

    February 1st, 2011 @ 11:46 AM

  5. Greg Schueler
    Greg Schueler
    • Milestone order changed from 5 to 0

    What name should this attribute have? "active"? or should we combine it with "state"?

    The new plugin system/service architecture will make this easy to implement. The question is what should happen when...

    e.g.:

    if node attribute "active" has value "false" then: skip over the node completely and echo a message that the node has been skipped.

    Is this the desired behavior?

    April 20th, 2011 @ 10:00 AM

  6. Deleted User
    Deleted User

    Why not punt on having rundeck do anything with the information? Just make sure it's passed to the dispatcher plugin and let it decide.

    April 20th, 2011 @ 10:08 AM

  7. Greg Schueler
    Greg Schueler

    Well, I think this would be implemented at a higher level than the Node Executor (at the Command interpreter level). This would intercept any workflow command (script, exec, etc).

    It also might be inconsistent/not applied depending on the particular node executor/file copier you are using. I think if we want to add this feature it should work consistently.

    Better to bake this in at the higher level so it is reliable, (at least for the active/inactive behavior.)

    Either way the same question then arises for our built in SSH/SCP implementations: what should the attribute be and what should the behavior be?

    April 20th, 2011 @ 10:24 AM

  8. Deleted User
    Deleted User

    I don't think this ticket is about acting on the data...open another ticket for that feature. Just allow the ability to put it in the resource.xml and pass it along so it can be acted upon.

    April 20th, 2011 @ 02:59 PM

  9. Greg Schueler
    Greg Schueler

    in that case it's already done due to resources allowing arbitrary attributes.

    vote to mark resolved?

    April 20th, 2011 @ 03:09 PM

  10. Deleted User
    Deleted User

    If it is passed through to the plugin then close it.

    April 20th, 2011 @ 07:42 PM

  11. Greg Schueler
    Greg Schueler
    • State changed from new to resolved

    node attributes are available to any node executor/file copier provider as part of #114 Refactor resource model definition and #240 Customizable dispatch plugin

    April 20th, 2011 @ 09:37 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.