Re: [VOTE] Set a finite default for max_attachment_size
Ok, fair enough, +0 from me with a note that I'd still prefer to see this limit aligned with 4.x limits, so users wouldn't have to adjust to this change twice. Eric > On Feb 1, 2021, at 14:47, Nick Vatamaniuc wrote: > > I am +1 to lowering as it's better than infinity. > > But I also see Eric's point. I was surprised a while back just like > Eric that I could successfully upload >1GB-sized files. So why not > 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes > and file systems (FAT32) since they use ints for file size and > offsets. Since our attachment won't be saved as is in the file systems > inside a .couch file 2GB may be too high, so 1GB as a limit makes > sense to me. > > -Nick > > On Mon, Feb 1, 2021 at 1:25 PM Paul Davis wrote: >> >> +1 >> >> Default unlimited seems like an oversight regardless of what we change it to. >> >> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey wrote: >>> >>> Maybe I didn't express myself clear enough. Setting some finit default is >>> not a purpose, it's what you are doing and I'm asking what the reason for >>> this change. In other words I'm not asking what are you doing, I'm asking >>> why are you doing this. >>> >>> Introducing a new limit will be a breaking change to anoyone who uploads >>> attachments larger than that limit, obviously, so "assumed 1G is large >>> enough" sounds really arbitrary to me without any factual support for that >>> assumption. >>> >>> >>> Eric >>> >>> >>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát wrote: >>>> >>>> The purpose of this vote / PR is to set _some_ finite default. I went >>>> with 1G as I assumed that would not break anyone's production system. >>>> I'd support decreasing that limit over time. >>>> >>>> The vote has been open for 72 hours now, but I believe it still needs >>>> two more +1s to pass. >>>> >>>> >>>> Donat >>>> >>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey wrote: >>>>> >>>>> This got me curious and I tried to upload Ubuntu image as an attachment. >>>>> Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then >>>>> returned proper 201 response with a new doc revision, which I certanly >>>>> didn't expect. Should say, that 1.4G seems suspiciously similar to a >>>>> normal memory limit for a 32 bit process. >>>>> >>>>> Putting this aside, I agree that uploading large attachments is an >>>>> anti-pattern and 1G seems excessive, hence my question. I'd expect this >>>>> number to be based on something and correlating it with a technical >>>>> limit in 4.x makes a lot of sense to me. >>>>> >>>>> >>>>> Eric >>>>> >>>>> >>>>>> On Jan 28, 2021, at 16:02, Robert Newson wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I think a gigabyte is _very_ generous given our experience of this >>>>>> feature in practice. >>>>>> >>>>>> In 4.x attachment size will necessarily be much more restrictive, so it >>>>>> seems prudent to move toward that limit. >>>>>> >>>>>> I don’t think many folks (hopefully no one!) is routinely inserting >>>>>> attachments over 1 gib today, I’d be fairly surprised if it even works. >>>>>> >>>>>> B. >>>>>> >>>>>>> On 28 Jan 2021, at 19:42, Eric Avdey wrote: >>>>>>> >>>>>>> There is no justification neither here or on the PR for this change, >>>>>>> i.e. why this is done. Original infinity default was set to preserve >>>>>>> previous behaviour, this change will inadvertently break workflow for >>>>>>> users who upload large attachment and haven't set explicit default, so >>>>>>> why is it fine to do now? There might be some discussion around this >>>>>>> somewhere, but it'd be nice to include it here for sake of people like >>>>>>> me who's out of the loop. >>>>>>> >>>>>>> Also 1G limit seems arbitrary - how was it choosen? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Eric >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a >>>>>>>> finite default for max_attachment_size . >>>>>>>> The PR is approved, but as per Ilya's request, I'd like to call for a >>>>>>>> lazy majority vote here. >>>>>>>> The vote will remain open for at least 72 hours from now. >>>>>>>> >>>>>>>> Please let me know if you have any questions, comments or concerns. >>>>>>>> >>>>>>>> >>>>>>>> Donat >>>>>>> >>>>>> >>>>> >>>
Re: [VOTE] Set a finite default for max_attachment_size
Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this. Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption. Eric > On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát wrote: > > The purpose of this vote / PR is to set _some_ finite default. I went > with 1G as I assumed that would not break anyone's production system. > I'd support decreasing that limit over time. > > The vote has been open for 72 hours now, but I believe it still needs > two more +1s to pass. > > > Donat > > On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey wrote: >> >> This got me curious and I tried to upload Ubuntu image as an attachment. >> Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned >> proper 201 response with a new doc revision, which I certanly didn't expect. >> Should say, that 1.4G seems suspiciously similar to a normal memory limit >> for a 32 bit process. >> >> Putting this aside, I agree that uploading large attachments is an >> anti-pattern and 1G seems excessive, hence my question. I'd expect this >> number to be based on something and correlating it with a technical limit >> in 4.x makes a lot of sense to me. >> >> >> Eric >> >> >>> On Jan 28, 2021, at 16:02, Robert Newson wrote: >>> >>> Hi, >>> >>> I think a gigabyte is _very_ generous given our experience of this feature >>> in practice. >>> >>> In 4.x attachment size will necessarily be much more restrictive, so it >>> seems prudent to move toward that limit. >>> >>> I don’t think many folks (hopefully no one!) is routinely inserting >>> attachments over 1 gib today, I’d be fairly surprised if it even works. >>> >>> B. >>> >>>> On 28 Jan 2021, at 19:42, Eric Avdey wrote: >>>> >>>> There is no justification neither here or on the PR for this change, i.e. >>>> why this is done. Original infinity default was set to preserve previous >>>> behaviour, this change will inadvertently break workflow for users who >>>> upload large attachment and haven't set explicit default, so why is it >>>> fine to do now? There might be some discussion around this somewhere, but >>>> it'd be nice to include it here for sake of people like me who's out of >>>> the loop. >>>> >>>> Also 1G limit seems arbitrary - how was it choosen? >>>> >>>> >>>> Thanks, >>>> Eric >>>> >>>> >>>> >>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát >>>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a >>>>> finite default for max_attachment_size . >>>>> The PR is approved, but as per Ilya's request, I'd like to call for a >>>>> lazy majority vote here. >>>>> The vote will remain open for at least 72 hours from now. >>>>> >>>>> Please let me know if you have any questions, comments or concerns. >>>>> >>>>> >>>>> Donat >>>> >>> >>
Re: [VOTE] Set a finite default for max_attachment_size
This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process. Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me. Eric > On Jan 28, 2021, at 16:02, Robert Newson wrote: > > Hi, > > I think a gigabyte is _very_ generous given our experience of this feature in > practice. > > In 4.x attachment size will necessarily be much more restrictive, so it seems > prudent to move toward that limit. > > I don’t think many folks (hopefully no one!) is routinely inserting > attachments over 1 gib today, I’d be fairly surprised if it even works. > > B. > >> On 28 Jan 2021, at 19:42, Eric Avdey wrote: >> >> There is no justification neither here or on the PR for this change, i.e. >> why this is done. Original infinity default was set to preserve previous >> behaviour, this change will inadvertently break workflow for users who >> upload large attachment and haven't set explicit default, so why is it fine >> to do now? There might be some discussion around this somewhere, but it'd be >> nice to include it here for sake of people like me who's out of the loop. >> >> Also 1G limit seems arbitrary - how was it choosen? >> >> >> Thanks, >> Eric >> >> >> >>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát wrote: >>> >>> Hi All, >>> >>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a >>> finite default for max_attachment_size . >>> The PR is approved, but as per Ilya's request, I'd like to call for a >>> lazy majority vote here. >>> The vote will remain open for at least 72 hours from now. >>> >>> Please let me know if you have any questions, comments or concerns. >>> >>> >>> Donat >> >
Re: [VOTE] Set a finite default for max_attachment_size
There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop. Also 1G limit seems arbitrary - how was it choosen? Thanks, Eric > On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát wrote: > > Hi All, > > In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a > finite default for max_attachment_size . > The PR is approved, but as per Ilya's request, I'd like to call for a > lazy majority vote here. > The vote will remain open for at least 72 hours from now. > > Please let me know if you have any questions, comments or concerns. > > > Donat
Re: Jenkins "restart" access available to all committers.
Hi Joan, I didn't realize I was bugging you, sorry about that, I'll make sure to avoid it in the future. Yes, the restart button wasn't available for me right after login into Jenkins and appear with something of an hour of delay and a couple of logout/logins later. I suspect there might be some permissions propagation happening on a background on a first login (I haven't logged in Jenkins for a while), so if anyone else will notice that it might be just a question of waiting a little and try again later. Regards, Eric > On Sep 15, 2020, at 15:00, Joan Touzet wrote: > > Hi there, > > Recently, I believe Eric Avdey (eiri) said that he wasn't able to restart a > Jenkins job. > > I've checked with Infra and they state that anyone with committer access > should be able to restart any job, any stage, or replay a job. > > https://issues.apache.org/jira/browse/INFRA-20851 > > No committer should ever have to bug me, personally (or any PMC member) to > restart a job. > > If you still have problems after logging into Jenkins with your ASF ID, > please reply to this thread. > > Thanks, > Joan
Re: CouchDB 3.0 Weekly Update - Oct.16
I want to volunteer for #2167 I was gunning at it for some time. I’m traveling at the moment, but should be able to start looking into it next Tuesday. Regards, Eric Avdey Sent from my iPhone > On Oct 16, 2019, at 16:54, Denitsa Burroughs > wrote: > > Hi all, > > Thank you to those who helped close out tickets over the past few weeks. We > are down to 5 tickets in the 3.x column and 2 in progress. We are inching > closer but still need volunteers to help out with the remaining work. If > you can help out with any of the outstanding issues, please comment in the > ticket and/or assign it to yourself. > I also want to draw your attention to the 2 tickets that require more > discussion around scope/design. Please add your thoughts to the tickets > and/or the ML threads on those topics so that we can start narrowing down > the scope. > > *2 tickets have a well defined scope - looking for volunteers: * > - 2167 Remove vestiges of view-based `_changes` feed > <https://github.com/apache/couchdb/issues/2167> > - 1524 Per-document access control #1524 > <https://github.com/apache/couchdb/issues/1524> > > *2 of the tickets need more discussion/scope definition/design:* > - 2249 Cluster setup does not create IOQ stats database > <https://github.com/apache/couchdb/issues/2249> > - 2191 Tighten up security model > <https://github.com/apache/couchdb/issues/2191> - Jan working on design > > > *Deprecations/release notes ticket (some action might be required): * > - 2218 Deprecation list for 3.0 (release notes compilation) > <https://github.com/apache/couchdb/issues/2218> > > *In Progress: * > - 1875 Update SpiderMonkey version > <https://github.com/apache/couchdb/issues/1875> (Peng Hui) > - 1523 Retire the node-local interface (port 5986) > <https://github.com/apache/couchdb/issues/1523> (Bob) - ticket needs to be > moved from the 3.0 backlog to In progress > > Thanks, > > Deni
Re: [VOTE] CouchDB Logo - Round #3
Paul Davis: +1 Nick Pavlica #1 (globe): -1 Nick Pavlica #2 (hexagon): -1 Nick Pavlica #3 (geometric): 0 Brad Noble: -1 Sean Barclay #1: -1 Sean Barclay #2: -1 Sean Barclay #3: -1 Apache CouchDB (old logo): +1 Constantin Angheloiu +1 Regards, Eric
