You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "John E. Conlon" <jc...@verticon.com> on 2006/01/20 16:44:40 UTC
Re: Using OSGi as a provisioning and management platform for
distributed components.
IMHO I think the Initial Provisioning Service would provide the standard
infrastructure to do this.
> > When each node starts up, it contacts to the configuration and component
> > (bundle) repository and pulls its required components on the fly.
Alternately if one were to use the Provisioning Service...when each
node boots up it starts the Provisioning Service which then retrieves
the Provisioning Zip pointed to by a preconfigured URL. This Zip
contains configuration information, bundles, or references to additional
Provisioning Zips. It also specifies which bundle to start.
This start up bundle is considered a management agent. A management
agent could be anything a provider would like. When the management agent
starts up it looks for the Provisioning Service. The Provisioning
Service Interface than provides all the hooks to control and restart the
process. It's a chicken and egg kind of thing. Provisioning starts the
management agent and then exposes itself to its management agent child.
In this case it could install bundles from repositories or bring in
other management agents. It could be autonomous or be under the control
of the local or remote operator. (Or a combination.) Control can also be
passed off from one operator to the next.
> If the
> > node's profile changes, the repository notifies the change to it and it will
> > automatically update existing bundles, deploy new bundles, and undeploy
> > unused bundles. Of course, all configurations and states of the deployed
> > components are supposed to be monitored and reconfigured by a GUI console
> > which runs in an Administrator's desktop PC.
Again I think this can be done in a standard way. As a matter of fact I
am attempting this with the Provisioning Service and JMX.
Trustin is this for the ApacheDS or the MINA project?
cheers,
John
On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
> Trustin,
>
> There is no standard way to do what you ask. Some pieces may help you,
> such as the OBR bundle repository and others. Other people have created
> management consoles too, although I am not sure what is freely
> available. I definitely think OSGi sounds up to the task for what you
> want to do.
>
> -> richard
>
> Trustin Lee wrote:
> > Hi all,
> >
> > I'm designing a distributed application platform which provides provisioning
> > and management.
> >
> > When each node starts up, it contacts to the configuration and component
> > (bundle) repository and pulls its required components on the fly. If the
> > node's profile changes, the repository notifies the change to it and it will
> > automatically update existing bundles, deploy new bundles, and undeploy
> > unused bundles. Of course, all configurations and states of the deployed
> > components are supposed to be monitored and reconfigured by a GUI console
> > which runs in an Administrator's desktop PC.
> >
> > I think I can do this with OSGi, but I have no idea if it is standardized,
> > or the standardization is in progress. Anyone who can provision me? :)
> >
> > Thanks in advance,
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > PGP Key ID: 0x854B996C
> >
> >
>
Re: Provisioning Service
Posted by "John E. Conlon" <jc...@verticon.com>.
Peter,
You can retrieve a Provisioning zip that I created from a M2
Provisioning Plugin from:
http://www.verticon.com/repository/org/apache/felix/provisioning/tests/provisioning-test-zip1/1.0/provisioning-test-zip1-1.0.zip
Notes:
1. HTTP site is only a web server and does not expect service platform
information.
2. Provisioning Zip contains:
a. Management Agent
b. Two Bundle-URL entries referencing a Log Service and a Log Reader
bundle URLs reference in the Oscar repository.
c. Two Text Entries
d. One Binary Entry
3. Management agent in Provisioning Zip does the following actions when
it starts:
a. Starts all Installed Bundles (this is intended for the Log Service
and Reader bundles but the agent does not know about those, it is just
starting bundles.)
b. Finds the Provisioning Service and dumps its information dictionary
to the system out or a log service if it exists.
Let me know how it works.
Oh BTW - Can you send me one of your Provisioning Zips so I can test it
with the provisioning service that I have implemented?
cheers,
John Conlon
Verticon, Inc.
On Tue, 2006-01-24 at 00:55, Peter Kriens wrote:
> Yes, you can send them to me and I will verify them against the ref
> impl.
>
> Kind regards,
>
> Peter Kriens
>
> JEC> Peter,
>
> JEC> It is my intention to donate a Provisioning Implementation in addition
> JEC> to a M2 plugin for creating the zips to felix.
>
> JEC> Peter, you mentioned you have a tool for creating Provisioning Zip
> JEC> files. My M2 plugin seems to be producing valid zips that function for
> JEC> my implementation, but I would like to confirm this with some interop
> JEC> testing with the artifacts created from your tool.
>
> JEC> Can we exchange some Provisioning Zip files for interop testing?
>
> JEC> cheers,
> JEC> John Conlon
> JEC> Verticon, Inc.
>
> JEC> On Fri, 2006-01-20 at 11:18, Peter Kriens wrote:
> >> I wrote a tool that makes the ZIP files and I am trying desperately to
> >> make it open source ...
>
>
Re: Provisioning Service
Posted by Peter Kriens <Pe...@aQute.se>.
Yes, you can send them to me and I will verify them against the ref
impl.
Kind regards,
Peter Kriens
JEC> Peter,
JEC> It is my intention to donate a Provisioning Implementation in addition
JEC> to a M2 plugin for creating the zips to felix.
JEC> Peter, you mentioned you have a tool for creating Provisioning Zip
JEC> files. My M2 plugin seems to be producing valid zips that function for
JEC> my implementation, but I would like to confirm this with some interop
JEC> testing with the artifacts created from your tool.
JEC> Can we exchange some Provisioning Zip files for interop testing?
JEC> cheers,
JEC> John Conlon
JEC> Verticon, Inc.
JEC> On Fri, 2006-01-20 at 11:18, Peter Kriens wrote:
>> I wrote a tool that makes the ZIP files and I am trying desperately to
>> make it open source ...
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Provisioning Service
Posted by "John E. Conlon" <jc...@verticon.com>.
Peter,
It is my intention to donate a Provisioning Implementation in addition
to a M2 plugin for creating the zips to felix.
Peter, you mentioned you have a tool for creating Provisioning Zip
files. My M2 plugin seems to be producing valid zips that function for
my implementation, but I would like to confirm this with some interop
testing with the artifacts created from your tool.
Can we exchange some Provisioning Zip files for interop testing?
cheers,
John Conlon
Verticon, Inc.
On Fri, 2006-01-20 at 11:18, Peter Kriens wrote:
> I wrote a tool that makes the ZIP files and I am trying desperately to
> make it open source ...
Re: Re[2]: Using OSGi as a provisioning and management platform
for distributed components.
Posted by "John E. Conlon" <jc...@verticon.com>.
RSH> Well, if I understand correctly, then that gets back to the
original
> RSH> point I made, which is there is no standard way to achieve the desired
> RSH> result, you just have to code your own custom management agent.
Right. Sorry if I appeared contradictory. The management agent does the
major work and it would be custom. (Provisioning is another standard way
to support a higher level something that is custom.) But the cool thing
about provisioning is that if it is used for supporting that custom
management agent, one custom agent once done with its task, could then
pass off control to another custom management agent, by just passing a
URL.
> On Fri, 2006-01-20 at 11:18, Peter Kriens wrote:
> The Initial Provisioning specification is NOT the management agent. It
> can install a set of bundles but it cannot uninstall bundles. It is
> exactly what it is called, a model to download an operator's
> environment in a virginal box.
>
> I am very interested in how this evolves, I always liked Initial
> Provisioning but few companies picked it up as far as I know.
>
> I wrote a tool that makes the ZIP files and I am trying desperately to
> make it open source ...
I am writing a M2 plugin to do this right now. It's my first M2 plugin so I am
fumbling and learning as I go.
regards, John
> Kind regards,
>
> Peter Kriens
>
> RSH> John E. Conlon wrote:
> >> The Provisioning spec doesn't dictate what happens with the state of the
> >> bundles already on the machine. Those bundle may not be effected with
> >> the start or stop of the provisioning service. It just offers it's
> >> service, loads one or more bundles, and starts one. It's just a way to
> >> dynamically load and start something else: the management agent.
> >>
> >> Now the management agent on the other hand, could like you suggested be
> >> totalitarian and stop and uninstall everything or it could, be a more
> >> mellow component like a shellTUI or a shellGUI or it could do fine
> >> grained tuning and orchestration of the other bundles.
> >>
> >> I think of the Provisioning service like the foot in the door and the
> >> management agent as the salesperson;-)
> >>
>
> RSH> Well, if I understand correctly, then that gets back to the original
> RSH> point I made, which is there is no standard way to achieve the desired
> RSH> result, you just have to code your own custom management agent.
>
> ->> richard
>
> >> John
> >>
> >> On Fri, 2006-01-20 at 10:05, Richard S. Hall wrote:
> >>
> >>> I guess I was thinking that changes to a node would be more
> >>> fine-grained, i.e., only some components would be added/updated/removed,
> >>> and more uncoordinated. However, if the whole configuration just needs
> >>> to be wiped out and reset by a central authority, then I agree it is
> >>> probably possible to do so using the Initial Provisioning Service.
> >>>
> >>> -> richard
> >>>
> >>> John E. Conlon wrote:
> >>>
> >>>> IMHO I think the Initial Provisioning Service would provide the standard
> >>>> infrastructure to do this.
> >>>>
> >>>>
> >>>>
> >>>>>> When each node starts up, it contacts to the configuration and component
> >>>>>> (bundle) repository and pulls its required components on the fly.
> >>>>>>
> >>>>>>
> >>>> Alternately if one were to use the Provisioning Service...when each
> >>>> node boots up it starts the Provisioning Service which then retrieves
> >>>> the Provisioning Zip pointed to by a preconfigured URL. This Zip
> >>>> contains configuration information, bundles, or references to additional
> >>>> Provisioning Zips. It also specifies which bundle to start.
> >>>> This start up bundle is considered a management agent. A management
> >>>> agent could be anything a provider would like. When the management agent
> >>>> starts up it looks for the Provisioning Service. The Provisioning
> >>>> Service Interface than provides all the hooks to control and restart the
> >>>> process. It's a chicken and egg kind of thing. Provisioning starts the
> >>>> management agent and then exposes itself to its management agent child.
> >>>> In this case it could install bundles from repositories or bring in
> >>>> other management agents. It could be autonomous or be under the control
> >>>> of the local or remote operator. (Or a combination.) Control can also be
> >>>> passed off from one operator to the next.
> >>>>
> >>>>
> >>>>> If the
> >>>>>
> >>>>>
> >>>>>> node's profile changes, the repository notifies the change to it and it will
> >>>>>> automatically update existing bundles, deploy new bundles, and undeploy
> >>>>>> unused bundles. Of course, all configurations and states of the deployed
> >>>>>> components are supposed to be monitored and reconfigured by a GUI console
> >>>>>> which runs in an Administrator's desktop PC.
> >>>>>>
> >>>>>>
> >>>> Again I think this can be done in a standard way. As a matter of fact I
> >>>> am attempting this with the Provisioning Service and JMX.
> >>>>
> >>>> Trustin is this for the ApacheDS or the MINA project?
> >>>>
> >>>> cheers,
> >>>> John
> >>>>
> >>>>
> >>>> On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
> >>>>
> >>>>
> >>>>> Trustin,
> >>>>>
> >>>>> There is no standard way to do what you ask. Some pieces may help you,
> >>>>> such as the OBR bundle repository and others. Other people have created
> >>>>> management consoles too, although I am not sure what is freely
> >>>>> available. I definitely think OSGi sounds up to the task for what you
> >>>>> want to do.
> >>>>>
> >>>>> -> richard
> >>>>>
> >>>>> Trustin Lee wrote:
> >>>>>
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm designing a distributed application platform which provides provisioning
> >>>>>> and management.
> >>>>>>
> >>>>>> When each node starts up, it contacts to the configuration and component
> >>>>>> (bundle) repository and pulls its required components on the fly. If the
> >>>>>> node's profile changes, the repository notifies the change to it and it will
> >>>>>> automatically update existing bundles, deploy new bundles, and undeploy
> >>>>>> unused bundles. Of course, all configurations and states of the deployed
> >>>>>> components are supposed to be monitored and reconfigured by a GUI console
> >>>>>> which runs in an Administrator's desktop PC.
> >>>>>>
> >>>>>> I think I can do this with OSGi, but I have no idea if it is standardized,
> >>>>>> or the standardization is in progress. Anyone who can provision me? :)
> >>>>>>
> >>>>>> Thanks in advance,
> >>>>>> Trustin
> >>>>>> --
> >>>>>> what we call human nature is actually human habit
> >>>>>> --
> >>>>>> http://gleamynode.net/
> >>>>>> PGP Key ID: 0x854B996C
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >>
Re: Using OSGi as a provisioning and management platform for distributed components.
Posted by Trustin Lee <tr...@gmail.com>.
Sounds great. I'm looking forward to OBR2! :)
Thanks,
Trustin
2006/1/24, Richard S. Hall <he...@ungoverned.org>:
>
> Trustin Lee wrote:
> > Another question I'd like to ask is... Can OBR (OSGi Bundle Repository?)
> > specify the dependency and version information as expressively as Maven
> 2
> > do? I need that level of detail so nodes can pull bundles automatically
> > calculating their dependencies. This will help administrator to specify
> > minimal set of bundles to create a node profile.
>
> The original OBR assumed backwards compatibility for version numbers,
> but the newer [not yet complete] OBR supports LDAP filters for
> expressing constraints, so it should be pretty expressive.
>
> -> richard
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Re: Using OSGi as a provisioning and management platform for distributed
components.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Trustin Lee wrote:
> Another question I'd like to ask is... Can OBR (OSGi Bundle Repository?)
> specify the dependency and version information as expressively as Maven 2
> do? I need that level of detail so nodes can pull bundles automatically
> calculating their dependencies. This will help administrator to specify
> minimal set of bundles to create a node profile.
The original OBR assumed backwards compatibility for version numbers,
but the newer [not yet complete] OBR supports LDAP filters for
expressing constraints, so it should be pretty expressive.
-> richard
Re: Re[2]: Using OSGi as a provisioning and management platform
for distributed components.
Posted by "John E. Conlon" <jc...@verticon.com>.
On Fri, 2006-01-20 at 17:51, Trustin Lee wrote:
> Hi all OSGi gurus,
>
> It is great to see you Peter. Your PPT slides helped me a lot when I learn
> the basics of OSGi. :)
>
> 2006/1/21, Peter Kriens <Pe...@aqute.se>:
> >
> > The Initial Provisioning specification is NOT the management agent. It
> > can install a set of bundles but it cannot uninstall bundles. It is
> > exactly what it is called, a model to download an operator's
> > environment in a virginal box.
Perhaps the name is a bit misleading. It is also a model to download an
operator's environment or a management agent, or a set of new bundles,
or set of updates to existing modules in a 'non-virginal' boxes;-) as
well.
>
> I see. From the higher view, isn't provisioning process a subset of
> reconfiguration from 'empty' OSGi container? It doesn't make sense for me to
> use the Initial Provisioning specification at the first boot and then use
> proprietary way for reconfiguration.
One can use a proprietary way for agent management but deliver it via
the Provisioning service. It's a very convenient way to move agents into
the platform and let them do the work for you. I think this could be
likened to the visitor pattern, where various management agents may
visit the platform and reconfigure it as conditions require. With the
provisioning service the management agent code can be really minimal to
reconfigure the platform.
I worked with Sun's Rio CyberNode (AKA Jini on steroids) on several
projects see: http://rio.jini.org/index.html and check out their write
up on dynamic provisioning. It's pretty sweet. I think the Provisioning
Service has the potential to enable something similar for OSGi
containers.
>
> What I'm going to do is for the implementation of Google File System of the
> company I'm working for. Google File System, a distributed and replicated
> file system, will have more than 100 nodes per cluster. Each node's
> configuration should be managed by central system so it can be easily
> deployed and undeployed on demand (both automatically by a load balancer and
> manually by an administrator).
>
> If we provide 'node profile repository', 'bundle repository', and
> 'reconfiguration notifier', then we could implement this very easily.
>
> Another question I'd like to ask is... Can OBR (OSGi Bundle Repository?)
> specify the dependency and version information as expressively as Maven 2
> do? I need that level of detail so nodes can pull bundles automatically
> calculating their dependencies. This will help administrator to specify
> minimal set of bundles to create a node profile.
John
Re: Re[2]: Using OSGi as a provisioning and management platform for distributed components.
Posted by Trustin Lee <tr...@gmail.com>.
Hi all OSGi gurus,
It is great to see you Peter. Your PPT slides helped me a lot when I learn
the basics of OSGi. :)
2006/1/21, Peter Kriens <Pe...@aqute.se>:
>
> The Initial Provisioning specification is NOT the management agent. It
> can install a set of bundles but it cannot uninstall bundles. It is
> exactly what it is called, a model to download an operator's
> environment in a virginal box.
I see. From the higher view, isn't provisioning process a subset of
reconfiguration from 'empty' OSGi container? It doesn't make sense for me to
use the Initial Provisioning specification at the first boot and then use
proprietary way for reconfiguration.
What I'm going to do is for the implementation of Google File System of the
company I'm working for. Google File System, a distributed and replicated
file system, will have more than 100 nodes per cluster. Each node's
configuration should be managed by central system so it can be easily
deployed and undeployed on demand (both automatically by a load balancer and
manually by an administrator).
If we provide 'node profile repository', 'bundle repository', and
'reconfiguration notifier', then we could implement this very easily.
Another question I'd like to ask is... Can OBR (OSGi Bundle Repository?)
specify the dependency and version information as expressively as Maven 2
do? I need that level of detail so nodes can pull bundles automatically
calculating their dependencies. This will help administrator to specify
minimal set of bundles to create a node profile.
Thank you for all your help!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Re: Using OSGi as a provisioning and management platform for distributed
components.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Kriens wrote:
> The Initial Provisioning specification is NOT the management agent.
Correct. That was my point. The Initial Provisioning Service is
standard, but the management agent that is needed to fulfill the
scenario is not.
> I am very interested in how this evolves, I always liked Initial
> Provisioning but few companies picked it up as far as I know.
>
I think it sounded reasonable when I read the spec back in R3, but I
have just never had the time to implement it myself...maybe John can
help Felix in this regard. :-)
> I wrote a tool that makes the ZIP files and I am trying desperately to
> make it open source ...
>
Felix would gladly accept the contribution.
-> richard
> Kind regards,
>
> Peter Kriens
>
> RSH> John E. Conlon wrote:
>
>>> The Provisioning spec doesn't dictate what happens with the state of the
>>> bundles already on the machine. Those bundle may not be effected with
>>> the start or stop of the provisioning service. It just offers it's
>>> service, loads one or more bundles, and starts one. It's just a way to
>>> dynamically load and start something else: the management agent.
>>>
>>> Now the management agent on the other hand, could like you suggested be
>>> totalitarian and stop and uninstall everything or it could, be a more
>>> mellow component like a shellTUI or a shellGUI or it could do fine
>>> grained tuning and orchestration of the other bundles.
>>>
>>> I think of the Provisioning service like the foot in the door and the
>>> management agent as the salesperson;-)
>>>
>>>
>
> RSH> Well, if I understand correctly, then that gets back to the original
> RSH> point I made, which is there is no standard way to achieve the desired
> RSH> result, you just have to code your own custom management agent.
>
> ->> richard
>
>
>>> John
>>>
>>> On Fri, 2006-01-20 at 10:05, Richard S. Hall wrote:
>>>
>>>
>>>> I guess I was thinking that changes to a node would be more
>>>> fine-grained, i.e., only some components would be added/updated/removed,
>>>> and more uncoordinated. However, if the whole configuration just needs
>>>> to be wiped out and reset by a central authority, then I agree it is
>>>> probably possible to do so using the Initial Provisioning Service.
>>>>
>>>> -> richard
>>>>
>>>> John E. Conlon wrote:
>>>>
>>>>
>>>>> IMHO I think the Initial Provisioning Service would provide the standard
>>>>> infrastructure to do this.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> When each node starts up, it contacts to the configuration and component
>>>>>>> (bundle) repository and pulls its required components on the fly.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Alternately if one were to use the Provisioning Service...when each
>>>>> node boots up it starts the Provisioning Service which then retrieves
>>>>> the Provisioning Zip pointed to by a preconfigured URL. This Zip
>>>>> contains configuration information, bundles, or references to additional
>>>>> Provisioning Zips. It also specifies which bundle to start.
>>>>> This start up bundle is considered a management agent. A management
>>>>> agent could be anything a provider would like. When the management agent
>>>>> starts up it looks for the Provisioning Service. The Provisioning
>>>>> Service Interface than provides all the hooks to control and restart the
>>>>> process. It's a chicken and egg kind of thing. Provisioning starts the
>>>>> management agent and then exposes itself to its management agent child.
>>>>> In this case it could install bundles from repositories or bring in
>>>>> other management agents. It could be autonomous or be under the control
>>>>> of the local or remote operator. (Or a combination.) Control can also be
>>>>> passed off from one operator to the next.
>>>>>
>>>>>
>>>>>
>>>>>> If the
>>>>>>
>>>>>>
>>>>>>
>>>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>>>> which runs in an Administrator's desktop PC.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Again I think this can be done in a standard way. As a matter of fact I
>>>>> am attempting this with the Provisioning Service and JMX.
>>>>>
>>>>> Trustin is this for the ApacheDS or the MINA project?
>>>>>
>>>>> cheers,
>>>>> John
>>>>>
>>>>>
>>>>> On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Trustin,
>>>>>>
>>>>>> There is no standard way to do what you ask. Some pieces may help you,
>>>>>> such as the OBR bundle repository and others. Other people have created
>>>>>> management consoles too, although I am not sure what is freely
>>>>>> available. I definitely think OSGi sounds up to the task for what you
>>>>>> want to do.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> Trustin Lee wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm designing a distributed application platform which provides provisioning
>>>>>>> and management.
>>>>>>>
>>>>>>> When each node starts up, it contacts to the configuration and component
>>>>>>> (bundle) repository and pulls its required components on the fly. If the
>>>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>>>> which runs in an Administrator's desktop PC.
>>>>>>>
>>>>>>> I think I can do this with OSGi, but I have no idea if it is standardized,
>>>>>>> or the standardization is in progress. Anyone who can provision me? :)
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Trustin
>>>>>>> --
>>>>>>> what we call human nature is actually human habit
>>>>>>> --
>>>>>>> http://gleamynode.net/
>>>>>>> PGP Key ID: 0x854B996C
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re[2]: Using OSGi as a provisioning and management platform for distributed components.
Posted by Peter Kriens <Pe...@aQute.se>.
The Initial Provisioning specification is NOT the management agent. It
can install a set of bundles but it cannot uninstall bundles. It is
exactly what it is called, a model to download an operator's
environment in a virginal box.
I am very interested in how this evolves, I always liked Initial
Provisioning but few companies picked it up as far as I know.
I wrote a tool that makes the ZIP files and I am trying desperately to
make it open source ...
Kind regards,
Peter Kriens
RSH> John E. Conlon wrote:
>> The Provisioning spec doesn't dictate what happens with the state of the
>> bundles already on the machine. Those bundle may not be effected with
>> the start or stop of the provisioning service. It just offers it's
>> service, loads one or more bundles, and starts one. It's just a way to
>> dynamically load and start something else: the management agent.
>>
>> Now the management agent on the other hand, could like you suggested be
>> totalitarian and stop and uninstall everything or it could, be a more
>> mellow component like a shellTUI or a shellGUI or it could do fine
>> grained tuning and orchestration of the other bundles.
>>
>> I think of the Provisioning service like the foot in the door and the
>> management agent as the salesperson;-)
>>
RSH> Well, if I understand correctly, then that gets back to the original
RSH> point I made, which is there is no standard way to achieve the desired
RSH> result, you just have to code your own custom management agent.
->> richard
>> John
>>
>> On Fri, 2006-01-20 at 10:05, Richard S. Hall wrote:
>>
>>> I guess I was thinking that changes to a node would be more
>>> fine-grained, i.e., only some components would be added/updated/removed,
>>> and more uncoordinated. However, if the whole configuration just needs
>>> to be wiped out and reset by a central authority, then I agree it is
>>> probably possible to do so using the Initial Provisioning Service.
>>>
>>> -> richard
>>>
>>> John E. Conlon wrote:
>>>
>>>> IMHO I think the Initial Provisioning Service would provide the standard
>>>> infrastructure to do this.
>>>>
>>>>
>>>>
>>>>>> When each node starts up, it contacts to the configuration and component
>>>>>> (bundle) repository and pulls its required components on the fly.
>>>>>>
>>>>>>
>>>> Alternately if one were to use the Provisioning Service...when each
>>>> node boots up it starts the Provisioning Service which then retrieves
>>>> the Provisioning Zip pointed to by a preconfigured URL. This Zip
>>>> contains configuration information, bundles, or references to additional
>>>> Provisioning Zips. It also specifies which bundle to start.
>>>> This start up bundle is considered a management agent. A management
>>>> agent could be anything a provider would like. When the management agent
>>>> starts up it looks for the Provisioning Service. The Provisioning
>>>> Service Interface than provides all the hooks to control and restart the
>>>> process. It's a chicken and egg kind of thing. Provisioning starts the
>>>> management agent and then exposes itself to its management agent child.
>>>> In this case it could install bundles from repositories or bring in
>>>> other management agents. It could be autonomous or be under the control
>>>> of the local or remote operator. (Or a combination.) Control can also be
>>>> passed off from one operator to the next.
>>>>
>>>>
>>>>> If the
>>>>>
>>>>>
>>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>>> which runs in an Administrator's desktop PC.
>>>>>>
>>>>>>
>>>> Again I think this can be done in a standard way. As a matter of fact I
>>>> am attempting this with the Provisioning Service and JMX.
>>>>
>>>> Trustin is this for the ApacheDS or the MINA project?
>>>>
>>>> cheers,
>>>> John
>>>>
>>>>
>>>> On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
>>>>
>>>>
>>>>> Trustin,
>>>>>
>>>>> There is no standard way to do what you ask. Some pieces may help you,
>>>>> such as the OBR bundle repository and others. Other people have created
>>>>> management consoles too, although I am not sure what is freely
>>>>> available. I definitely think OSGi sounds up to the task for what you
>>>>> want to do.
>>>>>
>>>>> -> richard
>>>>>
>>>>> Trustin Lee wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm designing a distributed application platform which provides provisioning
>>>>>> and management.
>>>>>>
>>>>>> When each node starts up, it contacts to the configuration and component
>>>>>> (bundle) repository and pulls its required components on the fly. If the
>>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>>> which runs in an Administrator's desktop PC.
>>>>>>
>>>>>> I think I can do this with OSGi, but I have no idea if it is standardized,
>>>>>> or the standardization is in progress. Anyone who can provision me? :)
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Trustin
>>>>>> --
>>>>>> what we call human nature is actually human habit
>>>>>> --
>>>>>> http://gleamynode.net/
>>>>>> PGP Key ID: 0x854B996C
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Using OSGi as a provisioning and management platform for distributed
components.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> The Provisioning spec doesn't dictate what happens with the state of the
> bundles already on the machine. Those bundle may not be effected with
> the start or stop of the provisioning service. It just offers it's
> service, loads one or more bundles, and starts one. It's just a way to
> dynamically load and start something else: the management agent.
>
> Now the management agent on the other hand, could like you suggested be
> totalitarian and stop and uninstall everything or it could, be a more
> mellow component like a shellTUI or a shellGUI or it could do fine
> grained tuning and orchestration of the other bundles.
>
> I think of the Provisioning service like the foot in the door and the
> management agent as the salesperson;-)
>
Well, if I understand correctly, then that gets back to the original
point I made, which is there is no standard way to achieve the desired
result, you just have to code your own custom management agent.
-> richard
> John
>
> On Fri, 2006-01-20 at 10:05, Richard S. Hall wrote:
>
>> I guess I was thinking that changes to a node would be more
>> fine-grained, i.e., only some components would be added/updated/removed,
>> and more uncoordinated. However, if the whole configuration just needs
>> to be wiped out and reset by a central authority, then I agree it is
>> probably possible to do so using the Initial Provisioning Service.
>>
>> -> richard
>>
>> John E. Conlon wrote:
>>
>>> IMHO I think the Initial Provisioning Service would provide the standard
>>> infrastructure to do this.
>>>
>>>
>>>
>>>>> When each node starts up, it contacts to the configuration and component
>>>>> (bundle) repository and pulls its required components on the fly.
>>>>>
>>>>>
>>> Alternately if one were to use the Provisioning Service...when each
>>> node boots up it starts the Provisioning Service which then retrieves
>>> the Provisioning Zip pointed to by a preconfigured URL. This Zip
>>> contains configuration information, bundles, or references to additional
>>> Provisioning Zips. It also specifies which bundle to start.
>>> This start up bundle is considered a management agent. A management
>>> agent could be anything a provider would like. When the management agent
>>> starts up it looks for the Provisioning Service. The Provisioning
>>> Service Interface than provides all the hooks to control and restart the
>>> process. It's a chicken and egg kind of thing. Provisioning starts the
>>> management agent and then exposes itself to its management agent child.
>>> In this case it could install bundles from repositories or bring in
>>> other management agents. It could be autonomous or be under the control
>>> of the local or remote operator. (Or a combination.) Control can also be
>>> passed off from one operator to the next.
>>>
>>>
>>>> If the
>>>>
>>>>
>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>> which runs in an Administrator's desktop PC.
>>>>>
>>>>>
>>> Again I think this can be done in a standard way. As a matter of fact I
>>> am attempting this with the Provisioning Service and JMX.
>>>
>>> Trustin is this for the ApacheDS or the MINA project?
>>>
>>> cheers,
>>> John
>>>
>>>
>>> On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
>>>
>>>
>>>> Trustin,
>>>>
>>>> There is no standard way to do what you ask. Some pieces may help you,
>>>> such as the OBR bundle repository and others. Other people have created
>>>> management consoles too, although I am not sure what is freely
>>>> available. I definitely think OSGi sounds up to the task for what you
>>>> want to do.
>>>>
>>>> -> richard
>>>>
>>>> Trustin Lee wrote:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm designing a distributed application platform which provides provisioning
>>>>> and management.
>>>>>
>>>>> When each node starts up, it contacts to the configuration and component
>>>>> (bundle) repository and pulls its required components on the fly. If the
>>>>> node's profile changes, the repository notifies the change to it and it will
>>>>> automatically update existing bundles, deploy new bundles, and undeploy
>>>>> unused bundles. Of course, all configurations and states of the deployed
>>>>> components are supposed to be monitored and reconfigured by a GUI console
>>>>> which runs in an Administrator's desktop PC.
>>>>>
>>>>> I think I can do this with OSGi, but I have no idea if it is standardized,
>>>>> or the standardization is in progress. Anyone who can provision me? :)
>>>>>
>>>>> Thanks in advance,
>>>>> Trustin
>>>>> --
>>>>> what we call human nature is actually human habit
>>>>> --
>>>>> http://gleamynode.net/
>>>>> PGP Key ID: 0x854B996C
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: Using OSGi as a provisioning and management platform
for distributed components.
Posted by "John E. Conlon" <jc...@verticon.com>.
The Provisioning spec doesn't dictate what happens with the state of the
bundles already on the machine. Those bundle may not be effected with
the start or stop of the provisioning service. It just offers it's
service, loads one or more bundles, and starts one. It's just a way to
dynamically load and start something else: the management agent.
Now the management agent on the other hand, could like you suggested be
totalitarian and stop and uninstall everything or it could, be a more
mellow component like a shellTUI or a shellGUI or it could do fine
grained tuning and orchestration of the other bundles.
I think of the Provisioning service like the foot in the door and the
management agent as the salesperson;-)
John
On Fri, 2006-01-20 at 10:05, Richard S. Hall wrote:
> I guess I was thinking that changes to a node would be more
> fine-grained, i.e., only some components would be added/updated/removed,
> and more uncoordinated. However, if the whole configuration just needs
> to be wiped out and reset by a central authority, then I agree it is
> probably possible to do so using the Initial Provisioning Service.
>
> -> richard
>
> John E. Conlon wrote:
> > IMHO I think the Initial Provisioning Service would provide the standard
> > infrastructure to do this.
> >
> >
> >>> When each node starts up, it contacts to the configuration and component
> >>> (bundle) repository and pulls its required components on the fly.
> >>>
> >
> > Alternately if one were to use the Provisioning Service...when each
> > node boots up it starts the Provisioning Service which then retrieves
> > the Provisioning Zip pointed to by a preconfigured URL. This Zip
> > contains configuration information, bundles, or references to additional
> > Provisioning Zips. It also specifies which bundle to start.
> > This start up bundle is considered a management agent. A management
> > agent could be anything a provider would like. When the management agent
> > starts up it looks for the Provisioning Service. The Provisioning
> > Service Interface than provides all the hooks to control and restart the
> > process. It's a chicken and egg kind of thing. Provisioning starts the
> > management agent and then exposes itself to its management agent child.
> > In this case it could install bundles from repositories or bring in
> > other management agents. It could be autonomous or be under the control
> > of the local or remote operator. (Or a combination.) Control can also be
> > passed off from one operator to the next.
> >
> >> If the
> >>
> >>> node's profile changes, the repository notifies the change to it and it will
> >>> automatically update existing bundles, deploy new bundles, and undeploy
> >>> unused bundles. Of course, all configurations and states of the deployed
> >>> components are supposed to be monitored and reconfigured by a GUI console
> >>> which runs in an Administrator's desktop PC.
> >>>
> > Again I think this can be done in a standard way. As a matter of fact I
> > am attempting this with the Provisioning Service and JMX.
> >
> > Trustin is this for the ApacheDS or the MINA project?
> >
> > cheers,
> > John
> >
> >
> > On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
> >
> >> Trustin,
> >>
> >> There is no standard way to do what you ask. Some pieces may help you,
> >> such as the OBR bundle repository and others. Other people have created
> >> management consoles too, although I am not sure what is freely
> >> available. I definitely think OSGi sounds up to the task for what you
> >> want to do.
> >>
> >> -> richard
> >>
> >> Trustin Lee wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm designing a distributed application platform which provides provisioning
> >>> and management.
> >>>
> >>> When each node starts up, it contacts to the configuration and component
> >>> (bundle) repository and pulls its required components on the fly. If the
> >>> node's profile changes, the repository notifies the change to it and it will
> >>> automatically update existing bundles, deploy new bundles, and undeploy
> >>> unused bundles. Of course, all configurations and states of the deployed
> >>> components are supposed to be monitored and reconfigured by a GUI console
> >>> which runs in an Administrator's desktop PC.
> >>>
> >>> I think I can do this with OSGi, but I have no idea if it is standardized,
> >>> or the standardization is in progress. Anyone who can provision me? :)
> >>>
> >>> Thanks in advance,
> >>> Trustin
> >>> --
> >>> what we call human nature is actually human habit
> >>> --
> >>> http://gleamynode.net/
> >>> PGP Key ID: 0x854B996C
> >>>
> >>>
> >>>
> >
> >
> >
>
Re: Using OSGi as a provisioning and management platform for distributed
components.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I guess I was thinking that changes to a node would be more
fine-grained, i.e., only some components would be added/updated/removed,
and more uncoordinated. However, if the whole configuration just needs
to be wiped out and reset by a central authority, then I agree it is
probably possible to do so using the Initial Provisioning Service.
-> richard
John E. Conlon wrote:
> IMHO I think the Initial Provisioning Service would provide the standard
> infrastructure to do this.
>
>
>>> When each node starts up, it contacts to the configuration and component
>>> (bundle) repository and pulls its required components on the fly.
>>>
>
> Alternately if one were to use the Provisioning Service...when each
> node boots up it starts the Provisioning Service which then retrieves
> the Provisioning Zip pointed to by a preconfigured URL. This Zip
> contains configuration information, bundles, or references to additional
> Provisioning Zips. It also specifies which bundle to start.
> This start up bundle is considered a management agent. A management
> agent could be anything a provider would like. When the management agent
> starts up it looks for the Provisioning Service. The Provisioning
> Service Interface than provides all the hooks to control and restart the
> process. It's a chicken and egg kind of thing. Provisioning starts the
> management agent and then exposes itself to its management agent child.
> In this case it could install bundles from repositories or bring in
> other management agents. It could be autonomous or be under the control
> of the local or remote operator. (Or a combination.) Control can also be
> passed off from one operator to the next.
>
>> If the
>>
>>> node's profile changes, the repository notifies the change to it and it will
>>> automatically update existing bundles, deploy new bundles, and undeploy
>>> unused bundles. Of course, all configurations and states of the deployed
>>> components are supposed to be monitored and reconfigured by a GUI console
>>> which runs in an Administrator's desktop PC.
>>>
> Again I think this can be done in a standard way. As a matter of fact I
> am attempting this with the Provisioning Service and JMX.
>
> Trustin is this for the ApacheDS or the MINA project?
>
> cheers,
> John
>
>
> On Fri, 2006-01-20 at 07:21, Richard S. Hall wrote:
>
>> Trustin,
>>
>> There is no standard way to do what you ask. Some pieces may help you,
>> such as the OBR bundle repository and others. Other people have created
>> management consoles too, although I am not sure what is freely
>> available. I definitely think OSGi sounds up to the task for what you
>> want to do.
>>
>> -> richard
>>
>> Trustin Lee wrote:
>>
>>> Hi all,
>>>
>>> I'm designing a distributed application platform which provides provisioning
>>> and management.
>>>
>>> When each node starts up, it contacts to the configuration and component
>>> (bundle) repository and pulls its required components on the fly. If the
>>> node's profile changes, the repository notifies the change to it and it will
>>> automatically update existing bundles, deploy new bundles, and undeploy
>>> unused bundles. Of course, all configurations and states of the deployed
>>> components are supposed to be monitored and reconfigured by a GUI console
>>> which runs in an Administrator's desktop PC.
>>>
>>> I think I can do this with OSGi, but I have no idea if it is standardized,
>>> or the standardization is in progress. Anyone who can provision me? :)
>>>
>>> Thanks in advance,
>>> Trustin
>>> --
>>> what we call human nature is actually human habit
>>> --
>>> http://gleamynode.net/
>>> PGP Key ID: 0x854B996C
>>>
>>>
>>>
>
>
>