Created this issue. Would like input from more people to ensure this is a
good idea and I'm not overlooking something...
https://issues.apache.org/jira/browse/TC-129
On Tue, Jan 31, 2017 at 10:47 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:
> Yes, when modifying a DS, it would be
Jeremy +1. Unless someone still got a "purge" agent running around the
extra dependancies can be removed. There is no purge going on, just
revalidate.
On Wed, Feb 1, 2017 at 4:57 PM, Jeremy Mitchell
wrote:
> I also created this issue to remove unused job tables if anyone
> On Feb 1, 2017, at 3:21 PM, Leif Hedstrom wrote:
>
> Hi all,
>
> I’ve enabled the Clang analyzer builds for the CI. I’d highly recommend that
> if it fails, you look into why, at least for PRs on master. Unfortunately, I
> haven’t figured out a good way to expose the
Hi all,
I’ve enabled the Clang analyzer builds for the CI. I’d highly recommend that if
it fails, you look into why, at least for PRs on master. Unfortunately, I
haven’t figured out a good way to expose the actual details in some meaningful
way, I’m still working on that. In the mean time, if
Indeed, under these circumstances, further investing in this area seems not
to be very productive.
Thank you Dewayne, both for your answer and further discussing the issue,
Nir
On Tue, Jan 31, 2017 at 11:43 PM, Dewayne Richardson
wrote:
> Hi Nir,
>
> The server hardware tab
I created this issue to account for seed data lost in the transition from
1.8 to 2.0
https://issues.apache.org/jira/browse/TC-126
On Wed, Feb 1, 2017 at 10:26 AM, Jeremy Mitchell
wrote:
> hmmm. i think you've stumbled on a larger issue. the move from 1.8 to 2.0
>
hmmm. i think you've stumbled on a larger issue. the move from 1.8 to 2.0
(master) included the consolidation of migration files into
create_tables.sql file but.some of those migrations represented the
seeding of data (i.e. 2015120800_add_job_status.sql) which would not be
represented in
Indeed I failed to notice that the
file traffic_ops/app/db/migrations/2015120800_add_job_status.sql does
not exist anymore in master,
and the seeds.sql file in master does not contain any insert to a
job-related table to compensate for that.
So the job_agent and job_status tables are empty
I am pretty sure he already said it works in master?
On Wed, Feb 1, 2017 at 8:30 AM, Jeremy Mitchell
wrote:
> So going forward with the master branch (it's too late for 1.8 so your
> workaround will have to suffice), I think 2 lines need to be added to
> seeds.sql so
Hey Nir-
Interesting thought for sure.
Would TM “health changes” (loss of connectivity, BW/loadavg too high) change
the generation count? It seems like the answer is Yes, because the health of a
cache impacts the state of the consistent hash ring.
If so, how do these generation changes get
Hi Eric,
Formalizing the approach you suggested, one may introduce the concept of a
delivery-service configuration "generation" which would be an ordinal
identifier for the a delivery service configuration. A "generation" changes
whenever the remap rule changes or the consistent hash mapping of
11 matches
Mail list logo