It doesn't matter if the tools develop in lockstep or not, for backwards compatibility all that the application cares about is that the behaviour doesn't change. So if an application has been developed for and tested with OpenSAF 4.4, then it can set the environment variable OSAF_TOOL_VERSION to 4.4 and that will guarantee that the tools continue to work in the same way even after upgrading OpenSAF to a new version.
I am not sure if this is needed for long DNs, though. An application that only uses short DNs will continue to work anyhow even if the tools support long DNs. / Anders Widell On 08/26/2014 02:54 PM, Anders Björnerstedt wrote: > The problem is that the total set of tools do not evolve on the same generic > features > in lockstep with OpenSAF version. In the particualr exampe of longDns, since > not all > Services will support longDnsin 4.5, I guess not all tools can support > longDns in 4.5 > > Also I am not sure if backwards compatibility is relevant in the case of long > DNs. > In the end you have to decide per deployment/site if you are enabling long > DNs in IMM or not. > If you do enable long DNs and a tool supports long DNs then saying you dont > want to see > long DNs should not be an issue. The bottom line will be that for services > that services/tools > That dont support long DNs should and could never process or pass-on long DNs. > > If an application/deployment does not want long DNs then they should of > course not enable it > In the imm configuration and thus it wont matter what the tools can handle or > not. > > /AndersBj > > -----Original Message----- > From: Anders Widell > Sent: den 26 augusti 2014 14:43 > To: Anders Björnerstedt; Hans Feldt > Cc: Zoran Milinkovic; [email protected]; > [email protected] > Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of extended names > in immcfg [#980] > > I think it is part of the more general problem of backwards compatibility for > tools. Currently, we don't have any API version that controls command line > parameters, printouts, and behaviour. Maybe we could have something like this: > > export OSAF_TOOL_VERSION=4.4 > immcfg ... > immlist ... > > The above sequence gives you the behaviour of the tools as they were in > OpenSAF 4.4.x even if you run a later version of OpenSAF (like 4.5). If you > don't set the environment variable, you get the default (latest) tool > behaviour. > > / Anders Widell > > On 08/26/2014 02:11 PM, Anders Björnerstedt wrote: >> In that case it should be an option to NOT allow long DNs and default >> (no option set) should be that the tool allows long DNs (the version >> of the tool that has been adapted to handle long DNs. >> >> This since we are evolving in that direction. >> >> /AndersBj >> >> -----Original Message----- >> From: Anders Widell >> Sent: den 26 augusti 2014 14:08 >> To: Anders Björnerstedt; Hans Feldt >> Cc: Zoran Milinkovic; [email protected]; >> [email protected] >> Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of extended >> names in immcfg [#980] >> >> >> On 08/26/2014 02:00 PM, Anders Bjornerstedt wrote: >>> Hans Feldt wrote: >>>>> -----Original Message----- >>>>> From: Anders Widell [mailto:[email protected]] >>>>> Sent: den 26 augusti 2014 13:13 >>>>> To: Zoran Milinkovic; [email protected] >>>>> Cc: [email protected] >>>>> Subject: Re: [devel] [PATCH 1 of 1] immtools: fix the use of >>>>> extended names in immcfg [#980] >>>>> >>>>> Hi! >>>>> >>>>> Two comments: >>>>> >>>>> 1) I suppose this bug exists in all tools, so they other ones also >>>>> need to be fixed? >>>>> >>>>> 2) Maybe the tools should always support long DNs, so that you >>>>> don't have to set the environment variable in the shell? >>>> [Hans] why would you set env vars? The tool should instead have a >>>> new option >>> Sure add an option also. >>> But *if* you have set the environmentt variable and not set the >>> option then you should get the same result as if you had set the >>> option and not the environment-variable. >>> >>> I am assuming here you can not set the environment variable >>> explicitly to not allow long DNs. >>> If that where the case then the two could conflict. >> Hmm, I am still thinking, but here are my current thoughts. :-) The original >> intended meaning of the environment variable was to signal to the agent that >> the application has been adapted to support long DNs, by using >> saAisNameLend() and saAisNameBorrow() etc. We were even trying to find a way >> to avoid the need for the environment variable - i.e. to find a way for the >> agent to detect if the application has been compiled with the preprocessor >> macro defined or not. However, this turned out to be difficult and hence the >> environment variable was introduced. >> >> So clearly with this reasoning the tools should set the environment variable >> since they have been adapted. But - you could by "application" >> actually mean something bigger than the tool, like the shell script which is >> using the tool. Then you could potentially run into problems. >> Maybe option is the way to go, as Hans suggests. >> >> / Anders Widell >> >>> /AndersBj >>>>> regards, >>>>> / Anders Widell >>>>> >>>>> On 08/25/2014 03:44 PM, Zoran Milinkovic wrote: >>>>>> osaf/tools/safimm/immcfg/imm_cfg.c | 1 + >>>>>> 1 files changed, 1 insertions(+), 0 deletions(-) >>>>>> >>>>>> >>>>>> The patch enables using osaf_extended_name_* functions in the >>>>>> correct way before the first saImmOmInitialize() is called. >>>>>> >>>>>> diff --git a/osaf/tools/safimm/immcfg/imm_cfg.c >>>>>> b/osaf/tools/safimm/immcfg/imm_cfg.c >>>>>> --- a/osaf/tools/safimm/immcfg/imm_cfg.c >>>>>> +++ b/osaf/tools/safimm/immcfg/imm_cfg.c >>>>>> @@ -1539,5 +1539,6 @@ static int imm_operation(int argc, char >>>>>> } >>>>>> >>>>>> int main(int argc, char *argv[]) { >>>>>> + osaf_extended_name_init(); >>>>>> return imm_operation(argc, argv); >>>>>> } >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> - >>>>>> ----------- >>>>>> >>>>>> Slashdot TV. >>>>>> Video for Nerds. Stuff that matters. >>>>>> http://tv.slashdot.org/ >>>>>> _______________________________________________ >>>>>> Opensaf-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>> >>>>>> >>>>> ------------------------------------------------------------------- >>>>> - >>>>> ---------- >>>>> >>>>> Slashdot TV. >>>>> Video for Nerds. Stuff that matters. >>>>> http://tv.slashdot.org/ >>>>> _______________________________________________ >>>>> Opensaf-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>> -------------------------------------------------------------------- >>>> - >>>> --------- >>>> >>>> Slashdot TV. Video for Nerds. Stuff that matters. >>>> http://tv.slashdot.org/ >>>> _______________________________________________ >>>> Opensaf-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
