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 u
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 feels so
> inclined:
>
>
> 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 actual details in some
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 a
I also created this issue to remove unused job tables if anyone feels so
inclined:
https://issues.apache.org/jira/browse/TC-128
On Wed, Feb 1, 2017 at 10:52 AM, Jeremy Mitchell
wrote:
> I created this issue to account for seed data lost in the transition from
> 1.8 to 2.0
>
> https://issues.apa
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 we plan on removing e
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
> (master) included the consolid
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 c
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 afte
It works IF he does a manual insert into the job_agent table and it so
happens in master that insert is assigned an id of 1. Is that correct,
Oren? If so, I don't "think" imo you should have to do any manual inserts
but i suppose that can be debated. I'll leave it alone and if anyone thinks
the job
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 invalidate content works on
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 invalidate content works on a fresh install:
- an insert into the job_agent table (so a job agent with id=1 exists)
- an insert into the the job
As for the release notes, since Dan is our release manager, I would get
them over to him.
On Wed, Feb 1, 2017 at 8:11 AM, Oren Shemesh wrote:
> Thanks Jeremy :-)
>
> On Wed, Feb 1, 2017 at 5:09 PM, Jeremy Mitchell
> wrote:
>
> > I don't think jobs are ever programmatically removed from the jobs
Thanks Jeremy :-)
On Wed, Feb 1, 2017 at 5:09 PM, Jeremy Mitchell
wrote:
> I don't think jobs are ever programmatically removed from the jobs table
> nor are their statuses changed. They always remain in a pending state.
>
> SELECT COUNT(*) FROM job WHERE status NOT IN ( SELECT id FROM job_statu
I don't think jobs are ever programmatically removed from the jobs table
nor are their statuses changed. They always remain in a pending state.
SELECT COUNT(*) FROM job WHERE status NOT IN ( SELECT id FROM job_status
WHERE name = 'PENDING' )
0
Like I mentioned earlier, I think there was a lot mor
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 co
Thanks for your replies and the information :-)
Dave, Is there a place I can document a work-around for being included in
the release notes of 1.8 ?
My suggested work-around would be fixing the create_tables.sql script
before running 'postinstall'. (I have a nice awk command that does it).
And a
18 matches
Mail list logo
