Open Stack

Thomas Goirand <zigo at debian.org> writes:

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> That is, I think Horizon developers will use these tools to produce a
>> release -- a tarball -- and that tarball will be something you unpack
>> on your webserver and then you're done. I base this on what I've seen
>> in the project I've been working. The release tarball you download
>> here don't mention npm, bower, or any of the other tools:
>> 
>>   https://github.com/zerovm/swift-browser/releases
>> 
>> The tools were used to produce the tarball and were used to test it,
>> but they're not part of the released product. Somewhat similar to how
>> GCC isn't included in the tarball if you download a pre-compiled
>> binary.
>
> When doing packages, I don't even use the tarball, but a git clone,
> which itself produces an orig.tar.xz file. I do that to allow more
> flexibility and to be able to do "upstream" code change easily.

That seems to be a choice you're making -- I think you could also use
the upstream tarball as provided (let's say I also include unminified
source files in the tarball).

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> Maybe a difference is that you don't (yet) install a web application
>> like you install a system application. Instead you *deploy* it: you
>> unpack files on a webserver, you configure permissions, you setup
>> cache rules, you configure a database, etc.
>
> I really don't see why a web application should be any different from
> any other component of OpenStack. No, I wont "deploy" it, I will just
> apt-get install it...

I'm a long time Debian user and web developer. I install system tools
(web servers, databases, editors) and I deploy web applications. I
believe that's the most common way to handle web applications today.

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> I agree that it would be cool to have web apps be as robust and
>> general purpose as system apps. However, I think that day is a ways
>> off.
>
> I'm not sure why you are saying this. Horizon works out of the box in
> Debian, and so is murano-dashboard and the sahara support.

That's cool!

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> The dependency solver is as good as the community needs it to be. Or
>> put differently, if the JavaScript community is able to produce
>> working software with npm, then they obviously produce it within the
>> bounds of the capabilities of its dependency solver.
>>
>> I'm happy to believe that apt has a top-notch and highly tuned
>> dependency solver. That doesn't really matter since it would be
>> solving problems we don't have.
>
> Dependency solving is pure math. It's very hard to get it right. I don't
> agree that some language may need something weaker, and that it's
> possible for the maintainers to adapt. It's just that it may, in some
> case, be possible to go around some defects if they exist, but everyone
> needs a robust dependency solver.

I think you're misunderstanding the implication. If apt has a stronger
dependency solver than npm, then that's fine. The argument that apt is
stronger than npm is not an argument for moving node packages from npm
to apt -- the Debian packages will still only use a subset of apt
dependency solver, namely the subset they use with npm.

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> In my view, you're taking on way too much work by going into those
>> details. I don't think I need or want you do to anything more than
>> repack the tarball that npm retrieves -- I don't think you should run
>> tests or generate documentation.
>
> 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.)

> On 11/14/2014 06:30 AM, Martin Geisler wrote:
>> As a user or sysadmin, I would be happy to add a deb line to my
>> sources.list and get Debian packages that wrap the node modules.
>
> This means that the packages would *not* be in Debian. Therefore,
> horizon couldn't be uploaded to Debian (as there would be some not
> available dependencies). That's absolutely not what I want to do. I
> want Horizon, just like the rest of OpenStack, to be fully in Debian.

You don't have to convince me -- I'm not going to deploy OpenStack
anytime soon (apart from DevStack). So I'm not really the right customer
for these packages.

All I wanted to say is that if there is a cool OpenStack dashboard
written as a web app, then I would be happy to deploy it like I deploy
other web apps. If there were a package I could use, that would be cool,
but it's by no means a show-stopper for someone like me.

Organizations might have other rules and concerns. If they cannot
install using npm, then I would expect them to roll their own simple
packages that simply bundle the files installed by npm. In the end, such
a dashboard would be a directory tree with a bunch of static HTML and
JavaScript files (no references to npm after the build) and that can be
packaged and installed quite easily.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/d948db14/attachment.pgp>