Hi David, thanks for your insight.
I don't have much time before next week to go into details, but I can for once be short : I tend to consider zc.buildout as a lower layer that tools such as Ansible could in turn use. As a hint towards that, the playbook you link to below cares mostly about stuff that Odoo buildouts leave to the system admin, whereas the odoo-itself command is just getting odoo mainline from Github [1] So to speak, buildout defines the edge of the application, and Ansible (or Puppet or Fabric [2]) could take care of deploying in a concrete, given system. Same is true of the deployment scripts we use on Anybox servers. I don't know Ansible, but I've heard good things about it (lightweight, easy to grasp, notably), but I wonder if you could convince a hosting company And btw, on a personal note, I dislike the predominance of INI format (could rant for hours about that) and would indeed prefer very much zc.buildout to be based on YML. Regards, [1] that's also the example I gave, I know, but it's not representative of a real-life project where use of buildout is meaningful [2] just examples based on different principles On 06/09/2014 08:19 PM, David Arnold - El Alemán wrote: > *Hello Georges* > * > * > I'd like to make a suggestion for medium term plans. > > Probably after due analysis you might find, that some things that you > are handling in the anybox reciptes in a rather coustom build manner, > could be easily and effectively abstracted (and maintainance > outsurced) to another provisioning standard, such as *ansible > <http://www.ansible.com/home>*. > > I acknowledge path dependencies as a valid actuation pattern, but I > kindly ask for effective and unbiased processing and analysis of this > suggestion. > > As main long-term advantage, I see YAML readability, for both > developers and newcomers, so a well commented code would probably make > efforts such > as > http://www.theopensourcerer.com/2012/12/how-to-install-openerp-7-0-on-ubuntu-12-04-lts/ > and many more optional. > It could equally and very flexibly serve the needs of entire and > complex project setups du tu it's inherent plub-and-play paradigm. > There are many playbooks out there for common subtasks (If 'm right, > that's what you call subfactories) such as setting up ngnx and > unicorn, ntp server, set up hardened linux, etc... > > Here > <https://github.com/odoo-colombia/provisioning/blob/master/vagrant-ubuntu-ansible/ansible_odoo/roles/odoo/tasks/odoo.yml> > is an example of the odoo-playbook, which throws up a simple > dev-instance. Not concluding, this is a beautiful unficiation of the > two (until now seperate) concepts of code and documentation, wouldn't > be understandable by many. I think what we do here > <https://github.com/odoo-colombia/provisioning/tree/master/vagrant-ubuntu-ansible> > is not the intention to found a competing framework, but an attempt to > get something working, draw momentum and influence joint decision > making towards a unified approache. Please keep that in mind while > evaluating. > > Please analyze and draw youre conclusion, I hope on the long run, the > community will always opt for the best solutions available. > > *Best,* David > > > * > * > ---------------------- > *David Arnold B.A. HSG* > *Gerente* > > +57 315 304 1368 > [email protected] <mailto:[email protected]> > www.elaleman.co <http://www.elaleman.co> > > El Alemán S.A.S, Carrera 13 # 93 - 40 P4, Bogotá D.C, Colombia > > > 2014-06-09 11:03 GMT-05:00 Georges Racinet <[email protected] > <mailto:[email protected]>>: > > Hi there, back from the OpenDays, it's been a great experience, > and I'm especially glad to have met so many of you in real life ! > This message summarizes the current status of > anybox.recipe.openerp (for short, *a.r.openerp*), future plans for > Odoo support (*a.r.odoo*), and asks for testing. > > We're open to suggestions, especially for the medium term plans. > > I'll be mostly offline until next monday, 2014-06-16 > > > a.r.openerp stable release > > We are very close to a 1.8.4 stable version, that'll handle Odoo > properly. > > Both bzr branches of the recipe are supposed to work for Github > versions of > - Odoo 8 > - OpenERP 7 (odoo repo, branch 7.0) > or any fork of them, of course. > > (many thanks to the contributors that helped make this happen) > > This is a special time for assembly / packaging tools, so we'll > try and do it the cautious way. > If all goes well, release should happen during next week. > > Since it's called a "stable" branch, existing buildouts should run > smoothly, so, please, give it a try in the context of your > projects (whatever version of OpenERP or Odoo they use), and > report any problems on launchpad. I'll look them up once I return. > Preliminary tests look good, and anybox's buildbot is green, but > that's never enough. > > Here's a sample config to use the stable (1.8) bzr branch: > > [buildout] > extensions = gp.vcsdevelop > vcs-extend-develop = > bzr+http://bazaar.launchpad.net/~anybox/anybox.recipe.openerp/1.8#egg=aro-1.8 > vcs-update > <http://bazaar.launchpad.net/%7Eanybox/anybox.recipe.openerp/1.8#egg=aro-1.8vcs-update> > = True > > [versions] > # in some cases that's needed > anybox.recipe.openerp = > > (see also > > http://pythonhosted.org/anybox.recipe.openerp/contributing.html#using-a-development-version) > > To check that you are indeed on the correct version (assuming the > part is called 'openerp'): > > bin/python_openerp > >>> import anybox.recipe.openerp as aro > >>> aro.__file_ > > Simplest Odoo 8 config: > > [odoo] > recipe = anybox.recipe.openerp:server > version = git http://github.com/odoo/odoo.git odoo master > > [versions] > reportlab = 2.7 > > There should not be a new development branch (1.10 or 2.0) after > 1.9 (the current trunk) is declared stable. > > > anybox.recipe.odoo > > As I announced during my talk, there'll be a new recipe for Odoo, > and we'll take the name change as an opportunity to drop backwards > compatibility and remove all these nasty workarounds meant to > support OpenERP from 5.0 onwards. > > So, a.r.odoo will support Odoo 8 and subsequent versions. > To ease the transition, a.r.openerp should also support Odoo 8. > If that becomes too much of work, we may change plans about that. > > As for version numbers, they'd start from 1.9.x > > > Transition to Github (both recipes) > > So far our plans are to have a reference repository on Github, > with three branches: > > - master: that's anybox.recipe.odoo, and the work starts from the > current 1.9 branch of a.r.openerp > - a.r.openerp-1.8, a.r.openerp-1.9 : current branches of > anybox.recipe.openerp, imported from launchpad > > > It's too early for a stable branch of a.r.odoo, we'll see about > that later down the road. > > After 1.9 becomes the new stable, all development of a.r.openerp > will stop on launchpad, in favor of the correct branch in Github. > That should happen around the end of june. Do we need a precise > deadline ? > > My current experiment to that effect is at > https://github.com/gracinet/a.r.odoo-testimport > > Sounds good ? > > > Regards, > > -- > Georges Racinet > Anybox SAS, http://anybox.fr > Bureau: 09 72 39 50 97 / 09 72 39 13 06 > Portable: 06 51 32 07 27 > GPG: 0x33AB0A35, sur serveurs publics > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-community > <https://launchpad.net/%7Eopenerp-community> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~openerp-community > <https://launchpad.net/%7Eopenerp-community> > More help : https://help.launchpad.net/ListHelp > > -- Georges Racinet Anybox SAS, http://anybox.fr Bureau: 09 72 39 50 97 / 09 72 39 13 06 Portable: 06 51 32 07 27 GPG: 0x33AB0A35, sur serveurs publics
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp

