Re: Traffic Ops UI Deprecation in favor of Traffic Portal

[Jason Tucker]

Jeremy - I realized I never submitted the follow-up issue for the bulk
delete of parameters, so I just opened it now:
https://github.com/apache/incubator-trafficcontrol/issues/1969

Right now, this is something that can only be done through the legacy UI
(or, via the DB directly). I think we should have it before the legacy UI
goes away.

__Jason

On Tue, Mar 6, 2018 at 10:38 PM, Rawlin Peters 
wrote:

> Thanks, Jeremy. I'd like to add that all new features don't
> necessarily need to be added to the old Traffic Ops UI. That precedent
> has already been set with features like Delivery Service Cloning and
> URI Signing which are only available in Traffic Portal as of today,
> and I think that's perfectly acceptable given the plan to deprecate
> the old Traffic Ops UI in the near future.
>
> I'm not sure if we need to formalize this with a vote or not because
> the precedent is already set, but I'd say we should continue to fix
> things like bugs and security issues but not add new
> features/enhancements to the old Traffic Ops UI. This should reduce
> the burden of shipping new features in Traffic Control while we're in
> this stage of having two different UIs.
>
> - Rawlin
>
> On Tue, Mar 6, 2018 at 3:12 PM, Jeremy Mitchell 
> wrote:
> > At last year's TC summit, we discussed the deprecation of the TO UI in
> > favor of the Traffic Portal.
> >
> > Now that TP has almost achieved feature parity with the TO UI, that day
> is
> > coming soon.
> > Here are 2 issues I know that need to be complete to achieve feature
> parity:
> >
> > https://github.com/apache/incubator-trafficcontrol/issues/1616
> > https://github.com/apache/incubator-trafficcontrol/issues/1287
> >
> > Deprecation may mean simply deleting traffic_ops/app/public/ for 2.3 (or
> > 3.x). Or maybe it means something else. Not sure yet.
> >
> > But the point is, if you want to ensure that all new UI features that you
> > build live past 2.3 (or 3.x), please be sure to put those features in TP.
> > Reach out to me if you need help with TP.
> >
> > Jeremy
>

Re: [VOTE] Traffic Control graduation to TLP

[Jason Tucker]

+1

On Thu, Mar 1, 2018 at 6:32 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> +1 for graduation
> > On Mar 1, 2018, at 12:13 PM, Jan van Doorn  wrote:
> >
> > +1
> >
> > On Thu, Mar 1, 2018 at 9:38 AM Chris Lemmons  wrote:
> >
> >> The Traffic Control project has grown so much over the last year, it's
> >> incredible.
> >>
> >> +1
> >>
> >> On Thu, Mar 1, 2018 at 9:33 AM, Gelinas, Derek
> >>  wrote:
> >>> +1
> >>>
>  On Mar 1, 2018, at 10:41 AM, Dave Neuman  wrote:
> 
>  Hey All,
> 
>  After a great discussion amongst the Apache Traffic Control PPMC,
> >> reviewing
>  the graduation checklist[1], updating the podling status page[2], and
>  updating the project website to ensure the whimsy podling website
> checks
>  pass[3], I would like to call a vote for Apache Traffic Control
> >> graduating
>  to a top level project.
> 
>  Apache Traffic Control entered the incubator on July 12, 2016.  Since
> >> then
>  we have announced 4 releases, nominated 4 new committers, organized 3
>  summits, had almost 8,000 commits from 63 different contributors, and
> --
>  most importantly -- we have grown and diversified our community.
> Apache
>  Traffic Control is a healthy project that is already acting like an
> >> Apache
>  top level project, so we should take the next step.
> 
>  If we agree that we should graduate to a top level project, the next
> >> steps
>  will be to pick the initial PMC chair for the TLP and draft a
> Resolution
>  for the PPMC and IPMC to vote upon.
> 
>  Please take a minute to vote on wheter or not Traffic Control should
>  graduate to a Top Level Project by responding with one of the
> following:
> 
>  [ ] +1 Apache Traffic Control should graduate.
>  [ ] +0 No opinion
>  [ ] -1 Apache Traffic Control should not graduate (please provide the
>  reason)
> 
>  The VOTE will be opened for at least the next 72 hours.  Per Apache
>  guidelines[4] I will also be notifying the incubator mailing list
> that a
>  community vote is under way.
> 
>  Thanks,
>  Dave
> 
> 
>  [1]
> 
> >> https://incubator.apache.org/guides/graduation.html#
> graduation_check_list
>  [2] http://incubator.apache.org/projects/trafficcontrol.html
>  [3] https://whimsy.apache.org/pods/project/trafficcontrol
>  [4]
> 
> >> https://incubator.apache.org/guides/graduation.html#
> community_graduation_vote
> >>>
> >>
>
>

