Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Nick Vatamaniuc]

Agree, "uuid" is a better name.

On Tue, May 26, 2020 at 2:38 PM Paul Davis  wrote:
>
> We already have the uuid generated. I'd suggest just adding a `uuid`
> field that exposes it.
>
> On Tue, May 26, 2020 at 1:27 PM Nick Vatamaniuc  wrote:
> >
> > Hi everyone,
> >
> > I was wondering if we could expose an "instance_id" field in the top
> > level `/` (db_info) result. The value would be a uuid which is
> > unique for every database instance. That is, if a database is deleted
> > and re-created with the same name, it would have a different
> > "instance_id". [*]
> >
> > We'd get at least 2 benefits from it:
> >
> > 1) Replicator could eventually could be updated to checkpoint on the
> > target only, and thus have a read-only access to the source. Currently
> > we need to checkpoint on the source to account for the case when the
> > source db has been recreated, so we maintain the checkpoint history on
> > the source and the target.
> >
> > 2) User's code might want to know if it the database has been
> > recreated, mostly to avoid mishaps when they continue performing
> > requests against the db with the same, which now may have completely
> > different data in it.
> >
> > What do we think, do we like this idea?
> >
> > Cheers,
> > -Nick
> >
> > [*] Back in 1.x we had the "instance_start_time" field which does
> > mostly same thing, but is based on time. In 2.x and 3.x we still emit
> > that field and for compatibility and hard code it to "0". We could
> > re-use that field, but I think since the idea is to make it a uuid and
> > not a timestamp so it's name doesn't quite match and it would have a
> > different format (64bits vs 128bits).

Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Paul Davis]

We already have the uuid generated. I'd suggest just adding a `uuid`
field that exposes it.

On Tue, May 26, 2020 at 1:27 PM Nick Vatamaniuc  wrote:
>
> Hi everyone,
>
> I was wondering if we could expose an "instance_id" field in the top
> level `/` (db_info) result. The value would be a uuid which is
> unique for every database instance. That is, if a database is deleted
> and re-created with the same name, it would have a different
> "instance_id". [*]
>
> We'd get at least 2 benefits from it:
>
> 1) Replicator could eventually could be updated to checkpoint on the
> target only, and thus have a read-only access to the source. Currently
> we need to checkpoint on the source to account for the case when the
> source db has been recreated, so we maintain the checkpoint history on
> the source and the target.
>
> 2) User's code might want to know if it the database has been
> recreated, mostly to avoid mishaps when they continue performing
> requests against the db with the same, which now may have completely
> different data in it.
>
> What do we think, do we like this idea?
>
> Cheers,
> -Nick
>
> [*] Back in 1.x we had the "instance_start_time" field which does
> mostly same thing, but is based on time. In 2.x and 3.x we still emit
> that field and for compatibility and hard code it to "0". We could
> re-use that field, but I think since the idea is to make it a uuid and
> not a timestamp so it's name doesn't quite match and it would have a
> different format (64bits vs 128bits).

[DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

[Nick Vatamaniuc]

Hi everyone,

I was wondering if we could expose an "instance_id" field in the top
level `/` (db_info) result. The value would be a uuid which is
unique for every database instance. That is, if a database is deleted
and re-created with the same name, it would have a different
"instance_id". [*]

We'd get at least 2 benefits from it:

1) Replicator could eventually could be updated to checkpoint on the
target only, and thus have a read-only access to the source. Currently
we need to checkpoint on the source to account for the case when the
source db has been recreated, so we maintain the checkpoint history on
the source and the target.

2) User's code might want to know if it the database has been
recreated, mostly to avoid mishaps when they continue performing
requests against the db with the same, which now may have completely
different data in it.

What do we think, do we like this idea?

Cheers,
-Nick

[*] Back in 1.x we had the "instance_start_time" field which does
mostly same thing, but is based on time. In 2.x and 3.x we still emit
that field and for compatibility and hard code it to "0". We could
re-use that field, but I think since the idea is to make it a uuid and
not a timestamp so it's name doesn't quite match and it would have a
different format (64bits vs 128bits).

Re: moving email lists to GitHub Discussions (Was: [DISCUSS] moving email lists to Discourse)

[Joan Touzet]

Quick update for those who don't want to read JIRA (you can subscribe to 
the issue, by the way - could use more voices...):


Because the request is to put user support discussions there only for 
now, we aren't strictly required to have email integration with our 
users@ list. That's good!


The bad news is that GitHub Repo Discussions are still in limited beta, 
and we need someone at GH to enable that for our repo.


I have asked Infra to reach out to GH to ask about this, but have zero 
visibility into progress on that.


If I don't see any progress in a week or two, I'll poke them again.

The _good_ news is that if we felt we wanted to move forward with an 
alternative solution - again for user help only, no product decision 
making allowed outside of dev@ / something that cc's to dev@ - we could 
do that. But let's not be too hasty, GH Repo Discussions looks like the 
best match for us and the least long-term maintenance work.


-Joan "less admin == more maintainable" Touzet

On 2020-05-26 10:52, Nick Vatamaniuc wrote:

+1

Thank you, Joan!

On Fri, May 22, 2020 at 2:50 PM Jan Lehnardt  wrote:


Thanks Joan, I’m looking forward to Infra feedback.

Best
Jan
—


On 22. May 2020, at 19:31, Joan Touzet  wrote:

I haven't gotten a lot of feedback on this proposal. (I know a lot of people 
are marching towards deadlines right now.) I also don't want to take it to 
users@, unless there's a reality of it happening.

