The sudden arrival of the wdqs cloudvirts (T221631) has provided a very
straightforward use case for nova host aggregates. We'd already been
planning to adopt them at some point (T226731) so I've gone ahead and
set some up today.
Starting sometime soon (maybe tomorrow!) a host aggregate named
'standard' will replace the existing 'scheduler pool,' and the
profile::openstack::eqiad1::nova::scheduler_pool: hiera key will
vanish. That knowledge will instead live inside the nova database, and
can be queried in a few ways, most simply with '# openstack aggregate
show standard'
I've done my best to document all this[0] but want to call out a few points:
- We will no longer have git history explaining why a given cloudvirt is
pooled or depooled. For that reason it is more important than ever to
!log any change to aggregate membership. I propose we standardize on
the !log admin SAL in -cloud rather than the production -operations SAL
in for this.
- In order to reduce the chances of losing track of a hypervisor
entirely, I've created some tracking aggregates. If you remove a
cloudvirt from the 'standard' aggregate, please re-assign it to
'maintenance', 'spare', or 'toobusy' as appropriate.
That's it! If anyone really hates this please let me know and I can
roll things back. I'm already regretting the name 'standard' but at
least it's not badly overloaded like my first choice, 'public', is.
[0]
https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Host_aggregates
Hi Arzhel,
I'm working on writing down required changes to our setup to introduce BGP
routing in CloudVPS transport network (between the Neutron virtual router and
the Core Router).
It would be great if you can write details of what you need from us, and a
recommended procedure/timeline for doing the changes.
Example of stuff I'm expecting:
* Neutron would need to use BGP protocol version X (I ignore this bit)
* We can only recv x.x.x.x ranges, and not other ranges
* we'd need to do the switch from static to BGP only on a concrete day
* You need to use AS # NNN
* Make sure protocol X is allowed in any firewalling for the session to be
correctly established (or monitoring or whatever)
My idea is to merge your ideas/requirements with what Neutron docs say. The docs
will end up here:
https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Enhanceme…
For now, let's assume everything will happen in codfw (in our codfw1dev deployment).
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation
Following our latest team agreements regarding DNS, we have now 2 wikitech pages:
* https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/DNS
This includes information about the DNS domains we handle, and their setup.
* https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/Designate
This includes specific information about how to operate the Openstack Designate
component. I refactored the content to make this seperation and to include the
information from the enhancement proposals.
Edits welcome.
regards.
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation