couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: Publisher account for CouchDB snap
Date Thu, 26 Jan 2017 22:40:01 GMT
Are issues with and troubleshooting of the previously-provided CouchDB
2.0 snap files on topic for dev? If not, I can take it private.

Honest question - not wanting to step on toes, and my internal
calibration doesn't seem to line up with Bob's (I figured that
discussing binary packaging for 2.0 would be on-topic for the list),
so I figure it's best to ask.

Thanks,
Eli

On Sat, Jan 21, 2017 at 2:30 AM, Robert Samuel Newson
<rnewson@apache.org> wrote:
> 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