NO startlevels is best … :-)
If you really need start levels (and after thinking again) then you can your
set start levels by your management agent. One more reason why only one bundle
is started.
Though start levels can be helpful to make it look like the systems boots
faster, it is too often used to mask bad bundles that are not properly handling
their dependencies. Those bundles will give you pain in the future so it is
better to fix them from the start. And then they do not need start levels.
Kind regards,
Peter Kriens
> On 14 dec. 2015, at 17:02, Seth Lana <sethlanag...@gmail.com> wrote:
>
> Hi Peter,
>
> many thanks for your inputs, it really helped us to defined the way our team
> should to go.
>
> We had some difficulties defining the requirements of this pilot project due
> to, as you said, the large number of possibilities and combinations that we
> could have. But we are getting there...
>
> One last doubt, we have found no reference about bundle start level on both
> Initial Provisioning and Deployment Admin specs.
>
> In case of IP, we thought about two possibilities. One is to use IP archive's
> manifest file to hold the information and let the IP implementation bundle to
> use it after it install the bundle. for example:
> InitialProvisioning-Entries: org.apache.felix.scr;type=bundle;startLevel=2
> Another one is to add a text entry on the IP zip. as that will be stored in
> the provisioning dictionary then the management agent can obtain that
> information using the provisioning service and use it to set the startLevel.
>
> We are inclined for the option one. which would be the best approach for you?
>
> best regards,
>
> Seth
>
> On 10-12-2015 11:48, Peter Kriens wrote:
>>> On 9 dec. 2015, at 00:46, Seth Lana <sethlanag...@gmail.com>
>>> <mailto:sethlanag...@gmail.com> wrote:
>>> Hello,
>>> I’m researching about the best ways to provide automatic remote
>>> provisioning for small devices and also for the servers that will provide
>>> content for such devices. Reading the OSGi compendium, some specs caught my
>>> attention: Initial Provisioning, Deployment Admin, Subsystems and
>>> Repository Services.
>>>
>>> If I got it right, we can have a device with only the OSGi container(with a
>>> minimal deps) and the IP Agent bundle jars assembled at factory.
>> Yes. The core idea is that you deliver identical devices to all your
>> customers except for the identity (serial number or so).
>>
>>> At first use, the IP agent will contact the remote provisioning service
>>> (using Http or another protocol) and will download one or more IP zip files
>>> containing one or more bundles and configuration files defined by the
>>> remote provisioning operator for that device. All bundles inside the IP
>>> zips will be installed by the IP agent. So, this process follows until all
>>> necessary bundles are installed, ending with the Management Agent bundle
>>> being started. Am I right?
>> Yup.
>>
>>> What I found strange was the fact that only one bundle can be started at
>>> each time (each zip can have only one start entry pointing to only one
>>> bundle). Why this restriction?
>> This allows this single bundle to verify the environment, do some checks,
>> and setup security & start levels for example.
>>
>>> Should the Management Agent uninstall the IP agent after it is fully
>>> operational? or the IP must run every time the device starts up ?
>> There is no obligation here. Personally, I would make sure that in certain
>> situations the device can go back to initial mode so that the operator can
>> regain control of the device after a catastrophic event. But again, there
>> are not rules defined here.
>>
>>> But the biggest doubt is about that Management Agent itself. It seems that
>>> one needs to be developed, right?.
>> Yes. Something needs to provide YOUR policy, this is the management agent.
>> You could buy one (this was ProSyst’s answer), there is open source (this
>> was Marcel’s answer, or there is building it yourself. I prefer the latter
>> because it allows you to provide your policy to the management operations.
>> It is not a big deal because the management operations are part of the well
>> defined OSGi API and are almost trivial to use.
>>
>>> Should the Management Agent to use a Deployment Admin service provided by
>>> another bundle or should it be itself the provider of such service?
>> There are no restrictions here. Make sure the Management Agent only provides
>> policy so if you insist on using Deployment Admin then it is not a good idea
>> to implement it yourself.
>>
>>> And about the Repository Service, should it be used by the Management Agent
>>> or Deployment Admin or both?
>> I think you are focusing too much on all potential possibilities. What are
>> your requirements? OSGi is a bit like a box of Lego. Once you have a clear
>> vision of how you want to manage your devices you find the components in
>> OSGi. However, you can combine these components in infinite ways and
>> exploring all combinations is not providing you with the right solution any
>> time soon.
>>
>>> Can a Subsystem (.esa) be package inside a Deployment Package?
>> You can write your own Resource Processor with Deployment Admin so in
>> principle yes. However, both Deployment Admin and subsystems struggle with
>> sharing bundles. Deployment Admin took the easy way out and decided to not
>> share bundles. Subsystems do allow sharing but struggles because of the
>> complexity this creates.
>>
>>> Can the Deployment Packages (*.dp) or Subsystems (*.esa) also be provided
>>> by an OSGi repository ?
>> Again yes. You will need to write a Resource Processor and then you can
>> install anything anywhere with Deployment Admin.
>>
>> You might get more useful advice from this group if you provide us with the
>> actual use case.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>> thanks for any opinion.
>>>
>>> regards, Seth.
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
