Bug 1261609 - rhel-osp-director: "openstack flavor create" in undercloud should ignore all arguments except id/name and should set reasonable defaults for disk/ram/cpu.
rhel-osp-director: "openstack flavor create" in undercloud should ignore all ...
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-openstackclient (Show other bugs)
unspecified
x86_64 Linux
medium Severity low
: z5
: 7.0 (Kilo)
Assigned To: Jason E. Rist
Shai Revivo
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-09 14:55 EDT by Alexander Chuzhoy
Modified: 2017-08-31 10:56 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-31 10:56:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexander Chuzhoy 2015-09-09 14:55:39 EDT
rhel-osp-director: "openstack flavor create" in undercloud should ignore all arguments except id/name and should set reasonable defaults for disk/ram/cpu.

Environment:
python-openstackclient-1.0.3-2.el7ost.noarch
instack-undercloud-2.1.2-23.el7ost.noarch


Usually, there are various HW specs for systems sharing a specific flavor. Creating a flavor while specifying the amount of RAM, CPU,DISK can be confusing due to a fact that the machines don't really match.

Also, if we omit the disk size today - it's set to 0, which makes it impossible to launch the nova instances with this flavor.
Comment 3 chris alfonso 2015-09-14 12:42:01 EDT
We need to reach consensus on how we want to set flavor defaults. There are different perspectives on what the right thing to do here is. Setting to y2/medium and expect to have a conversation with eng between now and then.
Comment 4 James Slagle 2015-09-14 12:42:35 EDT
we don't have code that sets flavor defaults, nor should we IMO.
Comment 5 Alexander Chuzhoy 2015-09-14 13:16:01 EDT
Unlike the "nova flavor-create" command, for the "openstack flavor create" it's not mandatory to specify the specs for cpu,disk,ram  and by default a flavor is created with:

disk: 0
cpu: 1
ram: 256


Booting an overcloud node fails with disk < 1.
Comment 6 Ben Nemec 2015-09-14 18:06:25 EDT
openstack flavor create isn't code under our control, and I can't imagine upstream changing the defaults for this one specific use case.

I actually still think it would be perfectly reasonable to have a single OSP director call that creates all of the flavors with sane values and tags them with the correct profile/localboot params.  We have a finite number of possible profiles, and we don't do matching based on the flavor values anyway, we do it based on the profile (or not at all).  Plus, more advanced matching based on hardware specs should be done with AHC, so I'm not sure we even want people to be able to do node matching based on the flavor settings.
Comment 7 Alexander Chuzhoy 2015-09-14 19:45:51 EDT
Ben, this is exactly why I thought of having the reasonable defaults instead of specifying with arguments.
Comment 8 James Slagle 2015-09-14 19:48:07 EDT
profiles are not always assigned, that's an optional flow. some may (and do) choose to use flavors. that's really why I object to this bug as written. I'm not in favor of removing the ability to match on hw specs as specified by flavors alone. the use of profiles should remain optional, if we want to make it the default, fine, but it should be optional to disable it.

note that you can also disable individual filters (such as DiskFilter, etc) in nova.conf for the scheduler. however, these would have to be manual steps reapplied after subsequent runs of "openstack undercloud install".

I don't want to be outright dismissive of what you're asking for.

I gather there is a valid and specific need or scenario that is driving this request based on the customer experience. Instead of requesting the specific implementation, could you describe the issue, what you had to work around, and your proposal to how it could work? It's possible it could be as simple as documenting something better, or changing a default behavior.
Comment 12 Beth Elwell 2017-08-31 10:56:02 EDT
See comment 9 that there is a workaround and documentation should suffice.

Note You need to log in before you can comment on or make changes to this bug.