Re: [openstack-dev] [horizon] static files handling, bower/
On 2015-01-23 12:02:19 +0100 (+0100), Matthias Runge wrote: [...] I think providing/updating distro packages is quite comparable to updating pypi packages. [...] Within an order of magnitude anyway. The difference is that most Python module upstream authors do their own packaging for PyPI (for better or worse), but few are also package maintainers for Debian and Red Hat so distro packages have a tendency to lag PyPI even if you ignore distro release cycle induced delays. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote: [...] It would be totally awesome to switch from pip install to using distribution packages for testing purposes. At least for dependencies. [...] While it seems nice on the surface, the unfortunate truth is that neither the infra team nor the various package maintainers has the excess of manpower needed to be able to near-instantly package new requirements and new versions of requirements for the platforms on which we run our CI jobs. I fear that the turn-around on getting new requirements into projects would go from being on the order of hours or days to weeks or even months. We could work around that by generating our own system packages for multiple platforms rather than relying on actual distro packages, but doing that from an automated process isn't _really_ testing distro packages at that point so wouldn't necessarily be any better in the end than the situation we're in now. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
On Thu, Jan 22, 2015 at 09:18:46PM +, Jeremy Stanley wrote: On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote: [...] When there is an update to our requirements, such as the recent version increment in the version of angular used, a new package version doesn't automatically show up as evident from that list. How would that process be kicked off so we don't end up with a missing dependency? Does that have to wait for a release cycle? I don't want to speak for the distro package maintainers, but from what I've seen they generally wait until close enough to an integrated release that they can be pretty sure the requirements are close to frozen, so as not to waste effort packaging things which will end up not being used. Yes, exactly. I for myself am using horizonfrom a github checkout, providing all dependencies as RPM packages. That being said, I'm updating/packaging requirements, whenever they'll show up for me. There is no automatic process. I assume (perhaps incorrectly?) that we do use those in CI jobs, so that we can download the things a given project needs in an automated fashion--for us handling pip requirements lists is a solved problem (well, for some definitions of solved at least). It would be totally awesome to switch from pip install to using distribution packages for testing purposes. At least for dependencies. This appears to affect the testing setup as well. When we start to use a new version of a JavaScript dependency no package will exist for it. I believe this would mean the testing environment needs to use the development setup, in the proposal, of bower. IIRC, bower goes out to the Internet and there isn't a mirror of packages (just a mirror of the registry). That means we'll loose the ability to run testing installs from local mirrors for these dependencies. I imagine a solution has been thought of for this. Can you share any details? Uh, we have seen so many timeouts and failing tests, because some mirror was not answering fast enough etc. I don't think, adding another external service will improve the situation here. -- Matthias Runge mru...@redhat.com __ 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] [horizon] static files handling, bower/
On 23/01/15 10:31, Jeremy Stanley wrote: On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote: [...] It would be totally awesome to switch from pip install to using distribution packages for testing purposes. At least for dependencies. [...] While it seems nice on the surface, the unfortunate truth is that neither the infra team nor the various package maintainers has the excess of manpower needed to be able to near-instantly package new requirements and new versions of requirements for the platforms on which we run our CI jobs. I fear that the turn-around on getting new requirements into projects would go from being on the order of hours or days to weeks or even months. We could work around that by generating our own system packages for multiple platforms rather than relying on actual distro packages, Oh, I still would try to get that enabled from a distro perspective. But that's something, a distro CI could provide feedback here. I think providing/updating distro packages is quite comparable to updating pypi packages. Maintaining an additional set of packages is just wrong IMO. Nevertheless, that might be required for a transitional phase. Matthias __ 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] [horizon] static files handling, bower/
Radomir Dopieralski openst...@sheep.art.pl writes: On 22/01/15 11:27, Martin Geisler wrote: Maybe this is a dumb question, but if there already is a system package for, say, Angular, why is the XStatic packge needed then? Could the system package for Horizon not just point directly to where the Angular package has put its files? Yes, that is *exactly* the change that we want to make now and that we are discussing! Drop the whole XStatic thing, and have a file in Horizon that configures all the paths. Then use Bower for downloading the files in development environments, and system packages in production. Heh, I see, sorry for not reading carefully enough then! -- Martin Geisler http://google.com/+MartinGeisler signature.asc Description: PGP signature __ 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] [horizon] static files handling, bower/
On 22/01/15 11:27, Martin Geisler wrote: Maybe this is a dumb question, but if there already is a system package for, say, Angular, why is the XStatic packge needed then? Could the system package for Horizon not just point directly to where the Angular package has put its files? Yes, that is *exactly* the change that we want to make now and that we are discussing! Drop the whole XStatic thing, and have a file in Horizon that configures all the paths. Then use Bower for downloading the files in development environments, and system packages in production. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On 21/01/15 19:04, Matthew Farina wrote: Radomir, thanks for adding some clarity. I do have follow-on questions. In your example the packages are managed by xstatic. The proposal for horizon, as I understand it, is to move away from xstatic packages and instead use bower for development and system packages (for example, debian, rpm, and other packages) for production. Right now, we (the horizon community) is maintaining some of the xstatic packages. For many of these xstatic packages there is no corollary in a system package. Who will create and maintain the system packages for the JavaScript libraries? You noted that we get maintenance and updates for free. Since the system packages don't exist now and we don't know who will create or maintain them I'm not sure how to reconcile this. What am I missing? All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On 22/01/15 09:48, Radomir Dopieralski wrote: All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. Yupp, poniting to system packages is something, which makes the XStatic approach way more acceptable. But, if you don't have them (yet), xstatic packages will bundle js libs for you. Matthias __ 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] [horizon] static files handling, bower/
Matthias Runge mru...@redhat.com writes: On 22/01/15 09:48, Radomir Dopieralski wrote: All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. Yupp, poniting to system packages is something, which makes the XStatic approach way more acceptable. Maybe this is a dumb question, but if there already is a system package for, say, Angular, why is the XStatic packge needed then? Could the system package for Horizon not just point directly to where the Angular package has put its files? -- Martin Geisler http://google.com/+MartinGeisler signature.asc Description: PGP signature __ 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] [horizon] static files handling, bower/
On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote: Has anyone done an inventory of xstatic packages that are available as system packages? I ask because I started asking these questions after doing a cursory inventory and finding few xstatic packages as system packages. [...] https://packages.debian.org/xstatic Found 41 matching packages. I believe the majority are due to distro efforts around packaging OpenStack. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
Radomir and Matthias, Has anyone done an inventory of xstatic packages that are available as system packages? I ask because I started asking these questions after doing a cursory inventory and finding few xstatic packages as system packages. It appeared to me that the common case was the one Matthias noted where the xstatic package bundles the js libs. That we're actually getting them from pypi or a mirror. Can someone show me there really are system packages to replace the xstatic packages? On Thu, Jan 22, 2015 at 5:15 AM, Matthias Runge mru...@redhat.com wrote: On 22/01/15 09:48, Radomir Dopieralski wrote: All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. Yupp, poniting to system packages is something, which makes the XStatic approach way more acceptable. But, if you don't have them (yet), xstatic packages will bundle js libs for you. Matthias __ 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] [horizon] static files handling, bower/
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com wrote: I would like to add one more nuance to this discussion that I don't remember seeing. JavaScript libraries run in web browser in their JavaScript engines (like v8) rather than on the server. A version of a JS library may be fine on a system, without any security issues, but contain browser issues. The version used matters more to the application and the web browsers consuming the application than to the system it's on. I think you're confusing Javascript in the browser vs. Javascript for node.js Those are two separate things. Javascript used in the browser is rarely (never in our case) used also for node.js development. There are even two separate packaging systems: bower is all about components for browsers, whereas npm is all about packages for node.js. Our discussion is about bower, and definitely not about npm or the node.js programming language. Some of the libraries exist as packages. For example, there are some debian packages. These have older versions of libraries than those that will work in Horizon. Thanks to packagers working with OpenStack we are able to get newer versions of the components we need once we have pinned them in our code. The libraries need to integrate for horizon and the browsers. So, supporting varying versions of a js library, their interactions together, and creating a usable interface will be a real problem. For example the debian packages of old or varying versions will a problem for those of us attempting to craft a UI. What's there isn't practically usable today. Some things are missing. It's entirely up to us to specify a pinned set of component versions that we need, which we then need the system packagers to ensure are available as deb or rpm. Gaps will be filled as part of the usual packaging efforts that go on during the OpenStack release cycle. Richard __ 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] [horizon] static files handling, bower/
I would like to add one more nuance to this discussion that I don't remember seeing. JavaScript libraries run in web browser in their JavaScript engines (like v8) rather than on the server. A version of a JS library may be fine on a system, without any security issues, but contain browser issues. The version used matters more to the application and the web browsers consuming the application than to the system it's on. Some of the libraries exist as packages. For example, there are some debian packages. These have older versions of libraries than those that will work in Horizon. The libraries need to integrate for horizon and the browsers. So, supporting varying versions of a js library, their interactions together, and creating a usable interface will be a real problem. For example the debian packages of old or varying versions will a problem for those of us attempting to craft a UI. What's there isn't practically usable today. Some things are missing. Does that help add clarity? On Thu, Jan 22, 2015 at 11:53 AM, Matthew Farina m...@mattfarina.com wrote: Radomir and Matthias, Has anyone done an inventory of xstatic packages that are available as system packages? I ask because I started asking these questions after doing a cursory inventory and finding few xstatic packages as system packages. It appeared to me that the common case was the one Matthias noted where the xstatic package bundles the js libs. That we're actually getting them from pypi or a mirror. Can someone show me there really are system packages to replace the xstatic packages? On Thu, Jan 22, 2015 at 5:15 AM, Matthias Runge mru...@redhat.com wrote: On 22/01/15 09:48, Radomir Dopieralski wrote: All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. Yupp, poniting to system packages is something, which makes the XStatic approach way more acceptable. But, if you don't have them (yet), xstatic packages will bundle js libs for you. Matthias __ 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] [horizon] static files handling, bower/
Jeremy, thanks for sharing this. I do have a couple more questions and comments based on this. When there is an update to our requirements, such as the recent version increment in the version of angular used, a new package version doesn't automatically show up as evident from that list. How would that process be kicked off so we don't end up with a missing dependency? Does that have to wait for a release cycle? Many of the xstatic packages are maintained by the OpenStack community. Just see the list in stackforge ( https://github.com/stackforge/?query=xstatic). Right now we need to update the xstatic package ourselves and then start using it. It also feels a little odd to maintain xstatic packages for pypi that we don't consume that way. This appears to affect the testing setup as well. When we start to use a new version of a JavaScript dependency no package will exist for it. I believe this would mean the testing environment needs to use the development setup, in the proposal, of bower. IIRC, bower goes out to the Internet and there isn't a mirror of packages (just a mirror of the registry). That means we'll loose the ability to run testing installs from local mirrors for these dependencies. I imagine a solution has been thought of for this. Can you share any details? Thanks, On Thu, Jan 22, 2015 at 2:35 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote: Has anyone done an inventory of xstatic packages that are available as system packages? I ask because I started asking these questions after doing a cursory inventory and finding few xstatic packages as system packages. [...] https://packages.debian.org/xstatic Found 41 matching packages. I believe the majority are due to distro efforts around packaging OpenStack. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
Richard, I'm quite familiar with node.js and browser development. I think some of the issue here may be a lack of detailed explanations and assumptions. By asking questions here I, and some others, have been learning details that we didn't know before. And, we're getting to follow from the intent from start to finish. I'm finding this to be incredibly revealing. Thanks, On Thu, Jan 22, 2015 at 3:47 PM, Richard Jones r1chardj0...@gmail.com wrote: On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com wrote: I would like to add one more nuance to this discussion that I don't remember seeing. JavaScript libraries run in web browser in their JavaScript engines (like v8) rather than on the server. A version of a JS library may be fine on a system, without any security issues, but contain browser issues. The version used matters more to the application and the web browsers consuming the application than to the system it's on. I think you're confusing Javascript in the browser vs. Javascript for node.js Those are two separate things. Javascript used in the browser is rarely (never in our case) used also for node.js development. There are even two separate packaging systems: bower is all about components for browsers, whereas npm is all about packages for node.js. Our discussion is about bower, and definitely not about npm or the node.js programming language. Some of the libraries exist as packages. For example, there are some debian packages. These have older versions of libraries than those that will work in Horizon. Thanks to packagers working with OpenStack we are able to get newer versions of the components we need once we have pinned them in our code. The libraries need to integrate for horizon and the browsers. So, supporting varying versions of a js library, their interactions together, and creating a usable interface will be a real problem. For example the debian packages of old or varying versions will a problem for those of us attempting to craft a UI. What's there isn't practically usable today. Some things are missing. It's entirely up to us to specify a pinned set of component versions that we need, which we then need the system packagers to ensure are available as deb or rpm. Gaps will be filled as part of the usual packaging efforts that go on during the OpenStack release cycle. Richard __ 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] [horizon] static files handling, bower/
On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote: [...] When there is an update to our requirements, such as the recent version increment in the version of angular used, a new package version doesn't automatically show up as evident from that list. How would that process be kicked off so we don't end up with a missing dependency? Does that have to wait for a release cycle? I don't want to speak for the distro package maintainers, but from what I've seen they generally wait until close enough to an integrated release that they can be pretty sure the requirements are close to frozen, so as not to waste effort packaging things which will end up not being used. Many of the xstatic packages are maintained by the OpenStack community. Just see the list in stackforge (https://github.com/stackforge/?query=xstatic). Right now we need to update the xstatic package ourselves and then start using it. It also feels a little odd to maintain xstatic packages for pypi that we don't consume that way. I assume (perhaps incorrectly?) that we do use those in CI jobs, so that we can download the things a given project needs in an automated fashion--for us handling pip requirements lists is a solved problem (well, for some definitions of solved at least). This appears to affect the testing setup as well. When we start to use a new version of a JavaScript dependency no package will exist for it. I believe this would mean the testing environment needs to use the development setup, in the proposal, of bower. IIRC, bower goes out to the Internet and there isn't a mirror of packages (just a mirror of the registry). That means we'll loose the ability to run testing installs from local mirrors for these dependencies. I imagine a solution has been thought of for this. Can you share any details? I am not aware of what the solution for this would be, but it will be a show-stopper for the plan and so I (Infra hat on) would expect the horizon developers to come up with an implementation which solves that. Perhaps some routine to retrieve and pre-cache the necessary files like we do with a lot of the random files devstack uses, and then run that during image build time so that it's already present on the filesystems of the machines which will run the jobs needing it? -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
Radomir, thanks for adding some clarity. I do have follow-on questions. In your example the packages are managed by xstatic. The proposal for horizon, as I understand it, is to move away from xstatic packages and instead use bower for development and system packages (for example, debian, rpm, and other packages) for production. Right now, we (the horizon community) is maintaining some of the xstatic packages. For many of these xstatic packages there is no corollary in a system package. Who will create and maintain the system packages for the JavaScript libraries? You noted that we get maintenance and updates for free. Since the system packages don't exist now and we don't know who will create or maintain them I'm not sure how to reconcile this. What am I missing? On Wed, Jan 21, 2015 at 3:04 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 20/01/15 20:58, Matthew Farina wrote: Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. Any distribution (perhaps except Ubuntu, which is a little funny in that regard) that has packaged the latest release of OpenStack, has those libraries. For instance, see http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/python-django-horizon.spec#n129 Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Certainly. The XStatic system itself is lifted from MoinMoin wiki, for example -- it was created to solve exactly this problem there, and is used by a couple of other projects too. As for our work and updates, using system-wide packages is an excellent solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
Martin, django_compressor does handles creating aggregated and compressed files for you. This isn't quite the same as C programs because it's not just due to file size. For example, if you have 2 files many browsers will make two separate connections to get each file. That mean negotiating a connection (can include tls), and pulling down the file dealing with TCP slow-start. This means one larger file is faster to download then multiple files that are smaller in overall size. To get a 304 Not Modified message you'll need to make sure your web server is handling that. I've encountered horizon instances where 304 Not Modified messages aren't happening. Cheers, Matt Farina On Wed, Jan 21, 2015 at 5:40 AM, Martin Geisler mar...@geisler.net wrote: Matthias Runge mru...@redhat.com writes: On 21/01/15 09:59, Martin Geisler wrote: This seems to imply that users will download at least one .js file per dependency. Not necessarily. We still use django-compressor, which copies all javascript into fewer files. E.g. here in my untweaked juno environment, I just get 3 instead of 10-15 following your logic above. (at least one js file per xstatic package). Cool, I did not know about this! Radomir said that this is run in a post-install hook for Horizon and that he's unsure how or if the distros re-run the scripts when the dependencies are installed. That is, if an updated version of the js-foo package is installed, all apps that depend on js-foo would need to have their JS bundles refreshed. Or maybe it's simply run every time Horizon is started? That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. see above :D I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages dynamic linking. I'm not sure, I can really follow you here. I was trying to draw a parallel to how traditional (C) programs use dynamic when loading -- perfect for distributions since this allows them to patch a security problem just once and know that all programs that use the affected library will get the update since they dynamically load the library at runtime. Contrast this with static linking -- which is normally discouraged or forbidden by distributions since you'll have to recompile all dependant programs when you patch a library. I was thinking that web apps look like statically linked programs when they're deployed using compressed and minified sources for maximum performance. Let me add that this kind of optimization matters the most if your visitors who only visit the app once or rarely. With a file per dependency, they'll get poor performance since their browser won't have cached the files. For an app like Horizon it might not be as important: even if it loads a little slow on your first visit, you're likely to visit it many times as you admin your deployment and those subsequent visits will be faster. Still not as fast as they would be if the server could reply with a single 304 Not Modified, but probably fast enough. -- Martin Geisler http://google.com/+MartinGeisler __ 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] [horizon] static files handling, bower/
Matthias Runge mru...@redhat.com writes: On 21/01/15 09:59, Martin Geisler wrote: This seems to imply that users will download at least one .js file per dependency. Not necessarily. We still use django-compressor, which copies all javascript into fewer files. E.g. here in my untweaked juno environment, I just get 3 instead of 10-15 following your logic above. (at least one js file per xstatic package). Cool, I did not know about this! Radomir said that this is run in a post-install hook for Horizon and that he's unsure how or if the distros re-run the scripts when the dependencies are installed. That is, if an updated version of the js-foo package is installed, all apps that depend on js-foo would need to have their JS bundles refreshed. Or maybe it's simply run every time Horizon is started? That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. see above :D I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages dynamic linking. I'm not sure, I can really follow you here. I was trying to draw a parallel to how traditional (C) programs use dynamic when loading -- perfect for distributions since this allows them to patch a security problem just once and know that all programs that use the affected library will get the update since they dynamically load the library at runtime. Contrast this with static linking -- which is normally discouraged or forbidden by distributions since you'll have to recompile all dependant programs when you patch a library. I was thinking that web apps look like statically linked programs when they're deployed using compressed and minified sources for maximum performance. Let me add that this kind of optimization matters the most if your visitors who only visit the app once or rarely. With a file per dependency, they'll get poor performance since their browser won't have cached the files. For an app like Horizon it might not be as important: even if it loads a little slow on your first visit, you're likely to visit it many times as you admin your deployment and those subsequent visits will be faster. Still not as fast as they would be if the server could reply with a single 304 Not Modified, but probably fast enough. -- Martin Geisler http://google.com/+MartinGeisler signature.asc Description: PGP signature __ 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] [horizon] static files handling, bower/
On 20/01/15 20:58, Matthew Farina wrote: Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. Any distribution (perhaps except Ubuntu, which is a little funny in that regard) that has packaged the latest release of OpenStack, has those libraries. For instance, see http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/python-django-horizon.spec#n129 Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Certainly. The XStatic system itself is lifted from MoinMoin wiki, for example -- it was created to solve exactly this problem there, and is used by a couple of other projects too. As for our work and updates, using system-wide packages is an excellent solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On 21/01/15 09:21, david.co...@oracle.com wrote: As for our work and updates, using system-wide packages is an excellent solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. But for distributions that package Horizon itself, don't they effectively need to patch Horizon? Namely, don't they need to install on their build systems fixed JavaScript distribution packages to address the security issue and then they need to rebuild Horizon itself even if there are no Horizon source code changes. From a Horizon end-user perspective who relies on the distribution's packages to get Horizon, they'll get the security fix but it seems distributors will still need to rebuild and deliver Horizon for every upstream JavaScript fix whether the files come from XStatic, Bower, or some other method. No, why would they? They don't copy the static files into the Horizon's package. That's the whole point, Horizon only has paths to them. The files themselves are provided by the system-wide packages. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
Radomir Dopieralski openst...@sheep.art.pl writes: On 21/01/15 09:21, david.co...@oracle.com wrote: As for our work and updates, using system-wide packages is an excellent solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. But for distributions that package Horizon itself, don't they effectively need to patch Horizon? Namely, don't they need to install on their build systems fixed JavaScript distribution packages to address the security issue and then they need to rebuild Horizon itself even if there are no Horizon source code changes. From a Horizon end-user perspective who relies on the distribution's packages to get Horizon, they'll get the security fix but it seems distributors will still need to rebuild and deliver Horizon for every upstream JavaScript fix whether the files come from XStatic, Bower, or some other method. No, why would they? They don't copy the static files into the Horizon's package. That's the whole point, Horizon only has paths to them. The files themselves are provided by the system-wide packages. This seems to imply that users will download at least one .js file per dependency. That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages dynamic linking. -- Martin Geisler http://google.com/+MartinGeisler signature.asc Description: PGP signature __ 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] [horizon] static files handling, bower/
On 21/01/15 09:59, Martin Geisler wrote: This seems to imply that users will download at least one .js file per dependency. Not necessarily. We still use django-compressor, which copies all javascript into fewer files. E.g. here in my untweaked juno environment, I just get 3 instead of 10-15 following your logic above. (at least one js file per xstatic package). That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. see above :D I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages dynamic linking. I'm not sure, I can really follow you here. Matthias __ 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] [horizon] static files handling, bower/
As for our work and updates, using system-wide packages is an excellent solution in this regard, as we get maintenance and updates for free. For instance, if there is a security issue in one of the JavaScript libraries, we don't need to patch Horizon -- the patch that is prepared for that specific library and applied system-wide is sufficient. But for distributions that package Horizon itself, don't they effectively need to patch Horizon? Namely, don't they need to install on their build systems fixed JavaScript distribution packages to address the security issue and then they need to rebuild Horizon itself even if there are no Horizon source code changes. From a Horizon end-user perspective who relies on the distribution's packages to get Horizon, they'll get the security fix but it seems distributors will still need to rebuild and deliver Horizon for every upstream JavaScript fix whether the files come from XStatic, Bower, or some other method. __ 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] [horizon] static files handling, bower/
Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Thanks, Matt On Mon, Jan 19, 2015 at 3:45 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 16/01/15 18:55, Matthew Farina wrote: Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. You are mistaken here. It's actually the other way around. Fedora and Debian packagers used to do heroic work with previous releases to unbundle the static files from Horizon and link to the system-wide JavaScript libraries installed from packages, because their packaging policies require that. The introduction of XStatic was supposed to merely simplify and formalize that process, but now it turns out that it is redundant, and we can cut a corner and save the packagers having to create all those dummy XStatic shims. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On Wed Jan 21 2015 at 7:00:12 AM Matthew Farina m...@mattfarina.com wrote: Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. I'm not a user of these packaging systems, but I found this, which I believe shows the javascript system packages used: https://packages.debian.org/sid/openstack-dashboard Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Horizon is not a typical web front end system, it's part of OpenStack, and thus has to abide by OpenStack packaging conventions. Those dictate that we must have Horizon packaged by system packagers for deployment. Richard __ 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] [horizon] static files handling, bower/
On 16/01/15 18:55, Matthew Farina wrote: Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. You are mistaken here. It's actually the other way around. Fedora and Debian packagers used to do heroic work with previous releases to unbundle the static files from Horizon and link to the system-wide JavaScript libraries installed from packages, because their packaging policies require that. The introduction of XStatic was supposed to merely simplify and formalize that process, but now it turns out that it is redundant, and we can cut a corner and save the packagers having to create all those dummy XStatic shims. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On Jan 15, 2015, at 7:27 PM, Michael Krotscheck krotsch...@gmail.com wrote: I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? Well, normally the argument I've received is We don't have the time/resources/insert-other-fiscally-motivated-reason to support/work on node. Ergo, money. But then, given Oracle's conduct around the whole Java ridiculousness I'm not exactly favorably disposed towards anything or anyone associated with them. They'd get a lot more respect if they open-sourced Solaris. Which actually reminds me of something: Infra only tests against Debian, CentOS, and Fedora. It does not test Solaris. So, no offense, but I don't care about your SPARC servers. ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. I haven't missed it, I just made the assumption that if someone wants to use a tool, they would be busy porting that tool rather than arguing on a list about it. Case and point: I wanted to use javascript in OpenStack Infra, so I did a ton of legwork to bring node, npm, bower, karma, jasmine, protractor, and grunt into the infra toolchain. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. It has everything to do with it: There are javascript engineers that want to use their tools, just like there are python engineers that want to user their tools. You're saying we can't use javascript tools because of SPARC's lack of support. I'm merely asking that our python engineers reciprocate and abandon your own tools out of solidarity. After all, we're all in this together, right? We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? Doug [1] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054538.html Michael __ 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] [horizon] static files handling, bower/
On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. -Drew __ 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] [horizon] static files handling, bower/
Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? We only support what we test. Unless I missed something, there are no platforms, relevant to horizon and openstack, in where nodejs is not supported natively. - Fedora 18 and later have a native nodejs package, infra offers versions 20/21. - CentOS delivers a native package via EPEL as of version 5. Infra includes the EPEL repository and offers CentOS 6/7. - Debian offers it as of Wheezy, Ubuntu as of Trusty. Infra's in the process of deprecating most of our Precise nodes, which I believe we're only keeping around for our python3.3 jobs (3.4 is already on trusty). Horizon only tests Python 2.7. Michael __ 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] [horizon] static files handling, bower/
On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! Doug __ 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] [horizon] static files handling, bower/
Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. Updating a JavaScript dependency, such as angular, would mean each of the system packages needs to be updated as well as the Horizon project. Would would this process look like with packages on different systems needing updates? Using bower for development and system packages for production doesn't appear to be ready to start using. On Fri, Jan 16, 2015 at 12:09 PM, Doug Hellmann d...@doughellmann.com wrote: On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! Doug __ 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] [horizon] static files handling, bower/
On Jan 16, 2015, at 12:55 PM, Matthew Farina m...@mattfarina.com wrote: Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. Updating a JavaScript dependency, such as angular, would mean each of the system packages needs to be updated as well as the Horizon project. Would would this process look like with packages on different systems needing updates? Using bower for development and system packages for production doesn't appear to be ready to start using. We have, so far, relied on the distributors to build packages in whatever way works for their tools. What is it about JavaScript libraries that makes packaging them “unusual”? If we’re going to continue to rely on distributors to handle the packaging, the next step is to get some of the distribution packagers to chime in on what else might be useful to make their jobs easier. We’ve collaborated in the past by adding features or writing some of our own tools (that’s part of what led to pbr being created for python packages, for example). This thread is fairly long, so you might want to start a new one with an appropriate subject line to attract the right input. Was there a spec for this work? If not, that would be useful to have. On Fri, Jan 16, 2015 at 12:09 PM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com mailto:drew.fis...@oracle.com wrote: On 1/16/15 9:08 AM, Doug Hellmann wrote: We are, and as this conversation has veered off in a destructive direction, I think we should back up and look at the compromise Radomir posted [1] to see if that solves the original technical problem we all have. Does having the requirements specified in a JSON file, without requiring a specific build tool to install the files, solve the packaging, testing, and deployment issue on platforms where node.js isn’t supported natively right now? For Solaris, yes. We can make that work. Thanks, Radomir for the suggestion. Great! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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 __ 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] [horizon] static files handling, bower/
I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? Well, normally the argument I've received is We don't have the time/resources/insert-other-fiscally-motivated-reason to support/work on node. Ergo, money. But then, given Oracle's conduct around the whole Java ridiculousness I'm not exactly favorably disposed towards anything or anyone associated with them. They'd get a lot more respect if they open-sourced Solaris. Which actually reminds me of something: Infra only tests against Debian, CentOS, and Fedora. It does not test Solaris. So, no offense, but I don't care about your SPARC servers. ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. I haven't missed it, I just made the assumption that if someone wants to use a tool, they would be busy porting that tool rather than arguing on a list about it. Case and point: I wanted to use javascript in OpenStack Infra, so I did a ton of legwork to bring node, npm, bower, karma, jasmine, protractor, and grunt into the infra toolchain. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. It has everything to do with it: There are javascript engineers that want to use their tools, just like there are python engineers that want to user their tools. You're saying we can't use javascript tools because of SPARC's lack of support. I'm merely asking that our python engineers reciprocate and abandon your own tools out of solidarity. After all, we're all in this together, right? Michael __ 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] [horizon] static files handling, bower/
All we need is to have someone spend some time to make it possible to have a common meta files(configs, package descriptions, etc.) so that they can be interchangeable and used by both Bower and pip, e.g. some tool to sync changes made in one config and adding it to another. Then - whoever prefers Bower - will use Bower, that's mostly for development, and whoever prefers pip - will use pip. Ideally, it seems fine to have the static files into separate git repo(s), as it is now in XStatic. I'll try to make an (incomplete or maybe not so correct) list of the stages a static file goes through: 1. Development - all we need is versions of uncompressed js and css files. We can On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote: I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Not to belabor the thread, but yes, of course JavaScript is very relevant to Oracle, Solaris, our customers/partners, etc. And that includes both client and server-side. As Drew stated, as of this moment we haven't yet made Node.js available on SPARC but I expect that to change in the future. But the question or potential concern remains as to whether adding a non-Python/pip build dependency makes sense. I'm not particularly well-versed in the Horizon build process so perhaps I'm way off base. But given that a distribution's Horizon build package embeds various JavaScript libraries to be used by the browser, how those libraries are obtained during the build process is an interesting build detail. I thought the intent of the XStatic work was to provide Python wrappers around the various JavaScript libraries so they could be pulled down via pip. Since there's already a Python requirements.txt file for versioning information, that seemed to be a nice way of indicating which versions of the JavaScript libraries could be used by Horizon and Python was used all the way through the build. I realize that it takes work to build the XStatic packages but given the Python packages are basically wrappers, it seems creating those and uploading them to pypi could be automated by using Bower and setup.py but perhaps translating the metadata isn't straightforward. __ 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 -- Regards, Tihomir Trifonov __ 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] [horizon] static files handling, bower/
Ops, sent the prev mail before finishing it... 1. Development - all we need is versions of uncompressed js and css files. We can use bower or pip requirements to get specific versions. 2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or grunt and to run tests on that. Is is possible to have both configurations for grunt and pyscss ? 3. Packaging - again - 'uglifyng' some scripts and css to make packages contain ready for production static files. This seems like quite work to prepare the whole environment, but will it work for the needs we have? On Thu, Jan 15, 2015 at 10:12 AM, Tihomir Trifonov t.trifo...@gmail.com wrote: All we need is to have someone spend some time to make it possible to have a common meta files(configs, package descriptions, etc.) so that they can be interchangeable and used by both Bower and pip, e.g. some tool to sync changes made in one config and adding it to another. Then - whoever prefers Bower - will use Bower, that's mostly for development, and whoever prefers pip - will use pip. Ideally, it seems fine to have the static files into separate git repo(s), as it is now in XStatic. I'll try to make an (incomplete or maybe not so correct) list of the stages a static file goes through: 1. Development - all we need is versions of uncompressed js and css files. We can On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote: I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Not to belabor the thread, but yes, of course JavaScript is very relevant to Oracle, Solaris, our customers/partners, etc. And that includes both client and server-side. As Drew stated, as of this moment we haven't yet made Node.js available on SPARC but I expect that to change in the future. But the question or potential concern remains as to whether adding a non-Python/pip build dependency makes sense. I'm not particularly well-versed in the Horizon build process so perhaps I'm way off base. But given that a distribution's Horizon build package embeds various JavaScript libraries to be used by the browser, how those libraries are obtained during the build process is an interesting build detail. I thought the intent of the XStatic work was to provide Python wrappers around the various JavaScript libraries so they could be pulled down via pip. Since there's already a Python requirements.txt file for versioning information, that seemed to be a nice way of indicating which versions of the JavaScript libraries could be used by Horizon and Python was used all the way through the build. I realize that it takes work to build the XStatic packages but given the Python packages are basically wrappers, it seems creating those and uploading them to pypi could be automated by using Bower and setup.py but perhaps translating the metadata isn't straightforward. __ 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 -- Regards, Tihomir Trifonov -- Regards, Tihomir Trifonov __ 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] [horizon] static files handling, bower/
On 14/01/15 23:05, david.co...@oracle.com wrote: I'm not particularly well-versed in the Horizon build process so perhaps I'm way off base. But given that a distribution's Horizon build package embeds various JavaScript libraries to be used by the browser, how those libraries are obtained during the build process is an interesting build detail. I thought the intent of the XStatic work was to provide Python wrappers around the various JavaScript libraries so they could be pulled down via pip. Since there's already a Python requirements.txt file for versioning information, that seemed to be a nice way of indicating which versions of the JavaScript libraries could be used by Horizon and Python was used all the way through the build. I realize that it takes work to build the XStatic packages but given the Python packages are basically wrappers, it seems creating those and uploading them to pypi could be automated by using Bower and setup.py but perhaps translating the metadata isn't straightforward. This has actually been discussed. The problem is, that it adds considerable complexity and some amount of work, while solves exactly zero problems. You are just sweeping the node.js dependency under the rug, because now, instead of being a direct dependency (for development) of Horizon, it becomes a dependency (for building) of a package that Horizon is dependent on. That doesn't solve anything, since all distributions insist on building their own packages from sources, not relying on pre-built binaries. So what we settled on is a compromise. Horizon will not care *how* the static files got there. Whether you put them there by hand, use Bower, or install your distribution's packages -- Horizon doesn't care. And neither do the tests written for Horizon, or the build scripts. They just assume the files are where you configured them. Period. Let me repeat that: ***You will not need Node.js or Bower to build and test Horizon.*** The packagers for different distributions will want to make packages for the JavaScript and CSS libraries on their own anyways, and they will want to test Horizon with those -- not with what Bower installs. The only place where you will need Bower (but only for convenience, as you may as well install everything manually or with your own scripts) is the development machine. For convenience, we will keep the list of dependencies in a format compatible with Bower -- but it's a simple JSON file that can be read by any other tool or script, written in any language. I hope that clears it. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On 1/14/15 11:49 AM, Michael Krotscheck wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Under no circumstances am I refusing to use it. I stated in my original email ... ---8--- For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. ---8--- ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. I continued this thread because we came across the and the blueprint suggesting moving to using Bower rather than XStatic and I'm attempting to voice the concerns we have for moving to Node. It may be that nothing can be done in the short term (for Kilo) with the long term action being to get Node ported to SPARC. -Drew __ 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] [horizon] static files handling, bower/
Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. I think Oracle's got enough money to support Node.js on SPARC. I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Don't get me wrong: Node.js run as a server is a horrible, horrible idea, and I *like* javascript. But then, running PHP3 on a server is *also* a horrible, horrible idea, but that didn't really stop anyone 15 years ago. The same goes for lots of other languages. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? Michael __ 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] [horizon] static files handling, bower/
I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Not to belabor the thread, but yes, of course JavaScript is very relevant to Oracle, Solaris, our customers/partners, etc. And that includes both client and server-side. As Drew stated, as of this moment we haven't yet made Node.js available on SPARC but I expect that to change in the future. But the question or potential concern remains as to whether adding a non-Python/pip build dependency makes sense. I'm not particularly well-versed in the Horizon build process so perhaps I'm way off base. But given that a distribution's Horizon build package embeds various JavaScript libraries to be used by the browser, how those libraries are obtained during the build process is an interesting build detail. I thought the intent of the XStatic work was to provide Python wrappers around the various JavaScript libraries so they could be pulled down via pip. Since there's already a Python requirements.txt file for versioning information, that seemed to be a nice way of indicating which versions of the JavaScript libraries could be used by Horizon and Python was used all the way through the build. I realize that it takes work to build the XStatic packages but given the Python packages are basically wrappers, it seems creating those and uploading them to pypi could be automated by using Bower and setup.py but perhaps translating the metadata isn't straightforward. __ 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] [horizon] static files handling, bower/
On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew __ 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] [horizon] static files handling, bower/
On 2015-01-14 17:25:46 +0400 (+0400), Anton Zemlyanov wrote: Solaris is supported by node.js: Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/ node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/ node-v0.10.35-sunos-x64.tar.gz I believe the point made was that without SPARC (probably only the 64-bit variant these days but still) support, that's not enough. Solaris targets more than just Intel's processors. (So does Linux for that matter!) I think Solaris is no longer relevant The Solaris developer community probably disagrees with you on this point. ;) -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
On 01/14/2015 09:14 AM, Matthew Farina wrote: I think we're discussing two different situations with slightly different requirements. First, there is development and test. I believe the stated goal is to have node.js here. Would an environment not supporting node.js be needed for development or testing? Note, the JavaScript under test and to be executed by users is in browser rather than server side. The important execution environment is in their browser. The second environment is production. In that case the system packages would be used. What's still unclear is who creates and maintains those packages since many of them don't exist today. On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew Seems to me like you'd want to test using packages for SPARC, not using a dev sort of environment. Packages again for production. My two cents is that you need to contribute to the node community if you require SPARC compatibility for node for development, since SPARC is an outlier. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen __ 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] [horizon] static files handling, bower/
I think we're discussing two different situations with slightly different requirements. First, there is development and test. I believe the stated goal is to have node.js here. Would an environment not supporting node.js be needed for development or testing? Note, the JavaScript under test and to be executed by users is in browser rather than server side. The important execution environment is in their browser. The second environment is production. In that case the system packages would be used. What's still unclear is who creates and maintains those packages since many of them don't exist today. On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew __ 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] [horizon] static files handling, bower/
Solaris is supported by node.js: Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant On Tue, Jan 13, 2015 at 7:13 PM, Drew Fisher drew.fis...@oracle.com wrote: On 1/13/15 7:59 AM, Jeremy Stanley wrote: On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. -Drew __ 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] [horizon] static files handling, bower/
On 13/01/15 16:13, Drew Fisher wrote: On 1/13/15 7:59 AM, Jeremy Stanley wrote: On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. I have some bad news for you. Horizon already uses node.js for running jshint on its JavaScript files on the gate. Simply because there is no other alternative. You are welcome to work on and propose a better solution. -- Radomir Dopieralski __ 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] [horizon] static files handling, bower/
On 13/01/15 16:31, Jeremy Stanley wrote: On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote: [...] Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. I disagree. If those libraries aren't developed as part of Horizon then they should not be copied into and distributed as part of its source tree. That's code duplication, plain and simple. I'm in favor of cleaning out all the vendoring of third-party libraries in OpenStack projects, but agree that it would be nice to find a cross-platform/portable mechanism for handling them. Yes! Keeping libraries separate, makes maintaining stuff so much easier. You don't need to persuade me here. I completely agree. Matthias __ 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] [horizon] static files handling, bower/
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
On 1/13/15 7:59 AM, Jeremy Stanley wrote: On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. -Drew __ 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] [horizon] static files handling, bower/
On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote: [...] Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. I disagree. If those libraries aren't developed as part of Horizon then they should not be copied into and distributed as part of its source tree. That's code duplication, plain and simple. I'm in favor of cleaning out all the vendoring of third-party libraries in OpenStack projects, but agree that it would be nice to find a cross-platform/portable mechanism for handling them. -- Jeremy Stanley __ 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] [horizon] static files handling, bower/
On 12/18/14 6:58 AM, Radomir Dopieralski wrote: Hello, revisiting the package management for the Horizon's static files again, I would like to propose a particular solution. Hopefully it will allow us to both simplify the whole setup, and use the popular tools for the job, without losing too much of benefits of our current process. The changes we would need to make are as follows: * get rid of XStatic entirely; * add to the repository a configuration file for Bower, with all the required bower packages listed and their versions specified; I know I'm very very late to this thread but can I ask why Bower? Bower has a hard requirement on Node.js which was removed as a dependency in Havana. Why are we reintroducing this requirement? For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. I agree that XStatic isn't really the best solution here but are there any other solutions that don't involve Node.js? Thanks. -Drew __ 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] [horizon] static files handling, bower/
On 12/01/15 21:53, Drew Fisher wrote: I know I'm very very late to this thread but can I ask why Bower? Bower has a hard requirement on Node.js which was removed as a dependency in Havana. Why are we reintroducing this requirement? For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. I agree that XStatic isn't really the best solution here but are there any other solutions that don't involve Node.js? The same is true for ARM based machines, as node.js is AFAIK x86 only. But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. Bower is just another package manager, comparable to npm, pip etc. if you use that aside your systems package manager. The idea is, to use something like dpkg or rpm to provide dependencies for installation. During development and testing, it's proposed to rely on bower to install dependencies. Matthias __ 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] [horizon] static files handling, bower/
Thanks, Radomir. How much detail from this discussion should be captured in the blueprint? I'm afraid I'm more familiar with the Python PEP process. On Thu Jan 08 2015 at 11:38:57 PM Radomir Dopieralski openst...@sheep.art.pl wrote: On 06/01/15 01:53, Richard Jones wrote: I think the only outstanding question is how developers and non-packagers populate the bower_components directory - that is, how is bower expected to be available for them? I think following the Storyboard approach is a good idea: isolate a known-working node/bower environment local to horizon which is managed by tox - so to invoke bower you run tox -e bower command. No worries about system installation or compatibility, and works in the gate. Horizon installation (whenever a pip install would be invoked) would then also have a tox -e bower install invocation. Storyboard[1] uses a thing called nodeenv[2] which is installed through pip / requirements.txt to control the node environment. It then has bower commands in tox.ini[3] (though I'd just have a single bower environment to implement the tox command I suggest above. Richard [1] https://wiki.openstack.org/wiki/StoryBoard [2] https://pypi.python.org/pypi/nodeenv [3] https://git.openstack.org/cgit/openstack-infra/ storyboard-webclient/tree/tox.ini I created a blueprint for this. https://blueprints.launchpad.net/horizon/+spec/static-file-bower -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 06/01/15 01:53, Richard Jones wrote: I think the only outstanding question is how developers and non-packagers populate the bower_components directory - that is, how is bower expected to be available for them? I think following the Storyboard approach is a good idea: isolate a known-working node/bower environment local to horizon which is managed by tox - so to invoke bower you run tox -e bower command. No worries about system installation or compatibility, and works in the gate. Horizon installation (whenever a pip install would be invoked) would then also have a tox -e bower install invocation. Storyboard[1] uses a thing called nodeenv[2] which is installed through pip / requirements.txt to control the node environment. It then has bower commands in tox.ini[3] (though I'd just have a single bower environment to implement the tox command I suggest above. Richard [1] https://wiki.openstack.org/wiki/StoryBoard [2] https://pypi.python.org/pypi/nodeenv [3] https://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/tox.ini I created a blueprint for this. https://blueprints.launchpad.net/horizon/+spec/static-file-bower -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 06/01/15 18:39, Lin Hua Cheng wrote: Radomir, The current version of Angular were using in Horizon still does not have cookie and mock packages: https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data We still need to do it the long way: 1. Update the Angular version in global-requirements 2. Wait till it gets merge and propagate to horizon requirements 3. Remove references loading of mock and cookie packages in horizon and horizon requirement 4. Remove mock and cookie from global-requirements. That's strange, I thought that we use 1.2.16 already. Sorry for my mistake. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
Radomir, The current version of Angular were using in Horizon still does not have cookie and mock packages: https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data We still need to do it the long way: 1. Update the Angular version in global-requirements 2. Wait till it gets merge and propagate to horizon requirements 3. Remove references loading of mock and cookie packages in horizon and horizon requirement 4. Remove mock and cookie from global-requirements. -Lin On Tue, Jan 6, 2015 at 1:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
Thanks, Radomir. I originally started a patch on Horizon and was going to do that, but was guided to update global requirements first. I¹ll go ahead and redo that patch on Horizon. -Travis On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I¹m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I¹m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn¹t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don¹t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is populated by a developer (as opposed to a
packager, which you described).
It's not, the developer version is included in the repository, and
simply points to where Bower is configured to put the files.
So just to be clear, as developers we:
1. have a bower.json listing the bower component to use,
2. use bower to fetch and install those to the bower_components
directory at the top level of the Horizon repos checkout, and
3. manually edit static_settings.py when we add a new bower component to
bower.json so it knows the appropriate static files to load from that
component.
Is that correct?
The above will increase the burden on those adding or upgrading bower
components (they'll need to check the bower.json in the component for
the appropriate static files to link in) but will make life easier for
the re-packagers since they'll know which files they need to cater for
in static_settings.py
Well, I expect you can tell Bower to put the files somewhere else than
in the root directory of the project -- a directory like ``bower_files``
or something (that directory is also added to ``.gitignore`` so that you
don't commit it by mistake). Then only that directory needs to be added
to the ``static_settings.py``. Of course, you still need to make all the
``script`` links in appropriate places with the right URLs, but you
would have to do that anyways.
Let's look at an example. Suppose you need to a new JavaScript library
called hipster.js. You add it to the ``bower.json`` file, and run
Bower. Bower downloads the right files and does whatever it is that it
does to them, and puts them in ``bower_files/hipster-js``. Now you edit
Horizon's templates and add ``script src={{ STATIC_URL
}}/hipster-js/hipster.js`` to ``_scripts.html``. That's it for you.
Since your ``static_settings.py`` file already has a line:
('', os.path.join(BASE_DIR, '/bower_files')),
in it, it will just work.
Now, suppose that a packager wants to package this for, say, Debian. And
suppose that Debian has hipster.js packaged, except it was called
bro.js before, and they left the old name for compatibility reasons.
He will look at the change history to the ``bower.json`` and the
``_scripts.html`` files, take the ``static_settings.py`` file for his
distribution, and add a line:
('hipster-js/hipster.js', '/usr/lib/js_libraries/bro_js/bro.js'),
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is populated by a developer (as opposed to
a
packager, which you described).
It's not, the developer version is included in the repository, and
simply points to where Bower is configured to put the files.
So just to be clear, as developers we:
1. have a bower.json listing the bower component to use,
2. use bower to fetch and install those to the bower_components
directory at the top level of the Horizon repos checkout, and
3. manually edit static_settings.py when we add a new bower component to
bower.json so it knows the appropriate static files to load from that
component.
Is that correct?
The above will increase the burden on those adding or upgrading bower
components (they'll need to check the bower.json in the component for
the appropriate static files to link in) but will make life easier for
the re-packagers since they'll know which files they need to cater for
in static_settings.py
Well, I expect you can tell Bower to put the files somewhere else than
in the root directory of the project -- a directory like ``bower_files``
or something (that directory is also added to ``.gitignore`` so that you
don't commit it by mistake). Then only that directory needs to be added
to the ``static_settings.py``. Of course, you still need to make all the
``script`` links in appropriate places with the right URLs, but you
would have to do that anyways.
Bower installs into a directory called bower_components in the current
directory, which is equivalent to your bower_files above.
Let's look at an example. Suppose you need to a new JavaScript library
called hipster.js. You add it to the ``bower.json`` file, and run
Bower. Bower downloads the right files and does whatever it is that it
does to them, and puts them in ``bower_files/hipster-js``. Now you edit
Horizon's templates and add ``script src={{ STATIC_URL
}}/hipster-js/hipster.js`` to ``_scripts.html``. That's it for you.
Since your ``static_settings.py`` file already has a line:
('', os.path.join(BASE_DIR, '/bower_files')),
in it, it will just work.
Yep, except s/bower_files/bower_components :)
Now, suppose that a packager wants to package this for, say, Debian. And
suppose that Debian has hipster.js packaged, except it was called
bro.js before, and they left the old name for compatibility reasons.
He will look at the change history to the ``bower.json`` and the
``_scripts.html`` files, take the ``static_settings.py`` file for his
distribution, and add a line:
('hipster-js/hipster.js', '/usr/lib/js_libraries/bro_js/bro.js')
Ah! I had forgotten about that feature. Yep, all good :)
Richard
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
What Radomir proposes looks like it would greatly ease the process I am still
going through to get the latest angular available to Horizon for current
development. At the time of writing this, I’m still trying to get the updated
library through. I hit a rather difficult workflow:
1. Packaged the latest into Xstatic-Angular-1.3.7
2. Submitted patch which deprecated the separate older
xstatic-angular-cookies and xstatic-angular-mock packages
3. Reviewed and approved (after correcting an initial mis-repackaging)
4. Radomir released to Pypi
This was pretty easy and not too hard. Not too much to complain about.
However, now, to get Horizon to use it, I have to get that into global
requirements. Since I’m deprecating old packages I got stuck in a sort of ugly
dependency path. I couldn’t remove the cookies and mock libraries from the
global requirements patch that added the new 1.3.7 package because of horizon
still referencing the deprecated packages. And, when I did it anyway, the
integration tests failed due to horizon being dependent on something not in
global requirements. So, now, as far as I can tell we have to jump through the
following hoops:
1. Global requirements patch to add angular 1.3.7
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and
cookies packages
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
3. Global requirements patch to remove deprecated mock and cookies
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
Don’t get me wrong, I really do think the gate is brilliant and am all for a
review / approval process, but this does seem excessive for a UI library that
should only be used by Horizon. Is there some other reason that this should
have to go through global requirements?
Thanks,
Travis
From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote:
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.plmailto:openst...@sheep.art.pl
mailto:openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is populated by a developer (as opposed to a
packager, which you described).
It's not, the developer version is included in the repository, and
simply points to where Bower is configured to put the files.
So just to be clear, as developers we:
1. have a bower.json listing the bower component to use,
2. use bower to fetch and install those to the bower_components
directory at the top level of the Horizon repos checkout, and
3. manually edit static_settings.py when we add a new bower component to
bower.json so it knows the appropriate static files to load from that
component.
Is that correct?
The above will increase the burden on those adding or upgrading bower
components (they'll need to check the bower.json in the component for
the appropriate static files to link in) but will make life easier for
the re-packagers since they'll know which files they need to cater for
in static_settings.py
Well, I expect you can tell Bower to put the files somewhere else than
in the root directory of the project -- a directory like ``bower_files``
or something (that directory is also added to ``.gitignore`` so that you
don't commit it by mistake). Then only that directory needs to be added
to the ``static_settings.py``. Of course, you still need to make all the
``script`` links in appropriate places with the right URLs, but you
would have to do that anyways.
Bower installs into a directory called bower_components in the current
directory, which is equivalent to your bower_files above.
Let's look at an example. Suppose you need to a new JavaScript library
called hipster.js. You add it to the ``bower.json`` file, and run
Bower. Bower downloads the right files and does whatever it is that it
does to them, and puts them in ``bower_files/hipster-js``. Now you edit
Horizon's templates and add ``script src={{ STATIC_URL
}}/hipster-js/hipster.js`` to ``_scripts.html``. That's it for you.
Since your ``static_settings.py`` file already has a line:
('', os.path.join(BASE_DIR, '/bower_files')),
in it, it will just work.
Yep, except s/bower_files/bower_components :)
Now, suppose
Re: [openstack-dev] [horizon] static files handling, bower/
I think the only outstanding question is how developers and non-packagers populate the bower_components directory - that is, how is bower expected to be available for them? I think following the Storyboard approach is a good idea: isolate a known-working node/bower environment local to horizon which is managed by tox - so to invoke bower you run tox -e bower command. No worries about system installation or compatibility, and works in the gate. Horizon installation (whenever a pip install would be invoked) would then also have a tox -e bower install invocation. Storyboard[1] uses a thing called nodeenv[2] which is installed through pip / requirements.txt to control the node environment. It then has bower commands in tox.ini[3] (though I'd just have a single bower environment to implement the tox command I suggest above. Richard [1] https://wiki.openstack.org/wiki/StoryBoard [2] https://pypi.python.org/pypi/nodeenv [3] https://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/tox.ini On Tue Jan 06 2015 at 11:42:17 AM Tripp, Travis S travis.tr...@hp.com wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? Thanks, Travis From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto: openstack-dev@lists.openstack.org Date: Monday, January 5, 2015 at 2:08 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack -d...@lists.openstack.org Subject: Re: [openstack-dev] [horizon] static files handling, bower/ On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote: On 05/01/15 00:35, Richard Jones wrote: On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski openst...@sheep.art.plmailto:openst...@sheep.art.pl mailto: openst...@sheep.art.plmailto:openst...@sheep.art.pl wrote: On 20/12/14 21:25, Richard Jones wrote: This is a good proposal, though I'm unclear on how the static_settings.py file is populated by a developer (as opposed to a packager, which you described). It's not, the developer version is included in the repository, and simply points to where Bower is configured to put the files. So just to be clear, as developers we: 1. have a bower.json listing the bower component to use, 2. use bower to fetch and install those to the bower_components directory at the top level of the Horizon repos checkout, and 3. manually edit static_settings.py when we add a new bower component to bower.json so it knows the appropriate static files to load from that component. Is that correct? The above will increase the burden on those adding or upgrading bower components (they'll need to check the bower.json in the component for the appropriate static files to link in) but will make life easier for the re-packagers since they'll know which files they need to cater for in static_settings.py Well, I expect you can tell Bower to put
Re: [openstack-dev] [horizon] static files handling, bower/
So just to be clear, as developers we: 1. have a bower.json listing the bower component to use, 2. use bower to fetch and install those to the bower_components directory at the top level of the Horizon repos checkout, and 3. manually edit static_settings.py when we add a new bower component to bower.json so it knows the appropriate static files to load from that component. Is that correct? The above will increase the burden on those adding or upgrading bower components (they'll need to check the bower.json in the component for the appropriate static files to link in) but will make life easier for the re-packagers since they'll know which files they need to cater for in static_settings.py Richard On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski openst...@sheep.art.pl wrote: On 20/12/14 21:25, Richard Jones wrote: This is a good proposal, though I'm unclear on how the static_settings.py file is populated by a developer (as opposed to a packager, which you described). It's not, the developer version is included in the repository, and simply points to where Bower is configured to put the files. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 20/12/14 21:25, Richard Jones wrote: This is a good proposal, though I'm unclear on how the static_settings.py file is populated by a developer (as opposed to a packager, which you described). It's not, the developer version is included in the repository, and simply points to where Bower is configured to put the files. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
This is a good proposal, though I'm unclear on how the static_settings.py file is populated by a developer (as opposed to a packager, which you described). Richard On Fri Dec 19 2014 at 12:59:37 AM Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, revisiting the package management for the Horizon's static files again, I would like to propose a particular solution. Hopefully it will allow us to both simplify the whole setup, and use the popular tools for the job, without losing too much of benefits of our current process. The changes we would need to make are as follows: * get rid of XStatic entirely; * add to the repository a configuration file for Bower, with all the required bower packages listed and their versions specified; * add to the repository a static_settings.py file, with a single variable defined, STATICFILES_DIRS. That variable would be initialized to a list of pairs mapping filesystem directories to URLs within the /static tree. By default it would only have a single mapping, pointing to where Bower installs all the stuff by default; * add a line from static_settings import STATICFILES_DIRS to the settings.py file; * add jobs both to run_tests.sh and any gate scripts, that would run Bower; * add a check on the gate that makes sure that all direct and indirect dependencies of all required Bower packages are listed in its configuration files (pretty much what we have for requirements.txt now); That's all. Now, how that would be used. 1. The developers will just use Bower the way they would normally use it, being able to install and test any of the libraries in any versions they like. The only additional thing is that they would need to add any additional libraries or changed versions to the Bower configuration file before they push their patch for review and merge. 2. The packagers can read the list of all required packages from the Bower configuration file, and make sure they have all the required libraries packages in the required versions. Next, they replace the static_settings.py file with one they have prepared manually or automatically. The file lists the locations of all the library directories, and, in the case when the directory structure differs from what Bower provides, even mappings between subdirectories and individual files. 3. Security patches need to go into the Bower packages directly, which is good for the whole community. 4. If we aver need a library that is not packaged for Bower, we will package it just as we had with the XStatic packages, only for Bower, which has much larger user base and more chance of other projects also using that package and helping with its testing. What do you think? Do you see any disastrous problems with this system? -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
