Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in build
Solly Ross sr...@redhat.com writes: Hi, I recently began using using ESLint for all my JavaScript linting: http://eslint.org/ It has nice documentation, a normal license, and you can easily write new rules for it. P.S. Here's hoping that the JSHint devs eventually find a way to remove that line from the file -- according to https://github.com/jshint/jshint/issues/1234, not much of the original remains. I don't think it matters how much of the original code remains -- what matters is that any rewrite is a derived work. Otherwise Debian and others could have made the license pure MIT long ago. -- Martin Geisler http://google.com/+MartinGeisler pgpBeHS_mQeu4.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load
Chris Friesen chris.frie...@windriver.com writes: On 06/18/2014 08:35 AM, Duncan Thomas wrote: On 18 June 2014 15:28, Matthew Booth mbo...@redhat.com wrote: The answer is not always more review: there are other tools in the box. Imagine we spent 50% of the time we spend on review writing tempest tests instead. Or we push the work off of core into the wider community and require 100% unit test coverage of every change *and* record the tempest coverage of any changed lines so that the reviewer can gauge better what the risks are? 100% coverage is not realistic. I was thinking the same, but there are actually some non-trivial projects that have 100% code coverage in their tests. These are two large projects that I know of: * http://www.pylonsproject.org/projects/pyramid/about: Every release of Pyramid has 100% statement coverage via unit tests * http://www.sqlite.org/testing.html: 100% branch test coverage in an as-deployed configuration Whether 100% test coverage is worth is it another question. People sometimes confuse 100% test coverage with 100% bug free, which is just wrong. -- Martin Geisler http://google.com/+MartinGeisler pgpfLHxEQODiG.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Translating log and exception messages in Oslo libraries
Mark McLoughlin mar...@redhat.com writes: Hi I'm not sure we've ever discussed this before, but I had previously figured that we shouldn't translate log and exception messages in oslo.messaging. My thinking is: - it seems like an odd thing for a library to do, I don't know of examples of other libraries doing this .. but I haven't gone looking - it involves a dependency on oslo.i18n - more than just marking strings for translation and using gettextutils, you also need to set up the infrastructure for pushing the .pot files to transifex, pulling the .po files from .transifex and installing the .mo files at install time In addition, you will have a fun time when people submit their logs to you in a language you cannot understand :) You can of course map the log back to the English string via the .po file, but it's an extra step to go through when someone asks for help. -- Martin Geisler http://google.com/+MartinGeisler pgpxn5XA_IOxa.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
Mark McLoughlin mar...@redhat.com writes: On Tue, 2014-06-24 at 13:56 -0700, Clint Byrum wrote: Excerpts from Mark McLoughlin's message of 2014-06-24 12:49:52 -0700: However, there is a debate, and thus I would _never_ block a patch based on this rule. It was feedback.. just as sometimes there is feedback in commit messages that isn't taken and doesn't lead to a -1. Absolutely, and I try and be clear about that with e.g. not a -1 or if you're rebasing anyway, perhaps fix this. Perhaps the problem is the round-trips such corrections imply? In the Mercurial project we accept contributions sent as patches only. There it's common for the core developers to fix the commit message locally before importing a patch. That makes it quick to fix these problems and I think that this workflow puts less work on the core maintainers. With Gerrit, it seems that simply fixing the commit message in the web interface could work. I know that a patch submitter can update it online, but I don't know if (core) reviewers can also just update it? (Updating the patch in Gerrit would go behind the back of the submitter who would then have to rebase any additional work he has done on the branch. So this is not 100% pain free.) -- Martin Geisler http://google.com/+MartinGeisler pgpPXvqvE_28i.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
Sean Dague s...@dague.net writes: On 06/25/2014 03:56 AM, Martin Geisler wrote: In the Mercurial project we accept contributions sent as patches only. There it's common for the core developers to fix the commit message locally before importing a patch. That makes it quick to fix these problems and I think that this workflow puts less work on the core maintainers. With Gerrit, it seems that simply fixing the commit message in the web interface could work. I know that a patch submitter can update it online, but I don't know if (core) reviewers can also just update it? Anyone can actually upload a 2nd patch, which includes changing the commit message. We just mostly have a culture of not rewriting people's patches, for better or worse. Thanks, I did not know about this possibility. (Updating the patch in Gerrit would go behind the back of the submitter who would then have to rebase any additional work he has done on the branch. So this is not 100% pain free.) That's often the challenge, it works fine if the original author is actually paying attention, and does a git review -d instead of just using their local branch. But is many cases that's not happening. (Also it's completely off book for how we teach folks to use git --amend in the base case). I've had instances of working with someone where even though we were talking on IRC during the whole thing, they kept overwriting the fix I was sticking in for them to get the test fixed. So typically you only want to do this with really advanced developers, with heads up that you pushed over them. I would guess that these developers would also typically respond quickly and positively if you point out typos in the commit message. So this makes the extra round trip less of an issue. I've only submitted some small trivial patches. As far as I could tell, Gerrit triggered a full test cycle when I just changed the commit message. That surprised me and made the reviews more time-consuming, especially because Jenkins would fail fairly often because of what looks like heisenbugs to me. I do also think people often get grumpy about other people rewriting their code. Which I think is just human, so erring on the side of giving feedback instead of taking it over is I think the right thing to do. I agree that such tricks are likely to do more harm than good for new contributors. -- Martin Geisler http://google.com/+MartinGeisler pgpSKzywISun0.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
Sean Dague s...@dague.net writes: On 06/25/2014 07:53 AM, Martin Geisler wrote: Sean Dague s...@dague.net writes: I've only submitted some small trivial patches. As far as I could tell, Gerrit triggered a full test cycle when I just changed the commit message. That surprised me and made the reviews more time-consuming, especially because Jenkins would fail fairly often because of what looks like heisenbugs to me. We track them here - http://status.openstack.org/elastic-recheck/ - help always appreciated in fixing them. Most of them are actually race conditions that exist in OpenStack. I should have said that I did meet that page. I tried looking for a relevant bug, but I didn't manage to match the error messages I with the known bugs. I just counted the mails from Jenkins and I see 61 mails with build succeeded and 12 mails with build failed. This is for patches that only touch a comment line in the beginning of the file: https://review.openstack.org/#/q/owner:martin%2540geisler.net,n,z That looks like a 20% failure rate. Is this normal or have I been extra unlucky? :) I think optimizing the zuul path for commit message only changes would be useful. Today the pipeline only knows that there was a change. That's not something anyone's gotten around to yet. Okay, thanks for the explanation. -- Martin Geisler http://google.com/+MartinGeisler pgpAEArX9gUsn.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][devstack-gate] mad rechecks
Sergey Skripnick sskripn...@mirantis.com writes: After 2 days and 11 rechecks I finally got +1 https://review.openstack.org/#/c/104123/ failed jobs: job times check-dg-tempest-dsvm-full 1 check-dg-tempest-dsvm-full-reexec 3 check-grenade-dsvm 3 check-grenade-dsvm-partial-ncpu 3 check-tempest-dsvm-full-havana 1 check-tempest-dsvm-neutron 1 check-tempest-dsvm-neutron-heat-slow1 check-tempest-dsvm-postgres-full1 check-tempest-dsvm-postgres-full-icehouse 1 Is there any hope that jobs will just work? Such number of failures leads to significant amount of extra work for test nodes. I recently submitted some patches that cleaned up the comment headers of Python files. Since I was editing a comment, I was surprised to see test failures. I counted 12 failed and 61 successful test runs -- about 16% of the test runs failed for no good reason. -- Martin Geisler http://google.com/+MartinGeisler pgp10BD5WPkym.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [git-review] Supporting development in local branches
Ben Nemec openst...@nemebean.com writes: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: When you're developing some big change you'll end up with trying dozens of different approaches and make thousands of mistakes. For reviewers this is just unnecessary noise (commit title Scratch my last CR, that was bullshit) while for you it's a precious history that can provide basis for future research or bug-hunting. So basically keeping a record of how not to do it? I get that, but I think I'm more onboard with the suggestion of sticking those dead end changes into a separate branch. There's no particular reason to keep them on your working branch anyway since they'll never merge to master. They're basically unnecessary conflicts waiting to happen. Yeah, I would never keep broken or unfinished commits around like this. In my opinion (as a core Mercurial developer), the best workflow is to work on a feature and make small and large commits as you go along. When the feature works, you begin squashing/splitting the commits to make them into logical pieces, if they aren't already in good shape. You then submit the branch for review and iterate on it until it is accepted. As a reviewer, it cannot be stressed enough how much small, atomic, commits help. Squashing things together into large commits make reviews very tricky and removes the possibility of me accepting a later commit while still discussing or rejecting earlier commits (cherry-picking). FWIW, I have had long-lived patch series, and I don't really see what is so difficult about running git rebase master. Other than conflicts, of course, which are going to be an issue with any long-running change no matter how it's submitted. There isn't a ton of git magic involved. I agree. The conflicts you talk about are intrinsic to the parallel development. Doing a rebase is equivalent to doing a series of merges, so if rebase gives you conflicts, you can be near certain that a plain merge would give you conflicts too. The same applies other way around. So as you may have guessed by now, I'm opposed to adding this to git-review. I think it's going to encourage bad committer behavior (monolithic commits) and doesn't address a use case I find compelling enough to offset that concern. I don't understand why this would even be in the domain of git-review. A submitter can do the puff magic stuff himself using basic Git commands before he submits the collapsed commit. -- Martin Geisler http://google.com/+MartinGeisler pgp2cgqzpZO4I.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Specifying file encoding
Hi everybody, I'm trying to get my feet wet with OpenStack development, so I recently tried to submit some small patches. One small thing I noticed was that some files used # -*- encoding: utf-8 -*- to specify the file encoding for both Python and Emacs. Unfortunately, Emacs expects you to set coding, not encoding. Python is fine with either. I submitted a set of patches for this: * https://review.openstack.org/95862 * https://review.openstack.org/95864 * https://review.openstack.org/95865 * https://review.openstack.org/95869 * https://review.openstack.org/95871 * https://review.openstack.org/95880 * https://review.openstack.org/95882 * https://review.openstack.org/95886 It was pointed out to me that such a change ought to be coordinated better via bug(s) or the mailinglist, so here I am :) It was also suggested that the lines should be removed completely with a reference to this thread: http://lists.openstack.org/pipermail/openstack-dev/2013-October/017353.html Unfortunately, the issue is only somewhat similar: the thread is about removing Vim modelines: # vim: tabstop=4 shiftwidth=4 softtabstop=4 My patches is about using an Emacs-friendly way to specify the file encoding. PEP 263 (http://legacy.python.org/dev/peps/pep-0263/) explains that is it a SyntaxError not to specify an encoding when a file has non-ASCII characters. Many of the files (but not all) have a © copyright symbol in the file header and so the encoding line cannot be removed from these files unless the copyright symbol is removed at the same time. I saw references to hacking in the Vim modeline thread. At first I thought it might be a tool used to check the style, but now I think it migth just be this document: http://docs.openstack.org/developer/hacking/ I look forward to hearing your comments! -- Martin Geisler https://plus.google.com/+MartinGeisler/ pgpH6fMgxteZ9.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Specifying file encoding
Pádraig Brady p...@draigbrady.com writes: On 05/28/2014 08:16 AM, Martin Geisler wrote: Hi everybody, I'm trying to get my feet wet with OpenStack development, so I recently tried to submit some small patches. One small thing I noticed was that some files used # -*- encoding: utf-8 -*- to specify the file encoding for both Python and Emacs. Unfortunately, Emacs expects you to set coding, not encoding. Python is fine with either. I submitted a set of patches for this: * https://review.openstack.org/95862 * https://review.openstack.org/95864 * https://review.openstack.org/95865 * https://review.openstack.org/95869 * https://review.openstack.org/95871 * https://review.openstack.org/95880 * https://review.openstack.org/95882 * https://review.openstack.org/95886 It was pointed out to me that such a change ought to be coordinated better via bug(s) or the mailinglist, so here I am :) This is valid change. I don't see why there is any question as it only improves the situation for emacs which will pop up an error when trying to edit these files. Yes, exactly :) It's also worth noting that the files *already* use Emacs-specific markup in the form of the -*- markers. Python doesn't care about those at all, but Emacs relies on them. The reviewers in https://review.openstack.org/95886/ suggests removing the coding lines completely and also remove non-ASCII characters as necessary to make that possible. I can definitely do that instead if people like that better. The only problem I see is that we'll have to hope that © is the only non-ASCII character -- I haven't checked if that's the case yet, but it's not uncommon to find non-ASCII characters in author names as well. You could create a bug I suppose to reference all the changes though I don't think that's mandatory since this isn't user facing. Okay, I'm not really familiar with the process around here. I hoped I could just make some commits and submit them for review :) -- Martin Geisler https://plus.google.com/+MartinGeisler/ pgpuijH_jhThC.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Specifying file encoding
Ryan Brady rbr...@redhat.com writes: - Original Message - From: Pádraig Brady p...@draigbrady.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, May 28, 2014 6:28:28 AM Subject: Re: [openstack-dev] Specifying file encoding On 05/28/2014 08:16 AM, Martin Geisler wrote: Hi everybody, I'm trying to get my feet wet with OpenStack development, Welcome aboard! Thanks for contributing. :) so I recently tried to submit some small patches. One small thing I noticed was that some files used # -*- encoding: utf-8 -*- to specify the file encoding for both Python and Emacs. Unfortunately, Emacs expects you to set coding, not encoding. Python is fine with either. I submitted a set of patches for this: * https://review.openstack.org/95862 * https://review.openstack.org/95864 * https://review.openstack.org/95865 * https://review.openstack.org/95869 * https://review.openstack.org/95871 * https://review.openstack.org/95880 * https://review.openstack.org/95882 * https://review.openstack.org/95886 It was pointed out to me that such a change ought to be coordinated better via bug(s) or the mailinglist, so here I am :) This is valid change. I don't see why there is any question as it only improves the situation for emacs which will pop up an error when trying to edit these files. I guess I approach this differently. When I saw this patch, my first thought was to validate if the line being changed needed to exist at all. That makes a lot of sense! If the file has valid non-ascii characters that effect its execution, are absolutely required for documentation to convey a specific meaning, or in strings that need to translate, then I agree the change is valid. But in the case the characters in the file can be changed, it seems like the bug is the extra encoding comment itself. I see what you mean -- I also try to keep my files just ASCII for convenience (even though I'm from Denmark where we have the extra three vowels æ, ø, and å). As a brand new contributor, changing copyright statements seemed like a bigger change than updating the coding line :) Taking tuskar for example, the files in question seem to only need this encoding line to support the copyright symbol. [rb@localhost tuskar]$ grep -R -i -P [^\x00-\x7F] ./* Binary file ./doc/source/api/img/model_v2.jpg matches Binary file ./doc/source/api/img/model_v4.odg matches Binary file ./doc/source/api/img/model.odg matches Binary file ./doc/source/api/img/model_v3.jpg matches Binary file ./doc/source/api/img/model_v3.odg matches Binary file ./doc/source/api/img/model_v2.odg matches Binary file ./doc/source/api/img/model_v4.jpg matches Binary file ./doc/source/api/img/model_v1.jpg matches Binary file ./doc/source/_static/header_bg.jpg matches Binary file ./doc/source/_static/header-line.gif matches Binary file ./doc/source/_static/openstack_logo.png matches ./tuskar/api/hooks.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/api/app.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/api/acl.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) ./tuskar/common/service.py:# Copyright © 2012 eNovance licens...@enovance.com ./tuskar/tests/api/api.py:# Copyright © 2012 New Dream Network, LLC (DreamHost) In the U.S., copyright notices haven't really been needed since 1989. You also only need to include one instance of the symbol, Copyright or copr [1]. If the requirements for copyright are different outside the U.S., then I hope we capture that in the copyright wiki page [2]. Maybe the current info in that wiki needs to be updated or at least notated as to why the specific notice text is suggested. Unless there is another valid requirement to keep the © in the files, I think it's best if we just remove them altogether and eliminate the need to add the encoding comments at all. Sounds good to me. I'll update my script to do this and rework the patch sets. I've made most patches as two: one that removes coding lines that are currently redudant and one that adjusts the remaining lines to make Emacs happy. Would you want to merge the patches that simply remove the unneeded lines and then let me followup with patches that remove © along with the then unnecessary coding lines? I'm asking since it seems that Gerrit encourages a different style of development than most other projects I know -- single large commits instead of a series of smaller commits, each one logical step building on the previous. -- Martin Geisler https://plus.google.com/+MartinGeisler/ pgpael_3tsbag.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Specifying file encoding
Ryan Brady rbr...@redhat.com writes: Would you want to merge the patches that simply remove the unneeded lines and then let me followup with patches that remove © along with the then unnecessary coding lines? If I was in your position, I'd update the patches that remove lines to include all of the affected files and also remove the ©. I'd abandon the patches that simply update the line for Emacs compatibility. Done: https://review.openstack.org/96123/ Let me know what you think. I'm asking since it seems that Gerrit encourages a different style of development than most other projects I know -- single large commits instead of a series of smaller commits, each one logical step building on the previous. When patches are too complex, breaking them down makes it easier to review, easier to test and easier to revert. In this case, I don't think you're adding complexity by changing a line and a character in comments for each file in the scope of a project. Opinions may vary project to project. Yeah, that makes sense and I've already heard some differnet opinions. That's of course fine with me! I'm a developer in the Mercurial project, and we have strict policies about patches doing one thing only. Exaclty what one thing can then sometimes be up for debate :) Thanks for the help so far! -- Martin Geisler https://plus.google.com/+MartinGeisler/ pgpzwz81KBikm.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs
Richard Jones r1chardj0...@gmail.com writes: Hi, I'm working on the ZeroVM project at Rackspace and as part of that I'm writing a JavaScript based file manager for Swift which I've called Swift Browser: https://github.com/zerovm/swift-browser When writing this, I of course ran in to exactly the problems you describe below. 2. add CORS support to all the OpenStack APIs though a new WSGI middleware (for example oslo.middleware.cors) and configured into each of the API services individually since they all exist on different origin host:port combinations, or This was the solution I picked first and it was not difficult to get working. I used this middleware: http://blog.yunak.eu/2013/07/24/keystone_cors/ Since I only case about Swift, another solution that I've been using is to use swauth (or really https://github.com/zerovm/liteauth) which lets you authenticate to Swift directly. There are thus only a single origin to consider and the same-origin problems disappear. 3. a new web service that proxies all the APIs and serves the static Javascript (etc) content from the one origin (host). That sounds like another good alternative. I'm not sure familiar with how people normally deploy Swift, but I would imagine that people setup some proxying anyway to rewrite the URLs to a nicer format. I have implemented options 2 and 3 as an exercise to see how horrid each one is. == CORS Middleware == The middleware option results in a reasonably nice bit of middleware. It's short and relatively easy to test. The big problem with it comes in configuring it in all the APIs. The configuration for the middleware takes two forms: 1. hooking oslo.middleware.cors into the WSGI pipeline (there's more than one in each API), If this became a standard part of OpenStack, could one imagine that the default WSGI pipelines would already contain the CORS middleware? 2. adding the CORS configuration itself for the middleware in the API's main configuration file (eg. keystone.conf or nova.conf). So for each service, that's two configuration files *and* the kicker is that the paste configuration file is non-trivially different in almost every case. I'm unsure why it would have to be different for each service? Would the services not be configured mostly the same, as in: [filter:cors] allow_origins = https://static.company.com == New Single-Point API Service == Actually, this is not horrid in any way - unless that publicURL rewriting gives you the heebie-jeebies. It works, and offers us some nice additional features like being able to host the service behind SSL without needing to get a bazillion certificates. And maybe load balancing. And maybe API access filtering. I like this option for the flexibility it gives you. -- Martin Geisler http://google.com/+MartinGeisler pgpbntQlgOsos.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs
Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com writes: May be it's a bit too late, but in mid 2012 the FIWARE team developed a horizon clone 100% in Javascript. https://github.com/ging/horizon-js Nice! I poked around a little in the repo and found no mention of Swift? [...] Portal has evolved and now it's more like a 'chroot' for safe execution of javascript apps. And we use it for our own OpenStack extensions (accounting, rating, billing, monitoring, advanced network management...). Sounds cool! So maybe if you want to discuss about how to proceed in the future for a 100% javascript user interface, maybe we can talk about it in Paris. I'm unfortunately not coming to Paris, but we can discuss this over email. The ZeroVM mailinglist would be fine if it's too off-topic for this list. In the ZeroVM project, we're mostly (only really) interested in an interface for Swift since we can embed the ZeroVM sandbox in Swift. This gives you a Swift cluster where you can execute map-reduce jobs (from untrusted clients because of the ZeroVM sandbox) directly on the data. We like say that you can send the code to the data instead of doing it the other way around. So that is why I'm focusing on Swift now and will later add support for starting these ZeroVM jobs to the browser. -- Martin Geisler http://google.com/+MartinGeisler pgpTx2xioHhGZ.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [swift] Swift Browser 0.1.0 released
Hi everybody, I'm happy to announce the release of Swift Browser 0.1.0. Swift Browser is a JavaScript based interface for Swift. You will find a pre-built tarball and zip file here: https://github.com/zerovm/swift-browser/releases/tag/0.1.0 They are ready to be unpacked and uploaded to your Swift installation. This first release includes a basic feature set which allows you to: * Authenticate using Keystone and LiteAuth. * Browse containers and pseudo-directories. * Create and delete containers. * Edit object content and metadata. * Upload and delete objects. -- Martin Geisler http://google.com/+MartinGeisler pgpP1c8E_QNji.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Richard Jones r1chardj0...@gmail.com writes: On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote: Sigh, this nonsense doesn't go away? This is the third time the same issue comes up. jshint is NOT free software. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 They're trying to resolve that https://github.com/jshint/jshint/issues/1234 I've switched to ESLint for my own projects: http://eslint.org/ I find it to be better documented and easier to extend than JSHint. Plus it has had a sane license from the beginning :) -- Martin Geisler http://google.com/+MartinGeisler pgpwAiqU4ITyx.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Richard Jones r1chardj0...@gmail.com writes: Hi all, At the summit last week, we developed a plan for moving forward with modernising Horizon's UI using AngularJS. If you weren't at that meeting and are interested in helping out with this effort please let me know! I have been working on an interface for Swift written in Angular. You'll find a ready-to-deploy tarball and zip file here: https://github.com/zerovm/swift-browser/releases/ This will eventually be an interface for starting ZeroVM instances on a Swift cluster, but for now it's a pure Swift interface. I don't know if this is something that can be used in Horizon, but maybe there are useful bits. One thing interesting thing in Swift Browser is its testing: I wrote a Swift simulator that is injected into the application for end-to-end testing with Protractor. Is is basically an in-memory (and in-browser) Swift that responds to queries made against the Swift REST API. I've found that very useful in the development: https://github.com/zerovm/swift-browser/blob/master/app/js/test/swift-simulator.js I don't know the other OpenStack components and their APIs very well, but I guess that this kind of mocking might be too much for a full OpenStack dashboard. -- Martin Geisler http://google.com/+MartinGeisler pgpHlDlDL2w3E.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Matthias Runge mru...@redhat.com writes:
On Wed, Nov 12, 2014 at 08:35:18AM -0500, Monty Taylor wrote:
Just for the record, I believe that we should chose the tools that
make sense for making our software, as long as it's not physically
impossible for them to be packaged. This means we should absolutely
not use things that require multiple versions of node to be needed.
The nodejs that's in trusty is new enough to work with all of the
modern javascript tool chain things needed for this, so other than
the various javascript tools and libraries not being packaged in the
distros yet, it should be fine.
Agreed. We're in the position to describe or define, what we'd like to
use or to see in the future. That may require us to create required
tools.
You're not concerned about node.js? Most probably, since you're not
distributing it. Looking at the changelog, I'm a bit worried[1]:
[...]
For better or for worse, the JavaScript community is using Node,
Grunt/Gulp, bower, ... as the default infrastructure tools.
Not using them or putting effort into creating alternatives would be
working against that community and I would say it's wasted effort. That
effort could be put to better use in the core OpenStack code.
I haven't cared much about Node itself, it's just a VM that runs my
JavaScript code. If I were to deploy it on a server I would agree that
the security and robustness becomes critical.
I find npm and bower alright -- they do their job just fine. The
semantic versioning craze is strange to me, but you can avoid it by
fully specifying the versions you depend on.
I find Grunt and Gulp to be overrated. My very simple Gruntfile[1] now
has about 170 lines of JSON to configure the simple tasks. For a copy
this to that task, the JSON format is fine, but for more complex tasks
with several steps it feels forced. I mean, I need to copy files in
several tasks, so I end up with
copy: {
some_target: {
...
},
other_target: {
...
}
}
in one part of the Gruntfile and then
task: {
some_target: {
...
}
}
many lines away. There's nothing to connect the two pieces of
configuration than a third task that runs both.
The whole multi-task idea also seems strange to me. It feels like an
idea that felt nice when the system was small and now the entire system
is built around it. As an example, running 'grunt copy' by itself is
useless when the two copy targets are small parts of bigger tasks.
About Gulp... I don't get it and I don't buy it :) The implication that
using streams will make your build fast is at best an
over-simplification. While streaming data is cool, elevating this single
idea to the fundamental building block in a simple task runner seems
contrieved.
It forces you into a pattern and you end up writing code looking like:
gulp.src('./client/templates/*.jade')
.pipe(jade())
.pipe(gulp.dest('./build/templates'))
.pipe(minify())
.pipe(gulp.dest('./build/minified_templates'));
That might look cute for a minimal example like this, but I bet it'll
make things harder than they should be in the future. As in, how can I
inject more files into the stream conditionally? How do I read an
environment variable and inject some extra files? With normal JavaScript
I would know how to do this.
(Here I would apparently use gulp-if together with something called a
lazypipe and I would still need to somehow insert the extra files in the
stream.)
[1]: https://github.com/zerovm/swift-browser/blob/master/Gruntfile.js
--
Martin Geisler
http://google.com/+MartinGeisler
pgp8QxY1uE7Ym.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Jiri Tomasek jtoma...@redhat.com writes: Which tools should we use eventually: Based on the contributions by Maxime, Martin and the others, I think the list of tools should end up as follows: Tooling: npm bower gulp While I find the design of Gulp strange, I'm sure it will do the job. Someone said that the Angular teams is moving to it, so that is a +1 in its favor. Jasmine Karma/Protractor(?)/eslint I've used Protractor for my end-to-end tests and after getting to know it, it works fine. It's my impression that it used to be annying to getup selenium and actually writing this kind of tests -- with Protractor you get up and running very quickly. I don't have anything to compare it with, though, but it's the standard for Angular development and that alone should be a strong hint. -- Martin Geisler http://google.com/+MartinGeisler pgp0giFB1wybi.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Radomir Dopieralski openst...@sheep.art.pl writes: On 11/11/14 08:02, Richard Jones wrote: [...] There were some discussions around tooling. We're using xstatic to manage 3rd party components, but there's a lot missing from that environment. I hesitate to add supporting xstatic components on to the already large pile of work we have to do, so would recommend we switch to managing those components with bower instead. For reference the list of 3rd party components I used in angboard* (which is really only a teensy fraction of the total application we'd end up with, so this components list is probably reduced): [...] Just looking at PyPI, it looks like only a few of those are in xstatic, and those are out of date. There is a very good reason why we only have a few external JavaScript libraries, and why they are in those versions. You see, we are not developing Horizon for our own enjoyment, or to install it at our own webserver and be done with it. What we write has to be then packaged for different Linux distributions by the packagers. [...] Maybe a silly question, but why insist on this? Why would you insist on installing a JavaScript based application using your package manager? I'm a huge fan of package managers and typically refuse to install anything globally if it doesn't come as a package. However, the whole JavaScript ecosystem seems to be centered around the idea of doing local installations. That means that you no longer need the package manager to install the software -- you only need a package manager to install the base system (NodeJs and npm for JavaScript). Notice that Python has been moving rapidly in the same direction for years: you only need Python and pip to bootstrap yourself. After getting used to virtualenv, I've mostly stopped installing Python modules globally and that is how the JavaScript world expects you to work too. (Come to think of it, the same applies to some extend to Haskell and Emacs where there also exist nice package managers that'll pull in and manage dependencies for you.) So maybe the Horizon package should be an installer package like the ones that download fonts or Adobe? That package would get the right version of node and which then runs the npm and bower commands to download the rest plus (importantly and much appreciated) puts the files in a sensible location and gives them good permissions. -- Martin Geisler http://google.com/+MartinGeisler pgph36NhgvYqz.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Thomas Goirand z...@debian.org writes:
Also, if the Horizon project starts using something like NPM (which
again, is already available in Debian, so it has my preference), will we
at least be able to control what version gets in, just like with pip?
Yes, npm similarly to pip in that you can specify the versions you want
to install. You can expect loose versions (like 1.2.x if you're okay
with gettting a random patch version) or you can specify the full
version.
In parallel with that, you can add a shrinkwrap file which lists the
versions to install recursively. This locks down the versions of
indirect dependencies too (one of your dependencies might otherwise
depend on a loose version number).
Because that's a huge concern for me, and this has been very well and
carefully addressed during the Juno cycle. I would very much appreciate
if the same kind of care was taken again during the Kilo cycle, whatever
path we take. How do I use npm by the way? Any pointer?
After installing it, you can try running 'npm install eslint'. That will
create a node_modules folder in your current working directory and
install ESLint inside it. It will also create a cache in ~/.npm.
The ESLint executable is now
node_modules/.bin/eslint
You'll notice that npm creates
node_modules/eslint/node_modules/
and install the ESLint dependencies there. Try removing node_modules,
then install one of the dependencies first followed by ESLint:
rm -r node_modules
npm install object-assign eslint
This will put both object-assign and eslint at the top of node_modules
and object-assign is no longer in node_modules/eslint/node_modules/.
This works because require('object-assign') in NodeJS will search up the
directory tree until it finds the module. So the ESLint code can still
use object-assign.
You can run 'npm dedupe' to move modules up the tree and de-duplicate
the install somewhat.
This nested module system also works the other way: if you run 'npm
install bower' after installing ESLint, you end up with two versions of
object-assign -- check 'npm list object-assign' for a dependency graph.
Surprisingly and unlike, say, Python, executing
require('object-assign')
can give you different modules depending on where the code lives that
execute the statement. This allows different parts of Bower to use
different versions of object-assign. This is seen as a feature in this
world... I fear that it can cause strange problems and bugs when data
travels from one part of the program to another.
So, the philosophy behind this is very different from what we're used to
with system-level package managers (focus on local installs) and even
From what we have in the Python world with pip (multiple versions
installed concurrently).
--
Martin Geisler
http://google.com/+MartinGeisler
pgp6u4TvkQL2G.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Matthias Runge mru...@redhat.com writes: On 13/11/14 15:56, Martin Geisler wrote: Maybe a silly question, but why insist on this? Why would you insist on installing a JavaScript based application using your package manager? I'm a huge fan of package managers and typically refuse to install anything globally if it doesn't come as a package. However, the whole JavaScript ecosystem seems to be centered around the idea of doing local installations. That means that you no longer need the package manager to install the software -- you only need a package manager to install the base system (NodeJs and npm for JavaScript). Yeah, I understand you. Let me just add that this shift has been a very recent change for me. With anything but Python and JavaScript, I use my system-level package manager. But: doing local installs or: installing things aside a package manager means, that software is not maintained, or properly updated any more. I'm a huge fan of not bundling stuff and re-using libraries from a central location. Copying foreign code to your own codebase is quite popular in JavaScript world. That doesn't mean, it's the right thing to do. I agree that you don't want to copy third-party libraries into your code. In some sense, that's not what the JavaScript world is doing, at least not before install time. What I mean is: the ease of use of local package managers has lead to an explosion in the number of tiny packages. So JS projects will no longer copy dependencies into their own project (into their version control system). They will instead depend on them using a package manager such as npm or bower. It seems to me that it should be possible translate the node module into system level packages in a mechanical fashion, assuming that you're willing to have a system package for each version of the node module (you'll need multiple system packages since it's very likely that you'll end up using multiple different versions at the same time -- alternatively, you could let each system package install every published or popular node module version). The guys behind npm has written a little about how that could work here: http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips Has anyone written such wrapper packages? Not the xstatic system which seems to incur a porting effort -- but really a wrapper system that can translate any node module into a system package. -- Martin Geisler http://google.com/+MartinGeisler pgpvFpbyk_SbN.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Thomas Goirand z...@debian.org writes: On 11/13/2014 10:56 PM, Martin Geisler wrote: Maybe a silly question, but why insist on this? Why would you insist on installing a JavaScript based application using your package manager? I'm a huge fan of package managers and typically refuse to install anything globally if it doesn't come as a package. However, the whole JavaScript ecosystem seems to be centered around the idea of doing local installations. That means that you no longer need the package manager to install the software -- you only need a package manager to install the base system (NodeJs and npm for JavaScript). Yeah... Just like for Java, PHP, Perl, Python, you-name-it... In what way Javascript will be any different from all of these languages? Let me again say that I'm fairly new to this modern JavaScript world. I knew almost nothing about node, npm, bower, and grunt six months ago. One answer may be that there isn't an expectation in the JavaScript community that you'll be reusing system libraries the same way that there is in at least the Python and Perl communities. It's my impression that the JavaScript world is used to move *very* quickly. People release versions very rapidly and are happy to break APIs. I think they're okay with it because of semver -- the idea that as long as you increment the right digit in your version number, you don't have to care (much) about the work you put on your users when you ask them to upgrade. I hope that's too harsh a description, but the way the node module system is explicitly designed to allow a single running program to use multiple versions of the *same* module hints that this chaotic situation is both expected and considered normal. When reading about the module system, I came across blog posts that called it superior compared to, say, Python, exactly because of this flexibility. Reasonable people are sure to disagree, but that seems to be the current situation. Notice that Python has been moving rapidly in the same direction for years: you only need Python and pip to bootstrap yourself. After getting used to virtualenv, I've mostly stopped installing Python modules globally and that is how the JavaScript world expects you to work too. Fine for development. Not for deployments. Not for distributions. Or you just get a huge mess of every library installed 10 times, with 10 different versions, and then a security issue needs to be fixed... While I agree that it's chaotic, I also think you make the problem worse than it really is. First, remember that the user who installs Horizon won't need to use the JavaScript based *developer* tools such as npm, bower, etc. 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. So maybe the Horizon package should be an installer package like the ones that download fonts or Adobe? This is a horrible design which will *never* make it to distributions. Please think again. What is it that makes Horizon so special? Answer: nothing. It's just a web app, so it doesn't need any special care. It should be packaged, just like the rest of everything, with .deb/.rpm and so on. 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 find this to be quite different from, say, installing Emacs. Emacs is something you install once on a system and this single installation can be done in a right way so that it's useable for several users on the system. A web app is something a single user installs on a system (www-data or a similar user) and then this user configures the system web server to serve this web app. 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. That package would get the right version of node and which then runs the npm and bower commands to download the rest plus (importantly and much appreciated) puts the files in a sensible location and gives them good permissions. Fine for your development environment. But that's it. Also, does your $language-specific-package--manager has enough checks so that there's no man in the middle attack possible? Is it secured enough? Can a replay attack be done on it? Does it supports any kind of cryptography checks like
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Thomas Goirand z...@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
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Gabriel Hurley gabriel.hur...@nebula.com writes: Hi Gabriel, 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. I'm sorry if I came across as being hostile towards packagers and distros. I've been running Debian for 15 years and that is because of the work the Debian developers put into making the system work well together at a whole. When it comes to installing software, I only use apt to touch paths outside my home directory. That is to ensure that the integrity of the system isn't compromised. That means that software not yet packaged for Debian has a low change of being installed by me. However, the chances of me installing it improve significantly if I can install it with pip or npm. Simply because this allows me to do a local installation in a home directory -- I know then that I can easily remove the sofware later. -- Martin Geisler http://google.com/+MartinGeisler pgpXzFJPPlcp8.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Thomas Goirand z...@debian.org writes: Hi Thomas, On 11/15/2014 05:34 PM, Martin Geisler wrote: I'm sorry if I came across as being hostile towards packagers and distros. I've been running Debian for 15 years and that is because of the work the Debian developers put into making the system work well together at a whole. When it comes to installing software, I only use apt to touch paths outside my home directory. That is to ensure that the integrity of the system isn't compromised. That means that software not yet packaged for Debian has a low change of being installed by me. However, the chances of me installing it improve significantly if I can install it with pip or npm. Simply because this allows me to do a local installation in a home directory -- I know then that I can easily remove the sofware later. Sorry to say it this way, and it's not about you in particular, You're quite right, it's not about me! I'm not about to deploy OpenStack anytime soon so you don't have to sell the packaging solution to me :) My main goal in this discussion was to bring some web development knowledge to the table. It's clear to me that you have a very strong background in Debian packaging -- and (I'm guessing here) not a very strong background in web development. What we care is to find a system that will satisfy both worlds: distributions upstream fast moving development. It is looking like NPM has the best feature and that it would be a winner against Bower and Grunt. As Richard said, npm and bower are not competitors. You use npm to install bower, and you use bower to download Angular, jQuery, Bootstrap and other static files. These are the static files that you will want to include when you finally deploy the web app to your server. Before using Bower, people would simply download Angular from the projects homepage and check it into version control. Bower is not doing much, but using it avoids this bad practice. There is often a kind of compilation step between bower downloading a dependency and the deployment on the webserver: minification and compression of the JavaScript and CSS. Concatenating and minifying the files serve to reduce the number of HTTP requests -- which can make an app much faster. Finally, you use Grunt/Gulp to execute other tools during development. These tools could be a local web server, it could be running the unit tests. Grunt is only a convenience tool here -- think of it as a kind of Makefile that tells you how to lunch various tasks. Again, I'm just trying to bring information to light and let you know the tools of the trade -- how you and OpenStack as a whole decide to use and package them is not my concern. -- Martin Geisler http://google.com/+MartinGeisler pgpU3qC4oRLtU.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] Swift Browser 0.2.0 released
Hi all, Swift Browser 0.2.0 has been released: https://github.com/zerovm/swift-browser/releases/tag/0.2.0 This release adds support for copying objects and deleting containers. Furthermore, the JavaScript and CSS files are now concatenated and minified, resulting in a faster page load. You can find a demo here: http://www.zerovm.org/swift-browser/ (Please let me know if these announcements become too frequent. I expect to release minor versions in 2-4 week intervals in the future.) -- Martin Geisler http://google.com/+MartinGeisler pgpuSTTtDrLis.pgp Description: PGP signature ___ 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 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/
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/
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/
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] [Swift] Swift GUI (free or open source)?
Adam Lawson alaw...@aqorn.com writes: Hi Adam, I'm researching for a web-based visualization that simply displays OpenStack Swift and/or node status, cluster health etc in some manner. I wrote Swift Browser, which will let you browse the containers and objects in your Swift cluster: Repository: https://github.com/zerovm/swift-browser Demo here: http://www.zerovm.org/swift-browser/#/ You mention node status and cluster health -- this is unfortunately not what I considered in Swift Browser. -- 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] [Glance] IRC logging
Kuvaja, Erno kuv...@hp.com writes: I'm heavily against the public logging to the level that I will just leave the channel if that will be enabled. My point is not foul language and I do understand that there could be some benefits out of it. Personally I think we have enough tracked public communication means like ask.openstack.org and the mailing lists. IRC is and has always been real time communications with defined audience. For what it's worth, we've had the same discussion in the Mercurial community and decided no *not* enable public logging on the IRC channel. The arguments are similar to what you say, plus people said that they would behave differently if the channels were logged in public. We don't have problems with foul language, but people felt that they would be more restricted if everything they write end up in a log like on a mailing list. Some people said that they would be less active on the list during their work hours -- not because it was strictly forbidden for them to spend some time help an open source project (and everybody needs a break once in a while), but because they felt it could look strange if their boss sees a full archive of their activity. It is similar to how I'm allowed to use the Internet for personal things at work (as long as I do it in a reasonable amount) but I don't want to hand over a complete log to my boss. So people should be aware that enabling logging and putting a notice about it in the channel topic is likely to affect the behavior. It will have some pros (people can search the logs for old discussions) and some cons (people might not bother posting a summary of an IRC discussion on the mailing list). -- 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
