content sharing from $SNAP_COMMON

[Jacek Nykis]

On 21/12/16 17:22, Pat McGowan wrote:
> The documentation on sharing writable data was updated last week, notably
> saying this works in version 2.19.1 and later. There is also a
> recommendation to not use subfolders. 2.20.1 is available from xenial
> proposed.
> 
> https://github.com/snapcore/snapd/wiki/Content-Interface
> 
> Hope it helps
> Pat

Thanks for suggestion Pat.

I saw that page but I am trying to share read only data. It does not
work in 2.17, I also tried with 2.20.1 without luck.

I am trying to share single directory containing one file.

Regards,
Jacek

> 
> On Wed, Dec 21, 2016 at 11:48 AM, Jacek Nykis <jacek.nykis at canonical.com>
> wrote:
> 
>> Hi,
>>
>> I'm also affected by this problem, I can see that there is a bug in
>> Launchpad now:
>>
>> https://bugs.launchpad.net/snappy/+bug/1650671
>>
>> Does anybody know how to troubleshoot this? There is nothing interesting
>> in /var/log/syslog
>>
>> Jacek
>>
>> On 09/12/16 22:53, Tim Kuhlman wrote:
>>> I had an opportunity to experiment some more unfortunately it still
>> isn't working but I can provide more details.
>>>
>>> I was pointed to some documentation at https://github.com/snapcore/
>> snapd/wiki/Content-Interface and used that
>>> to update a bit of naming in the config. I have been running on yakety
>> with the version of snapd and other
>>> tools from yakety but in my debugging I updated to the latest snapd from
>> the snappy edge ppa because I
>>> discovered that without that $SNAP* prefixes in the config don't work
>> otherwise.
>>>
>>> I'm working with the promreg charm which is the producer, it has this
>> config:
>>> slots:
>>>   content:
>>>     content: promreg
>>>     read: [$SNAP_COMMON/promreg]
>>>
>>> The consumer is the prometheus charm which has this config.
>>> plugs:
>>>   content:
>>>     content: promreg
>>>     target: etc/prometheus/promreg
>>>
>>> After creating the charms and installing them then linking with the
>> command `snap connect prometheus:content
>>> promreg:content` I ran `sudo snap run --shell prometheus` initially I
>> would get path errors, which I solved
>>> with the upgraded snapd.
>>>
>>> The directory '/var/snap/promreg/common/promreg' does exist and has
>> data in it. The destination directory in
>>> the prometheus snap didn't originally exist but I tried creating it
>> after reading
>>> http://askubuntu.com/questions/841004/cannot-get-
>> basic-content-interface-example-working-with-snapcraft
>>>
>>> After getting a shell with the command `sudo snap run --shell
>> prometheus` I see that the destination dir is
>>> empty if the destination dir was pre-existing and it doesn't exist at
>> all if dir wasn't pre-existing.
>>>
>>> Any details I am missing? other debug steps?
>>>
>>> Tim
>>>
>>> On 12/05/2016 12:25 AM, Didier Roche wrote:
>>>> Le 02/12/2016 à 19:34, Tim Kuhlman a écrit :
>>>>> I have a snap that writes data to $SNAP_COMMON as it runs and I want
>> to make that data available to another
>>>>> snap. Unfortunately when I setup the content interface and set the
>> plug side to share
>>>>> '/var/snap/snap-name/common/subdir' it fails.
>>>>>
>>>>> I can share data in $SNAP with the content interface but of course the
>> daemon running in that snap can't
>>>>> write there. Am I missing anything? Is there any way to share
>> dynamically created data from one snap with another?
>>>>>
>>>>> Thanks for the help.
>>>>
>>>> Hey Tim,
>>>>
>>>> I know that was supposed to be supported, but I don't know the
>>>> implementation status of this.
>>>>
>>>> Zygmunt, can you shed some lights to us there?
>>>> Cheers,
>>>> Didier
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/snapcraft
>>
>>
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161221/8a2e1d33/attachment.sig>