Re: [openstack-dev] [devstack] noVNC disabled by default?
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" 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] noVNC disabled by default?
> 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, > but I think we could work on doing release installs until then, > especially if the install process is crisp. I'll see if I can find some time to do this. I've been rather busy with a few other things (chiefly, getting my Nova patch series all ready and tested before next week). > 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. The "bulk" of noVNC is a series of Javascript and HTML files. "Installation" may differ depending on how you plan on serving the noVNC files themselves. That's the main reason why there's no "INSTALLATION" file for noVNC. That being said, it is not uncommon for people to serve noVNC using websockify's built-in web server -- this is what the "utils/launch.sh" script does. Fedora places the noVNC source in /usr/share/novnc, so I think that's a reasonable place for devstack to "install" (mainly just unzip the sources) noVNC for the time being. Thoughts? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] noVNC disabled by default?
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] noVNC disabled by default?
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, 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 -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack] noVNC disabled by default?
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. 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? Best Regards, Solly Ross __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
