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? 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 < [email protected]> 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 <[email protected]> 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 : [email protected] >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
