openerp-community team mailing list archive

[Ovnicraft <ovnicraft@xxxxxxxxx>]

On Sat, May 24, 2014 at 1:14 PM, Raphael Valyi <rvalyi@xxxxxxxxx> wrote:

> hello all,
>
> a deployment issue I have with the Anybox recipe is that if you target
> HEAD or say last:1 on bzr branches, the recipe will try to grab the last
> available revisions. But it won't freeze anywhere the versions being
> actually deployed. So if in an other environment you want to replicate the
> environment or if you want to roll back a deployment it falls short.
> I may be wrong but I think the same issue happens with the eggs you don't
> specify the version. I mean it's cool to let the door open to the newest
> things. But once it's actually deployed you make like to know what exactly
> has been deployed for reference.
>
> What is the idea? never say last:1 / HEAD and always specify revisions to
> deploy? That sounds possible, but is it ideal?
>

IMO here, the best way is pull from defined version  in configuration, so
you want to deploy ocb-7.0 taks pull from branch.
Being that must consider update modules ? or specific modules from config ?

This doubts is hard to manage so developer or devop must to know what
modules to update.

In another hand, deploy machine is considering install new or update python
deps ? check this at sanboxed level with virtualenv or all its installed by
default in OS ? and what other services must be considered to deployed.

Could be time to make it better one existing tool to deploy (anybox.recipe
is the best candidate ? )

Comments !


>
> An alternative could be that when the recipe is "converged" to the desired
> state, it could produce some kind of buildout.lock file where exact
> revision converged would be kept under revision control.
> Several packages management have a similar strategy, like:
> Gemfile/Gemfile.lock for bundler, Berksfile/Berksfile.lock for Berkshelf
> and it's extremely efficient.
> Is there such a concept with Buildout? How?
>
> BTW,
>
> After I contributed a generic bzr provider for Chef
> https://github.com/akretion/ak-bzr (yes that was before the surprise git
> migration but will certainly be useful for v7 still).
> and after I generalized a config parser so it can now parse buildout
> configurations https://github.com/akretion/configparser
> my idea is to advance our ak-openerp-base Chef recipe
> https://github.com/akretion/ak-openerp-base so I will create e new
> OpenERP env provider that will be able to take a buildout.cfg build
> specification as an input and converge it but using Chef tools inside the
> Chef (solo or server) environment instead of Buildout (so you don't give up
> on Chef tooling in the context of Chef as you would be delegating the
> installation to Buildout). It will use virtualenv but only optionally.
> So I'm actually interested in knowing what is the idea to pin the exact
> branch revisions and module versions with buildout.cfg
>
> Any help is welcome.
>
>
> Regards.
>
>
>
>
>
> On Fri, May 23, 2014 at 9:05 AM, Yannick Vaucher <
> yannick.vaucher@xxxxxxxxxxxxxx> wrote:
>
>> Maybe you want to take a look at for instance deployement:
>>
>> https://pypi.python.org/pypi/anybox.recipe.openerp
>>
>> Cheers,
>>
>>
>> On Fri, May 23, 2014 at 1:46 PM, Phui Hock <phuihock@xxxxxxxxxxxx> wrote:
>>
>>> Hello all,
>>>
>>> OpenERP doesn't advocate any standard steps to deploy a new or update an
>>> existing instance. I draw much of the inspiration from pip and use fabric.
>>>
>>> 1. "freeze" modules (create a installed.txt) for modules that are
>>> currently installed
>>> 2. update ir_module_module table and set installable = False for other
>>> modules
>>> 3. pack the modules into a distribution zip
>>> 4. commit installed.txt and tag project
>>>
>>> I am not sure if this is the best way. Any other strategies that you may
>>> have developed over the years that you can share?
>>>
>>> Chang Phui Hock
>>> CODEKAKI SYSTEMS (R49045/14) - A web-dev company
>>> Skype: phuihock
>>> Website: http://www.codekaki.com
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Yannick Vaucher
>> Business Solutions Software Developer
>>
>> Camptocamp SA
>> PSE A, CH-1015 Lausanne
>> Phone: +41 21 619 10 30
>> Office: +41 21 619 10 10
>> http://www.camptocamp.com/
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>


-- 

[image: Cristian Salamea on about.me]

Cristian Salamea
about.me/ovnicraft
    <http://about.me/ovnicraft>