Add Block Storage API

[gierens]

This starts adding the block storage API alias cinder. So far it implements rudimentary versions of list_volumes, find_volumes and get_volume with an equally minimal Volume struct. But I does compile and returns things.

Although the cinder API is very similar to nova's API, this is currently closer to the image module. For example, at the moment it goes directly to the /volumes/detail endpoint, rather than defining some kind of VolumeSummary for /volumes and offering a detailed() as the compute module does.

This is for simplicity, just to get things rolling. I need this at work, so I can invest a fair bit of time. I'll make it more consistent along the way.

[dtantsur]

@gierens is this change still a draft? It looks pretty good to me. Could use a full acceptance test, and at least some unit test failures seem real (I need to check the others).

[gierens]

@gierens is this change still a draft? It looks pretty good to me.

Yeah, I was a little busy the last couple of weeks, that's why I didn't add anything more up until now. But I wanted to at least provide the most important volume functions before turning it into a normal PR. And then for snapshots and other stuff, this could go into a follow-up PR.

Could use a full acceptance test, and at least some unit test failures seem real (I need to check the others).

I will now continue to work on this, I just added volume deletion and can also take a look at the failing jobs.

[gierens]

I just added volume creation and with that I guess the most important functionality is present. On top of this I can now write a few integration tests and take a look at the still failing CI jobs. But after that the PR should be ready for review.

[dtantsur]

The No floating IP issue has been haunting the project for a long time. It's possible that I'm simply too optimistic when assuming how long it takes to allocate such an IP. Chances are high, your patch is not at fault.

[dtantsur]

Let's see if #153 provides any improvement.

[dtantsur]

@gierens if you rebase the patch, you'll pick up various CI fixes. Everything that fails afterwards is probably on you.

[dtantsur]

Great job, thank you! I've left a few comments inline, could you check them?

Please let me know when I reach the point of abusing your patience, I can fix minor issues myself then :)

[gierens]

@dtantsur Alright, I think I have addressed all comments and for the more complex cases as with the DateTime I also provided some info about how I solved them in my answers to the respective comments.

[dtantsur]

Won't this actually mean UTC?

[dtantsur]

Could be a helper for serialize_with (to convert None to "")

[dtantsur]

Properties should be sorted here for easier navigation in the docs.

[dtantsur]

@gierens I hope you don't mind me squashing the commits: 58 may easily be more than we had in rust-openstack before that :)

Let's continue the discussion around DateTime? I have a strong feeling that when they don't provide a timezone, they actually mean UTC. Could you try confirming?

I'll hold releasing the changes until we solve the DateTime problem and maybe figure out enums.

[gierens]

@dtantsur That's totally fine. I tend to do atomic commits because squashing is a lot easier than taking commits apart. I probably could've done an interactive rebase in the end to cleanup the history a bit. But now that this one is in we can work on the rest in smaller chunks/PRs.

About the DateTime, yeah, I do share that suspicion. It's unfortunate the API reference is this vague. I'll experiment around a bit and get back to you then.

About releasing, sure totally understandable.