| Summary: | [RFE] Optionally create basic overcloud flavors during deployment | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Alexander Stafeyev <astafeye> | |
| Component: | openstack-tripleo | Assignee: | Sven Anderson <svanders> | |
| Status: | CLOSED WONTFIX | QA Contact: | Prasanth Anbalagan <panbalag> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 10.0 (Newton) | CC: | arkady_kanevsky, christopher_dearborn, dcain, jdonohue, judd.maltin, kurt_hey, mburns, oblaut, randy_perryman, rhel-osp-director-maint, sgordon, smerrow, sreichar, tonishim, wayne_allen | |
| Target Milestone: | Upstream M2 | Keywords: | EasyFix, FutureFeature, Triaged | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1408994 (view as bug list) | Environment: | ||
| Last Closed: | 2018-01-12 17:23:10 UTC | Type: | Feature Request | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | 1396396 | |||
| Bug Blocks: | 1393243, 1394885, 1408994, 1476900 | |||
|
Description
Alexander Stafeyev
2016-10-06 08:41:27 UTC
This has been removed from nova because operators were removing them anyways. If this is really a customer driven requirement, it should be created by tripleO/director with an opt-in option. Is there any evidence that customers have a real demand for that? Part of the concern here is that with RHOS7-9 these flavors have been available in some form or fashion out of the box. Some of our partners have joint solutions with us and these flavors were used in tandem with sanity checking once the overcloud was deployed, etc. If these flavors have been removed completely (and will remain dropped in the GA release), is there documentation announcing that change? How does one re-create the default flavors with OSP-d as a part of the deployment via OpenStack tripleo-heat-templates / Heat? Flavors are still supported in OSP10 and in Newton. What is the rationale to remove default created flavors for overcloud? For workloads that are deployed and tested by QE team on overcloud what flavors are they using? For example for Tempest or Rally testing? What flavors does OpenShift on OpenStack Ansible deployment is using? (In reply to arkady kanevsky from comment #3) > Flavors are still supported in OSP10 and in Newton. What is the rationale to > remove default created flavors for overcloud? > > For workloads that are deployed and tested by QE team on overcloud what > flavors are they using? For example for Tempest or Rally testing? > What flavors does OpenShift on OpenStack Ansible deployment is using? OpenShift on Openstack: tests create their own flavor: m1.shift https://github.com/redhat-openstack/openshift-on-openstack/blob/97380f1b0a75796426910597c1b7847ff5562cb7/tests/roles/deploy/tasks/main.yml deployment configs docs indicate configuration option: https://github.com/redhat-openstack/openshift-on-openstack/blob/275d12be15254a706a56b6a7bf0d42cd10b116e9/env_aop.yaml There doesn't seem to be a default in the Heat templates for flavors for hosts deployed. Correction: Default flavor for all host types: m1.medium https://github.com/redhat-openstack/openshift-on-openstack/blob/268f22a372acd3bb76842e697692ed410b5a8d9f/openshift.yaml (In reply to arkady kanevsky from comment #3) > Flavors are still supported in OSP10 and in Newton. What is the rationale to > remove default created flavors for overcloud? > > For workloads that are deployed and tested by QE team on overcloud what > flavors are they using? For example for Tempest or Rally testing? > What flavors does OpenShift on OpenStack Ansible deployment is using? Looks like this was an upstream decision to remove the default flavors. According to Sven's previous comments "This has been removed from nova because operators were removing them anyways...." From OpenStack Newton release notes [1]: "The default flavors that nova has previously had are no longer created as part of the first database migration. New deployments will need to create appropriate flavors before first use." [1] http://docs.openstack.org/releasenotes/nova/newton.html#id12 Sounds like a possible RFE would be to have OSPd enhanced to ship with a template to configure the former default flavors if the installer would like them. (In reply to arkady kanevsky from comment #3) > Flavors are still supported in OSP10 and in Newton. What is the rationale to > remove default created flavors for overcloud? Refer to the operators list thread from March 2016: http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html Follow-up responses in April 2016 were generally OK with removal: http://lists.openstack.org/pipermail/openstack-operators/2016-April/thread.html#10060 If we're relying on specific flavors being there for things we're building on top of OpenStack, without actually checking they are there, then that would seem to be at odds with the way flavors are being used in real world deployments. Operators can and do delete all the flavors and create their own even on 7/8/9, so this is a scenario we need to cater to even if they weren't removed by default in 10. > For workloads that are deployed and tested by QE team on overcloud what flavors are they using? For example for Tempest or Rally testing? > What flavors does OpenShift on OpenStack Ansible deployment is using? Tempest and the OpenShift deployment uses whatever flavor you tell it to in the configuration/environment file. Upstream devstack was modified to create its own flavors. (In reply to Sean Merrow from comment #6) > Sounds like a possible RFE would be to have OSPd enhanced to ship with a > template to configure the former default flavors if the installer would like > them. I'm marking this bug as an RFE for 12/Pike, but will create a clone for 10.0.z to make this change and how to go about base flavor creation clearer in the documentation. FWIW, I don't care about this any more as users have accepted the fact that they need to create flavours after deployment and whats an ansible playbook between friends? Also, for anyone watching with the necessary bugzilla permissions, we now have a release name for R - Rocky. :) |