Ok, so the fact that we’ll be putting out a response with the URL list and current server certificate should be sufficient in this case as it can similarly be used to know that the request was processed.
I think so. If it’s a single write to the relation data after the client certificate was added and the URL list is not provided before the client certificate is provided then that can work. If I recall correct there was a not predictable order back when we did this. It wasn’t predictable which side wrote first when the relation was joined. So either the provider doesn’t write anything until the client has written it’s request or you have something else to signal the request was processed successfully (e.g. trusted_certs_fp)
Yeah, we wouldn’t have the LXD charm do anything until the connecting charm has provided the data, so you’d only get the connection details once we’ve gotten that data and have put the cert into the trust store.
I had another look at the now documented interfaces. Do we really want to leave it with one certificate + projects pair or do we want to allow multiple pairs per relation? If not, we force the relating charm to have an endpoint per certificate it wants to register which might be really specific to how the actual user uses the software (think of a dashboard which has a cert per registered user where each user has access to different projects). Is there a particular reason it is specified this way?
The common case is going to be another application connecting to LXD and wanting API access. Such an application really should have a single certificate and be associated with its model and unit so the audit trail in LXD makes sense.
If an application is going to need to access multiple projects (or all of them), then having a single credential configured as such would be preferable.
In your example of a dashboard acting as multiple user, our recommendation is to not use TLS based auth as this doesn’t actually have the concept of users and instead use candid based auth which does (possibly add RBAC on top).
If that’s not an option, then I’d actually prefer that such an application register as an unrestricted API client with LXD and then use its privileges to add additional restricted certificates to the trust store through the LXD API, making sure to annotate those certificates for its users.
In general the plan for this charm is to not re-implement things that LXD itself already provides through its API. So if an application by design needs to do active trust store management operations, we’d much rather it just asks for a full API cred through the charm and then performs the rest through the LXD API.
The dashboard was more of a quick but unrealistic example. I agree that generally going via the API is the go-to approach.
Thanks for clarifying this. Approved from my side 
Current spec looks good to me too.
1 Like
I think generally this spec looks really good - I have one style comment which you can feel free to ignore but the snap{_config} prefixes on some of the charm options seem a bit superfluous - the charm only deploys using the snap! Less typing when producing bundles and using the CLI as well if these are not used.
I also prefer ‘-’ to ‘_’ and that’s something we’ve tried to standardise on in the OpenStack Charms.
The goal with the snap prefix was to clearly separate what’s a LXD config from what’s coming as a snap config (snap set) while also keeping things nicely sortable. This should allow for possible future expansions of charm config without having to ever deal with conflicts or confusing keys 
For the dash vs underscore part, I don’t personally have an opinion on it, so if we’re trying to standardize on dash, we should go with that then!
Spec marked as approved now.
So as it turns out, this isn’t really possible as there’s no easy way to get the full model+machine config from the charm, so we’ll skip this for now.
As discussed, since Juju makes proxy information available in /etc/juju-proxy.conf, I’ve implemented the core.proxy_ initial setting based on it.
I watched the video of all this which was to say the least IMPRESSIVE!
https://www.youtube.com/watch?v=ix5XMDDkHLA
I’m looking for some help on who implemented the grafana dashboard side of the charm here since I’m trying to develop a charm that does the integration with grafana automatically.
Truly amazing work on this charm. I will for sure start using this down the road.
Sure, I’m happy to help!
1 Like
I would appreciate that a lot. How would we ideally do this?
I have created a charm which I hope to be useful as a reference implementation for also later use here: juju-operators-examples/grafana-dashboard-example at main · erik78se/juju-operators-examples · GitHub
I’ve found some inspiration for the implementation here: charm-ceph-dashboard/interface_grafana_dashboard.py at af80051429960db357c51e8966fc2bf9f0c220f8 - charm-ceph-dashboard - OpenDev: Free Software Needs Free Tools - but I can’t understand why its implemented the way it is.
I’m also in a discourse about the implmentation here: Looking for some help debuging why grafana-dashboard isnt getting all json - #6 by erik-lonroth - development - Charmhub
Its still missing interface for prometheus to be useful currently, but I’m not sure how to implement it yet since I can’t modify the snap config etc. How to edit prometheus.yml - snap - snapcraft.io
Let’s move to a another thread/topic whatever it is called on discourse 
1 Like
Sure, I’ll prepare an initial post. I’m also using chat.charmhub.io (mattermost) if we can meet up there and/or hangouts.
I’ve pinged you in to this thread which is where I’ve communicated on this topic so far. Looking for some help debuging why grafana-dashboard isnt getting all json - #7 by wallyworld - development - Charmhub
I’ve also committed the code I’ve got so far and the README.md should be fairly up to date.