Uploaded image for project: 'Libcloud'
  1. Libcloud
  2. LIBCLOUD-296

Proposal to add a node state - STOPPED - to the standard list of states.

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 0.11.2
    • Fix Version/s: 0.14.0-beta3
    • Component/s: Compute
    • Labels:
      None

      Description

      With providers like EC2, a node can be stopped and started again.

      STOPPED - is a reasonably useful state to determine the nodes that are just stopped but not terminated and initiate a start operation, if required.

      Currently a EC2 stopped node is being mapped to UNKNOWN state. Without a STOPPED state, we are losing an important information with all the providers who supports this state.

      A sample ec2 node data in stopped state
      ------------------------------------------------------------
      {'private_ips': [], 'extra': {'status': 'stopped', 'productcode': [], 'groups': [None], 'tags': {}, 'instanceId': 'i-f9654189', 'dns_name': '', 'launchdatetime': '2013-02-09T15:35:09.000Z', 'imageId': 'ami-3fec7956', 'kernelid': 'aki-88aa75e1', 'keyname': 'jv', 'availability': 'us-east-1c', 'clienttoken': 'pfoKe1360424109512', 'launchindex': '0', 'ramdiskid': None, 'private_dns': '', 'instancetype': 't1.micro'}, 'image': None, '_uuid': None, 'driver': <libcloud.compute.drivers.ec2.EC2NodeDriver object at 0x9bbbbac>, 'state': 4, 'public_ips': [], 'size': None, 'id': 'i-f9654189', 'name': 'i-f9654189'}

        Activity

        Hide
        jayyy0v Jay Kumar added a comment -

        Noticed that with EC2, the original value of node state gets retained under node.extra['status']. Still it will be more convenient to map the stopped state.

        Show
        jayyy0v Jay Kumar added a comment - Noticed that with EC2, the original value of node state gets retained under node.extra ['status'] . Still it will be more convenient to map the stopped state.
        Hide
        kami Tomaz Muraus added a comment -

        I know that multiple providers besides EC2 allow you to stop a node and have a separate "stopped" state so adding a new STOPPED NodeState seems reasonable to me.

        As far preserving the old mapping, I think the attribute should be called "old_state" or something like that.

        On a related note - when this change lands in a release it should be documented on the "Upgrading Instructions" page, because it could break or change the behavior of the existing code which depends on the current behavior.

        Show
        kami Tomaz Muraus added a comment - I know that multiple providers besides EC2 allow you to stop a node and have a separate "stopped" state so adding a new STOPPED NodeState seems reasonable to me. As far preserving the old mapping, I think the attribute should be called "old_state" or something like that. On a related note - when this change lands in a release it should be documented on the "Upgrading Instructions" page, because it could break or change the behavior of the existing code which depends on the current behavior.
        Hide
        jayyy0v Jay Kumar added a comment -

        You are correct. It may break existing clients and I think preserving it under a new name (like 'old_state') still breaks but just an option to fix it back.

        Just tried to attempt a way we could introduce this without breaking.

        #1 Instead of old_state, we shall try new_state.
        It won't break existing clients. And is available for interested parties. But again, we need efforts to migrate from new_state -> state.

        #2 How about an environment variable LIBCLOUD_UPGRADE ? (like LIBCLOUD_DEBUG)

        We shall apply the upcoming changes when this flag is set. Otherwise, raise a deprecation warning.
        This way, new changes will become available for those who are ready to pick it up and a deprecation warning for others.

        Show
        jayyy0v Jay Kumar added a comment - You are correct. It may break existing clients and I think preserving it under a new name (like 'old_state') still breaks but just an option to fix it back. Just tried to attempt a way we could introduce this without breaking. #1 Instead of old_state, we shall try new_state. It won't break existing clients. And is available for interested parties. But again, we need efforts to migrate from new_state -> state. #2 How about an environment variable LIBCLOUD_UPGRADE ? (like LIBCLOUD_DEBUG) We shall apply the upcoming changes when this flag is set. Otherwise, raise a deprecation warning. This way, new changes will become available for those who are ready to pick it up and a deprecation warning for others.
        Hide
        dineshbhoopathy Dinesh Bhoopathy added a comment -

        Tomaz Muraus +1 on this. I remember discussing with you and decided to go with TERMINATED for a stopped node but It'd make sense to add STOPPED to NodeStates!

        Show
        dineshbhoopathy Dinesh Bhoopathy added a comment - Tomaz Muraus +1 on this. I remember discussing with you and decided to go with TERMINATED for a stopped node but It'd make sense to add STOPPED to NodeStates!
        Hide
        kami Tomaz Muraus added a comment -

        Yeah, in this case (afaik) there is no way around breaking backward compatibility which is fine imo.

        This change would be included in the next "minor" release which can contain backward incompatible changes. We obviously still try to do our best and avoid backward incompatible changes, but sadly that's not always possible.

        So as long as this change and the potential impact on the existing code is documented in the following places:

        • Release notes
        • Upgrade notes page on the website
        • Release announcement.

        We should be fine.

        Show
        kami Tomaz Muraus added a comment - Yeah, in this case (afaik) there is no way around breaking backward compatibility which is fine imo. This change would be included in the next "minor" release which can contain backward incompatible changes. We obviously still try to do our best and avoid backward incompatible changes, but sadly that's not always possible. So as long as this change and the potential impact on the existing code is documented in the following places: Release notes Upgrade notes page on the website Release announcement. We should be fine.
        Hide
        jayyy0v Jay Kumar added a comment -

        Thanks Tomaz. This sounds great.

        Show
        jayyy0v Jay Kumar added a comment - Thanks Tomaz. This sounds great.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 69a0740e722be235aa4f3a4f544aed9cbeb79cfe in branch refs/heads/trunk from Jay Kumar
        [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=69a0740 ]

        LIBCLOUD-296 : stopped state for compute nodes

        Signed-off-by: Tomaz Muraus <tomaz@apache.org>

        Show
        jira-bot ASF subversion and git services added a comment - Commit 69a0740e722be235aa4f3a4f544aed9cbeb79cfe in branch refs/heads/trunk from Jay Kumar [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=69a0740 ] LIBCLOUD-296 : stopped state for compute nodes Signed-off-by: Tomaz Muraus <tomaz@apache.org>
        Hide
        kami Tomaz Muraus added a comment -

        Merged into trunk, thanks!

        Show
        kami Tomaz Muraus added a comment - Merged into trunk, thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            jayyy0v Jay Kumar
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development