Re: Github PR/Issues Format Templates

[Jason Tucker]

+1 on issue template.
The ansible project uses a template, and it also works in conjunction with
a bot ("ansibot") that automatically links the issue to the associated
module source, if it can, which is handy.
For example, an issue I recently opened there:
https://github.com/ansible/ansible/issues/36557 showing the ansibot
reference...

__Jason

On Wed, Feb 28, 2018 at 5:14 PM, Jeremy Mitchell 
wrote:

> Chris, I really wanted the PR template to be less daunting and super short
> and to the point. It's intention is to give a super quick summary of what's
> included in this PR to help the merger...
>
> Example:
>
>  What does this PR do? Is there a related Github issue?
>
> "See Issue #1245" or "This PR cascade deletes all delivery service regexes
> when a delivery service is deleted"
>
>  What is the best way to verify this PR? <-- IMO this is really
> important for the merger so I know how to "test" or "verify" the
> functionality.
>
> Hit the DELETE /api/1.3/deliveryservices/:id endpoint and ensure all
> entries in the deliveryservice_regex table are deleted for that delivery
> service.
>
>  Does your PR include any of the following?
>
> - [ ] Tests
> - [ ] Documentation
> - [X] CHANGELOG.md entry
>
> ^^ I wasn't trying to imply that those last things were required. I just
> wanted to provide a checklist that might be helpful for the contributer and
> the merger. For example, I always for get to look for a CHANGELOG.md
> entry...
>
> Jeremy
>
>
> On Tue, Feb 27, 2018 at 9:47 PM, Chris Lemmons  wrote:
>
> > If there's a relevant GitHub issue, that should be noted in the
> > check-in comment, I think. Same for "what does it do?" I don't usually
> > want to spell out steps for someone to verify my stuff because those
> > are the steps that I took to verify it. The PR is so you can see the
> > things I didn't see. And the commit list will make the presence of
> > tests, documentation, and a changelog entry really obvious.
> >
> > Taking yours and reformatting a bit, what if we did something like this?
> >
> > ...
> >
> > *Describe your PR:* _(copy/paste from changeset comments is encouraged!)_
> >
> >
> >
> > *Quick Checklist:*
> >
> > - [ ] Each commit message tells you everything you need to know about
> > the change. (Squashing can help with this.)
> > - [ ] If applicable, the commit message mentions the appropriate issue
> > number.
> > - [ ] This PR does *not* fix a serious security flaw. (Read more:
> > www.apache.org/security )
> > - [ ] Automatic code formatters (like gofmt) have been run.
> >
> > *Tests:*
> >
> > - [ ] Are not necessary.
> > - [ ] Would be helpful, but aren't in this PR.
> > - [ ] Are present, but incomplete.
> > - [ ] Are included.
> >
> > *Doc updates:*
> >
> > - [ ] Are not necessary.
> > - [ ] Would be helpful, but aren't in this PR.
> > - [ ] Are present, but incomplete.
> > - [ ] Are included.
> >
> > *If there's no update to CHANGELOG.md, why not?*
> >
> > *Does this break backward compatibility?*
> >
> > *Is there anyone specific that ought to take a look at this?*
> >
> > ...
> >
> > We want to be friendly to committers, while still getting good
> > information for checking PRs. I could be easily convinced that the
> > "Tests" or "Doc updates" sections in there are too long, but I think
> > it should be clear that a potential committer can offer up some code
> > without hitting 100% on tests, docs, and such.
> >
> > On Tue, Feb 27, 2018 at 1:24 PM, Jeremy Mitchell 
> > wrote:
> > > How about something like this for a PR template?
> > >
> > >  What does this PR do? Is there a relevant Github issue?
> > >
> > >
> > >  What is the best way to verify this PR?
> > >
> > >
> > >  Does your PR include any of the following?
> > >
> > > - [ ] Tests
> > > - [ ] Documentation
> > > - [ ] CHANGELOG.md entry
> > >
> > > On Tue, Feb 27, 2018 at 10:46 AM, Jeremy Mitchell <
> mitchell...@gmail.com
> > >
> > > wrote:
> > >
> > >> With an issue and/or pr template, we will have 6/6 items checked:
> > >>
> > >> https://github.com/apache/incubator-trafficcontrol/community
> > >>
> > >> I actually think PR templates would be quite helpful. As a
> > >> committer/merger, it would be nice to know what problem the PR is
> > solving
> > >> and how to verify the functionality. A PR template could also help
> > >> contributors ensure that their PRs are complete. I.e. does this PR
> > includes
> > >> tests, documentation, etc.
> > >>
> > >> I'll take a stab at a couple of templates and run them by the group.
> > >>
> > >> Jeremy
> > >>
> > >> On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons 
> > wrote:
> > >>
> > >>> I'm +1 on Issue Templates, for sure. I don't know that PR templates
> > >>> are quite as critical, but it might be nice to have a reminder in
> > >>> there about verifying that the changelog is updated if necessary and
> > >>> documentation for new features is present. If the PR 

