search

openenergysolutions / openfmb.adapters

OpenFMB Adapters
Apache License 2.0
3 stars 1 forks source link

Integrate RTI plugin into docker build #59

Closed jadamcrain closed 5 years ago

jadamcrain commented 5 years ago

Specifically, do this by creating a private repo to host the RTI headers/libraries/license. Copy the license into the docker image.

Investigate ARM32v6 RTI library?

@larrylackey: Larry will ask RTI if the trial library is any different from the customer library. The trial library REQUIRES a run-time license. Also ask about ARM32v6 binaries.

emgre commented 5 years ago

I would advise for another method than git for this. The library is quite big (the compiled libraries are ~600 MB for each platform), and git is having trouble handling that much data. Also, if we put newer versions, it will make the download even bigger because we get the whole history, not just the one we are interested in (it can be mitigated with shallow clones, but still)

Why not a private AWS S3 bucket where we put each version as a zip?

EDIT: There's actually a lib file that is too large for GitHub (the file size limit is 100 MB)

larrylackey commented 5 years ago

Certainly an issue, which I suppose relates to rti-dds-libs repo. A question seems to be how to keep the libs private without having a password in a make file. Ideas?

And so far RTI has not responded about runtime licenses.

On Monday, August 12, 2019, 7:32:36 AM MDT, Émile Grégoire <notifications@github.com> wrote:

I would advise for another method than git for this. The library is quite big (the compiled libraries are ~600 MB for each platform), and git is having trouble handling that much data. Also, if we put newer versions, it will make the download even bigger because we get the whole history, not just the one we are interested in (it can be mitigated with shallow clones, but still)

Why not a private AWS S3 bucket where we put each version as a zip?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

jadamcrain commented 5 years ago

Ideally, it would work just like git, i.e. the credential is an SSH private key. We could SCP them from somewhere... that would allow us to re-use credentials.

On Mon, Aug 12, 2019 at 8:06 AM Larry Lackey notifications@github.com wrote:

Certainly an issue, which I suppose relates to rti-dds-libs repo. A question seems to be how to keep the libs private without having a password in a make file. Ideas?

And so far RTI has not responded about runtime licenses.

On Monday, August 12, 2019, 7:32:36 AM MDT, Émile Grégoire < notifications@github.com> wrote:

I would advise for another method than git for this. The library is quite big (the compiled libraries are ~600 MB for each platform), and git is having trouble handling that much data. Also, if we put newer versions, it will make the download even bigger because we get the whole history, not just the one we are interested in (it can be mitigated with shallow clones, but still)

Why not a private AWS S3 bucket where we put each version as a zip?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openenergysolutions/openfmb.adapters/issues/59?email_source=notifications&email_token=AACKVFKJS3XJY3OBVUUIRB3QEF4BFA5CNFSM4IKWF66KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4C2Q5Q#issuecomment-520464502, or mute the thread https://github.com/notifications/unsubscribe-auth/AACKVFPFPLB5IA4NIZAWSXDQEF4BFANCNFSM4IKWF66A .

emgre commented 5 years ago

We do have a more important problem though. The RTI DDS libraries were built with glibc, which is the default in most Linux distributions. However, in the Docker, we use Alpine because it's much smaller. Alpine doesn't have glibc, it uses musl. Therefore, when I build it in Docker, I get a linker error. I tried using compatibility librairies, but I didn't have any luck so far.

An easy workaround would be to use a Ubuntu base image instead of Alpine, but it will make the final image bigger.

cc @larrylackey @dwaynebradley

dwaynebradley commented 5 years ago

Quick question...

Are we building the adapter as a statically-linked application? I think the answer is "yes" to this question but I'm just making sure. Plus, I'm not 100% positive if RTI's DDS library even allows it or provides that capability.

If we are creating a statically-linked app, we can get around the requirement of glibc. Plus, we could completely eliminate the base image requirement (either Ubuntu or Alpine) from the final image shrinking our container even further.

Just let me know...

larrylackey commented 5 years ago

That would be a reasonable possibility with RTI DDS as the only pub-sub protocol in a special build.

On Tuesday, August 13, 2019, 9:32:30 AM MDT, Émile Grégoire <notifications@github.com> wrote:

We do have a more important problem though. The RTI DDS libraries were built with glibc, which is the default in most Linux distributions. However, in the Docker, we use Alpine because it's much smaller. Alpine doesn't have glibc, it uses musl. Therefore, when I build it in Docker, I get a linker error. I tried using compatibility librairies, but I didn't have any luck so far.

An easy workaround would be to use a Ubuntu base image instead of Alpine, but it will make the final image bigger.

cc @larrylackey @dwaynebradley

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

emgre commented 5 years ago

@dwaynebradley It is not completely statically-linked (most notably, we require libstdc++, libpcap and libpq to be installed on the system), but static linking won't solve the issue. RTI DDS is precompiled with a dependency on glibc that the image can't fulfill. The only solutions are to have glibc (from another image) or to compile RTI DDS from source with musl (and hope for the best).

larrylackey commented 5 years ago

On a related subject I still have not heard back from RTI about either licenses or ARM 32 bit. Does the DDS access they gave you include DDS Micro, which seems to be their ARM build? 

On Tuesday, August 13, 2019, 10:21:11 AM MDT, Émile Grégoire <notifications@github.com> wrote:

@dwaynebradley It is not completely statically-linked (most notably, we require libstdc++, libpcap and libpq to be installed on the system), but static linking won't solve the issue. RTI DDS is precompiled with a dependency on glibc that the image can't fulfill. The only solutions are to have glibc (from another image) or to compile RTI DDS from source with musl (and hope for the best).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

emgre commented 5 years ago

No, I don't have access to DDS Micro. What I downloaded was from here: https://www.rti.com/free-trial/dds-files#6.0.0

dwaynebradley commented 5 years ago

@larrylackey, sounds like a topic of discussion with RTI at some point then... 😉

larrylackey commented 5 years ago

Yes, yet again

On Tuesday, August 13, 2019, 10:35:47 AM MDT, Dwayne Bradley <notifications@github.com> wrote:

@larrylackey, sounds like a topic of discussion with RTI at some point then... 😉

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

jadamcrain commented 5 years ago

Status update:

1) We are using minideb instead of alpine to get around the issues w/ RTI lacking non-glibc libraries.

2) Emile is currently hosting the RTI libs privately on an Amazon S3 bucket. The build script uses the amazon CLI to retrieve this:

https://github.com/openenergysolutions/openfmb.adapters.docker/blob/minideb-rti/minideb-x64/build.sh#L16

It's recommended that OES get their own bucket that we can use going forward that we can use to host large binary files like this that aren't appropriate for Git.