On 12-09-28 02:40 PM, Denny wrote: > Hi folks! > > I messed around with using boxgrinder and the new rpm repository to > build MH v-boxen. I don't have any trouble grinding out images, and I'm > tossing puppet and whatnot into the mix as well, so managing > configurations after grinding is easy, etc.. (I'll post the recipes on > github as I iron them out- eventually add openstack y todo, probably).
That would be awesome. I build VMs when I release RCs or final releases, but unfortunately I just don't have the time to build them more frequently than that. Insert comments on getting RCs out faster here. > I'm just wondering how the different profiles will work from a binary > installation perspective. I'm not sure how they work in general, to be > honest. Is it mostly a matter of turning on and off bundles in felix > and adjusting corresponding service URLs? More like adding or removing bits of code. When you compile (or download) just a profile (eg, the engage profile from http://opencast.jira.com/wiki/display/MHTRUNK/Install+Across+Multiple+Servers), you only get the bits that are specified in that set of profiles. Assuming the config files are setup correctly across your cluster Matterhorn should figure out the details of who has which service on its own. For instance, when I setup the testing cluster (testadmin.usask.ca:8080), I follow these instructions more or less to the letter and then I'm done. > I generate an internal RPM repository as part of my CI stuff, and I'm > just wondering if it is best to have everything in one package, or to > break stuff up somehow (admin, worker, engage, capture?). In a way you want to do *both*. The all in one build has a different codebase than the distributed build: In a distributed build the -remote (eg: matterhorn-workflow-service-remote) bundles are built. These are stubs that encapsulate calls to remote services on other nodes in a cluster. These (obviously) don't get built when you're building an all in one build, and this can cause problems c.f: MH-9204. > How are people envisioning the binary installation experience? How are > people handling binary installation currently? I can't really speak to that, but I am pushing Maven artifacts to the nexus so pulling down a given release (candidate) should be fairly simple with some Maven magic. G > :Denny >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
