<elukey> some downtime is surely needed. We could create a new instance and move everything to it, starting from a fresh state. It shouldn't be a huge deal for deployment-prep, but some testing might be needed
<elukey> if you want we can open a task and then list what is needed in there
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T197804 Puppet: forbid new Python2 code | |||
| Open | None | T218426 Upgrade various Cloud VPS Python 2 scripts to Python 3 | |||
| Resolved | BUG REPORT | • Bstorm | T218423 Add python 3 packages to openstack::clientpackages::common | ||
| Resolved | MoritzMuehlenhoff | T232677 Remove support for Debian Jessie in Cloud Services | |||
| Duplicate | None | T236575 "deployment-prep" Cloud VPS project jessie deprecation | |||
| Resolved | None | T218729 Migrate deployment-prep away from Debian Jessie to Debian Stretch/Buster | |||
| Resolved | elukey | T222461 Migrate deployment-zookeeper02 from jessie to stretch |
Event Timeline
Comment Actions
elukey please could you list what we need, e.g. in terms of what to move and what testing is needed? I might be able to help a bit with the actual process though I don't know what this instance actually does right now.
Comment Actions
I killed the instance, wanted to create another m1.small with the same name but with stretch and there are some issues:
- I don't see m1.small anymore but only qcow2
- I only see buster available
If qcow2 is usable we could even go with Buster, should be ok.
Comment Actions
Scratch the above, yesterday I was doing other tasks and wasn't able to concentrate properly, I just started a new stretch instance.
Comment Actions
I think there was actually a period of time recently where only buster was
available and stretch was missing. Don't know what was up with qcow2
showing up though. Thanks for looking into it.
To clarify, since you removed the old instance: what stuff doesn't work
until the new instance is ready?
Comment Actions
Instance is ready now, I just applied profile::zookeeper::server to the new instance (same name, so it picks up the previous cluster config from the main hiera of the project). Kafka might be upset in the long run if it needs to store any metadata in zookeeper, but only when new topics are added etc.. (that shouldn't happen so often in deployment-prep). I am going to check to make sure that all is good.
Regarding firewall rules etc.. I am not sure how things are handled in deployment-prep, so possibly some follow up is needed.