Hide resources from showing on the store

[Jay Wren]

+1 its a workaround rather than a feature.

Can we allow publishing charms without resources? This simplifies things
for the charm author for the cases that the charm resource cannot be
uploaded to charmstore.

On Fri, Dec 2, 2016 at 11:59 AM, Gabriel Samfira <
gsamfira at cloudbasesolutions.com> wrote:

> I was not aware that the expected usage was to publish with dummy
> resources. At least, its not reflected in the documentation:
>
> https://jujucharms.com/docs/2.0/developer-resources
>
> Good to know :).
>
> Uploading 0 byte resources sounds like a workaround rather then a feature
> though. Would it not be the same to just allow users to publish a charm
> without attaching any resources at all? That way the charm author can set
> the charm im blocked status if declared resources have not been uploaded.
>
>
> On Vi, 2016-12-02 at 16:41 +0000, Nate Finch wrote:
>
> 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 <
> gsamfira at 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.tsakalozos at 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 listJuju at 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 at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161202/3261881e/attachment.html>