Question about bundle plans

[Simon Fayer]

Hi,

I was thinking about the plan to build a full externals/lcg bundle from
scratch as discussed at the meeting yesterday... Traditionally the inner
payload of the job (i.e. the actual user code) is executed in the same
environment as DIRAC, is that still going to be the case and, if so, won't
it cause problems due to having different GLIBC/stdc++/compiler
version/etc. to what the user compiled with? Some programs can work with
different versions of things, but common things (like ROOT) are far more
sensitive to changes like that.

A bonus question: Do you have SRPMs for all of the required grid packages
available? I've tried looking for these before (mainly to assist in
debugging things), but struggled to find them in recent years.

Regards,
Simon

[Christophe HAEN]

Hi Simon,

First of all, thanks for the feedback :-)

Yes, you have a very good point, but as far as I have understood, the environments are separated. Federico might confirm. 

As for the srpm, I have not done all the packages yet, but so far so good. Which one are you missing ?

Cheers

Chris

[Simon Fayer]

Hi Chris,

On Mon, Feb 26, 2018 at 12:44:31AM -0800, Christophe HAEN wrote:
> As for the srpm, I have not done all the packages yet, but so far so good.
> Which one are you missing ?

Mainly things that are only in UMD4 rather than EPEL (or Fedora): The
latest EL7 CREAM CLI interface is an obvious one, aka
glite-ce-cream-cli-1.15.4-1.el7.centos.src.rpm.

Regards,
Simon

[Christophe HAEN]

yeah... that one... 

I also struggled to find them, and I Could only find this "preview repo" https://wiki.egi.eu/wiki/Preview_Repository

So far, I am building the same versions as the current LcgBundle. 

And btw, I am building on SLC6, but:

* since we are shipping everything, it should run fine on centOs7

* the build procedure is normally agnostic to the host os (see fedora's mock tool). so it could be done there if needed.

I'd be happy to have you as an early tester once ready :-)

Cheers

Chris

--
You received this message because you are subscribed to a topic in the Google Groups "diracgrid-develop" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diracgrid-develop/CwvpkYqdXi8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diracgrid-develop+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christophe HAEN

[Simon Fayer]

On Mon, Feb 26, 2018 at 02:39:53PM +0100, Christophe HAEN wrote:
> I'd be happy to have you as an early tester once ready :-)

Sure, just drop Daniela & me an e-mail off-list when it's ready and we'd be
happy to give it a test.

Regards,
Simon

[Federico Stagni]

Hi,

only replying on the "environment separation": it is responsibility of the payload to decide in which environment to run. If the "DIRAC/Workflow/Module/Script" is used (the default), env is "None" - so the subprocess systemcall simply inherits the environment of the superprocess. So, by default there is NO separation. 

Cheers,

Federico

PS:

@Chris: In LHCb there's a environment separation for LHCb applications (that use lb-run) but NOT for "simple" user scripts.

--

You received this message because you are subscribed to the Google Groups "diracgrid-develop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diracgrid-develop+unsubscribe@googlegroups.com.

[Christophe HAEN]

Ah.... Now that's uncool :-)

This environment separation would then become a "desirable feature" to say the least ! 

Thanks @Simon !! 

--
You received this message because you are subscribed to a topic in the Google Groups "diracgrid-develop" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diracgrid-develop/CwvpkYqdXi8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diracgrid-develop+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Christophe HAEN