Contributors mailing list archives
Re: anybox buildout recipe and OCAby
I will have to have a look at Voodoo ;).
My idea of docker is actually to keep it simple to allow users to have a solid docker they can rely on without needing a high level of install/setup. Only few commands and go.
The second point is to allow the build of OCA docker repository, always up to date and always available.
We have built a docker file that allows oca_requirements.txt usage so that users can easily test repos.
This kind of features will probably satisfy 95% of the public and allow easy discovery of Odoo/OCA without polluting environment.
NB: In our specific case (China), we have to struggle as well with mirroring and docker mirroring works fine (from > 12h to download a docker from abroad to 3 min when using a mirror).
Anyway I agree with your approach and several tools might meet several requirements.--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Shenzhen/Singapore) Odoo Gold Partner, best Odoo Partner 2014 for APACOn 10/20/2015 02:38 PM, Raphaël Valyi wrote:<blockquote cite="mid:CAByrsx2ooe=aQEni0u71tuEgpuSMw3fXdJ6tNJywn==yU-Z1iw@mail.gmail.com" type="cite">I personally think we are loosing a bit the focus of the OCA here...I think deployment will have many peculiarities depending on what want to achieve. Meanwhile a Dockerfile such as presented by Eric is really trivial to build and maintain (even accepting pull in his repo), I don't see any benefit of the OCA here... Even Voodoo which is a bit more engineered is trivial to maintain...That is different for the Anybox recipe because it's still a large piece of software. And despite we may use the recipe differently, many of us will still use that part of the puzzle, so it makes sense to have it in the OCA (even if I was ok keeping Anybox in the name as I said).Further, At Akretion we start using the Anybox recipe as a deliverable lingua franca. Like we happily host and make the infrastructure of our customers. But if they prefer do it themselves or work with other partners, we are OK as long as we can deliver them a buildout.cfg, so at least it means if they screw their production stack, that's not us paying their mistakes.Finally, I think Docker and the recipe complete each other nicely and this is exactly what we do with Voodoo. Think that instead of using Virtualenv, we use a Dockerized virtualenv, but a voodoo project repo is totally deployable with virtualenv as usual for those who prefer. It's just we can get the project up on any computer in just 5 minutes without cluttering the developer small SSD disk with tons of native dependencies.Regards.On Tue, Oct 20, 2015 at 4:08 AM, Alexandre Fayolle <email@example.com> wrote:AlexandreI personnally see no issue with having both in OCA. I've been using buildout since long before docker existed, I depend on this recipe for a large number of customers, and this buildout recipe has gathered a significant community.I am committing to participating in the maintenance it as long as I'm part of the association. I can't say the same for a docker based solution which is not part of the stack I deploy for my customers, but I won't block an initiative to maintain a docker based solution in the OCA.@Raphael, thanks! As I understand it, they do basically the very same thing?from the anybox readme:
Some of its main features include:
- uniformity across Odoo versions (from 8.0 onwards)What does this mean, actually? Can't judge on this...
- installation of Odoo serverOverlap: with docker capabilities.
- retrieval of main software and addons from various sources, including the major version control systemsThis is very nice, kind of "go get" or "vodoo get".
- ability to pinpoint everything for replayabilityOverlay: Docker's main feature.
- management of Odoo configurationI imagine some advanced management of config files, this could be an interesting feature to spin out.
- dedicated scripts creation for easy integration of external tools, such as test launchersbash?!? is this docker's entrypoint.sh?
- packaging: creation of self-contained equivalents for easy deployment in tightly controlled hosting environmenents.Well nothing to say, this is dockers main purpose.So basically we have 2 out of 7 main features that would high-lite in a "diff docker anybox_recipt". Couldn't those be spun out?Obviously, things are working well, are stable and every one is accustomed to this. But I feel, my question if, on the long run(!), it is sustainable to maintain features inside the resource-limited odoo community, while other ecosystems solve them probably 100 times better (because they do nothing else).I'm just thinking loud because everyone is complaining about not having the appropriate resources...I also feel such important decisions (accepting a whole new contribution etc.) deserve public discussions, so I launched the thread to tell the community about this and give everyone an opportunity to discuss.and globally he is ok with this.* we add a compatibility entry point on the new recipe with the old name in order not to break existing buildout files* we modify the original recipe by publishing a new version on pypi which will be empty save for a dependency on the new name of the recipe* we change the name of the recipeJust for the record, I'm not suggesting we should make an exception in this case, and I certainly won't force an exception by abusing my commit rights and forcefully pushing the module in the OCA.I've discussed things with Georges this afternoon and what I proposed him was:2015-10-19 17:53 GMT+02:00 Raphaël Valyi <firstname.lastname@example.org>:Hello Alexandre and others,I defended the idea that Odoo module should not have a company name because several companies would too easily work on the same topic and changing a module name has impact in the database and because it seems more important to have a name that reflects what a module does.Now, for things like the Anybox recipe, I think Anybox will have done 90% of the work no matter the help now. It's not an Odoo module and I don't see reasons to be as strict. So for me I would leave the current name...More generally, overall I like what we do with the OCA, but let me tell I'm concerned with the business model of the thing: yes the OCA receives some donations, but nonetheless 99% of the R&D is invested by the contributing integrators themselves.May be some large integrators can do that as pure give away, but I'm not even sure. But generally, I think the model works IF AND ONLY F: an integrator company can get enough prestige from having its work accepted by peers at the OCA, then this can be a commercial advantage just as large as investing in marketing, at least in some rational high ends markets. THEN the model works and is sustainable.Now, if the OCA ends up totally anonymising and hiding who did some work, if the OCA gives the same visibilty to somebody who created and carried a project 5 years as somebody that just helped over the last 6 moths, then my friends we are shooting ourselves in the feets big times... Because what we get then, is a some ugly lobbying to fake some project participation and hijack the project credits, and this is something already happening.,.So I hope the OCA don't loose this economics reality. And this is for this reason I would be totally ok leaving the Anybox name in this case...Regards.2. I'd like to propose Georges (https://github.com/gracinet) as a member of the tools PSC.1. I propose the creation of a new OCA repository OCA/buildout_recipe under the responsibility of the Tools project steering comittee. I will make the required PRs to include the anybox recipes, once the naming issues are resolvedGeorges proposed a few months ago to share the maintenance of the anybox buildout recipe(s) (openerp and odoo) with the community. This was met with approval but as far as I remember the issue of the name (our policy says we should not have company names in module names) was not clearly resolved.Hello fellow,I'm at the PyconFR sprint sitting next to Georges Racinet and a number of Anybox contributors.--
Post to: mailto:email@example.com
Senior software engineer
Tel: +352 20 21 10 20 32
Fax: +352 20 21 10 21
Boulevard de la Woluwe 56, b4 Woluwedal
RPM Bruxelles 0835.207.216 RPR Brussel