I agree, if the flavors are removed, there should be a python script etc that can easily define the flavors using the CLI etc. Their presence may have been a presumption, but there are likely a lot of tests out there that depend upon the default flavors, and we should avoid breaking them until people have a chance to update their test environments/scripts as needed.
On Apr 4, 2016, at 1:50 PM, Joseph Bajin <josephba...@gmail.com<mailto:josephba...@gmail.com>> wrote: While I think it's fine to remove this from the normal setup, I think there should be either a file or process that one could run to add these basic flavors. I think without you will have things such as DevStack and other beginners not being able to get up and going. I think having the migration as a side option would be a good compromise. On Sun, Apr 3, 2016 at 1:46 PM, Robert Starmer <rob...@kumul.us<mailto:rob...@kumul.us>> wrote: I'll add a vote for removal, given how varied private clouds tend to be, the flavors are often "wrong" for any one particular purpose. R On Sat, Apr 2, 2016 at 8:41 PM, Mike Smith <mism...@overstock.com<mailto:mism...@overstock.com>> wrote: +1 from me. We always just remove them and add our own. Like Dan said, it’s consistent with populating your own images. Mike Smith Lead Cloud Systems Architect Overstock.com<http://Overstock.com> On Apr 2, 2016, at 8:33 PM, Eric Windisch <e...@windisch.us<mailto:e...@windisch.us>> wrote: I recall these being embedded being a real operational pain when my team wanted to replace the defaults. +1 on removal On Mar 31, 2016 2:27 PM, "Dan Smith" <d...@danplanet.com<mailto:d...@danplanet.com>> wrote: Hi all, I just wanted to float this past the operators list for visibility: Historically Nova has seeded some default flavors in an initial install. The way it has done this is really atypical of anything else we do, as it's embedded in the initial database schema migration. Since we're moving where we store those flavors now, leaving their creation in the original migration means even new deploys will just have to move them to the new location. That, and we don't even use them for our own testing as they're too large. So, this will involve removing them from that migration, making sure that devstack creates you some flavors to use if you're going that route, and updates to the manuals describing the creation of base flavors alongside getting an image set up to use. For real deployments, there should be little or no effect, but PoC type deploys that are used to those flavors being present may need to run a couple of flavor-create commands when bootstrapping, just like you have to do for images. Thanks! --Dan _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