In the interest of moving this forward, I'm going to open an exploratory issue 
with Infra to see how much work it'd be to make this happen. Hopefully, we're 
not the first people to ask.

We'll still need a vote here, or on users@, before we would actually move 
activity to GH Discussions, but it won't be the gating factor for a while yet, 
I bet.

FYI, per our project guidelines/bylaws, this would be a non-technical decision, 
allowing for lazy consensus and a lazy majority (3 binding +1s, more binding 
+1s than binding -1s), with binding votes cast by committers, and no vetos.

-Joan

On 2020-05-12 14:41, Joan Touzet wrote:

On 2020-05-12 5:46 a.m., Ilya Khlopotov wrote:

I would be +1 as long as it works and we have options to migrate archive 
elsewhere if/when we need to.
You are proposing to mirror email traffic which means that mail archive would 
have a complete history and spare the project from total vendor lock in.


Yup, that'd be a requirement from the ASF's perspective, regardless of 
technology we select.
-Joan

Best regards,
ILYA

On 2020/05/11 19:04:53, Joan Touzet  wrote:

On 2020-03-15 9:36, Dave Cottlehuber wrote:

On Fri, 13 Mar 2020, at 14:35, Naomi Slater wrote:

apparently GitHub has discussions now. it's still in beta, but you can
specifically request it if you want it if you contact support, I think

e.g., https://github.com/zeit/next.js/discussions



interesting.


I'm interested to know what we think about this and how this
might/could fit into our plans for user support, discussion, etc.


Given that we already have email integration with GitHub, this will
probably be easier to get through the ASF bureaucracy than something
brand new.

I'm willing to take this through Infra if people agree to it. It doesn't
look like there are any separate "boards" or tags yet, so the proposal
would likely be that discussions there would get emailed onto user@. The
hard part will be getting replies to the thread on user@ to go back into
the discussion on GH; we might be able to get an "asf-bot" to do this
for us.

I also looked at Infra's JIRA database, and no one has put in this
request there yet. So, we'd be the first, with all the difficulties that
entails.

Can I get an informal "vote" on this approach and go-ahead? Since it's
informal, anyone is encouraged to respond.

-Joan "adopt, adapt, improve" Touzet

Re: moving email lists to GitHub Discussions (Was: [DISCUSS] moving email lists to Discourse)

[Nick Vatamaniuc]

+1

Thank you, Joan!

On Fri, May 22, 2020 at 2:50 PM Jan Lehnardt  wrote:
>
> Thanks Joan, I’m looking forward to Infra feedback.
>
> Best
> Jan
> —
>
> > On 22. May 2020, at 19:31, Joan Touzet  wrote:
> >
> > I haven't gotten a lot of feedback on this proposal. (I know a lot of 
> > people are marching towards deadlines right now.) I also don't want to take 
> > it to users@, unless there's a reality of it happening.
> >
> > In the interest of moving this forward, I'm going to open an exploratory 
> > issue with Infra to see how much work it'd be to make this happen. 
> > Hopefully, we're not the first people to ask.
> >
> > We'll still need a vote here, or on users@, before we would actually move 
> > activity to GH Discussions, but it won't be the gating factor for a while 
> > yet, I bet.
> >
> > FYI, per our project guidelines/bylaws, this would be a non-technical 
> > decision, allowing for lazy consensus and a lazy majority (3 binding +1s, 
> > more binding +1s than binding -1s), with binding votes cast by committers, 
> > and no vetos.
> >
> > -Joan
> >
> > On 2020-05-12 14:41, Joan Touzet wrote:
> >> On 2020-05-12 5:46 a.m., Ilya Khlopotov wrote:
> >>> I would be +1 as long as it works and we have options to migrate archive 
> >>> elsewhere if/when we need to.
> >>> You are proposing to mirror email traffic which means that mail archive 
> >>> would have a complete history and spare the project from total vendor 
> >>> lock in.
> >>>
> >> Yup, that'd be a requirement from the ASF's perspective, regardless of 
> >> technology we select.
> >> -Joan
> >>> Best regards,
> >>> ILYA
> >>>
> >>> On 2020/05/11 19:04:53, Joan Touzet  wrote:
>  On 2020-03-15 9:36, Dave Cottlehuber wrote:
> > On Fri, 13 Mar 2020, at 14:35, Naomi Slater wrote:
> >> apparently GitHub has discussions now. it's still in beta, but you can
> >> specifically request it if you want it if you contact support, I think
> >>
> >> e.g., https://github.com/zeit/next.js/discussions
> >> 
> >
> > interesting.
> >
> >> I'm interested to know what we think about this and how this
> >> might/could fit into our plans for user support, discussion, etc.
> 
>  Given that we already have email integration with GitHub, this will
>  probably be easier to get through the ASF bureaucracy than something
>  brand new.
> 
>  I'm willing to take this through Infra if people agree to it. It doesn't
>  look like there are any separate "boards" or tags yet, so the proposal
>  would likely be that discussions there would get emailed onto user@. The
>  hard part will be getting replies to the thread on user@ to go back into
>  the discussion on GH; we might be able to get an "asf-bot" to do this
>  for us.
> 
>  I also looked at Infra's JIRA database, and no one has put in this
>  request there yet. So, we'd be the first, with all the difficulties that
>  entails.
> 
>  Can I get an informal "vote" on this approach and go-ahead? Since it's
>  informal, anyone is encouraged to respond.
> 
>  -Joan "adopt, adapt, improve" Touzet
> 
>