I'm with Rick... the expected usage is to publish a dummy resource with the charm. Then, when you deploy, you deploy the real resource from your local machine at deploy time. If you forget, you can always add the resource after deploy, as well. The charm needs to take into consideration that someone may forget to include the real resource at deploy time.
Yes, someone could download the dummy resource from the charmstore... I'm not sure why this matters, though? It should be pretty obvious right away that it's not the real resource, and the README should also ensure to clarify this. -Nate On Fri, Dec 2, 2016 at 9:08 AM Gabriel Samfira < gsamf...@cloudbasesolutions.com> wrote: > Say you have a charm that deploys a proprietary piece of software. That > software has an EULA that prohibits anyone from redistributing it. The user > is essentially forced to go to the software vendor website, login using > their account, buy the software, and accept the EULA before being able to > use the software. > > In this scenario, we cannot upload that piece of software as a resource > into the charm store, and set that as the "default" resource for the charm. > The license for that software does not allow us to. Most users that consume > such software are aware of this, and is of no surprise to them that they > have to "own" those resources before they can deploy them. > > There are 2 options here: > > 1) Canonical is given permission to redistribute the piece of software in > question (Sharepoint, Exchange, MS SQL ISOs, etc), and validates that the > user deploying the charm has the right to deploy that software. > 2) Allow a charm to be published without resources, and validate during > deployment if the resources are available or not. The charm can handle the > missing resources and print a nice comprehensive status message. If the > charm also includes a decent README on how to deploy the service, it should > be enough to smooth the process. In this scenario, the responsibility of > making sure all license terms are satisfied, falls onto the user. > > It is unfortunate that licensing gets in the way of simplicity, but it is > an issue that we need to keep in mind. > > Cheers, > Gabriel > > On Vi, 2016-12-02 at 13:33 +0000, Rick Harding wrote: > > On Fri, Dec 2, 2016 at 5:49 AM Konstantinos Tsakalozos < > kos.tsakalo...@canonical.com> wrote: > > This works but has a side effect, the dummy binaries are available for > downloading from the charm's page. Is there a way to hide the resources > from the charm's readme page? > > > I'm confused why the user cannot know there's a default resource there? > > In an ideal world, the author would provide a default resource that at > least helps guide the user to how to use the charm if they forget or use > the wrong type of local resource. We want to make sure the user is guided > on how to get things working as smoothly as possible. > > The other side is charm testing. The charm should have enough of what it > needs in the default resource to perform functional tests to pass via tools > such as Matrix. > > I'm curious how the user even knowing a thing is there is bad for the > user. At this time we don't have any pattern to assist this. > > -- > Juju mailing listj...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- > Regards, > Gabriel Adrian Samfira > Cloudbase Solutions SRL > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
