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.
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.
we don't have code that sets flavor defaults, nor should we IMO.
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.
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.
Ben, this is exactly why I thought of having the reasonable defaults instead of specifying with arguments.
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.
See comment 9 that there is a workaround and documentation should suffice.