openerp-community team mailing list archive

[David Arnold - El Alemán <david@xxxxxxxxxxx>]

*Hello Georges*

thanks for your considerations.

I'm not sure, if I understod everything, but let this be my duty, and I
will figure out what you mean.

*/Quick Proposal:*
1. We might try to built some ansible stuff with everyone invited to join
on our repository and lable it "community experimenting".
2. We could try to replicate concepts and ideas from your work at anybox
gradually.
Like this we can explore better the limits of ansible and make informed
decisions based on collected common experience. (Probably the reliance on
zc.builtout can be reduced to it's core funcionalities in favor of a more
usable yaml for the rest of the milkshake...)

Convincing a hosting company probably isn't that hard once identified the
right arguments. That's the cool thing about open source trouthfullness,
isn't it? ;) I know, that mere enthusiasm might not be enough... But that's
where it starts :)

*Best*, David


----------------------
*David Arnold B.A. HSG*
*Gerente*

+57 315 304 1368
david@xxxxxxxxxxx
www.elaleman.co

​El Alemán S.A.S, Carrera 13 # 93 - 40 P4, Bogotá D.C, Colombia


2014-06-09 14:34 GMT-05:00 Georges Racinet <gracinet@xxxxxxxxx>:

>  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
> david@xxxxxxxxxxx
> 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 <gracinet@xxxxxxxxx>:
>
>>  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
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-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
>
>