I¹ve opened a bug to track this effort for DevStack (and to help point others in the right direction when they stumble upon this): https://bugs.launchpad.net/devstack/+bug/1417735
- Marty On 1/12/15, 10:02 AM, "Ben Nemec" <[email protected]> wrote: >On 01/09/2015 05:24 PM, Sean Dague wrote: >> On 01/09/2015 06:12 PM, Solly Ross wrote: >>> Hi, >>> >>> I just noticed that noVNC was disabled by default in devstack (the >>>relevant >>> change was >>> >>> https://review.openstack.org/#/c/140860/). >>> >>> >>> >>> Now, if I understand correctly (based on the short commit message), >>>the >>> rationale is that we don't want devstack to reply on non-OpenStack Git >>> >>> repos, so that devstack doesn't fail when some external Git hosting >>> >>> service (e.g. GitHub) goes down. >> >> Realistically the policy is more about the fact that we should be using >> released (and commonly available) versions of dependent software. >> Ideally from packages, but definitely not from git trees. We don't want >> to be testing everyone else's bleeding edge, there are lots of edges and >> pointy parts in OpenStack as it is. >> >>> >>> >>> This is all fine and dandy (and a decent idea, IMO), but this leaves >>>devstack >>> installing a "broken" installation of Horizon by default -- Horizon >>>still >>> attempts to show the noVNC console when you go to the "console" tab >>>for an >>> instance, which is a bit confusing, initially. Now, it wasn't >>>particularly >>> hard to track not particularly hard to track down *why* this happened >>>(hmm... >>> my stackrc seems to be missing "n-novnc" in ENABLED_SERVICES. >>>Go-go-gadget >>> `git blame`), but it strikes me as a bit inconsistent and >>>inconvenient. >>> >>> >>> Personally, I would like to see noVNC back as a default service, since >>>it >>> can be useful when trying to see what your VM is actually doing during >>> >>> boot, or if you're having network issues. Is there anything I can do >>> >>> as a noVNC maintainer to help? >>> >>> >>> >>> We (the noVNC team) do publish releases, and I've been trying to make >>> >>> sure that they happen in a more timely fashion. In the past, it was >>>necessary >>> to use Git master to ensure that you got the latest version (there was >>>a >>> 2-year gap between 0.4 and 0.5!), but I'm trying to change that. >>>Currently, >>> it would appear that most of the distros are still using the old >>>version (0.4), >>> but versions 0.5 and 0.5.1 are up on GitHub as release tarballs (0.5 >>>being a 3 >>> months old and 0.5.1 having been tagged a couple weeks ago). I will >>>attempt to >>> work with distro maintainers to get the packages updated. However, in >>>the mean >>> time, is there a place would be acceptable to place the releases so >>>that devstack >>> can install them? >> >> If you rewrite the noNVC installation in devstack to work from a release >> URL that includes the released version on it, I think that would be >> sufficient to turn it back on. Again, ideally this should be in distros, > >FWIW, I looked into installing novnc from distro packages quite a while >ago and ran into problems because the dependencies were wonky. Like, >novnc would pull in Nova which then overwrote a bunch of the devstack >Nova stuff. I don't know if that's still an issue, but that's the main >reason I never pushed ahead with removing the git install of novnc (that >was during the release drought, so those weren't an option at the time >either). > >> but I think we could work on doing release installs until then, >> especially if the install process is crisp. >> >> I am looking at the upstream release tarball right now though, and don't >> see and INSTALL instructions in it. So lets see what the devstack patch >> would look like to do the install. >> >> -Sean >> > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
