Handling properietary bundles

framework
1

I am starting to go down the route of charming my infra… really excited… BUT I have one thing which I cannot figure out…

I have a proprietary asset which must be installed and allowed to pop up with a GUI to login … does Juju Charms manage or have a way to manage this ?

The asset in question is IB Gateway… a proprietary application I need to start and login to … in order to start querying for data … how is it suggested I start ?

https://www.interactivebrokers.com/en/index.php?f=16457

edit: one idea i had was to use states… and emit the state when the bundle is logged in or logged out… if I am at the login screen etc…

I will also investigate if it has a CLI to login that I can invoke

2

Really interesting question @emcp. Juju actually has a lot of internal functionality for supporting this use case.

  • charms can require that users accept terms & conditions
  • charms can add “metrics”. The intent there was to support billing

Terms

An charm that makes use of terms & conditions is Let’s Encrypt support within ssl-termination-proxy charm written by @merlijn-sebrechts’s team at Tengu.

$ charm show cs:~tengu-team/ssl-termination-proxy terms
terms:
- isrg-lets-encrypt

Another one is cs:~ibmcharmers/ibm-http to allow IBM HTTP Server to be deployed:

$ charm show cs:~ibmcharmers/ibm-http terms
terms:
- ibmcharmers/ibm-im/1
- ibmcharmers/ibm-im/1
- ibmcharmers/ibm-im/1
- ibm-http-z/1
- ibm-http-plg-z/1
- ibm-http-wct-z/1

Metrics

Metrics is less well exercised, as far as I can tell. But the functionality is available and quite interesting to explore:

1 Like
3

Terms was a way that Canonical negotiated with others that “they have to agree to legal terms”, but they don’t have to necessarily block on an install screen to do so. The idea is that you can register a set of terms with Canonical, and then we will track what users have agreed to what terms, and when they go to deploy software that requires terms to be agreed, we can confirm if that person has/hasn’t agreed.

It doesn’t handle the GUI pop-up, and generally needs legal people to meet, since one bit of software was released that says “you must agree to terms” and you need to get the people offering that software to be ok with those terms being agreed upon in a different way. (It was modeled after Java terms for things like Oracle’s JVM.)

Given limitations there, I would probably say you need something more along the lines of having the charm set a Blocked status, indicating the user has to do something manual in order to proceed. If you can put that step into an Action, all the better, but it sounds like the actual steps are around getting a GUI in front of the user. Which is always a bit muddy in a cloud world.

Given that you’re running a Windows application, I would probably look at trying to get RDP working. You could use an action to tell the user the details of how to connect, and set that in your Blocked message.

1 Like
4

Interesting. My experience as someone deploying a charm with terms, e.g. ~tengu-team/ssl-termination-proxy, was that the deploy was blocked unless the terms were manually accepted.

5

Sorry, the idea is very much that you can’t deploy X until you’ve agreed to the terms, but that is in lieu of requiring a splash screen during install.

Put another way, Companies want to protect themselves by requiring the user to agree to terms. Which usually means their installer pops up terms that you have to agree to. In a cloud world, ‘pop up’ doesn’t work very well, so Canonical has worked out a system that still requires them to agree to terms (blocking deploy until they have done so), and in exchange the companies allow their software to be installed without the installer then doing a pop-up that they would have to agree to.

As I understand it, it needs a bit of special agreements, because you need a copy of the installer that doesn’t require a pop up.

2 Likes