Re: Hide resources from showing on the store

[Mark Shuttleworth]

On 11/12/16 13:42, Colin Watson wrote:
> I'm not sure that the current mechanism particularly helps with that,
> though.

Yes, I agree, because it's hard to know what 'reasonable result' looks
like in code :)

> Charm authors can still easily upload a zero-sized resource to
> the store and then have their charm refuse to do anything unless you
> attach a "real" resource.  If we assume that authors will legitimately
> want some way of doing optional resources (it seems like a handy way to
> have a payload which normally comes from some centralised source but
> which you might instead attach directly for quick iteration during
> development), then the zero-sized resource thing seems likely to become
> a fairly widespread pattern that people will copy.  Given that, making
> authors resort to non-declarative hacks to achieve the goal of an
> optional resource might just increase the chance of mistakes.

Yes, agreed.

> I can see how resources should default to being required at the charm
> store level to avoid making it easy to publish broken-by-default charms
> by accident.  But how about something like this:
>
>  * Add an "optional: true" option to resources, which the charm store
>would interpret as allowing a charm to be released without that
>resource.
>
>  * Add some kind of affordance to charm-helpers to make this easy to use
>correctly.  For instance, resource_get might be changed to take a
>"default" parameter, which would be accepted and required iff the
>resource in question is optional, or something along those lines.
>
>  * Perhaps also add something to layer-apt and layer-snap to encapsulate
>the "install from this source by default, but use a resource if it's
>attached" pattern.
>
> I don't have a broad enough view of charms to be able to tell whether
> this is a good idea in general or overkill, but it would certainly have
> saved me some effort the other day if I could have just written
> something like this instead of a bunch of reactive code that took me
> several tries to get right:
>
>   options:
>   apt:
>   packages:
>   - launchpad-buildd
>   - bzr-builder
>   - git-build-recipe
>   - quilt
>   optional-package-resources:
>   - launchpad-buildd
>   - python-lpbuildd
>


These are great suggestions. I think in the end what we want is to hold
the "works without a separate CD" requirement for the curated set, where
we manually review. But making resources optional seems like the
sensible avoid-hacky-workarounds-becoming-standard approach here.

Mark



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hide resources from showing on the store

[Colin Watson]

On Sun, Dec 11, 2016 at 12:57:35PM -0800, Mark Shuttleworth wrote:
> On 05/12/16 07:12, Colin Watson wrote:
> > As suggested in this thread and on IRC, I fell back to accepting
> > zero-sized resources instead and uploading those to the store, and that
> > works OK:
> >
> >   https://jujucharms.com/u/launchpad/launchpad-buildd
> >
> > It seems like a fairly nasty hack though.  Resources are pretty nice,
> > and this feels like a wart.
> 
> I think the point is that "juju deploy foo" should always give you a
> reasonable result. In your case, that's the PPA option. *if* a resource
> is specified, then it should be used. What we want to avoid is charms
> which don't work at all unless a resource is specified.

Right, I can definitely see that, and ensuring that there's always a
reasonable result is exactly what I'm trying to do.

I'm not sure that the current mechanism particularly helps with that,
though.  Charm authors can still easily upload a zero-sized resource to
the store and then have their charm refuse to do anything unless you
attach a "real" resource.  If we assume that authors will legitimately
want some way of doing optional resources (it seems like a handy way to
have a payload which normally comes from some centralised source but
which you might instead attach directly for quick iteration during
development), then the zero-sized resource thing seems likely to become
a fairly widespread pattern that people will copy.  Given that, making
authors resort to non-declarative hacks to achieve the goal of an
optional resource might just increase the chance of mistakes.

I can see how resources should default to being required at the charm
store level to avoid making it easy to publish broken-by-default charms
by accident.  But how about something like this:

 * Add an "optional: true" option to resources, which the charm store
   would interpret as allowing a charm to be released without that
   resource.

 * Add some kind of affordance to charm-helpers to make this easy to use
   correctly.  For instance, resource_get might be changed to take a
   "default" parameter, which would be accepted and required iff the
   resource in question is optional, or something along those lines.

 * Perhaps also add something to layer-apt and layer-snap to encapsulate
   the "install from this source by default, but use a resource if it's
   attached" pattern.

I don't have a broad enough view of charms to be able to tell whether
this is a good idea in general or overkill, but it would certainly have
saved me some effort the other day if I could have just written
something like this instead of a bunch of reactive code that took me
several tries to get right:

  options:
  apt:
  packages:
  - launchpad-buildd
  - bzr-builder
  - git-build-recipe
  - quilt
  optional-package-resources:
  - launchpad-buildd
  - python-lpbuildd

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hide resources from showing on the store

[Mark Shuttleworth]

On 05/12/16 07:12, Colin Watson wrote:
> As suggested in this thread and on IRC, I fell back to accepting
> zero-sized resources instead and uploading those to the store, and that
> works OK:
>
>   https://jujucharms.com/u/launchpad/launchpad-buildd
>
> It seems like a fairly nasty hack though.  Resources are pretty nice,
> and this feels like a wart.

I think the point is that "juju deploy foo" should always give you a
reasonable result. In your case, that's the PPA option. *if* a resource
is specified, then it should be used. What we want to avoid is charms
which don't work at all unless a resource is specified.

Mark

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hide resources from showing on the store

[Colin Watson]

Here's another use case for this kind of thing that doesn't involve
proprietary code or terms.

I recently put together a charm for launchpad-buildd: this lets you
deploy a builder node in a container that can be attached to a local
instance of Launchpad.  There are two plausible ways to get the actual
launchpad-buildd code in place:

 1) You don't really care about the details and just want the latest
