On Sat, May 24, 2014 at 1:14 PM, Raphael Valyi <[email protected]> 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 < > [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 > > -- [image: Cristian Salamea on about.me] Cristian Salamea about.me/ovnicraft <http://about.me/ovnicraft>
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
