Menu
▾
▴
Re: [Openhpi-devel] Dynamic domains configuration: first step
|
From: <ant...@pi...> - 2010-09-15 08:57:01
|
Hello!
Uli and me have been having discussion while my email with pictures
awaited moderator approval.
See below.
Moving right along:
I cannot get the importance of domain id.
It is merely a number user passes to saHpiSessionOpen.
If the oHpiDomainAdd assigns it, why HPI User should care?
What are the use cases of user selected domain id?
Anton Pak
> Hi,
> ok. Sorry, forgot.
>
> I looked into the patch now. One more idea. It might be good when a user
> can select the did. So I suggest that oHpiDomainAdd would assign the did
> (as you implemented) only in case of SAHPI_UNSPECIFIED_DOMAIN_ID being
> input. If the user inputs a reasonalble (>0) value, oh_add_domain_conf
> would check whether that domain-id is already used. If the did value is
> free, it shall be used, otherwise rejected. What do you think?
>
>
> ohcontrol calling oHpiDomainAdd could help to test oHpiDomainAdd.
> Other use-cases would always be complex scenarios that can better be
> done
> via hpi_shell.
> I think we should add some commands to hpi_shell for oHpiDomainAdd
> and also for ohcontrol stuff.
>
> Cheers,
> Uli
>
>
>
>> -----Original Message-----
>> From: ext ant...@pi...
>> [mailto:ant...@pi...]
>> Sent: Wednesday, September 15, 2010 8:42 AM
>> To: Kleber, Ulrich (NSN - DE/Munich)
>> Subject: RE: [Openhpi-devel] Dynamic domains configuration: first step
>>
>> Actually I have implemented oHpiDomainConfAdd. See the patch
>> attached to
>> SF feature request.
>>
>> As for ohcontrol:
>> We may add option for oHpiDomainAdd. However it is not persistent
>> and will be present only for ohcontrol process.
>> Only current ohcontrol will be able to work with created domain.
>> Do you think it can be useful?
>>
>> Anton Pak
>>
>> > Hi,
>> > I agree.
>> >
>> > Baselib can be identical, when libslave calls oHpiDomainAdd to tell
>> > baselib
>> > the host:port of a domain. That was my missing point (no
>> new idea during
>> > my sleep ;-)
>> >
>> > So let's fill-in the others.
>> >
>> > Should I work on the oHpiDomainAdd function? It fits to my ohcontrol
>> > client and drt
>> > work.
>> >
>> > Cheers,
>> > Uli
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: ext Anton Pak [mailto:ant...@pi...]
>> >> Sent: Tuesday, September 14, 2010 5:42 PM
>> >> To: Kleber, Ulrich (NSN - DE/Munich)
>> >> Subject: Re: [Openhpi-devel] Dynamic domains
>> configuration: first step
>> >>
>> >> Ok,
>> >>
>> >> So we agreed that:
>> >>
>> >> - slave1.png is not an option.
>> >>
>> >> - slave3.png (I like it most) or slave2.png or something else
>> >> are options
>> >>
>> >> - Slave OpenHPI daemon resources has its entity paths and
>> >> slave plug-in on
>> >> the Master
>> >> OpenHPI daemon extend those entity paths.
>> >>
>> >> - grand children idea is very insteresting but need more
>> elaboration
>> >>
>> >> Right?
>> >>
>> >> My agruments for slave3 approach:
>> >>
>> >> - single configuration file
>> >> - better match for dynamic configuration
>> >> - dynamic domain id is visible only for the libslave handler
>> >> that called
>> >> oHpiDomainAdd
>> >>
>> >> So slave3 approach allows work without openhpiclient.conf.
>> >> libslave just loads libopenhpi.so, calls oHpiDomainAdd from loaded
>> >> libopenhpi.so and
>> >> calls saHpiSessionOpen with obtained dynamic domain id.
>> >>
>> >> The oHpiDomainAdd API does not change anything in existing
>> >> API and does
>> >> not affect it.
>> >> HPI Application may use base library with oHpiDomainAdd
>> >> feature and does
>> >> not call it at all.
>> >> HPI Application may use base library with oHpiDomainAdd feature and
>> >> openhpiclient.conf.
>> >> Base lib on the HPI Application system and Base lib on Master
>> >> OpenHPI
>> >> daemon system
>> >> and Base lib on Slave OpenHPI daemon system are identical.
>> >>
>> >>
>> >> Anton Pak
>> >>
>> >>
>> >> On Tue, 14 Sep 2010 18:16:03 +0400, Kleber, Ulrich (NSN -
>> DE/Munich)
>> >> <ulr...@ns...> wrote:
>> >>
>> >> > Hi,
>> >> > again inline.
>> >> >
>> >> > Cheers,
>> >> > Uli
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: ext Anton Pak [mailto:ant...@pi...]
>> >> >> Sent: Tuesday, September 14, 2010 2:36 PM
>> >> >> To: Kleber, Ulrich (NSN - DE/Munich)
>> >> >> Subject: Re: [Openhpi-devel] Dynamic domains
>> >> configuration: first step
>> >> >>
>> >> >> Uli,
>> >> >>
>> >> >> See comments inline.
>> >> >>
>> >> >> Anton Pak
>> >> >>
>> >> >> On Tue, 14 Sep 2010 16:18:59 +0400, Kleber, Ulrich (NSN -
>> >> DE/Munich)
>> >> >> <ulr...@ns...> wrote:
>> >> >>
>> >> >> > Hi,
>> >> >> > now I know what you mean with "slave". Sorry.
>> >> >> >
>> >> >> > I fully agree that there shouldn't be a
>> >> openhpiclient.conf for the
>> >> >> > daemon.
>> >> >> > It is just redundant information and confuses everybody.
>> >> >> > So your picture slave3 is nearest to what I think.
>> >> >>
>> >> >>
>> >> >> me too!
>> >> >>
>> >> >> Slave2 variant with domain_ids in libslave stanza also
>> looks good.
>> >> >> But not so dynamic.
>> >> > Ok, now I see the difference. But this has a few drawbacks.
>> >> > You need to export OPENHPICLIENT_CONF where you start the daemon,
>> >> > so it will find the correct file.
>> >> > If you change the file it must be consistent.
>> >> > Dynamic adding of domains gets a mess.
>> >> > So I prefer slave3.
>> >> >
>> >> > (but after going through the whole email I am not so
>> sure anymore.
>> >> > see later)
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > I was thinking a bit about the entity_root parameter.
>> >> >> > I assume you put it there, so a slave doesn't need to be
>> >> >> changed, when
>> >> >> > the
>> >> >> > parent wishes a different entity-root. But still the slave
>> >> >> needs that
>> >> >> > parameter
>> >> >> > for every handler. Will the master just add the entity_root
>> >> >> string to
>> >> >> > the
>> >> >> > entity path it gets from the slave? Maybe the entity_root
>> >> >> of the master
>> >> >> > can
>> >> >> > also be empty ("").
>> >> >>
>> >> >>
>> >> >> Not sure what you meant by "slave":
>> >> >> o) libslave plug-in on Master OpenHPI daemon
>> >> >> o) Slave OpenHPI daemon.
>> >> > I meant the slave daemon.
>> >> >
>> >> >>
>> >> >> Yes, libslave just adds entity root to all entity paths it
>> >> >> gets from Slave
>> >> >> OpenHPI
>> >> >> daemon.
>> >> >> I don't think this information shall be passed down to
>> >> Slave OpenHPI
>> >> >> daemon.
>> >> > agree.
>> >> >
>> >> >> Slave OpenHPI daemon is unaware it runs on AMC Module 2 on
>> >> >> Physical Slot
>> >> >> 10.
>> >> > agree.
>> >> > But still it will provide entity paths which start at some root.
>> >> >
>> >> >>
>> >> >> Not sure why you think slave will need entity_root for
>> >> every handler.
>> >> > Currently it has.
>> >> > The slave may use any plugin, including those using an
>> entity_root.
>> >> >
>> >> >>
>> >> >> I bear in mind that someday ATCA Shelf Manager will be able
>> >> >> to provide
>> >> >> Master OpenHPI daemon
>> >> >> with host/port/entity_root for every Board/AMC and we will
>> >> have 100%
>> >> >> dynamic solution.
>> >> > From architecture that looks nice. But ShM will always
>> be a slower
>> >> > processor
>> >> > than the blades. So people will tend to have a master
>> >> daemon on a CPU
>> >> > blade with libipmidirect or with libslave for slave-daemon
>> >> on ShM plus
>> >> > slaves on
>> >> > blades and AMCs.
>> >> > So the architecture should be very flexible.
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> > Maybe the libslave needs an id or name parameter for the
>> >> instances -
>> >> >> > similar
>> >> >> > to the domain id in the openhpiclient.conf.
>> >> >>
>> >> >>
>> >> >> Currently there is no id for different handler instances in
>> >> >> openhpi.conf.
>> >> >> Do you think we need it?
>> >> >> Could you draw use cases for the ids?
>> >> > I just thought to use them internally for open-session, so
>> >> the baselib
>> >> > can be identical
>> >> > (now you will say, we should do slave2).
>> >> >
>> >> >>
>> >> >>
>> >> >> > I expect the baselib#2 and baselib#1 should be very
>> similar. So
>> >> >> > baselib#2 will
>> >> >> > call opensession with something like domainid.
>> >> >>
>> >> >>
>> >> >> Actually it is be the same library but on the another system.
>> >> >> Like libc.so
>> >> >> for example.
>> >> > agree that should be so. But open-session currently needs
>> >> domain-id and
>> >> > the daemon location from openhpiclient.conf. So back to
>> slave2 idea.
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Maybe you should show the openhpi.conf of the slave
>> >> daemons in the
>> >> >> > picture.
>> >> >>
>> >> >>
>> >> >> I thought about it and decided against it.
>> >> >> It would add more complexity to the pictures.
>> >> >> It would not add any useful information about master-slave
>> >> >> relationship.
>> >> >> What say?
>> >> > It doesn't provide more info about architecture of
>> >> master-daemon, but a
>> >> > reader will
>> >> > understand easier.
>> >> > Btw. There even could be a configuration where a
>> slave-daemon has a
>> >> > libslave handler
>> >> > to some grand-children. (big systems with many shelves
>> >> could be easier
>> >> > to maintain)
>> >> >
>> >> > I need to think about dynamically adding handlers and daemons. My
>> >> > ohcontrol could
>> >> > easily add libslave with slave3 configuration. But with slave2
>> >> > configuration (which
>> >> > doesn't need changes on baselib), we would need
>> something special,
>> >> > probably a bit
>> >> > different to your new oHpiDomainAdd API.
>> >> > With grandchildren the dynamic stuff gets worse. I need to
>> >> sleep that
>> >> > over, but
>> >> > perhaps we need to identify everything by entity-paths.
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> > Probably you can send the pictures via the reflector when
>> >> >> you zip or pdf
>> >> >> > it.
>> >> >>
>> >> >>
>> >> >> Well, I think Bryan will wake up and will approve my mail. :)
>> >> > Yeah.
>> >> >
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Great concept! I hope I can support you a bit implementing it.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Uli
>> >> >> >
>> >> >> >> -----Original Message-----
>> >> >> >> From: ext Anton Pak [mailto:ant...@pi...]
>> >> >> >> Sent: Tuesday, September 14, 2010 12:39 PM
>> >> >> >> To: Kleber, Ulrich (NSN - DE/Munich)
>> >> >> >> Subject: Re: [Openhpi-devel] Dynamic domains
>> >> >> configuration: first step
>> >> >> >>
>> >> >> >> Uli,
>> >> >> >>
>> >> >> >> I tried to send it via openhpi-devel and it stuck.
>> >> >> >> Seems it requires moderator approval for delivery.
>> >> >> >>
>> >> >> >> I tried to show possible setups on the attached pictures.
>> >> >> >> The variant I prefer is one where openhpiclient.conf is
>> >> not needed.
>> >> >> >>
>> >> >> >> Anton Pak
>> >> >> >>
>> >> >> >> On Tue, 14 Sep 2010 13:17:57 +0400, Kleber, Ulrich (NSN -
>> >> >> DE/Munich)
>> >> >> >> <ulr...@ns...> wrote:
>> >> >> >>
>> >> >> >> > Hi,
>> >> >> >> > OK.
>> >> >> >> > Just to re-align. A slave domain is a domain having the
>> >> >> >> same handlers as
>> >> >> >> > its master domain, but won't do any changes. So in case of
>> >> >> >> ipmidirect
>> >> >> >> > plugin,
>> >> >> >> > it would connect to the same host:port as the master
>> >> >> (specified in
>> >> >> >> > openhpi.conf, host being the address of teh ShM and port
>> >> >> >> the RMCP port).
>> >> >> >> > How does the slave domain know it's a slave? Do we need a
>> >> >> >> mechanism to
>> >> >> >> > make the slave active, when the master's daemon dies?
>> >> >> >> >
>> >> >> >> > The library needs the host address of the daemon serving
>> >> >> >> the domain as
>> >> >> >> > specified typically in the openhpiclient.conf.
>> >> >> >> > So I got a bit confused between your two "host:port" below.
>> >> >> >> >
>> >> >> >> > I would appreciate very much a oHpiDomainConfAdd or
>> >> >> >> oHpiDomainAdd API.
>> >> >> >> > I think it should have 3 parameters:
>> >> >> >> > - domain-id IN/OUT (OpenHPI should be able to assign a
>> >> >> >> domain id or use
>> >> >> >> > the id as specified)
>> >> >> >> > - host IN
>> >> >> >> > - port IN
>> >> >> >> >
>> >> >> >> > So according to my previous mail, I would also add
>> >> >> >> interface to free the
>> >> >> >> > domain-id and
>> >> >> >> > Maybe the disconnect is done already by saHpiSessionClose.
>> >> >> >> > And maybe the restart would be possible already by calling
>> >> >> >> > saHpiSessionClose
>> >> >> >> > and saHpiSessionOpen.
>> >> >> >> > Cheers,
>> >> >> >> > Uli
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> -----Original Message-----
>> >> >> >> >> From: ext ant...@pi...
>> >> >> >> >> [mailto:ant...@pi...]
>> >> >> >> >> Sent: Tuesday, September 14, 2010 8:43 AM
>> >> >> >> >> To: ope...@li...
>> >> >> >> >> Subject: Re: [Openhpi-devel] Dynamic domains
>> >> >> >> configuration: first step
>> >> >> >> >>
>> >> >> >> >> My idea now is about base lib dynamically connecting to an
>> >> >> >> additional
>> >> >> >> >> (new) domain.
>> >> >> >> >>
>> >> >> >> >> (actually I need it for slave domain).
>> >> >> >> >>
>> >> >> >> >> The problem is - I know slave host:port from plug-in
>> >> >> >> configuration in
>> >> >> >> >> openhpi.conf.
>> >> >> >> >> Then I load baselib to connect this host:port and
>> need to set
>> >> >> >> >> OPENHPI_DAEMON_HOST / OPENHPI_DAEMON_PORT or add
>> a record in
>> >> >> >> >> openhpiclient.conf. To avoid this I suggest
>> >> >> oHpiDomainConfAgg API
>> >> >> >> >> in baselib.
>> >> >> >> >>
>> >> >> >> >> Anton Pak
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> > Hi,
>> >> >> >> >> > I agree with both.
>> >> >> >> >> >
>> >> >> >> >> > But maybe I misunderstood the idea a bit.
>> >> >> >> >> > Were you talking about the baselib dynamically
>> >> >> connecting to an
>> >> >> >> >> > additional (new) domain? That is I start a new
>> >> daemon on a new
>> >> >> >> >> > machine and the client can connect to it with the
>> >> >> same loaded and
>> >> >> >> >> > initialized baselib?
>> >> >> >> >> > Or were you thinking of the new child-domain concept,
>> >> >> since you
>> >> >> >> >> > said openhpi.conf is affected?
>> >> >> >> >> >
>> >> >> >> >> > Both are very reasonable ideas, and in both cases we
>> >> >> maybe should
>> >> >> >> >> > think about persistency a bit.
>> >> >> >> >> > The configuration as in openhpi.conf and
>> >> openhpiclient.conf is
>> >> >> >> >> > persistent, but dynamic changes now are not.
>> >> >> >> >> > So in case of a daemon restart, all
>> >> plugin-instances loaded by
>> >> >> >> >> > oHpiHandlerCreate are gone and those unloaded by
>> >> >> >> oHpiHandlerDestroy
>> >> >> >> >> > are loaded again.
>> >> >> >> >> > If these plugins represent child-domains with your new
>> >> >> >> concept, this
>> >> >> >> >> > is also valid.
>> >> >> >> >> >
>> >> >> >> >> > The same would apply for clients when the baselib
>> >> >> >> connects to other
>> >> >> >> >> > domains than in openhpiclient.conf. When the
>> client process
>> >> >> >> >> restarts,
>> >> >> >> >> > the baselib initializes and the configuration of
>> >> >> >> openhpiclient.conf
>> >> >> >> >> > is effecive again.
>> >> >> >> >> >
>> >> >> >> >> > Re-connect for the baselib to repair communication to a
>> >> >> >> >> daemon we can
>> >> >> >> >> > discuss in a separate thread.
>> >> >> >> >> >
>> >> >> >> >> > Cheers,
>> >> >> >> >> > Uli
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> -----Original Message-----
>> >> >> >> >> >> From: ext Anton Pak [mailto:ant...@pi...]
>> >> >> >> >> >> Sent: Monday, September 13, 2010 4:52 PM
>> >> >> >> >> >> To: ope...@li...
>> >> >> >> >> >> Subject: Re: [Openhpi-devel] Dynamic domains
>> >> >> >> >> configuration: first step
>> >> >> >> >> >>
>> >> >> >> >> >> Uli,
>> >> >> >> >> >>
>> >> >> >> >> >> Welcome back!
>> >> >> >> >> >>
>> >> >> >> >> >> My comments are inline.
>> >> >> >> >> >>
>> >> >> >> >> >> Anton Pak
>> >> >> >> >> >>
>> >> >> >> >> >> On Mon, 13 Sep 2010 18:46:22 +0400, Kleber,
>> Ulrich (NSN -
>> >> >> >> >> DE/Munich)
>> >> >> >> >> >> <ulr...@ns...> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> > Hi,
>> >> >> >> >> >> > this is a great idea.
>> >> >> >> >> >> >
>> >> >> >> >> >> > I think we should add also a function to delete a
>> >> >> >> >> domain, since HA
>> >> >> >> >> >> > systems
>> >> >> >> >> >> > should live rather long, so a set of domain
>> changes may
>> >> >> >> >> >> happen over time
>> >> >> >> >> >> > and
>> >> >> >> >> >> > a clean-up could be helpful.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> In this case I suggest to protect domain configuration
>> >> >> >> entries from
>> >> >> >> >> >> openhpiclient.conf.
>> >> >> >> >> >> Or at least default domain entry.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> > I don't think we need the modify. A sequence
>> of delete
>> >> >> >> >> >> (remove?) and add
>> >> >> >> >> >> > domain,
>> >> >> >> >> >> > would do.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Ok for me.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> > But I remember a Bug some time ago:
>> >> 3019712:Daemon becomes
>> >> >> >> >> >> > non-responsiveupon comms loss.
>> >> >> >> >> >> > Perhaps we should add some
>> >> restart-communication API, so we
>> >> >> >> >> >> can repair
>> >> >> >> >> >> > the library when
>> >> >> >> >> >> > a daemon interface becomes broken without affecting
>> >> >> >> >> other domains.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Well, we may implement this. Need additional
>> >> >> >> investigation on this.
>> >> >> >> >> >> Suggest to do it as a separate feature.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> > Cheers,
>> >> >> >> >> >> > Uli
>> >> >> >> >> >> >
>> >> >> >> >> >> >> -----Original Message-----
>> >> >> >> >> >> >> From: ext ant...@pi...
>> >> >> >> >> >> >> [mailto:ant...@pi...]
>> >> >> >> >> >> >> Sent: Sunday, September 12, 2010 1:05 AM
>> >> >> >> >> >> >> To: ope...@li...
>> >> >> >> >> >> >> Subject: [Openhpi-devel] Dynamic domains
>> configuration:
>> >> >> >> >> first step
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Hello!
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Currently domain configuration is done with
>> >> >> >> >> >> openhpiclient.conf in the
>> >> >> >> >> >> >> following way:
>> >> >> >> >> >> >> ---------------------------
>> >> >> >> >> >> >> domain <id>
>> >> >> >> >> >> >> {
>> >> >> >> >> >> >> host = "<host>"
>> >> >> >> >> >> >> port = <port>
>> >> >> >> >> >> >> }
>> >> >> >> >> >> >> ---------------------------
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> It is proposed to introduce new function
>> >> oHpiDomainConfAdd
>> >> >> >> >> >> >> for adding domain configuration dynamically.
>> >> >> >> >> >> >> Proposed function signature is:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> SaErrorT oHpiDomainConfAdd(
>> >> >> >> >> >> >> const SaHpiTextBufferT *host,
>> >> >> >> >> >> >> SaHpiUint16T port,
>> >> >> >> >> >> >> SaHpiDomainIdT *domain_id
>> >> >> >> >> >> >> );
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> The function will be supported only on base
>> lib level.
>> >> >> >> >> >> >> OpenHPI daemon code will contain a stub returning
>> >> >> >> >> UNSUPPORTED_API.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Not sure if we need more functions: to delete or
>> >> >> >> modify domain
>> >> >> >> >> >> >> configurations.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Just created feature request #3064532 for it.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Comments welcome.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Anton Pak
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >>
>> --------------------------------------------------------------
>> >> >> >> >> >> >> ----------------
>> >> >> >> >> >> >> Start uncovering the many advantages of
>> >> virtual appliances
>> >> >> >> >> >> >> and start using them to simplify application
>> >> >> deployment and
>> >> >> >> >> >> >> accelerate your shift to cloud computing
>> >> >> >> >> >> >> http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> >> >> >> _______________________________________________
>> >> >> >> >> >> >> Openhpi-devel mailing list
>> >> >> >> >> >> >> Ope...@li...
>> >> >> >> >> >> >>
>> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> --------------------------------------------------------------
>> >> >> >> >> >> ----------------
>> >> >> >> >> >> > Start uncovering the many advantages of virtual
>> >> appliances
>> >> >> >> >> >> > and start using them to simplify application
>> >> deployment and
>> >> >> >> >> >> > accelerate your shift to cloud computing
>> >> >> >> >> >> > http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> >> >> > _______________________________________________
>> >> >> >> >> >> > Openhpi-devel mailing list
>> >> >> >> >> >> > Ope...@li...
>> >> >> >> >> >> >
>> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> --------------------------------------------------------------
>> >> >> >> >> >> ----------------
>> >> >> >> >> >> Start uncovering the many advantages of
>> virtual appliances
>> >> >> >> >> >> and start using them to simplify application
>> >> deployment and
>> >> >> >> >> >> accelerate your shift to cloud computing
>> >> >> >> >> >> http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> >> >> _______________________________________________
>> >> >> >> >> >> Openhpi-devel mailing list
>> >> >> >> >> >> Ope...@li...
>> >> >> >> >> >>
>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> --------------------------------------------------------------
>> >> >> >> >> ----------------
>> >> >> >> >> > Start uncovering the many advantages of virtual
>> appliances
>> >> >> >> >> > and start using them to simplify application
>> deployment and
>> >> >> >> >> > accelerate your shift to cloud computing.
>> >> >> >> >> > http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> >> > _______________________________________________
>> >> >> >> >> > Openhpi-devel mailing list
>> >> >> >> >> > Ope...@li...
>> >> >> >> >> >
>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> --------------------------------------------------------------
>> >> >> >> >> ----------------
>> >> >> >> >> Start uncovering the many advantages of virtual appliances
>> >> >> >> >> and start using them to simplify application
>> deployment and
>> >> >> >> >> accelerate your shift to cloud computing.
>> >> >> >> >> http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> >> _______________________________________________
>> >> >> >> >> Openhpi-devel mailing list
>> >> >> >> >> Ope...@li...
>> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> --------------------------------------------------------------
>> >> >> >> ----------------
>> >> >> >> > Start uncovering the many advantages of virtual appliances
>> >> >> >> > and start using them to simplify application deployment and
>> >> >> >> > accelerate your shift to cloud computing.
>> >> >> >> > http://p.sf.net/sfu/novell-sfdev2dev
>> >> >> >> > _______________________________________________
>> >> >> >> > Openhpi-devel mailing list
>> >> >> >> > Ope...@li...
>> >> >> >> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>>
>>
>>
>
|