Hi Christian, Thank you very much for this discussion. It is very interesting (and educational) since it is relevant to my current top priority: getting our development—> deployment pipeline up and running quickly.
Getting back to more immediate practical matters… Given that there is not currently a bnd plugin to create a features file, and since I do not want to head in a solitary direction, what do you recommend I do to automate the generation / installation of my features? What I have: * OBR repositories “deployed” by the devs, which are handed over to the deployer * A Karaf command for the deployer to browse the available OBR repos What I need: * A means to actually install and start the bundles I don’t mind doing this against the Features service in runtime, since I am building a “deployment” service anyway, to be used by the deployer. Any thoughts to help me get up and running quickly would be very welcome. :-) Cheers, =David On Nov 26, 2015, at 10:20 PM, Christian Schneider <[email protected]> wrote: > On 26.11.2015 12:54, David Leangen wrote: >> >> Hi Christian, >> >> >> >>> This part of the bndrun file is the input for the resolver. This is always >>> needed. […] It is the purpose of a feature file or a bndrun file. [...] You >>> need to give the resolver the initial hooks to pull the needed bundles out >>> of this pool. >> >> What I understand from what you write is that the bndrun/feature file (call >> it a “runtime descriptor”?) is also nothing but a list of requirements and >> capabilities. If so, it seems to be essentially the same thing as an obr >> index: a list of resources with requirements and capabilities. The only >> difference I can see is that the obr index is for storing stuff and is >> ignorant of the runtime, while the the runtime descriptor only cares about >> what is required during a runtime, and doesn’t care if it contains all the >> stored resources or not. The contents otherwise seem very similar, if not >> identical. >> >> Sounds like two different views on the same thing, maybe. > They are kind of similar but you could argue the same for bundles and the obr > index. The bundle contains the requirement and capability headers as well as > the index. Still you need the bundles as the index is created out of the > bundle meta data. So in some way you could consider the index to be just a > cache for the meta data. It could be replaced by just a list of resources as > the resolver could also look into each bundle / feature / bndrun file > individually. >> >> Or perhaps the features.xml file is itself nothing but a resource (having >> requirements and capabilities) that could be expressed in an obr index. > The feature/bndrun file is indeed a resource in the obr repository sense. You > still need it though as the index is normally created out of something (as it > is a kind of cache). >> >> >> Also, I am still a bit stuck on the fact that the developers are the ones >> expected to create the runtime descriptor. I can understand if they want to >> immediately run something in a local test environment, but otherwise it >> seems to couple the devs to the deployment/runtime. Am I missing something, >> or is this related to the page of the yet-to-be-developers scenario you >> showed in your previous post (reposted below)? > Theoretically you could have a split there that developers only write the > code of bundles and do not care about the deployment at all. In reality you > want to create automated build/test pipelines that maybe reach even into > production. > > As you correctly stated developers need to at the very least test their code > locally. So they need to be involved at least in that part of the pipeline. > In fact developers are normally also responsible for the integration tests > that run locally as well as in a dev or test environments. On the other hand > you could have a deployer role that is responsible for all of this. So yes > you can say that the developer is not responsible for the features. > As you typically want to build kind of devops teams today in the end the > development team is most times responsible for development + deployment > sometimes until dev, test sometimes even to production. > > What I see in practice is that the real admins (that are not part of the dev > team) often are just responsible for the production servers. As the > deployment must already be present for previous steps in the pipeline it > typically does not make sense to let them define the deployment on their own. > > Christian > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com
