Cross model relations for jimm models not implemented

Hello,

I am trying to make a cross-model-relation from an application in a vsphere model to an application in a MAAS model. The result, when I try to create the offer from the vsphere model:

17:55:56 INFO  juju.cmd supercommand.go:91 running juju [2.8.1 0 16439b3d1c528b7a0e019a16c2122ccfcf6aa41f gc go1.14.4]
17:55:56 DEBUG juju.cmd supercommand.go:92   args: []string{"/snap/juju/13324/bin/juju", "offer", "slurmctld:slurmd", "--debug"}
17:55:56 INFO  juju.juju api.go:67 connecting to API addresses: [jimm.bdxbdx.com:443]
17:55:56 DEBUG juju.api apiclient.go:1105 successfully dialed "wss://jimm.bdxbdx.com:443/api"
17:55:56 INFO  juju.api apiclient.go:1007 cannot resolve "jimm.bdxbdx.com": operation was canceled
17:55:56 INFO  juju.api apiclient.go:637 connection established to "wss://jimm.bdxbdx.com:443/api"
17:55:56 DEBUG juju.api apiclient.go:1105 successfully dialed "wss://jimm.bdxbdx.com:443/api"
17:55:56 DEBUG juju.api monitor.go:35 RPC connection died
ERROR unknown object type "ApplicationOffers" (not implemented)
17:55:56 DEBUG cmd supercommand.go:537 error stack: 
unknown object type "ApplicationOffers" (not implemented)
/build/snapcraft-juju-03af7d/parts/juju/src/rpc/client.go:178: 
/build/snapcraft-juju-03af7d/parts/juju/src/api/apiclient.go:1200: 
/build/snapcraft-juju-03af7d/parts/juju/src/api/applicationoffers/client.go:52:  

Seems that the offer functionality is not implemented in vsphere …

We have architected a solution using cross-model-relations to connect application running in vsphere models to applications running in models in MAAS. I didn’t previously understand that cross-model-relations only worked on certain clouds (not vsphere). Is there anything that can be done to get the cross-model-relations hooked up for MAAS and vsphere clouds?

Thank you!

1 Like

Furthermore, I can’t seem to create a cross model relation offer on a maas model either.

~$ juju status
Model         Controller       Cloud/Region   Version  SLA          Timestamp
slurm-nash-1  jimm.bdxbdx.com  bdxbdx-maas-1  2.8.1    unsupported  18:06:29Z

App     Version  Status   Scale  Charm   Store       Rev  OS      Notes
slurmd           waiting    0/1  slurmd  jujucharms    1  ubuntu  

Unit      Workload  Agent       Machine  Public address  Ports  Message
slurmd/0  waiting   allocating  0        10.104.195.134         waiting for machine

Machine  State  DNS             Inst id  Series  AZ          Message
0        down   10.104.195.134  n-c125   focal   se-west-1a  Failed deployment: Failed to power on node - Power on for the node failed: Could not contact node's BMC: Connection timed out while performing power action.  Check BMC configuration and connectivity and try again.

$ juju offer slurmd:slurmd
ERROR unknown object type "ApplicationOffers" (not implemented)
1 Like

(because we have a convo going with the webteam about cross-model-relations) @ziheliu214 @gomboli @hatch ^

2 Likes

Sorry about this. It’s a frustrating place to bump into the issue.

That error message is generated by the RPC infrastructure between Juju agents. It’s possible that this is a JIMM issue rather than a vSphere issue. I’ll check and get back to you.

1 Like

Thanks @timClicks! I filed a bug for this here

1 Like

CMR is not cloud specific - any standalone Juju controller on any cloud has the service facades needed to support CMR.

Ah, I just noticed your controller is “jimm.xxx” - have you set up a bespoke JAAS deployment? The Juju controllers will be fully CMR aware but the front end JIMM proxy may need work done to participate in a CMR deployment. A check on the JIMM project source seems to be missing the CMR facades. We’d need to check with the folks on that team to ask that that omission be addressed.

1 Like

@wallyworld Yes, we have a bespoke JAAS deployment. Sounds like a great start, to move in that direction. Is there anything I can do to help relay the information and/or get the correct eyes on this?

Nothing from your end per se - it’s purely a missing JAAS feature this side which needs resources allocated to get it done.

1 Like

We have an ubuntu advantage deal going on, I think @erik-lonroth may have carried ^bug over to the ubuntu advantage ticketing system as well. Not sure if that will help or not, but its over there also.

Good to know, thank you. We’ll raise it from this side also.

Yeah, I’ve logged a case for the issue and referenced this discussion along with the launchpad bug.

Thanx for the response and I will provide you with all info you need.

I have followed up on this through the Ubuntu Advantage subscription today as this still is in the pipe as a real problem.

Pinging @martin-hilton just to ensure everyone is in the loop ^^^^^

1 Like

This is biting us bad, in many ways … is there anything that we can do to move some water here?

Oh, the horror.

Not having cross-model relations functionality from juju in combination with JIMM/candid adds a major problem.

Let me elaborate on why:

So, we are running SLURM, which is a system that normally has many thousands of machines picked up from the underlying cloud. This can be MAAS or perhaps some other cloud with virtual machines. The SLURM principal charms needs one or two subordinates which adds a multiplier to the number of units in a model.

SLURM models then grows to potentially tens of thousands of units which is not manageable at all. To remedy this, we (wanted to) architect SLURM with juju by splitting up the SLURM clusters into smaller models and using CMR to make up a larger SLURM cluster split into many models. You can look at it like sharding or partitioning our HPC SLURM environment making the environment manageable.

This also saves alot of machine resources from our MAAS/cloud since we would also not need to replicate central components of SLURM, like databases, SLURM-controllers etc. Maintaining multiple of these central components adds to complexity aswell, so CMR is needed here for that purpose aswell.

Missing out on CMR with JIMM+juju+candid puts us in a bad place where we are now left to chose between JIMM xor Juju…

I’m more than happy to provide more information and help in resolving this.

Good news is that the CMR in JIMM is on the ‘to-do’ list, and we are going to post and show here on Discourse some design that @ziheliu214 recently discussed with users and teams about displaying the CMR in the Dashboard (hence having it on JIMM/JAAS).
CC @hatch if you want to add anything to this.

2 Likes

Can we audit all the facades that JIMM is using and updating all of them at the same time?

Here’s the design, if you want to have a look and leave comments:

1 Like

I’m very glad to hear that. Any way for us to track that progress in a way that we can also get an idea as how far away it is?

1 Like

Product roadmaps are going to be defined soon, so we can have a better idea about the timeline.

1 Like