I feel like we discussed this and agreed that moving forward tenancy should
no longer be optional in TP/TO but I can't find the email so maybe it was
just a dream. :) (fyi at Comcast, we've been using tenancy for over 1.5
years i think)
Currently, you can toggle tenancy on/off using a parameter (u
+1 down with optional tenancy.
Changes in Go would be similar I think - just remove the check for enabled
tenancy and the code that handles the disabled case.
(I'd also like to submit for consideration the idea of re-writing Perl
endpoints instead of updating them)
__
> we discussed this and agreed that moving forward tenancy should no longer
be optional in TP/TO but I can't find the email
I think it's this discussion, subject "Enforcing capability rules"
https://lists.apache.org/thread.html/57e2ea49fe27a14e6be06b8d8d8e9608dd8db5a671a5a47c1905f2f8@%3Cdev.traffi
I believe we essentially agreed to make tenancy required in 3.0 (and
have done so via a DB migration), but there is still a dependency on
the use_tenancy parameter in the codebase. So until we can go through
and fix all those places that check the use_tenancy parameter, we
can't really get rid of i
> Not sure what's required in the Go to ensure that tenancy can't be turned
off.
And yes, it's pretty easy in Go, too. Just a matter of removing those query
bits, and calls to IsTenancyEnabled.
On Tue, Jan 8, 2019 at 10:09 AM Rawlin Peters
wrote:
> I believe we essentially agreed to make tenan
So it sounds like from Go remove calls to IsTenancyEnabled() and from Perl
remove calls to use_tenancy() and maybe a migration to delete the
use_tenancy parameter and then it's no longer optional. Also, Rob and I
discussed on the side and this would not have to wait for
roles/capabilities.
Jeremy
Can anybody think of a reason why the ATC 3.x docs should include the pages for
migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for version X.y
should include instructions that pertain to version X - so an upgrade from X-1
to X would be fine, but from X-1.y to X-1.y+z doesn't really m
makes perfect sense to me
On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan
wrote:
> Can anybody think of a reason why the ATC 3.x docs should include the
> pages for migrating from 1.x to 2.x or from 2.0 to 2.2? IMO the docs for
> version X.y should include instructions that pertain to version X -
Submit a PR to remove them. Anything < 2.2 is not officially supported
anyway.
On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell
wrote:
> makes perfect sense to me
>
> On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan
> wrote:
>
> > Can anybody think of a reason why the ATC 3.x docs should include the
+1, old docs will always be available in the old releases if they
still need to be referenced. In general I think that should be a
documentation guideline for the project, so that whenever we cut a
release branch we can (and should) freely remove documentation from
master that does not pertain to w
I would consider keeping a footnote somewhere that outlines any upgrade
sequence requirements such as 1.0 -> 1.12 -> 2.0 -> 2.21 -> 3.0. Mostly just
so that if you do find yourself inheriting an antique setup that must be
maintained in place you know how many hops you should be looking for. Th
11 matches
Mail list logo
