couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Publisher account for CouchDB snap
Date Sat, 21 Jan 2017 10:30:32 GMT
Gentle reminder that this is the developer mailing list for CouchDB.

B.

> On 21 Jan 2017, at 05:04, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:
> 
> Ah, great. I'll be the first to admit I haven't done a deep dive on
> the docs yet.
> 
> Given what you just wrote, the only issue I that can see remaining is
> that the majority of our systems are behind hospital firewalls, unable
> to reach the open internet. We provide system updates by handing our
> customers a big GPG-signed and encrypted .tar.gz that gets unpacked,
> with install scripts, .deb files with new versions of libraries, our
> new application software, etc. all contained inside.
> 
> How would we update snaps in that kind of environment?
> 
> On Fri, Jan 20, 2017 at 6:13 PM, mhall119 <mhall119@gmail.com> wrote:
>> Hi Eli,
>> 
>> Enterprise servers, clouds and industrial IoT is a major focus for snaps,
>> perhaps more so than desktop.
>> 
>> As I understand it you're making a medical device, right? In this use case
>> we have a special class of snaps called "gadget snaps" which enable the
>> specific hardware your product is using. This lets you ship provide the
>> drivers and kernel modules your device will need on top of the Ubuntu OS
>> snap that contains the basic operating system, and combine it with
>> application snaps like CouchDB, all of which can be updated independently
>> of each other.
>> 
>> The "Update control" system is essentially what you describe, there's a
>> list of subordinate snaps that you can pin to a specific version. Then when
>> you update that list in the store, all your devices will see it and get
>> upgrade whatever snaps you've told them to upgrade.
>> 
>> The store we provide is build for this kind of use case, so it offers both
>> private snaps and custom stores (in case your product wants to let users
>> install other snaps you've chosen to support). We are still learning all of
>> the different use cases that are out there, so if our current offering
>> doesn't cover yours we'd still like to know more about it so we can try and
>> improve it.
>> 
>> On Tue, Jan 17, 2017 at 12:37 PM, Eli Stevens (Gmail) <wickedgrey@gmail.com>
>> wrote:
>> 
>>> Thanks for following up!
>>> 
>>> We were not planning on making our product into a snap at this time,
>>> though I suppose we could have a stub snap just to lock down CouchDB's
>>> version. Seems a bit kludgy, but I'm not convinced I'm understanding
>>> the situation you're describing well. We're certainly not interested
>>> in having any of our snaps available through the official store, as
>>> we've got some pretty specific hardware requirements, and a sales
>>> process that doesn't work well for that kind of setup (mostly about
>>> ongoing maintenance costs).
>>> 
>>> All we're really looking for is a way to say to the snap system "hey,
>>> I'll give you a directory full of snaps to install, and then I want
>>> you to leave them alone (in terms of no auto-updating). At some point
>>> in the future, a new directory of updated snaps will be provided, and
>>> then we'll want those installed, and then left alone."
>>> 
>>> Do you know if snaps have server/enterprise usage as a use-case, or
>>> are they aimed squarely at user/desktop applications?
>>> 
>>> Cheers,
>>> Eli
>>> 
>>> On Tue, Jan 17, 2017 at 7:20 AM, Michael Hall <mhall119@gmail.com> wrote:
>>>> On 12/20/2016 01:56 PM, Eli Stevens (Gmail) wrote:
>>>>> On Tue, Dec 20, 2016 at 9:16 AM, Michael Hall <mhall119@gmail.com>
>>> wrote:
>>>>>> On 12/19/2016 06:23 PM, Eli Stevens (Gmail) wrote:
>>>> 
>>>>>>> - Is it possible to disable automatic updates for snaps?
>>>>>> 
>>>>>> It's possible, I don't know the details of it though. Can you tell
me
>>>>>> what your concern is with leaving it on?
>>>>> 
>>>>> The FDA requires us to produce documentation detailing the versions of
>>>>> 3rd party software we use to construct our product, and attest to the
>>>>> suitability of those versions for the purpose that we're using them
>>>>> for. Maintaining the proper documentation gets a lot harder when the
>>>>> version can get swapped out from underneath us without warning. And if
>>>>> there's an actual incompatibility, that means that cancer patients
>>>>> might not be able to start their course of treatment on time, which
>>>>> the patients, clinical staff, and our director of customer support all
>>>>> agree is undesirable.  ;)
>>>>> 
>>>> 
>>>> Hi Eli, sorry for taking to long to get an answer for you on this, I had
>>>> to find someone in Canonical who could tell me what the options are, and
>>>> then it appears I accidentally deleted this email thread.
>>>> 
>>>> The Snap store that Canonical runs has a features called "Update
>>>> control" designed for device makers, which lets them specify what
>>>> versions of other snaps can be installed on their device. This would let
>>>> you specify, in your own snap, which version of couchdb will be used on
>>>> your device. You can then update that information in your snap in the
>>>> store, and all of your devices will see that only then will they update
>>>> couchdb to the new version.
>>>> 
>>>> This is a commercial feature of the store, it's not available to regular
>>>> application snap developers. I'd be happy to put you in touch with
>>>> someone at Canonical who can tell you more about it and help you get
>>>> setup with it.
>>>> 
>>>> --
>>>> Michael Hall
>>>> mhall119@gmail.com
>>> 


Mime
View raw message