Page History

Da Caracal a Epoxy

Procedura indicativa

A grandi linee la procedura sara':

• Sul secondo controller i servizi sono attivi con versione C
• Si configura HAproxy in modo da far puntare al secondo controller
• Si spengono tutti i servizi sul primo controller
• Si aggiornano i pacchetti a E sul primo controller senza fare partire i servizi
• Si configura e si fa partire un servizio alla volta sul primo controller e si configura HAproxy in modo da far puntare per quel servizio al primo controller
• Si spengono tutti i servizi sul secondo controller e si aggiorna il secondo controller a epoxy, facendo partire i servizi
• Si modifica HAproxy in modo che punti a entrambi i controller
• Si aggiornano i compute node uno alla volta

Check preliminari ed installazione release sul controller1

• Modificare la classe puppet epoxy dei controller in modo che non faccia partire i servizi
• Modificare l'HA in modo che per tutti i servizi punti al controller2 (che ha i servizi a caracal attivi)
• Spegnere e disabilitare puppet 
• Spegnere Controllare che tutti i servizi Openstack siano spenti Openstack 
• Migrare online il db placement e nova

• Code Block
  language bash
  #placement va fatto prima di nova su -s /bin/sh -c "placement-manage db online_data_migration" placement su -s /bin/sh -c "nova-manage db online_data_migration" nova su -s /bin/sh -c "cinder-manage db online_data_migrations" cinder

...

• KEYSTONE

  Code Block
  language bash
  su -s /bin/sh -c "keystone-manage doctor" keystone su -s /bin/sh -c "keystone-manage db_sync --expand" keystone Dopo l'aggiornamento del controller2 e fatto ripartire httpd, si deve eseguire il comando su -s /bin/sh -c "keystone-manage db_sync --contract" keystone

• PLACEMENT

• Code Block
  language bash
  su -s /bin/sh -c "placement-manage db expand" placement ---> ATTENZIONE: da verificare, altre guide dicono di fare solo il sync, che expand e contract non c'e' per placement... Al cnaf hanno fatto solo il sync accendere il servizio httpd sul controller1 (di fatto keystone, dashboard e placement), systemctl start httpd modificare HA proxy in modo che per questi tre servizi punti al controller 1 spegnere httpd sul controller2 systemctl stop httpd Controllare che funzioni tutto a livello di dashboard, in particolare il calendario prenotazioni GPU (se non funziona interviene Sergio) Quando il controller2 sara' aggiornato su -s /bin/sh -c "placement-manage db contract" placement ( da verificare)

• GLANCE

  Code Block
  language bash
  ATTENZIONE: controllare se c'e'un ordine per l'update di glance (si possono avere due release diverse contemporaneamente?) Parrebbe di si`: https://docs.openstack.org/glance/2025.1/admin/zero-downtime-db-upgrade.html su -s /bin/sh -c "glance-manage db expand" glance su -s /bin/sh -c "glance-manage db migrate" glance systemctl start openstack-glance-api.service Modificare l'HA proxy im podo che per glance punti al controller1 Spegnere il servizio nel controller2 systemctl stop openstack-glance-api.service Quanto anche il controller2 sara' aggiornato, eseguire su -s /bin/sh -c "glance-manage db contract" glance

• NOVA

  Code Block
  language bash
  su -s /bin/sh -c "nova-status upgrade check" nova su -s /bin/sh -c "nova-manage api_db sync" nova su -s /bin/sh -c "nova-manage db sync" nova Far partire il servizio nel controller1 systemctl start \ openstack-nova-api.service \ openstack-nova-scheduler.service \ openstack-nova-conductor.service \ openstack-nova-novncproxy.service Modificare l'HA in modo che nova punti al controller1 Spegnere il servizio nel controller2 systemctl stop \ openstack-nova-api.service \ openstack-nova-scheduler.service \ openstack-nova-conductor.service \ openstack-nova-novncproxy.service Quando anche il controller2 e tutti i compute saranno aggiornati, eseguire di nuovo su -s /bin/sh -c "nova-manage db online_data_migrations" nova

• NEUTRON

  Code Block
  language bash
  su -s /bin/sh -c "neutron-db-manage upgrade --expand" neutron Far partire il servizio systemctl start neutron-server.service \ neutron-openvswitch-agent.service neutron-dhcp-agent.service \ neutron-metadata-agent.service systemctl start neutron-l3-agent.service Modificare l'HA per far puntare neutron al controller2 Stoppare il servizio sul controller2 systemctl stop neutron-server.service \ neutron-openvswitch-agent.service neutron-dhcp-agent.service \ neutron-metadata-agent.service systemctl stop neutron-l3-agent.service Quando anche il controller2 sara' aggiornato eseguire il comando su -s /bin/sh -c "neutron-db-manage upgrade --contract" neutron

  
  

• CINDER

  Code Block
  language bash
  su -s /bin/sh -c "cinder-manage db sync" cinder Far partire il servizio sul controller1 systemctl start openstack-cinder-api.service openstack-cinder-scheduler.service openstack-cinder-volume.service Modificare l'HA per far puntare il servizio al controller1 Stopparlo sul controller2 systemctl stop openstack-cinder-api.service openstack-cinder-scheduler.service openstack-cinder-volume.service Quando il controller2 sara' aggiornato rieseguire il online_data_migration su -s /bin/sh -c "cinder-manage db online_data_migrations" cinder

  
  

  HEAT

  Code Block
  language bash
  su -s /bin/sh -c "heat-manage db_sync --command expand" heat su -s /bin/sh -c "heat-manage db_sync --command migrate_data" heat Accendere il servizio sul controller1 systemctl start openstack-heat-api.service \ openstack-heat-api-cfn.service openstack-heat-engine.service Modificare l'HA per far puntare il servizio nel controller1 e spegnerlo sul controller2 systemctl stop openstack-heat-api.service \ openstack-heat-api-cfn.service openstack-heat-engine.service Quando anche il controller2 sara' aggiornato su -s /bin/sh -c "heat-manage db_sync --command contract" heat

  
  

• DASHBOARD: nulla da fare

...