Re: [VOTE] Bugtracking in Github Issues

[Jason Tucker]

+1

On Mon, Aug 28, 2017 at 4:43 PM, Jan van Doorn  wrote:

> +1
>
> On Mon, Aug 28, 2017 at 10:38 AM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > We currently use JIRA Issues to track all of the Traffic Control bugs.
> >
> > Now that we have write access to Github, we can move back to GH Issues
> for
> > bug tracking.
> >
> > This will be a better workflow because its one fewer tool and account to
> > have to interact with. This will hopefully lower the bar for new
> > contributors to file bugs and engage with the product. We can also help
> use
> > it (along with the milestones) to create more useful changelogs and
> release
> > notes.
> >
> > A possible downside is that the Issues are maybe less flexible than JIRA
> > in terms of permissions, workflow, fields, etc. However, we were using
> > Issues before we entered the incubator and that was fine for us.
> Hopefully
> > no one has developed an attachment for JIRA in the last year.
> >
> >
> > Please Vote +1 to move to Github Issues or -1 to stay on Jira. I’ll
> assume
> > a lazy consensus if there aren’t enough votes.
> >
> > —Eric
> >
> >
> >
>

Re: traffic_router tomcat init script (shutdown) problems

[Jason Tucker]

I don't know if we've experienced problems with stopping traffic_monitor in
the past, but it certainly has the potential to have the same problem. The
only real difference between those two files was the CATALINA_OPTS variable
values (and also license header?)

I have an updated script for traffic_monitor here:

https://github.com/guzzijason/incubator-trafficcontrol/commit/7631f81ea754bbe0f63ac77120df5686c2310dd6

I can PR that if folks feel there is a need.

__Jason

On Wed, Jul 12, 2017 at 1:39 PM, Steve Malenfant <smalenf...@gmail.com>
wrote:

> Does Traffic Monitor (Java version) have the same problem? If it does, can
> the fix be applied?
>
> On Wed, Jul 12, 2017 at 12:43 PM, Jason Tucker <jasonwtuc...@gmail.com>
> wrote:
>
>> Thanks, Jeff.
>>
>> And just to clarify - this will *try* to do a graceful shutdown first,
>> wait
>> for the timeout period (10 seconds) and then force it if that was
>> unsuccessful. The previous behavior was to wait for 5 seconds, and then
>> give up entirely.
>>
>> We'll have to take another look at this when we move to a newer tomcat
>> package. I have some ideas on how to improve this further - like switching
>> to a systemd unit rather than init script for el7, and putting tunables in
>> an external config (i.e. /etc/sysconfig/tomcat) like the tomcat RPMs
>> generally do.
>>
>> __Jason
>>
>> On Wed, Jul 12, 2017 at 11:44 AM, Jeff Elsloo <els...@apache.org> wrote:
>>
>> > I discussed this with Jason, reviewed the PR and will be merging it
>> > soon unless someone has concerns. I asked specifically about "force"
>> > being the default shutdown mode, and that was done intentionally.
>> > There might be a use case for a graceful shutdown with typical
>> > applications deployed into Tomcat, but Traffic Router does not service
>> > any long running sessions, so getting it shut down quickly is actually
>> > desired.
>> >
>> > We can use this new init script and make changes as necessary in the
>> > future, but this should be an improvement. Hopefully we won't have to
>> > `kill -9 ` anymore.
>> > --
>> > Thanks,
>> > Jeff
>> >
>> >
>> > On Tue, Jul 11, 2017 at 3:37 PM, Jason Tucker <jasonwtuc...@gmail.com>
>> > wrote:
>> > > FYI - opened ticket and PR for this issue:
>> > >
>> > > The tomcat init script has a few problems:
>> > >
>> > > 1. "Clean" shutdowns frequently timeout, and the scripts give up,
>> leaving
>> > > tomcat running
>> > >
>> > > 2. Normal tomcat shutdown actually involves spinning up a second jvm
>> > > instance. Right now, we start this second instance with the same
>> > > CATALINA_OPTS as traffic_router, which can be problematic on
>> > > memory-constrained hosts.
>> > >
>> > > https://issues.apache.org/jira/browse/TC-416
>> > > https://github.com/apache/incubator-trafficcontrol/pull/724
>> > >
>> > > Thanks,
>> > >
>> > > _Jason
>> >
>>
>
>

Re: traffic_router tomcat init script (shutdown) problems

[Jason Tucker]

Thanks, Jeff.

And just to clarify - this will *try* to do a graceful shutdown first, wait
for the timeout period (10 seconds) and then force it if that was
unsuccessful. The previous behavior was to wait for 5 seconds, and then
give up entirely.

We'll have to take another look at this when we move to a newer tomcat
package. I have some ideas on how to improve this further - like switching
to a systemd unit rather than init script for el7, and putting tunables in
an external config (i.e. /etc/sysconfig/tomcat) like the tomcat RPMs
generally do.

__Jason

On Wed, Jul 12, 2017 at 11:44 AM, Jeff Elsloo <els...@apache.org> wrote:

> I discussed this with Jason, reviewed the PR and will be merging it
> soon unless someone has concerns. I asked specifically about "force"
> being the default shutdown mode, and that was done intentionally.
> There might be a use case for a graceful shutdown with typical
> applications deployed into Tomcat, but Traffic Router does not service
> any long running sessions, so getting it shut down quickly is actually
> desired.
>
> We can use this new init script and make changes as necessary in the
> future, but this should be an improvement. Hopefully we won't have to
> `kill -9 ` anymore.
> --
> Thanks,
> Jeff
>
>
> On Tue, Jul 11, 2017 at 3:37 PM, Jason Tucker <jasonwtuc...@gmail.com>
> wrote:
> > FYI - opened ticket and PR for this issue:
> >
> > The tomcat init script has a few problems:
> >
> > 1. "Clean" shutdowns frequently timeout, and the scripts give up, leaving
> > tomcat running
> >
> > 2. Normal tomcat shutdown actually involves spinning up a second jvm
> > instance. Right now, we start this second instance with the same
> > CATALINA_OPTS as traffic_router, which can be problematic on
> > memory-constrained hosts.
> >
> > https://issues.apache.org/jira/browse/TC-416
> > https://github.com/apache/incubator-trafficcontrol/pull/724
> >
> > Thanks,
> >
> > _Jason
>