stable version.  For this, it makes sense to install from our PPA,
which we're maintaining anyway for production use.  I don't want to
have to separately keep resources up to date.

 2) You're hacking on a change to the launchpad-buildd code and want an
easy way to deploy it locally to try it out.  While you *could*
build the whole thing in a PPA, that increases your iteration time
quite a bit; it's much quicker to just build the packages locally
and attach them as resources.

My first attempt was to list the resources in metadata.yaml and only
attach them if they were actually needed, which I naïvely assumed would
work.  And in fact it did almost entirely work: hookenv.resource_get
returned False as documented, and my charm handled that and fell back to
installing from a PPA.  What didn't work was when I tried to do "charm
release", which gave me:

  ERROR cannot release charm or bundle: bad request: charm published with 
incorrect resources: resources are missing from publish request: 
launchpad-buildd, python-lpbuildd

As suggested in this thread and on IRC, I fell back to accepting
zero-sized resources instead and uploading those to the store, and that
works OK:

  https://jujucharms.com/u/launchpad/launchpad-buildd

It seems like a fairly nasty hack though.  Resources are pretty nice,
and this feels like a wart.

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Hide resources from showing on the store

[John Meinel]

If the resource is available from the charm home page without the user
having signed the same licence agreement, then we *definitely* have a bug
that needs fixing. We should definitely require logging into the charm
website to have access to anything that has resources that are also behind
licensing agreements. I'll try to verify with my colleagues, but I would
expect the same gating that you have for "juju deploy" with a licensed
resource that you would have for "wget" from the webpage.

Just make sure if you're testing this to not be logged in with the account
that already has signed the EULA :).

John
=:->


On Fri, Dec 2, 2016 at 5:29 PM, Ionut Balutoiu <
ibalut...@cloudbasesolutions.com> wrote:

> Hello John,
>
>
>
> I’m aware that there is a way to prompt users to accept EULA on deploy
> time, but I’m worried about the fact the resources are downloadable from
> the charm home page.
>
> I’m not sure this is fine as I think we redistribute the software this way
> and there are EULA’s that might not allow this.
>
> Uploading a zero bytes resource and instructing the users in README how to
> pass the real resources, should do the work, but it’s just a workaround.
>
> I would’ve liked to be able to release/publish a charm without specifying
> any resource and have them grayed out on the portal, the way they are right
> now before publishing.
>
> This is an example of a charm that I want to publish and I don’t want any
> resources uploaded on the charm store: https://jujucharms.com/u/
> cloudbaseit/azure-service-fabric/8
>
>
>
> Regards,
>
> Ionut
>
>
>
> *From:* juju-boun...@lists.ubuntu.com [mailto:juju-bounces@lists.
> ubuntu.com] *On Behalf Of *John Meinel
> *Sent:* Friday, December 2, 2016 15:19
> *To:* Konstantinos Tsakalozos <kos.tsakalo...@canonical.com>
> *Cc:* juju <juju@lists.ubuntu.com>
> *Subject:* Re: Hide resources from showing on the store
>
>
>
> Why can he not upload the resources? We have several mechanisms in place
> to allow for gating charms based on things like "accepting terms", and a
> general policy that "juju deploy SOFTWARE" should actually get you SOFTWARE
> running in a functional manner. Telling people "do this deploy, but then go
> get the real functional by visiting these websites" is not a good user
> experience, so we're unlikely to try and polish things like "don't allow
> people to see that there are 0 byte resources".
>
>
>
> John
>
> =:->
>
>
>
>
>
> On Fri, Dec 2, 2016 at 2:48 PM, Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com> wrote:
>
> Hi all,
>
>
>
> Ionut Balutoiu (in cc) would like to use the resources mechanism but he
> cannot upload the actual resources to accompany the charm. Instead he will
> prompt the users to attach their own binaries during deployment. To serve
> this use case Ionut can upload a dummy zero-sized binary to the store and
> use its size to detect if the user has provided his own binary. 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? is there a more elegant way to serve this use-case?
>
>
>
> Thanks,
>
> Konstantinos
>
>
> --
> 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

Re: 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 <
gsamf...@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 +, 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 <
> 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 +, 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
>
> --
> 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

Re: Hide resources from showing on the store

[Gabriel Samfira]

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 +, 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 
> 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 +, Rick Harding wrote:
On Fri, Dec 2, 2016 at 5:49 AM Konstantinos Tsakalozos 
> 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 list
Juju@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

--
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

Re: Hide resources from showing on the store

[Nate Finch]

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 +, 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

Re: Hide resources from showing on the store

[Gabriel Samfira]

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 +, Rick Harding wrote:
On Fri, Dec 2, 2016 at 5:49 AM Konstantinos Tsakalozos 
> 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 list
Juju@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

Re: Hide resources from showing on the store

[John Meinel]

Why can he not upload the resources? We have several mechanisms in place to
allow for gating charms based on things like "accepting terms", and a
general policy that "juju deploy SOFTWARE" should actually get you SOFTWARE
running in a functional manner. Telling people "do this deploy, but then go
get the real functional by visiting these websites" is not a good user
experience, so we're unlikely to try and polish things like "don't allow
people to see that there are 0 byte resources".

John
=:->


On Fri, Dec 2, 2016 at 2:48 PM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi all,
>
> Ionut Balutoiu (in cc) would like to use the resources mechanism but he
> cannot upload the actual resources to accompany the charm. Instead he will
> prompt the users to attach their own binaries during deployment. To serve
> this use case Ionut can upload a dummy zero-sized binary to the store and
> use its size to detect if the user has provided his own binary. 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? is there a more elegant way to serve this use-case?
>
> Thanks,
> Konstantinos
>
> --
> 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