Open Stack

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 <josephbajin at gmail.com<mailto:josephbajin at 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 <robert at kumul.us<mailto:robert at 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 <mismith at overstock.com<mailto:mismith at 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 <eric at windisch.us<mailto:eric at 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" <dms at danplanet.com<mailto:dms at 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 at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160404/e87c27f1/attachment.html>