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

Att/Detach volume request syntax discrepancy #573

Open
johnarwe opened this issue Dec 30, 2021 · 4 comments
Open

Att/Detach volume request syntax discrepancy #573

johnarwe opened this issue Dec 30, 2021 · 4 comments

Comments

@johnarwe
Copy link
Member

Attach volume says in the parameter table that assigner_id is specified in (presumably, the request URI) path, but the example shows it within the connection dictionary.

Detach volume has the same discrepancy. Detach's parameters and example look like an exact copy of Attach's, which seems suspicious. I'm not sure how specifying is_root_volume on a Detach Volume request helps, or would be used. It might be that detach should say that extra/unknown parameters are ignored (that seems like it would be a useful statement at a higher level "all Feilong APIs...", if it's true, since unknown parameters could just as likely result in a request being rejected).

@jichenjc
Copy link
Collaborator

jichenjc commented Jan 12, 2022

I guess the doc is not up to date yet, maybe we will update the doc when we have time soon .. thanks for report that @dongyanyang FYI

@IBMCaoBiao
Copy link
Contributor

@johnarwe Hi john, thanks, the documents is outdated and I forget to maintain it.

  1. the assigner_id actually should be in body of URI.
  2. the body structure of attach/detach are same, so we use same template in docs. is_root_volume we need it to determine whether to operate FCP devices or not. root volume is different because we use refresh_bootmap to process it and it need to be operated differently with data volumes. And we will validate the content of connection in body, but we can not report messages like parater xxx are ignored, we can only report errors if the value or format is not correct.

I commit a pull request here: #585 to update the docs, please help review, thanks.
@jichenjc @dongyanyang FYI.

@johnarwe
Copy link
Member Author

johnarwe commented Jan 19, 2022

Related but different question: once the PR merges, is the documentation site automatically updated (perhaps with a minor delay for rebuilding from the source), or is the site updated less frequently and/or by hand? The presence of release numbers might be read to imply that merges are batched and the site regenerated (with a new minor version bump) less often than "with every merge". I don't care which it is, I'm just trying to set my own expectations accurately.

@jichenjc
Copy link
Collaborator

there is no Jenkins job assigned which means not able to update every time

so we manually trigger this time to time to build and online latest doc

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

No branches or pull requests

3 participants