Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn all States into string values instead of ints #624

Merged
merged 1 commit into from Dec 10, 2015

Conversation

allardhoeve
Copy link
Contributor

@Kami

Luckily, most tests already used the constants. I found a couple sloppy drivers, especially the ProfitBricks driver, which uses NodeState for everything, including Volumes and Snapshots. Maybe we fix that, maybe we leave it. It doesn't really matter.

@Kami
Copy link
Member

Kami commented Nov 3, 2015

Thanks.

We should just wait with merging this until we decide when to include it in a release since it's a breaking change if people used integers directly.

I'm fine with including it in 0.20.0 (next "major" release), but we also need to update documentation (upgrade notes) to reflect this change.

ERROR = 7
PAUSED = 8
RUNNING = "running"
REBOOTING = "rebooting"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor style thing - for consistency, please use single quotes around simple strings :)

@allardhoeve
Copy link
Contributor Author

So I added tests for all the objects that have strings as values now. All tests pass.

@Kami: I'd like for this to go into 0.20. Do you think that is still possible?

@allardhoeve
Copy link
Contributor Author

Also, I think the changes involved are minimal. I cannot imagine a use case where you would actually use the integers in normal code. I think everyone involved either used fromstring for NodeState and Provider, or raw strings, because the other objects did not have consistent states anyway.



class StorageVolumeState(object):
RUNNING = 'running'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we ok with this behavior change? The NodeState.tostring(node.state) values previously were all-caps, now they're all lower-case. I know this means my team's codebase will require changes to keep existing behavior. Could we make Type.tostring return value.upper()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! That is true. Let me add that test. We should've had tests for this stuff all along 😢 That would've made this much easier. Ah well, moving forward 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@jimbobhickville
Copy link
Contributor

Thanks @allardhoeve - lgtm

@allardhoeve
Copy link
Contributor Author

I added docs for 0.20

- Let all types derive from Type
- Turn all type attributes into strings
- Keep things backwards-compatible by having
  - tostring
  - fromstring
- Add tests for tostring, fromstring

closes apache#624

Signed-off-by: Allard Hoeve <allardhoeve@gmail.com>
@asfgit asfgit merged commit bef1f94 into apache:trunk Dec 10, 2015
@allardhoeve allardhoeve deleted the all-states-are-string branch Dec 10, 2015
* All NodeState, StorageVolumeState, VolumeSnapshotState and Provider attributes
are now strings instead of integers.

If you are using the ``tostring`` and ``fromstring`` methods of NodeState,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be good to note that you are affected if you directly store the enum value in the database (integer) - I know some users who do that.

For that scenario this is a backward incompatible change. We don't have any automatic migration path for it - users need to handle that in their code - so for users who do that it's quite an invasive change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants