Hi JP,
Firstly thank you for your response.
Over the weekend, I did something kind of similar to what you describe.
1. Built a AIO (inside main OSA) @ 16.04/Newton
2. took it's venv files and placed them in the higher level OSAs repo
but as - Example: glance....-xenial.tgz
3. copied the existing (14.04 based) venv files to glance.....-trusty.tgz
4. Updated the os-{component}-install.yml playbooks to have '-{{
ansible_distribution_release | lower }}' in their respective
_venv_download_url: variable.
5. cleared facts, destroyed containers (the new ones), ran
setup-hosts,setup-infra(without repo-install), setup-openstack.
6. All good.
Today I am proceeding with my other infrastructure nodes. When I make
it through all 16.04 upgrades I plan on rebuilding the repo_container
for all repo_hosts.
I didn't do something like shut off the other || old-14.04 containers
as you described above as I thought that it would deploy 16.04 based
venvs to my existing 14.04 servers as I roll through them one at a
time. Is that correct ?
again thank you very much for your time.
Best Regards,
Wade
On Mon, Dec 19, 2016 at 2:35 AM, Jean-Philippe Evrard
<[email protected]> wrote:
> Hello,
>
> This sounds like an interesting issue that we should fix as soon as possible.
> May I ask you more details on the channel?
>
> It’s still brainstorming, but I think that if you clear facts,
> destroy/upgrade one controller node, then make sure this controller node has
> a repo under 16.04, it should be the basis for the rest of the
> infrastructure, and ssl libs linking shouldn’t be an issue.
> Could you make sure the other repo containers are stopped, this way your load
> balancer always returns the repo server on the new controller?
> Then, we doing openstack services upgrade, could you continue the way you
> explained by destroying the container (let’s say for glance for example) and
> rebuilding? It should be taking the new repo server with the new venv, which
> should be fine (in theory).
>
> When all of that is done, I think we could have lots of fun with the ssl libs
> issue :D
>
> Best regards,
> JP
>
> On 17/12/2016, 00:36, "Wade Holler" <[email protected]> wrote:
>
> Hi All,
>
> I am trying to upgrade a multinode cluster that has been very valuable
> in our environment.
>
> The idea was to start at trusty/mitaka and get to xenial/newton.
>
> Step1 mitaka -> newton on a trusty environment went fine.
> Step2 trusty to xenial is not going well and I could use some help.
>
> So far I rebuilt the 1st of 3 infra nodes with Xenial. Then re-ran
> setup-hosts, setup-infrastructure, setup-openstack.
>
> All playbooks ran fairly clean ( relative to the current issue ) -
> HOWEVER the services don't actually start on the Xenial / 16.04 based
> containers. They just keep dying.
>
> Example error from a glance container here: http://pastebin.com/E6DvWdHy
>
> I jumped on IRC and "logan" was nice enough to help. We deleted the
> glance container, cleared ansible_facts and rebuilt. Same errors
> though. "logan" mentioned that he thought since the repo-build /
> requirement wheels were getting built on a trusty base / container
> that the wheels / venvs that make it to the 16.04 container are not
> compatible.
>
>
> So, can anyone advise on how to proceed ?
>
> Is there someway to not use the repo_server for the 16.04 hosts, then
> when all infra is at 16.04 re-enable the repo_server. Just brain
> storming. Any help would be very welcome.
>
> Best Regards,
> Wade
> [email protected]
> irc: wadeholler
>
> _______________________________________________
> OpenStack-operators mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> ________________________________
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington Road,
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
> contain confidential or privileged information intended for the recipient.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited. If you receive this transmission in error, please notify us
> immediately by e-mail at [email protected] and delete the original message.
> Your cooperation is appreciated.
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
