Juju Charms Collection
nova-cloud-controller package

Merge lp://qastaging/~gnuoy/charms/trusty/nova-cloud-controller/add-console-access into lp://qastaging/~openstack-charmers-archive/charms/trusty/nova-cloud-controller/next

Proposed by Liam Young on 2014-07-10

Status:

Merged

Merged at revision:

Proposed branch:

lp://qastaging/~gnuoy/charms/trusty/nova-cloud-controller/add-console-access

Merge into:

lp://qastaging/~openstack-charmers-archive/charms/trusty/nova-cloud-controller/next

Diff against target:

402 lines (+267/-2)

6 files modified

README.txt (+5/-0)
config.yaml (+17/-0)
hooks/nova_cc_hooks.py (+36/-0)
hooks/nova_cc_utils.py (+48/-0)
unit_tests/test_nova_cc_hooks.py (+93/-2)
unit_tests/test_nova_cc_utils.py (+68/-0)

To merge this branch:

bzr merge lp://qastaging/~gnuoy/charms/trusty/nova-cloud-controller/add-console-access

High

Fix Released

Link a bug report

Reviewer	Date Requested	Status
Liam Young (community)		Needs Resubmitting on 2014-07-30
James Page	2014-07-10	Needs Fixing on 2014-07-14
Review via email: mp+226319@code.qastaging.launchpad.net

Description of the change

Added support for console access to guest instances using vnc via browser (novnc), vnc via java client (xvpvnc) or spice via browser.

The bug reports suggests this should be baked into the nova-cloud-controller charm which is what I've done but I'm still sitting on the fence as to whether this would be better as a standalone principle charm.

Revision history for this message

James Page (james-page) wrote on 2014-07-14:

I think this is fine as a function of the nova-cc charm; I've made a couple of comments.

One other question - does this work OK when more that one nova-cc service unit is being used? I'm not familiar with how this part of openstack actually works. Right now, users would always be directed to the unit serving the VIP and would not be load balanced - but this might actually be the right behaviour!

review: Needs Fixing

lp://qastaging/~gnuoy/charms/trusty/nova-cloud-controller/add-console-access updated on 2014-07-30

95. By Liam Young on 2014-07-29: Remove none as default option for console-access-protocol and tidyup code accordingly
96. By Liam Young on 2014-07-29: Rebased
97. By Liam Young on 2014-07-29: Updated README
98. By Liam Young on 2014-07-30: Set console_settings for compute node if leader or not as leadership is irrelevant and stale settings can persist otherwise

Revision history for this message

Liam Young (gnuoy) wrote on 2014-07-30:

> I think this is fine as a function of the nova-cc charm; I've made a couple of
> comments.
>

I've made the changes you suggested

> One other question - does this work OK when more that one nova-cc service unit
> is being used? I'm not familiar with how this part of openstack actually
> works. Right now, users would always be directed to the unit serving the VIP
> and would not be load balanced - but this might actually be the right
> behaviour!

I think this is behaviour is fine tbh. I've had a play with an ha setup and the client handshake fails. I haven't looked into to much further (maybe sticky haproxy sessions are needed). If you have no objection I'll create a wishlist bug and grab it to look at ha further but I'm not convinced it will work.

review: Needs Resubmitting

lp://qastaging/~gnuoy/charms/trusty/nova-cloud-controller/add-console-access updated on 2014-07-30