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

Add more server actions #149

Merged
merged 4 commits into from
Oct 27, 2024
Merged

Conversation

milliams
Copy link
Contributor

This adds most of the remaining server actions.

This includes all of the simple actions which have very single or no arguments taken and return nothing, as well as some which take relatively simple arguments (e.g. a few strings) but might return values.

The first question is, given the diversity of return values given by these actions, is it ok for us to provide that as a generic serde_json::Value, or should we define deserialisable structs for each action that provides a value? Perhaps the generic Server::action should return a serde_json::Value, but if we implement specific functions for any other actions in the future (like we already have for e.g. Server::stop) we define return type structs/types for those?

I did a quick survey and at the moment, there are only 6 actions which return anything and if we want could probably be encoded as:

CreateBackup -> image_id: ImageRef
CreateImage -> image_id: ImageRef
Evacuate -> adminPass: Option<String>
Rebuild -> server: Server (or ServerSummary?)
Rescue -> adminPass: Option<String>
OsGetConsoleOutput -> output: String

So probably in that situation, the wrapper functions would be simple enough.

Secondly, there are some more complex actions not implemented here. Is that ok that they will be added in some later version of rust-openstack? I assume so, given the #[non_exhaustive]. I expect that OpenStack will add more in the future too, so that covers that also.

None of these actions have complicated request
arguments or have any responses returned.
These are actions which, while having return
values, are relatively simple in what they take
as arguments.
@milliams
Copy link
Contributor Author

milliams commented Oct 30, 2023

The functional tests are filing on this. One of them, test_server_ops_with_port I think is the one that ephemerally failed on the last PR, here failing with Cannot create a key pair: Error { kind: Conflict, message: "Key pair 'rust-openstack-integration' already exists.", status: Some(409) }. The other two failures may well be due to the code changes in this PR. I will investigate. It's caused by the actions returning an empty body, which I had assumed would be parsed correctly by serde, but is not. I'll need to turn this into some valid serde::Value or return Option<serde::Value>.

Some server actions return an empty body, which
is not valid JSON.
@milliams
Copy link
Contributor Author

The test test_server_ops_with_port is intermittently failing. Looking at the test, it's failing to find a floating IP just after a 1 second sleep. I'm guessing that the sleep was put in to give it time to assign the IP, but maybe sometimes it's not enough time. Maybe the sleep can be extended, or a retry added?

@dtantsur
Copy link
Owner

The test test_server_ops_with_port is intermittently failing. Looking at the test, it's failing to find a floating IP just after a 1 second sleep. I'm guessing that the sleep was put in to give it time to assign the IP, but maybe sometimes it's not enough time. Maybe the sleep can be extended, or a retry added?

Yeah, I've noticed it too. I suspect retrying for a longer time is the right way.

@dtantsur
Copy link
Owner

dtantsur commented Apr 5, 2024

@milliams hi, are you still interested in this?

@milliams
Copy link
Contributor Author

milliams commented Apr 8, 2024

@milliams hi, are you still interested in this?

Yes, I'd like to get this in. I see that the floating IP timeout has been fixed in a recent PR, but I think I'll need #157 merged before the CI passes here.

@dtantsur
Copy link
Owner

@milliams yep, just merged it.

@milliams milliams force-pushed the add_server_actions branch 2 times, most recently from e40f060 to e644b15 Compare April 14, 2024 22:31
@milliams milliams marked this pull request as ready for review April 15, 2024 08:21
Ok(ServerStatusWaiter {
server: self,
target: protocol::ServerStatus::ShutOff,
})
}

/// Run an action on the server.
pub async fn action(&mut self, action: ServerAction) -> Result<()> {
pub async fn action(&mut self, action: ServerAction) -> Result<Option<serde_json::Value>> {
Copy link
Owner

Choose a reason for hiding this comment

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

I wonder if we can consider this a breaking change (because Rust will insist on let _ = ... by default). It's not an objection, just wondering how I should release rust-openstack after this.

Copy link
Owner

Choose a reason for hiding this comment

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

I'm also really unsure about using serde_json::Value in a public function. I'm trying to design the high-level API here to be type safe. Is it only for GetConsoleOutput? Maybe make separate methods for actions that return something?

@@ -343,19 +343,125 @@ impl Server {
#[non_exhaustive]
#[allow(missing_copy_implementations)]
Copy link
Owner

Choose a reason for hiding this comment

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

nit: this can be dropped now, Copy is no longer possible

Restore,
/// Shows console output for a server.
#[serde(rename = "os-getConsoleOutput")]
OsGetConsoleOutput {
Copy link
Owner

Choose a reason for hiding this comment

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

Could you remove the "Os" prefix? I don't think it's meaningful, is it?

@dtantsur
Copy link
Owner

@milliams hey, are you still interested in this PR? If you no longer have time, I can merge it and clean up myself.

@milliams
Copy link
Contributor Author

I'm not sure that I'll have time to make the changes on this, so feel free to hack it as you see fit.

@dtantsur dtantsur merged commit 7875384 into dtantsur:master Oct 27, 2024
15 checks passed
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.

2 participants