> > the sizing details for control plane servers are not really listed anywhere
If they're not listed anywhere, I suppose that nobody follows up on the sizing until something breaks? Sometimes the cloud provider will provide us with custom flavors, or ask us > to use a particular variant Why would they ask for a particular variant? Is it because these resources are donated by the cloud provider? That's my best guess to justify this. for something not load-balanced that requires production downtime, it's a > very manual process Is it also the case that the load-balancing settings are not recorded anywhere? eg minimum and maximum number of machines in a load-balancing cluster, machine flavor It's just a trade-off between development time to create and maintain > that, and how often we actually start control-plane servers. > Are the control-plane servers the only cloud cost aspect to outweigh the development costs? I'm surprised there isn't already a tool out there that interfaces with rrdtool and/or cacti to help with this. rrdtool seems to have been around since 20 years now [1] [2] [1] https://tobi.oetiker.ch/webtools/appreciators.txt [2] https://github.com/oetiker/rrdtool-1.x/commit/37fc663811528ddf3ded4fe236ea26f4f76fa32d#diff-dee0aab09da2b4d69b6722a85037700d -- Shadi Akiki Founder & CEO, AutofitCloud https://autofitcloud.com/ +1 813 579 4935 On Thu, Aug 15, 2019 at 3:15 AM Ian Wienand <iwien...@redhat.com> wrote: > On Tue, Aug 13, 2019 at 11:44:36AM +0200, Shadi Akiki wrote: > > 2- how the allocated resource can be downsized (which I was hoping to > find > > in the opendev/system-config <https://opendev.org/opendev/system-config> > > repo) > > You are correct that the sizing details for control plane servers are > not really listed anywhere. > > This is really an artifact of us manually creating control-plane > servers. When we create a new control-plane server, we use the launch > tooling in [1] where you will see we manually select a flavor size. > This is dependent on the cloud we launch the server in and the flavors > they provide us. > > There isn't really a strict rule on what flavor is chosen; it's more > art than science :) Basically the smallest for what seems appropriate > for what the server is doing. > > After the server is created the exact flavor used is not recorded > separately (i.e. other than querying nova directly). So there is no > central YAML file or anything with the server and the flavor it was > created with. Sometimes the cloud provider will provide us with > custom flavors, or ask us to use a particular variant. > > So in terms of resizing the servers, we are limited to the flavors > provided to us by the providers, which varies. In terms of the > practicality of resizing, as I'm sure you know this can be harder or > easier depending on a big variety of things from the provider. We > have resized servers before when it becomes clear they're not > performing (recently adding swap to the gitea servers comes to mind). > Depending on the type of service it varies; for something not > load-balanced that requires production downtime, it's a very manual > process. > > Nobody is opposed to making any of this more programatic, I'm sure. > It's just a trade-off between development time to create and maintain > that, and how often we actually start control-plane servers. > > In terms of ask.o.o, that is a "8 GB Performance" flavor, as defined > by RAX's flavors. This was rebuilt when we upgraded it to Xenial as > an 8GB node (from 4GB) as investigation at the time showed 4GB was a > bit tight [2]. 8GB is the next quanta up of flavor provided by RAX > over 4GB. > > I hope this helps! > > -i > > [1] https://opendev.org/opendev/system-config/src/branch/master/launch > [2] > http://lists.openstack.org/pipermail/openstack-dev/2018-April/129078.html > >
_______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
