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 <rnew...@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) <wickedg...@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 <mhall...@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) <wickedg...@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 <mhall...@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 <mhall...@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 >>>>> mhall...@gmail.com >>>> >
