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

Orchestration: Add support for resource_type endpoints #1806

Merged
merged 1 commit into from
Jan 9, 2020

Conversation

zaneb
Copy link
Contributor

@zaneb zaneb commented Dec 21, 2019

Add client support for listing available resource types in Heat, getting
their schemata, and downloading example templates for use as provider
templates.

For #1805

Links to the line numbers/files in the OpenStack source code that support the
code in this PR:

@coveralls
Copy link

coveralls commented Dec 21, 2019

Coverage Status

Coverage increased (+0.05%) to 77.079% when pulling 906fb4a on zaneb:resource_types into de4ad42 on gophercloud:master.

@theopenlab-ci
Copy link

theopenlab-ci bot commented Dec 21, 2019

Build failed.

Copy link
Contributor

@jtopjian jtopjian left a comment

Choose a reason for hiding this comment

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

@zaneb Thank you for working on this. I did a few iterations of reviewing this, so I apologize about Github's awkward ordering. Please let me know if you have any questions.

openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/results.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/requests.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/results.go Outdated Show resolved Hide resolved
openstack/orchestration/v1/resourcetypes/doc.go Outdated Show resolved Hide resolved
// ListOpts allows the filtering of collections through the API.
type ListOpts struct {
// Filters the resource type list by a regex on the name.
Pattern string `q:"name"`
Copy link
Contributor

Choose a reason for hiding this comment

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

The Field name should match the JSON tag: Name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used a different name because this API has proved confusing to users: it isn't checking for that resource type by name, but filtering the list by a regex. I'd change the API if I could, but although that horse has bolted it would be nice to avoid perpetuating the confusion here. Would something like NameRegEx be acceptable?

@theopenlab-ci
Copy link

theopenlab-ci bot commented Jan 7, 2020

Build failed.

Copy link
Contributor

@jtopjian jtopjian left a comment

Choose a reason for hiding this comment

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

@zaneb Thank you for the updates. To be clear, I agree entirely with your opinion about implementing this in a modern/sane way that makes it easier to use -- notably with modeling the resource type result. I'm just in a tough position where showing favoritism in one area would be unfair to other areas that could also be updated, which leads into prioritizing one use-case over another etc. So thank you for making that change.

I've made two suggested changes to enable default values in the requests. Default values are something we normally don't use either, but I think it's a fair compromise given the other changes you made.

Please let me know if you have any questions.

ToResourceTypeListQuery() (string, error)
}

// ListOpts allows the filtering of collections through the API.
Copy link
Contributor

Choose a reason for hiding this comment

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

We can modify this a little to still use a default value but allowing a user to opt-out:

type ListOpts struct {
  NameRegex string `q:"name"`
  SupportStatus SupportStatus `q:"support_status"`
  WithDescription *bool `q:"with_description"`
}

func (opts ListOpts) ToResourceTypeListQuery() (string, error) {
  if opts.WithDescription == nil {
    iTrue := true
    opts.WithDescription = &iTrue
  }

  q, err := gophercloud.BuildQueryString(opts)
  return q.String(), err
}

This will cause with_description to be set to true by default, but allowing someone to opt-out and set it to false without having to override the method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You know, if we have to include this option then with this output format I think it's fine to just have it default to false and not try to do anything clever.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, but I thought the idea was to have with_description set to true by default so the user receives the more detailed API response?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Originally I was looking through the API code and interpreted it to mean that the old format was there only to support older versions of the client. But on closer inspection, it means that not specifying an option is there only to support older versions. The current openstackclient CLI still defaults to false. And with this data structure as the output it seems less weird to leave the description blank if the caller doesn't request it. So I'm ok with defaulting to false.

)

// GenerateTemplateOpts allows the filtering of collections through the API.
type GenerateTemplateOpts struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar here:

type GenerateTemplateOpts struct {
  TemplateType *GeneratedTemplateType `q:"template_type"`
}

func (opts GenerateTemplateOpts) ToGenerateTemplateQuery() (string, error) {
  if opts.TemplateType == nil {
    templateType := TemplateTypeHOT
    opts.TemplateType = &templateType
  }

  q, err := gophercloud.BuildQueryString(opts)
  return q.String(), err
}

func GenerateTemplate(client *gophercloud.ServiceClient, resourceType string, opts GenerateTemplateOptsBuilder) (r TemplateResult) {
  url := generateTemplateURL(client, resourceType)
  if opts == nil {
    opts = GenerateTemplateOpts{}
  }
  query, err := opts.ToGenerateTemplateQuery()
  if err != nil {
    r.Err = err
    return
  }
  url += query
  _, r.Err = client.Get(url, &r.Body, nil)
  return
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It'll just default to the empty string, so I don't think we even need to do pointers.

}

// PropertyType represents the expected type of a property or attribute value.
type PropertyType string
Copy link
Contributor

Choose a reason for hiding this comment

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

and also to have constants already defined to use in switch statements

Good point

Add client support for listing available resource types in Heat, getting
their schemata, and downloading example templates for use as provider
templates.

Fixes gophercloud#1805

Signed-off-by: Zane Bitter <[email protected]>
@theopenlab-ci
Copy link

theopenlab-ci bot commented Jan 8, 2020

Build failed.

@zaneb
Copy link
Contributor Author

zaneb commented Jan 8, 2020

Not sure why the Ironic tests have started failing now, but #1812 fixes them.

Copy link
Contributor

@jtopjian jtopjian left a comment

Choose a reason for hiding this comment

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

This LGTM - thank you for your patience with this.

Are you ready for this to be merged or did you have additional work you wanted to do?

@zaneb
Copy link
Contributor Author

zaneb commented Jan 9, 2020

This is ready to go from my perspective. Thanks for the detailed reviews, they were very helpful.

@jtopjian jtopjian merged commit af6dbf2 into gophercloud:master Jan 9, 2020
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.

3 participants