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 [email protected] >> [mailto:[email protected]] >> 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:[email protected]] >> >> 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) >> >> <[email protected]> wrote: >> >> >> >> > Hi, >> >> > again inline. >> >> > >> >> > Cheers, >> >> > Uli >> >> > >> >> >> -----Original Message----- >> >> >> From: ext Anton Pak [mailto:[email protected]] >> >> >> 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) >> >> >> <[email protected]> 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:[email protected]] >> >> >> >> 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) >> >> >> >> <[email protected]> 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 [email protected] >> >> >> >> >> [mailto:[email protected]] >> >> >> >> >> Sent: Tuesday, September 14, 2010 8:43 AM >> >> >> >> >> To: [email protected] >> >> >> >> >> 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:[email protected]] >> >> >> >> >> >> Sent: Monday, September 13, 2010 4:52 PM >> >> >> >> >> >> To: [email protected] >> >> >> >> >> >> 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) >> >> >> >> >> >> <[email protected]> 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 [email protected] >> >> >> >> >> >> >> [mailto:[email protected]] >> >> >> >> >> >> >> Sent: Sunday, September 12, 2010 1:05 AM >> >> >> >> >> >> >> To: [email protected] >> >> >> >> >> >> >> 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 >> >> >> >> >> >> >> [email protected] >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> >> > [email protected] >> >> >> >> >> >> > >> >> 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 >> >> >> >> >> >> [email protected] >> >> >> >> >> >> >> 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 >> >> >> >> >> > [email protected] >> >> >> >> >> > >> 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 >> >> >> >> >> [email protected] >> >> >> >> >> 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 >> >> >> >> > [email protected] >> >> >> >> > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