traffic_router tomcat init script (shutdown) problems

[Jason Tucker]

FYI - opened ticket and PR for this issue:

The tomcat init script has a few problems:

1. "Clean" shutdowns frequently timeout, and the scripts give up, leaving
tomcat running

2. Normal tomcat shutdown actually involves spinning up a second jvm
instance. Right now, we start this second instance with the same
CATALINA_OPTS as traffic_router, which can be problematic on
memory-constrained hosts.

https://issues.apache.org/jira/browse/TC-416
https://github.com/apache/incubator-trafficcontrol/pull/724

Thanks,

_Jason

Re: Using a full-chain SSL certificate For a Delivery Service.

[Jason Tucker]

I've got a quick-n-dirty bash/keytool script script here that I like to use
to verify the cert chain order:

https://gist.github.com/guzzijason/026998189b0a57ef0ba2a05d1baf966a

__Jason

On Tue, May 23, 2017 at 4:22 PM, Jeff Elsloo <els...@apache.org> wrote:

> It should be noted that you might need to use an external tool of some
> sort to order and verify the certificate chain properly. I believe
> that's what we did when we ran into the problem.
> --
> Thanks,
> Jeff
>
>
> On Tue, May 23, 2017 at 10:05 AM, Jason Tucker <jasonwtuc...@gmail.com>
> wrote:
> > +1 to what Dave said. A full cert chain shouldn't be a problem in Traffic
> > Ops. Best to make sure server cert is at the top of the chain, and the
> rest
> > of the certs are below, in order, with the CA cert last.
> >
> > __Jason
> >
> > On Tue, May 23, 2017 at 2:15 PM, Dave Neuman <neu...@apache.org> wrote:
> >
> >> Hey Oren,
> >> Yes you can enter an externally created, full-chain certificate in
> Traffic
> >> Ops; we do this all the time.  You shouldn't need to do anything special
> >> besides make sure that the certificate chain is in the correct order.  I
> >> think you need to have the server (wildcard first) then the
> intermediates,
> >> then the root block.  If that doesn't work, I would try reversing the
> >> order.
> >>
> >> --Dave
> >>
> >> On Tue, May 23, 2017 at 4:45 AM, Oren Shemesh <or...@qwilt.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > After creating a DS which supports SSL, and using an official
> certificate
> >> > created by GoDaddy (As opposed to a self-signed certificate generated
> by
> >> > Ops), we ran into the following issue:
> >> >
> >> > An SSL scan from https://www.ssllabs.com/ssltest , done on
> >> > tr.., complained about the fact that the server's
> >> > certificate chain is incomplete.
> >> > (Do try this tool on your servers, you might find the results
> >> interesting)
> >> >
> >> > I tried pasting the full certificate chain (Made from four blocks,
> each
> >> > marked with "-BEGIN CERTIFICATE-" and "-END
> CERTIFICATE-"
> >> > lines) into Ops, but this made the traffic router's situation worse:
> It
> >> > consumed the certificate chain with no problem, but now it presents a
> >> > certificate for GoDaddy, instead of a certificate for *
> >> > ...
> >> > So, I guess that when pasting a certificate for a DS via Ops, it only
> >> uses
> >> > the first block in the chain.
> >> >
> >> > A quick check with tomcat documentation shows that in order for it to
> >> > present a full-chain certificate, two different 'keytool -import'
> >> commands
> >> > should be used, one for the 'root' and another for the 'server'  (See
> >> > https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#
> >> > Importing_the_Certificate
> >> > ).
> >> > This might explain the problem: Given the current Ops GUI, I am
> entering
> >> a
> >> > chain of certificates in one block of text, using it as if it is a
> >> 'server'
> >> > certificate, instead of breaking it into a 'root' and a 'server'
> >> > certificate.
> >> >
> >> > So after all this, here is my question:
> >> >
> >> > Is there a way to use an externally-created, full-chain certificate,
> in
> >> > Traffic Ops ?
> >> >
> >> > Thanks a lot, Oren.
> >> >
> >> > --
> >> >
> >> > *Oren Shemesh*
> >> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 |
> or...@qwilt.com
> >> > <y...@qwilt.com>
> >> >
> >>
>

