[openstack-dev] [Horizon] the future of angularjs development in Horizon

Gabriel Hurley Gabriel.Hurley at nebula.com
Fri Nov 14 22:27:17 UTC 2014


As the former Horizon PTL, I have a great respect for the importance of the contributions the distro maintainers/developers make to Horizon and OpenStack as a whole. From how many bugs the distros manage to find, to their diligence in vetting the software that we as Horizon developers provide, to their overall passion for the work they do.

It is interesting to me to see the level to which the distros have not had to address this problem before. It shows a significant disconnect between the Node/JavaScript community and the distros as a whole (not surprising since node.js wasn't packaged on many distros until quite recently). I'm not excited to see the OpenStack community leading the charge on resolving packaging issues that ought to be settled between the JS community and the distros. Yet, if we have to in order to move forward I would urge us to reach out to the NPM maintainers, major library maintainers, etc. to try and make decisions that will benefit everyone for years to come.

It's also interesting to see how strongly people take sides in this debate... who is OpenStack for? How crucial are the distros? Obviously if you work for RedHat or Canonical the distros are the end-all; OpenStack has to be packaged. Other companies? Opinions vary. Flexibility on this issue is not consistent, as has been pointed out already.

Monty and Adam Young have, I think, voiced a good moderate viewpoint, which is that the distros are a core part of OpenStack's success and we have to ensure that they can package our software, but that the distros also cannot dictate the tools we use in order to produce the best possible product. Distros are ultimately middle-men, they provide value to their users and they make sure more people use the software we produce. We can all agree that we want to maximize the number of people we can reach.

So, I propose that a group gets together and defines criteria: we need to accept that the Horizon team (and those knowledgeable about web-app development) know best what tools they need, and they need to produce such a list as a starting point. We then need packagers and maintainers to examine that list and evaluate it for problems (non-free software, irresolvable dependencies, etc.). They're looking strictly for things which are un-packageable, not commenting on the necessity of said software. And we need people (thanks, Monty) willing to build new tools to find a way to turn that list into something the package maintainers can consume without burdening either side.

Make sense?

     - Gabriel



-----Original Message-----
From: Thomas Goirand [mailto:zigo at debian.org] 
Sent: Friday, November 14, 2014 11:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 11/14/2014 10:10 PM, Martin Geisler wrote:
>> Of course, I need to run tests. That's a big part of the QA work, and 
>> I
>> > will certainly not give-up on that. You will have a hard time 
>> > convincing anyone within the OpenStack community that it's OK to not run unit tests.
> That's not what I said: the OpenStack developers will continue to 
> tests the software. I personally don't think it's the job of the 
> downstream packagers to do this QA work. (It's of course cool to run 
> the tests on the system installed by your packages -- that test run 
> would then install the needed tools using npm and bower and whatnot if 
> that's how the upstream has setup the test framework.)

What happens is that the environment within the distribution, inevitably, will be different from the one ran on the gate. There's going to be different versions of many components and so on. So it is very important for me to also run these unit tests, to make sure that everything continues to work.

Yes, the build-dependencies will pull the same components as pulled by npm/bower, though they may be installed in different path, and maybe using different versions.

On 11/14/2014 10:21 PM, Jeremy Stanley wrote:> On 2014-11-14 15:10:59
+0100 (+0100), Martin Geisler wrote:
> [...]
> Just to quibble on this particular point... distro packagers are also 
> developers. They often (more often than we'd like, and we do try to 
> find ways to help avoid this where possible) need to carry their own 
> patches to tweak the software to fit their deployment and operation 
> model. Being able to rerun tests in-place with packaged versions of 
> everything including their patches helps them confirm that what they 
> distribute still works as intended. Further, the distro users are well 
> within their rights to modify and respin these packages themselves, 
> and will potentially want to be able to run these tests for the same 
> reasons.
>
> We distribute our tests as part of our software because our tests
> *are* part of our software.

Exactly! Let me give a few examples...

In Jessie, Nova carries patches so that there is support for Ceph. Until a few days, there was still an issue with live migration over NFS. This has just been fixed (thanks to Mehdi!), and running unit tests at build time confirmed that.

Another example. Jessie will be released with Icehouse Horizon, but with Django 1.7. The gate didn't test that, but I did. Most patches landed in Juno, though never Icehouse will be tested with Django 1.7 in the gate.
Lucky, my package runs these unit tests and I can confirm that it continues to work with Django 1.7 in Jessie.

Hoping these are giving you an insight as why it's *really* important to run unit tests at build time for distributions,

Cheers,

Thomas Goirand (zigo)

P.S: I also run tempest tests over a Debian package installation to make sure OpenStack is also functional. But that's another story... :)


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list