Re: Using a full-chain SSL certificate For a Delivery Service.

[Jason Tucker]

+1 to what Dave said. A full cert chain shouldn't be a problem in Traffic
Ops. Best to make sure server cert is at the top of the chain, and the rest
of the certs are below, in order, with the CA cert last.

__Jason

On Tue, May 23, 2017 at 2:15 PM, Dave Neuman  wrote:

> Hey Oren,
> Yes you can enter an externally created, full-chain certificate in Traffic
> Ops; we do this all the time.  You shouldn't need to do anything special
> besides make sure that the certificate chain is in the correct order.  I
> think you need to have the server (wildcard first) then the intermediates,
> then the root block.  If that doesn't work, I would try reversing the
> order.
>
> --Dave
>
> On Tue, May 23, 2017 at 4:45 AM, Oren Shemesh  wrote:
>
> > Hi,
> >
> > After creating a DS which supports SSL, and using an official certificate
> > created by GoDaddy (As opposed to a self-signed certificate generated by
> > Ops), we ran into the following issue:
> >
> > An SSL scan from https://www.ssllabs.com/ssltest , done on
> > tr.., complained about the fact that the server's
> > certificate chain is incomplete.
> > (Do try this tool on your servers, you might find the results
> interesting)
> >
> > I tried pasting the full certificate chain (Made from four blocks, each
> > marked with "-BEGIN CERTIFICATE-" and "-END CERTIFICATE-"
> > lines) into Ops, but this made the traffic router's situation worse: It
> > consumed the certificate chain with no problem, but now it presents a
> > certificate for GoDaddy, instead of a certificate for *
> > ...
> > So, I guess that when pasting a certificate for a DS via Ops, it only
> uses
> > the first block in the chain.
> >
> > A quick check with tomcat documentation shows that in order for it to
> > present a full-chain certificate, two different 'keytool -import'
> commands
> > should be used, one for the 'root' and another for the 'server'  (See
> > https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#
> > Importing_the_Certificate
> > ).
> > This might explain the problem: Given the current Ops GUI, I am entering
> a
> > chain of certificates in one block of text, using it as if it is a
> 'server'
> > certificate, instead of breaking it into a 'root' and a 'server'
> > certificate.
> >
> > So after all this, here is my question:
> >
> > Is there a way to use an externally-created, full-chain certificate, in
> > Traffic Ops ?
> >
> > Thanks a lot, Oren.
> >
> > --
> >
> > *Oren Shemesh*
> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | or...@qwilt.com
> > 
> >
>

Re: [VOTE] Move Traffic Control to full GitHub

[Jason Tucker]

+1

On Fri, May 19, 2017 at 1:41 PM, Dremin, Sergey 
wrote:

> +1
>
> On 5/18/17, 2:32 PM, "Jan van Doorn"  wrote:
>
> In
> https://lists.apache.org/thread.html/5bdb9b073343f49c1d5b85147eb9d2
> 60bf7ad15d61384929993c7e1d@%3Cdev.trafficcontrol.apache.org%3E
> Dave
> mentioned that we can now move to "full" GitHub. Some more information
> in
> that thread if you are not familiar. I would like to call an official
> vote
> on that.
>
> This vote will be open for at least 72 hours.
>
>  [ ] +1 Move Traffic Control to use full GitHub
>  [ ]  0 No opinion
>  [ ] -1 Do not Move Traffic Control to use full GitHub because...
>
> Rgds,
> JvD
>
>
>