You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID> on 2019/04/10 21:55:58 UTC
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Why can’t the form wizards and other self-service features be built into the existing AngularJS Traffic Portal code?
—Eric
> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com> wrote:
>
> I think I agree with Chris about just using the "experimental" folder as we
> always have. Then it's pretty easy to look in there and see what's
> "cooking":
>
> experimental
> - traffic_router_golang
> - traffic-portal-angular7
> - traffic_ops_ruby_on_rails (just kidding :) )
>
> Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences
> for TP:
>
> 1. Admin/ops type users
> 2. self-service type users
>
> TP works well for #1 but not really for #2. The trick is to build a UI that
> works well for both OR have 2 distinct UIs. As developers, we don't like
> the idea of 2 UIs as that sounds like double the UI work when something
> changes.
>
> So we could either:
>
> a. make TP (angularJS) more self-service friendly
> b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and
> such) and focus on ds, user and tenant management and then slowly port the
> rest of TP functionality into it
> c. support 2 distinct UIs
>
> I think "b" makes sense and the effort can start (as many of our efforts
> do) as "experimental" and if it gets legs maybe it does replace TP or maybe
> it doesn't and it simply becomes a UI that you can use (or not use) to
> solve ds/user/tenant management in a simple/self-service type way.
>
> Jeremy
>
> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com> wrote:
>
>>> Are we seriously considering totally re-writing another component?
>>
>> Depends how you count it. One of the most important parts of the
>> previous re-write (still in progress) is the "separation of powers"
>> that makes things like this relatively non-destructive and able to be
>> managed in parallel. I like experimental pokes into what the future
>> might hold, like this one. I'm not totally sold, but the scope isn't
>> crazy. It's mostly a UI on top of the existing API.
>>
>> Historically, experimental or alternate components have lived in the
>> main branch, but the experimental folder. That lets them be part of
>> the same process as the rest of the code, ensures code reviews as they
>> progress, and the CI will keep everything in license compliance.
>>
>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
>> <Br...@comcast.com> wrote:
>>>
>>> Branching is fine with me, I doubt I have permission to create a branch
>> myself, though.
>>>
>>> As an aside based on that: should `traffic_router_golang` also be moved
>> to a branch? I think the branch idea is better than having an
>> `experimental` directory. Or maybe that experiment is dead and should just
>> be removed instead? The last change was 10 months ago.
>>> ________________________________________
>>> From: Gray, Jonathan <Jo...@comcast.com>
>>> Sent: Wednesday, April 10, 2019 9:09 AM
>>> To: dev@trafficcontrol.apache.org
>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>> Self-Service
>>>
>>> Instead of merging it into master, could we merge it to a feature branch
>> like `experimental/TP.rewrite` if there is a desire for collaborative
>> efforts. This would allow changes to flow in without adding more code to
>> our normal review processes and polluting the changelog with WIP until it's
>> done and ready to be merged. As an additional bonus it provides a more
>> stable development for the new work since you'd be choosing when to pay the
>> merge costs of ongoing master changes.
>>>
>>> Jonathan G
>>>
>>>
>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
>> wrote:
>>>
>>> I guess that depends what you mean by "we". I personally think it's
>> worthwhile, and I'll probably keep working on it until it reaches feature
>> parity with the existing TP.
>>>
>>> I'm not saying development on the existing AngularJS-based TP should
>> stop in the meantime, just that self-service be implemented separately in a
>> more modern and flexible framework. Then - and only then - should we
>> consider replacing the old TP with the new. Slowly, over time. The current
>> TP was built for admins, so I don't think it'd actually be more work to
>> implement a customer-facing interface this way than restructuring the
>> existing TP to support it.
>>> ________________________________________
>>> From: Hank Beatty <hb...@apache.org>
>>> Sent: Wednesday, April 10, 2019 8:38 AM
>>> To: dev@trafficcontrol.apache.org
>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>> Self-Service
>>>
>>> Hello,
>>>
>>> Are we seriously considering totally re-writing another component?
>>>
>>> -Hank
>>>
>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
>>>> Some of you may have heard, but about two and a half weeks ago I
>> opened a Pull Request to add something to the `/experimental` directory.
>> It's basically a re-implementation of Traffic Portal, which I think is
>> beneficial not only because Traffic Portal wasn't designed with
>> self-service in mind, but also because it cleans up a few issues on the
>> development side. First of all, it uses the most recent LTS version of
>> Angular, while the one on which Traffic Portal is currently based is now
>> deprecated (this new version can also compile projects for Electron, which
>> would make TP distributable as a standalone/mobile app). It also uses
>> Typescript which compiles more cleanly to an overall smaller product, and
>> is much easier to read, write and document. Remember the SCSS compiler
>> issues (compass) we keep having? Angular 7 comes with a compiler at project
>> init, so we never need that as an externally-provided dependency again.
>> Finally, it already has unit testing and end-to-end testing working in four
>> different JS engines.
>>>>
>>>>
>>>> I'm currently looking for a reviewer (
>> https://github.com/apache/trafficcontrol/pull/3419) and you can read more
>> about what's implemented there, but a short summary:
>>>>
>>>>
>>>> * Login/authentication and API proxy
>>>> * Delivery Service view with bandwidth charts
>>>> * New Delivery Service creation targeted at self-service users
>> with limited advanced editing options
>>>>
>>>> * User listing (read-only)
>>>>
>>>> * Preliminary HTTPS support (currently only listens on 'localhost')
>>>>
>>>>
>>>> Plus, if I do say so myself, it all looks pretty snappy on every
>> screen I could test.
>>>>
>>>>
>>>> Feedback is also appreciated, especially concerning the "New
>> Delivery Service" form.
>>>>
>>>
>>>
>>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Jeremy Mitchell <mi...@gmail.com>.
+1 to experimental for the reasons Rob and Chris mentioned
I'll wait a bit and if i hear no objections, I'll merge this to the
experimental directory: https://github.com/apache/trafficcontrol/pull/3419
Jeremy
On Thu, Apr 11, 2019 at 2:53 PM Chris Lemmons <al...@gmail.com> wrote:
> I concur with Rob. Experimental means "no promises, no demands". We
> need an exit plan for AngularJS and a contributor is offering an idea.
> I'm not 100% convinced, but I don't need to be. If someone has a
> better plan and some effort to put behind it, I'm all ears.
> Personally, I'm quite intrigued by the idea of a framework that could
> produce a mobile app suitable for origin owners to use in monitoring
> their stuff.
>
> In the meantime, put it in experimental. That way, people can see what
> it has, use it if they find it useful, contribute to it if they find
> it lacking, and keep it "with" the rest of the code. Nobody has to
> maintain it, but if it turns out to be useful for people, they will.
> If it's sufficiently useful for everyone at some point, promote it and
> promise to maintain it.
>
> > traffic_ops_ruby_on_rails
>
> Your trolling game is very strong. :D
>
> On Thu, Apr 11, 2019 at 10:33 AM Robert Butts <ro...@apache.org> wrote:
> >
> > +1 on putting it in /experimental.
> >
> > IMO no one should be required to be responsible for experimental. I think
> > we should be liberal about putting experimental things in the repo, under
> > /experimental, which aren't necessarily complete or well-maintained. So
> > people other than the author can see them, try them out, vote on whether
> > they're useful, etc.
> >
> > If at some point it becomes clear something in /experimental won't ever
> see
> > production, we just remove it. No big deal.
> >
> >
> > On Thu, Apr 11, 2019 at 10:08 AM Jeremy Mitchell <mi...@gmail.com>
> > wrote:
> >
> > > If Brennan focuses TPv2 on the self-service things (delivery service,
> user
> > > and tenant management), I think it would be his responsibility to
> ensure
> > > that any new functionality added to TPv1 regarding those 3 things is
> also
> > > added to his experimental TPv2. And once he starts adding other
> > > functionality (cache group, server management, etc), his scope will
> > > increase of the things he needs to keep an eye on. Then once TPv2
> achieves
> > > critical mass, we'll have to officially deprecate TPv1 and only add new
> > > functionality to TPv2. So I don't see any double UI coding. At the
> rate we
> > > are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at
> least
> > > the ds, user, tenant part)
> > >
> > > Jeremy
> > >
> > > On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK
> > > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> > > <ef...@cisco.com.invalid> wrote:
> > >
> > > > If there is a decision to keep a TPv2 in experimental state for a
> > > somewhat
> > > > long term (1-2 years), who will be responsible for maintaining
> features
> > > > equal with the current TP?
> > > >
> > > > I don’t think its fair to ask contributors to write double the UI
> code.
> > > >
> > > > —Eric
> > > >
> > > >
> > > > > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <
> rawlin.peters@gmail.com>
> > > > wrote:
> > > > >
> > > > > Yeah, I think this is just the nature of Javascript UI frameworks
> and
> > > > > the pace at which they are advancing, but eventually we will have
> to
> > > > > get off of AngularJS anyway since it will no longer be supported
> after
> > > > > June 30, 2021:
> > > >
> > >
> https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
> > > > .
> > > > >
> > > > > So maybe it makes the most sense to try to get ahead of that and
> > > > > implement any significant new self-service features in TPv2 rather
> > > > > than trying to tack self-service features onto the existing TP. At
> > > > > least it seems like Angular 2+ (currently at 7 now) has some better
> > > > > staying power and clear upgrade paths.
> > > > >
> > > > > - Rawlin
> > > > >
> > > > > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
> > > > > <Br...@comcast.com> wrote:
> > > > >>
> > > > >> They can be. There's no reason they can't. But the framework it's
> > > built
> > > > on is on life support, TS > JS, fragile dependencies etc. etc.
> > > > >>
> > > > >> But the upshot is that I believe the effort to support self
> service
> > > > would be just as much work either way, but done this way we
> > > > eliminate/mitigate those problems at the same time.
> > > > >> ________________________________________
> > > > >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o
> Alter
> > > > Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> > > > >> Sent: Wednesday, April 10, 2019 3:55 PM
> > > > >> To: dev@trafficcontrol.apache.org
> > > > >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/
> > > Self-Service
> > > > >>
> > > > >> Why can’t the form wizards and other self-service features be
> built
> > > > into the existing AngularJS Traffic Portal code?
> > > > >>
> > > > >> —Eric
> > > > >>
> > > > >>
> > > > >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <
> mitchell852@gmail.com>
> > > > wrote:
> > > > >>>
> > > > >>> I think I agree with Chris about just using the "experimental"
> folder
> > > > as we
> > > > >>> always have. Then it's pretty easy to look in there and see
> what's
> > > > >>> "cooking":
> > > > >>>
> > > > >>> experimental
> > > > >>> - traffic_router_golang
> > > > >>> - traffic-portal-angular7
> > > > >>> - traffic_ops_ruby_on_rails (just kidding :) )
> > > > >>>
> > > > >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2
> > > > audiences
> > > > >>> for TP:
> > > > >>>
> > > > >>> 1. Admin/ops type users
> > > > >>> 2. self-service type users
> > > > >>>
> > > > >>> TP works well for #1 but not really for #2. The trick is to
> build a
> > > UI
> > > > that
> > > > >>> works well for both OR have 2 distinct UIs. As developers, we
> don't
> > > > like
> > > > >>> the idea of 2 UIs as that sounds like double the UI work when
> > > something
> > > > >>> changes.
> > > > >>>
> > > > >>> So we could either:
> > > > >>>
> > > > >>> a. make TP (angularJS) more self-service friendly
> > > > >>> b. create TPv2 (angular7) with self-service in mind (i.e. form
> > > wizards
> > > > and
> > > > >>> such) and focus on ds, user and tenant management and then slowly
> > > port
> > > > the
> > > > >>> rest of TP functionality into it
> > > > >>> c. support 2 distinct UIs
> > > > >>>
> > > > >>> I think "b" makes sense and the effort can start (as many of our
> > > > efforts
> > > > >>> do) as "experimental" and if it gets legs maybe it does replace
> TP or
> > > > maybe
> > > > >>> it doesn't and it simply becomes a UI that you can use (or not
> use)
> > > to
> > > > >>> solve ds/user/tenant management in a simple/self-service type
> way.
> > > > >>>
> > > > >>> Jeremy
> > > > >>>
> > > > >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <
> alficles@gmail.com>
> > > > wrote:
> > > > >>>
> > > > >>>>> Are we seriously considering totally re-writing another
> component?
> > > > >>>>
> > > > >>>> Depends how you count it. One of the most important parts of the
> > > > >>>> previous re-write (still in progress) is the "separation of
> powers"
> > > > >>>> that makes things like this relatively non-destructive and able
> to
> > > be
> > > > >>>> managed in parallel. I like experimental pokes into what the
> future
> > > > >>>> might hold, like this one. I'm not totally sold, but the scope
> isn't
> > > > >>>> crazy. It's mostly a UI on top of the existing API.
> > > > >>>>
> > > > >>>> Historically, experimental or alternate components have lived
> in the
> > > > >>>> main branch, but the experimental folder. That lets them be
> part of
> > > > >>>> the same process as the rest of the code, ensures code reviews
> as
> > > they
> > > > >>>> progress, and the CI will keep everything in license compliance.
> > > > >>>>
> > > > >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
> > > > >>>> <Br...@comcast.com> wrote:
> > > > >>>>>
> > > > >>>>> Branching is fine with me, I doubt I have permission to create
> a
> > > > branch
> > > > >>>> myself, though.
> > > > >>>>>
> > > > >>>>> As an aside based on that: should `traffic_router_golang` also
> be
> > > > moved
> > > > >>>> to a branch? I think the branch idea is better than having an
> > > > >>>> `experimental` directory. Or maybe that experiment is dead and
> > > should
> > > > just
> > > > >>>> be removed instead? The last change was 10 months ago.
> > > > >>>>> ________________________________________
> > > > >>>>> From: Gray, Jonathan <Jo...@comcast.com>
> > > > >>>>> Sent: Wednesday, April 10, 2019 9:09 AM
> > > > >>>>> To: dev@trafficcontrol.apache.org
> > > > >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > > > >>>> Self-Service
> > > > >>>>>
> > > > >>>>> Instead of merging it into master, could we merge it to a
> feature
> > > > branch
> > > > >>>> like `experimental/TP.rewrite` if there is a desire for
> > > collaborative
> > > > >>>> efforts. This would allow changes to flow in without adding
> more
> > > > code to
> > > > >>>> our normal review processes and polluting the changelog with WIP
> > > > until it's
> > > > >>>> done and ready to be merged. As an additional bonus it
> provides a
> > > > more
> > > > >>>> stable development for the new work since you'd be choosing
> when to
> > > > pay the
> > > > >>>> merge costs of ongoing master changes.
> > > > >>>>>
> > > > >>>>> Jonathan G
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <
> Brennan_Fieck@comcast.com>
> > > > >>>> wrote:
> > > > >>>>>
> > > > >>>>> I guess that depends what you mean by "we". I personally
> think
> > > it's
> > > > >>>> worthwhile, and I'll probably keep working on it until it
> reaches
> > > > feature
> > > > >>>> parity with the existing TP.
> > > > >>>>>
> > > > >>>>> I'm not saying development on the existing AngularJS-based TP
> > > > should
> > > > >>>> stop in the meantime, just that self-service be implemented
> > > > separately in a
> > > > >>>> more modern and flexible framework. Then - and only then -
> should we
> > > > >>>> consider replacing the old TP with the new. Slowly, over time.
> The
> > > > current
> > > > >>>> TP was built for admins, so I don't think it'd actually be more
> work
> > > > to
> > > > >>>> implement a customer-facing interface this way than
> restructuring
> > > the
> > > > >>>> existing TP to support it.
> > > > >>>>> ________________________________________
> > > > >>>>> From: Hank Beatty <hb...@apache.org>
> > > > >>>>> Sent: Wednesday, April 10, 2019 8:38 AM
> > > > >>>>> To: dev@trafficcontrol.apache.org
> > > > >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > > > >>>> Self-Service
> > > > >>>>>
> > > > >>>>> Hello,
> > > > >>>>>
> > > > >>>>> Are we seriously considering totally re-writing another
> > > component?
> > > > >>>>>
> > > > >>>>> -Hank
> > > > >>>>>
> > > > >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
> > > > >>>>>> Some of you may have heard, but about two and a half weeks
> ago I
> > > > >>>> opened a Pull Request to add something to the `/experimental`
> > > > directory.
> > > > >>>> It's basically a re-implementation of Traffic Portal, which I
> think
> > > is
> > > > >>>> beneficial not only because Traffic Portal wasn't designed with
> > > > >>>> self-service in mind, but also because it cleans up a few
> issues on
> > > > the
> > > > >>>> development side. First of all, it uses the most recent LTS
> version
> > > of
> > > > >>>> Angular, while the one on which Traffic Portal is currently
> based is
> > > > now
> > > > >>>> deprecated (this new version can also compile projects for
> Electron,
> > > > which
> > > > >>>> would make TP distributable as a standalone/mobile app). It also
> > > uses
> > > > >>>> Typescript which compiles more cleanly to an overall smaller
> > > product,
> > > > and
> > > > >>>> is much easier to read, write and document. Remember the SCSS
> > > compiler
> > > > >>>> issues (compass) we keep having? Angular 7 comes with a
> compiler at
> > > > project
> > > > >>>> init, so we never need that as an externally-provided dependency
> > > > again.
> > > > >>>> Finally, it already has unit testing and end-to-end testing
> working
> > > > in four
> > > > >>>> different JS engines.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> I'm currently looking for a reviewer (
> > > > >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can
> > > read
> > > > more
> > > > >>>> about what's implemented there, but a short summary:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> * Login/authentication and API proxy
> > > > >>>>>> * Delivery Service view with bandwidth charts
> > > > >>>>>> * New Delivery Service creation targeted at self-service users
> > > > >>>> with limited advanced editing options
> > > > >>>>>>
> > > > >>>>>> * User listing (read-only)
> > > > >>>>>>
> > > > >>>>>> * Preliminary HTTPS support (currently only listens on
> > > 'localhost')
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> Plus, if I do say so myself, it all looks pretty snappy on
> every
> > > > >>>> screen I could test.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> Feedback is also appreciated, especially concerning the "New
> > > > >>>> Delivery Service" form.
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> > > >
> > >
>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Chris Lemmons <al...@gmail.com>.
I concur with Rob. Experimental means "no promises, no demands". We
need an exit plan for AngularJS and a contributor is offering an idea.
I'm not 100% convinced, but I don't need to be. If someone has a
better plan and some effort to put behind it, I'm all ears.
Personally, I'm quite intrigued by the idea of a framework that could
produce a mobile app suitable for origin owners to use in monitoring
their stuff.
In the meantime, put it in experimental. That way, people can see what
it has, use it if they find it useful, contribute to it if they find
it lacking, and keep it "with" the rest of the code. Nobody has to
maintain it, but if it turns out to be useful for people, they will.
If it's sufficiently useful for everyone at some point, promote it and
promise to maintain it.
> traffic_ops_ruby_on_rails
Your trolling game is very strong. :D
On Thu, Apr 11, 2019 at 10:33 AM Robert Butts <ro...@apache.org> wrote:
>
> +1 on putting it in /experimental.
>
> IMO no one should be required to be responsible for experimental. I think
> we should be liberal about putting experimental things in the repo, under
> /experimental, which aren't necessarily complete or well-maintained. So
> people other than the author can see them, try them out, vote on whether
> they're useful, etc.
>
> If at some point it becomes clear something in /experimental won't ever see
> production, we just remove it. No big deal.
>
>
> On Thu, Apr 11, 2019 at 10:08 AM Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > If Brennan focuses TPv2 on the self-service things (delivery service, user
> > and tenant management), I think it would be his responsibility to ensure
> > that any new functionality added to TPv1 regarding those 3 things is also
> > added to his experimental TPv2. And once he starts adding other
> > functionality (cache group, server management, etc), his scope will
> > increase of the things he needs to keep an eye on. Then once TPv2 achieves
> > critical mass, we'll have to officially deprecate TPv1 and only add new
> > functionality to TPv2. So I don't see any double UI coding. At the rate we
> > are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at least
> > the ds, user, tenant part)
> >
> > Jeremy
> >
> > On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK
> > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> > <ef...@cisco.com.invalid> wrote:
> >
> > > If there is a decision to keep a TPv2 in experimental state for a
> > somewhat
> > > long term (1-2 years), who will be responsible for maintaining features
> > > equal with the current TP?
> > >
> > > I don’t think its fair to ask contributors to write double the UI code.
> > >
> > > —Eric
> > >
> > >
> > > > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <ra...@gmail.com>
> > > wrote:
> > > >
> > > > Yeah, I think this is just the nature of Javascript UI frameworks and
> > > > the pace at which they are advancing, but eventually we will have to
> > > > get off of AngularJS anyway since it will no longer be supported after
> > > > June 30, 2021:
> > >
> > https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
> > > .
> > > >
> > > > So maybe it makes the most sense to try to get ahead of that and
> > > > implement any significant new self-service features in TPv2 rather
> > > > than trying to tack self-service features onto the existing TP. At
> > > > least it seems like Angular 2+ (currently at 7 now) has some better
> > > > staying power and clear upgrade paths.
> > > >
> > > > - Rawlin
> > > >
> > > > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
> > > > <Br...@comcast.com> wrote:
> > > >>
> > > >> They can be. There's no reason they can't. But the framework it's
> > built
> > > on is on life support, TS > JS, fragile dependencies etc. etc.
> > > >>
> > > >> But the upshot is that I believe the effort to support self service
> > > would be just as much work either way, but done this way we
> > > eliminate/mitigate those problems at the same time.
> > > >> ________________________________________
> > > >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> > > Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> > > >> Sent: Wednesday, April 10, 2019 3:55 PM
> > > >> To: dev@trafficcontrol.apache.org
> > > >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/
> > Self-Service
> > > >>
> > > >> Why can’t the form wizards and other self-service features be built
> > > into the existing AngularJS Traffic Portal code?
> > > >>
> > > >> —Eric
> > > >>
> > > >>
> > > >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com>
> > > wrote:
> > > >>>
> > > >>> I think I agree with Chris about just using the "experimental" folder
> > > as we
> > > >>> always have. Then it's pretty easy to look in there and see what's
> > > >>> "cooking":
> > > >>>
> > > >>> experimental
> > > >>> - traffic_router_golang
> > > >>> - traffic-portal-angular7
> > > >>> - traffic_ops_ruby_on_rails (just kidding :) )
> > > >>>
> > > >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2
> > > audiences
> > > >>> for TP:
> > > >>>
> > > >>> 1. Admin/ops type users
> > > >>> 2. self-service type users
> > > >>>
> > > >>> TP works well for #1 but not really for #2. The trick is to build a
> > UI
> > > that
> > > >>> works well for both OR have 2 distinct UIs. As developers, we don't
> > > like
> > > >>> the idea of 2 UIs as that sounds like double the UI work when
> > something
> > > >>> changes.
> > > >>>
> > > >>> So we could either:
> > > >>>
> > > >>> a. make TP (angularJS) more self-service friendly
> > > >>> b. create TPv2 (angular7) with self-service in mind (i.e. form
> > wizards
> > > and
> > > >>> such) and focus on ds, user and tenant management and then slowly
> > port
> > > the
> > > >>> rest of TP functionality into it
> > > >>> c. support 2 distinct UIs
> > > >>>
> > > >>> I think "b" makes sense and the effort can start (as many of our
> > > efforts
> > > >>> do) as "experimental" and if it gets legs maybe it does replace TP or
> > > maybe
> > > >>> it doesn't and it simply becomes a UI that you can use (or not use)
> > to
> > > >>> solve ds/user/tenant management in a simple/self-service type way.
> > > >>>
> > > >>> Jeremy
> > > >>>
> > > >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com>
> > > wrote:
> > > >>>
> > > >>>>> Are we seriously considering totally re-writing another component?
> > > >>>>
> > > >>>> Depends how you count it. One of the most important parts of the
> > > >>>> previous re-write (still in progress) is the "separation of powers"
> > > >>>> that makes things like this relatively non-destructive and able to
> > be
> > > >>>> managed in parallel. I like experimental pokes into what the future
> > > >>>> might hold, like this one. I'm not totally sold, but the scope isn't
> > > >>>> crazy. It's mostly a UI on top of the existing API.
> > > >>>>
> > > >>>> Historically, experimental or alternate components have lived in the
> > > >>>> main branch, but the experimental folder. That lets them be part of
> > > >>>> the same process as the rest of the code, ensures code reviews as
> > they
> > > >>>> progress, and the CI will keep everything in license compliance.
> > > >>>>
> > > >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
> > > >>>> <Br...@comcast.com> wrote:
> > > >>>>>
> > > >>>>> Branching is fine with me, I doubt I have permission to create a
> > > branch
> > > >>>> myself, though.
> > > >>>>>
> > > >>>>> As an aside based on that: should `traffic_router_golang` also be
> > > moved
> > > >>>> to a branch? I think the branch idea is better than having an
> > > >>>> `experimental` directory. Or maybe that experiment is dead and
> > should
> > > just
> > > >>>> be removed instead? The last change was 10 months ago.
> > > >>>>> ________________________________________
> > > >>>>> From: Gray, Jonathan <Jo...@comcast.com>
> > > >>>>> Sent: Wednesday, April 10, 2019 9:09 AM
> > > >>>>> To: dev@trafficcontrol.apache.org
> > > >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > > >>>> Self-Service
> > > >>>>>
> > > >>>>> Instead of merging it into master, could we merge it to a feature
> > > branch
> > > >>>> like `experimental/TP.rewrite` if there is a desire for
> > collaborative
> > > >>>> efforts. This would allow changes to flow in without adding more
> > > code to
> > > >>>> our normal review processes and polluting the changelog with WIP
> > > until it's
> > > >>>> done and ready to be merged. As an additional bonus it provides a
> > > more
> > > >>>> stable development for the new work since you'd be choosing when to
> > > pay the
> > > >>>> merge costs of ongoing master changes.
> > > >>>>>
> > > >>>>> Jonathan G
> > > >>>>>
> > > >>>>>
> > > >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> I guess that depends what you mean by "we". I personally think
> > it's
> > > >>>> worthwhile, and I'll probably keep working on it until it reaches
> > > feature
> > > >>>> parity with the existing TP.
> > > >>>>>
> > > >>>>> I'm not saying development on the existing AngularJS-based TP
> > > should
> > > >>>> stop in the meantime, just that self-service be implemented
> > > separately in a
> > > >>>> more modern and flexible framework. Then - and only then - should we
> > > >>>> consider replacing the old TP with the new. Slowly, over time. The
> > > current
> > > >>>> TP was built for admins, so I don't think it'd actually be more work
> > > to
> > > >>>> implement a customer-facing interface this way than restructuring
> > the
> > > >>>> existing TP to support it.
> > > >>>>> ________________________________________
> > > >>>>> From: Hank Beatty <hb...@apache.org>
> > > >>>>> Sent: Wednesday, April 10, 2019 8:38 AM
> > > >>>>> To: dev@trafficcontrol.apache.org
> > > >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > > >>>> Self-Service
> > > >>>>>
> > > >>>>> Hello,
> > > >>>>>
> > > >>>>> Are we seriously considering totally re-writing another
> > component?
> > > >>>>>
> > > >>>>> -Hank
> > > >>>>>
> > > >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
> > > >>>>>> Some of you may have heard, but about two and a half weeks ago I
> > > >>>> opened a Pull Request to add something to the `/experimental`
> > > directory.
> > > >>>> It's basically a re-implementation of Traffic Portal, which I think
> > is
> > > >>>> beneficial not only because Traffic Portal wasn't designed with
> > > >>>> self-service in mind, but also because it cleans up a few issues on
> > > the
> > > >>>> development side. First of all, it uses the most recent LTS version
> > of
> > > >>>> Angular, while the one on which Traffic Portal is currently based is
> > > now
> > > >>>> deprecated (this new version can also compile projects for Electron,
> > > which
> > > >>>> would make TP distributable as a standalone/mobile app). It also
> > uses
> > > >>>> Typescript which compiles more cleanly to an overall smaller
> > product,
> > > and
> > > >>>> is much easier to read, write and document. Remember the SCSS
> > compiler
> > > >>>> issues (compass) we keep having? Angular 7 comes with a compiler at
> > > project
> > > >>>> init, so we never need that as an externally-provided dependency
> > > again.
> > > >>>> Finally, it already has unit testing and end-to-end testing working
> > > in four
> > > >>>> different JS engines.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> I'm currently looking for a reviewer (
> > > >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can
> > read
> > > more
> > > >>>> about what's implemented there, but a short summary:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> * Login/authentication and API proxy
> > > >>>>>> * Delivery Service view with bandwidth charts
> > > >>>>>> * New Delivery Service creation targeted at self-service users
> > > >>>> with limited advanced editing options
> > > >>>>>>
> > > >>>>>> * User listing (read-only)
> > > >>>>>>
> > > >>>>>> * Preliminary HTTPS support (currently only listens on
> > 'localhost')
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Plus, if I do say so myself, it all looks pretty snappy on every
> > > >>>> screen I could test.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Feedback is also appreciated, especially concerning the "New
> > > >>>> Delivery Service" form.
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > >
> > >
> >
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Robert Butts <ro...@apache.org>.
+1 on putting it in /experimental.
IMO no one should be required to be responsible for experimental. I think
we should be liberal about putting experimental things in the repo, under
/experimental, which aren't necessarily complete or well-maintained. So
people other than the author can see them, try them out, vote on whether
they're useful, etc.
If at some point it becomes clear something in /experimental won't ever see
production, we just remove it. No big deal.
On Thu, Apr 11, 2019 at 10:08 AM Jeremy Mitchell <mi...@gmail.com>
wrote:
> If Brennan focuses TPv2 on the self-service things (delivery service, user
> and tenant management), I think it would be his responsibility to ensure
> that any new functionality added to TPv1 regarding those 3 things is also
> added to his experimental TPv2. And once he starts adding other
> functionality (cache group, server management, etc), his scope will
> increase of the things he needs to keep an eye on. Then once TPv2 achieves
> critical mass, we'll have to officially deprecate TPv1 and only add new
> functionality to TPv2. So I don't see any double UI coding. At the rate we
> are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at least
> the ds, user, tenant part)
>
> Jeremy
>
> On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK
> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
> <ef...@cisco.com.invalid> wrote:
>
> > If there is a decision to keep a TPv2 in experimental state for a
> somewhat
> > long term (1-2 years), who will be responsible for maintaining features
> > equal with the current TP?
> >
> > I don’t think its fair to ask contributors to write double the UI code.
> >
> > —Eric
> >
> >
> > > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <ra...@gmail.com>
> > wrote:
> > >
> > > Yeah, I think this is just the nature of Javascript UI frameworks and
> > > the pace at which they are advancing, but eventually we will have to
> > > get off of AngularJS anyway since it will no longer be supported after
> > > June 30, 2021:
> >
> https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
> > .
> > >
> > > So maybe it makes the most sense to try to get ahead of that and
> > > implement any significant new self-service features in TPv2 rather
> > > than trying to tack self-service features onto the existing TP. At
> > > least it seems like Angular 2+ (currently at 7 now) has some better
> > > staying power and clear upgrade paths.
> > >
> > > - Rawlin
> > >
> > > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
> > > <Br...@comcast.com> wrote:
> > >>
> > >> They can be. There's no reason they can't. But the framework it's
> built
> > on is on life support, TS > JS, fragile dependencies etc. etc.
> > >>
> > >> But the upshot is that I believe the effort to support self service
> > would be just as much work either way, but done this way we
> > eliminate/mitigate those problems at the same time.
> > >> ________________________________________
> > >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> > Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> > >> Sent: Wednesday, April 10, 2019 3:55 PM
> > >> To: dev@trafficcontrol.apache.org
> > >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/
> Self-Service
> > >>
> > >> Why can’t the form wizards and other self-service features be built
> > into the existing AngularJS Traffic Portal code?
> > >>
> > >> —Eric
> > >>
> > >>
> > >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com>
> > wrote:
> > >>>
> > >>> I think I agree with Chris about just using the "experimental" folder
> > as we
> > >>> always have. Then it's pretty easy to look in there and see what's
> > >>> "cooking":
> > >>>
> > >>> experimental
> > >>> - traffic_router_golang
> > >>> - traffic-portal-angular7
> > >>> - traffic_ops_ruby_on_rails (just kidding :) )
> > >>>
> > >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2
> > audiences
> > >>> for TP:
> > >>>
> > >>> 1. Admin/ops type users
> > >>> 2. self-service type users
> > >>>
> > >>> TP works well for #1 but not really for #2. The trick is to build a
> UI
> > that
> > >>> works well for both OR have 2 distinct UIs. As developers, we don't
> > like
> > >>> the idea of 2 UIs as that sounds like double the UI work when
> something
> > >>> changes.
> > >>>
> > >>> So we could either:
> > >>>
> > >>> a. make TP (angularJS) more self-service friendly
> > >>> b. create TPv2 (angular7) with self-service in mind (i.e. form
> wizards
> > and
> > >>> such) and focus on ds, user and tenant management and then slowly
> port
> > the
> > >>> rest of TP functionality into it
> > >>> c. support 2 distinct UIs
> > >>>
> > >>> I think "b" makes sense and the effort can start (as many of our
> > efforts
> > >>> do) as "experimental" and if it gets legs maybe it does replace TP or
> > maybe
> > >>> it doesn't and it simply becomes a UI that you can use (or not use)
> to
> > >>> solve ds/user/tenant management in a simple/self-service type way.
> > >>>
> > >>> Jeremy
> > >>>
> > >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com>
> > wrote:
> > >>>
> > >>>>> Are we seriously considering totally re-writing another component?
> > >>>>
> > >>>> Depends how you count it. One of the most important parts of the
> > >>>> previous re-write (still in progress) is the "separation of powers"
> > >>>> that makes things like this relatively non-destructive and able to
> be
> > >>>> managed in parallel. I like experimental pokes into what the future
> > >>>> might hold, like this one. I'm not totally sold, but the scope isn't
> > >>>> crazy. It's mostly a UI on top of the existing API.
> > >>>>
> > >>>> Historically, experimental or alternate components have lived in the
> > >>>> main branch, but the experimental folder. That lets them be part of
> > >>>> the same process as the rest of the code, ensures code reviews as
> they
> > >>>> progress, and the CI will keep everything in license compliance.
> > >>>>
> > >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
> > >>>> <Br...@comcast.com> wrote:
> > >>>>>
> > >>>>> Branching is fine with me, I doubt I have permission to create a
> > branch
> > >>>> myself, though.
> > >>>>>
> > >>>>> As an aside based on that: should `traffic_router_golang` also be
> > moved
> > >>>> to a branch? I think the branch idea is better than having an
> > >>>> `experimental` directory. Or maybe that experiment is dead and
> should
> > just
> > >>>> be removed instead? The last change was 10 months ago.
> > >>>>> ________________________________________
> > >>>>> From: Gray, Jonathan <Jo...@comcast.com>
> > >>>>> Sent: Wednesday, April 10, 2019 9:09 AM
> > >>>>> To: dev@trafficcontrol.apache.org
> > >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > >>>> Self-Service
> > >>>>>
> > >>>>> Instead of merging it into master, could we merge it to a feature
> > branch
> > >>>> like `experimental/TP.rewrite` if there is a desire for
> collaborative
> > >>>> efforts. This would allow changes to flow in without adding more
> > code to
> > >>>> our normal review processes and polluting the changelog with WIP
> > until it's
> > >>>> done and ready to be merged. As an additional bonus it provides a
> > more
> > >>>> stable development for the new work since you'd be choosing when to
> > pay the
> > >>>> merge costs of ongoing master changes.
> > >>>>>
> > >>>>> Jonathan G
> > >>>>>
> > >>>>>
> > >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
> > >>>> wrote:
> > >>>>>
> > >>>>> I guess that depends what you mean by "we". I personally think
> it's
> > >>>> worthwhile, and I'll probably keep working on it until it reaches
> > feature
> > >>>> parity with the existing TP.
> > >>>>>
> > >>>>> I'm not saying development on the existing AngularJS-based TP
> > should
> > >>>> stop in the meantime, just that self-service be implemented
> > separately in a
> > >>>> more modern and flexible framework. Then - and only then - should we
> > >>>> consider replacing the old TP with the new. Slowly, over time. The
> > current
> > >>>> TP was built for admins, so I don't think it'd actually be more work
> > to
> > >>>> implement a customer-facing interface this way than restructuring
> the
> > >>>> existing TP to support it.
> > >>>>> ________________________________________
> > >>>>> From: Hank Beatty <hb...@apache.org>
> > >>>>> Sent: Wednesday, April 10, 2019 8:38 AM
> > >>>>> To: dev@trafficcontrol.apache.org
> > >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> > >>>> Self-Service
> > >>>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> Are we seriously considering totally re-writing another
> component?
> > >>>>>
> > >>>>> -Hank
> > >>>>>
> > >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
> > >>>>>> Some of you may have heard, but about two and a half weeks ago I
> > >>>> opened a Pull Request to add something to the `/experimental`
> > directory.
> > >>>> It's basically a re-implementation of Traffic Portal, which I think
> is
> > >>>> beneficial not only because Traffic Portal wasn't designed with
> > >>>> self-service in mind, but also because it cleans up a few issues on
> > the
> > >>>> development side. First of all, it uses the most recent LTS version
> of
> > >>>> Angular, while the one on which Traffic Portal is currently based is
> > now
> > >>>> deprecated (this new version can also compile projects for Electron,
> > which
> > >>>> would make TP distributable as a standalone/mobile app). It also
> uses
> > >>>> Typescript which compiles more cleanly to an overall smaller
> product,
> > and
> > >>>> is much easier to read, write and document. Remember the SCSS
> compiler
> > >>>> issues (compass) we keep having? Angular 7 comes with a compiler at
> > project
> > >>>> init, so we never need that as an externally-provided dependency
> > again.
> > >>>> Finally, it already has unit testing and end-to-end testing working
> > in four
> > >>>> different JS engines.
> > >>>>>>
> > >>>>>>
> > >>>>>> I'm currently looking for a reviewer (
> > >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can
> read
> > more
> > >>>> about what's implemented there, but a short summary:
> > >>>>>>
> > >>>>>>
> > >>>>>> * Login/authentication and API proxy
> > >>>>>> * Delivery Service view with bandwidth charts
> > >>>>>> * New Delivery Service creation targeted at self-service users
> > >>>> with limited advanced editing options
> > >>>>>>
> > >>>>>> * User listing (read-only)
> > >>>>>>
> > >>>>>> * Preliminary HTTPS support (currently only listens on
> 'localhost')
> > >>>>>>
> > >>>>>>
> > >>>>>> Plus, if I do say so myself, it all looks pretty snappy on every
> > >>>> screen I could test.
> > >>>>>>
> > >>>>>>
> > >>>>>> Feedback is also appreciated, especially concerning the "New
> > >>>> Delivery Service" form.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> >
> >
>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Jeremy Mitchell <mi...@gmail.com>.
If Brennan focuses TPv2 on the self-service things (delivery service, user
and tenant management), I think it would be his responsibility to ensure
that any new functionality added to TPv1 regarding those 3 things is also
added to his experimental TPv2. And once he starts adding other
functionality (cache group, server management, etc), his scope will
increase of the things he needs to keep an eye on. Then once TPv2 achieves
critical mass, we'll have to officially deprecate TPv1 and only add new
functionality to TPv2. So I don't see any double UI coding. At the rate we
are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at least
the ds, user, tenant part)
Jeremy
On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK
BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco)
<ef...@cisco.com.invalid> wrote:
> If there is a decision to keep a TPv2 in experimental state for a somewhat
> long term (1-2 years), who will be responsible for maintaining features
> equal with the current TP?
>
> I don’t think its fair to ask contributors to write double the UI code.
>
> —Eric
>
>
> > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <ra...@gmail.com>
> wrote:
> >
> > Yeah, I think this is just the nature of Javascript UI frameworks and
> > the pace at which they are advancing, but eventually we will have to
> > get off of AngularJS anyway since it will no longer be supported after
> > June 30, 2021:
> https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
> .
> >
> > So maybe it makes the most sense to try to get ahead of that and
> > implement any significant new self-service features in TPv2 rather
> > than trying to tack self-service features onto the existing TP. At
> > least it seems like Angular 2+ (currently at 7 now) has some better
> > staying power and clear upgrade paths.
> >
> > - Rawlin
> >
> > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
> > <Br...@comcast.com> wrote:
> >>
> >> They can be. There's no reason they can't. But the framework it's built
> on is on life support, TS > JS, fragile dependencies etc. etc.
> >>
> >> But the upshot is that I believe the effort to support self service
> would be just as much work either way, but done this way we
> eliminate/mitigate those problems at the same time.
> >> ________________________________________
> >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter
> Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> >> Sent: Wednesday, April 10, 2019 3:55 PM
> >> To: dev@trafficcontrol.apache.org
> >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
> >>
> >> Why can’t the form wizards and other self-service features be built
> into the existing AngularJS Traffic Portal code?
> >>
> >> —Eric
> >>
> >>
> >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
> >>>
> >>> I think I agree with Chris about just using the "experimental" folder
> as we
> >>> always have. Then it's pretty easy to look in there and see what's
> >>> "cooking":
> >>>
> >>> experimental
> >>> - traffic_router_golang
> >>> - traffic-portal-angular7
> >>> - traffic_ops_ruby_on_rails (just kidding :) )
> >>>
> >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2
> audiences
> >>> for TP:
> >>>
> >>> 1. Admin/ops type users
> >>> 2. self-service type users
> >>>
> >>> TP works well for #1 but not really for #2. The trick is to build a UI
> that
> >>> works well for both OR have 2 distinct UIs. As developers, we don't
> like
> >>> the idea of 2 UIs as that sounds like double the UI work when something
> >>> changes.
> >>>
> >>> So we could either:
> >>>
> >>> a. make TP (angularJS) more self-service friendly
> >>> b. create TPv2 (angular7) with self-service in mind (i.e. form wizards
> and
> >>> such) and focus on ds, user and tenant management and then slowly port
> the
> >>> rest of TP functionality into it
> >>> c. support 2 distinct UIs
> >>>
> >>> I think "b" makes sense and the effort can start (as many of our
> efforts
> >>> do) as "experimental" and if it gets legs maybe it does replace TP or
> maybe
> >>> it doesn't and it simply becomes a UI that you can use (or not use) to
> >>> solve ds/user/tenant management in a simple/self-service type way.
> >>>
> >>> Jeremy
> >>>
> >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com>
> wrote:
> >>>
> >>>>> Are we seriously considering totally re-writing another component?
> >>>>
> >>>> Depends how you count it. One of the most important parts of the
> >>>> previous re-write (still in progress) is the "separation of powers"
> >>>> that makes things like this relatively non-destructive and able to be
> >>>> managed in parallel. I like experimental pokes into what the future
> >>>> might hold, like this one. I'm not totally sold, but the scope isn't
> >>>> crazy. It's mostly a UI on top of the existing API.
> >>>>
> >>>> Historically, experimental or alternate components have lived in the
> >>>> main branch, but the experimental folder. That lets them be part of
> >>>> the same process as the rest of the code, ensures code reviews as they
> >>>> progress, and the CI will keep everything in license compliance.
> >>>>
> >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
> >>>> <Br...@comcast.com> wrote:
> >>>>>
> >>>>> Branching is fine with me, I doubt I have permission to create a
> branch
> >>>> myself, though.
> >>>>>
> >>>>> As an aside based on that: should `traffic_router_golang` also be
> moved
> >>>> to a branch? I think the branch idea is better than having an
> >>>> `experimental` directory. Or maybe that experiment is dead and should
> just
> >>>> be removed instead? The last change was 10 months ago.
> >>>>> ________________________________________
> >>>>> From: Gray, Jonathan <Jo...@comcast.com>
> >>>>> Sent: Wednesday, April 10, 2019 9:09 AM
> >>>>> To: dev@trafficcontrol.apache.org
> >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> >>>> Self-Service
> >>>>>
> >>>>> Instead of merging it into master, could we merge it to a feature
> branch
> >>>> like `experimental/TP.rewrite` if there is a desire for collaborative
> >>>> efforts. This would allow changes to flow in without adding more
> code to
> >>>> our normal review processes and polluting the changelog with WIP
> until it's
> >>>> done and ready to be merged. As an additional bonus it provides a
> more
> >>>> stable development for the new work since you'd be choosing when to
> pay the
> >>>> merge costs of ongoing master changes.
> >>>>>
> >>>>> Jonathan G
> >>>>>
> >>>>>
> >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
> >>>> wrote:
> >>>>>
> >>>>> I guess that depends what you mean by "we". I personally think it's
> >>>> worthwhile, and I'll probably keep working on it until it reaches
> feature
> >>>> parity with the existing TP.
> >>>>>
> >>>>> I'm not saying development on the existing AngularJS-based TP
> should
> >>>> stop in the meantime, just that self-service be implemented
> separately in a
> >>>> more modern and flexible framework. Then - and only then - should we
> >>>> consider replacing the old TP with the new. Slowly, over time. The
> current
> >>>> TP was built for admins, so I don't think it'd actually be more work
> to
> >>>> implement a customer-facing interface this way than restructuring the
> >>>> existing TP to support it.
> >>>>> ________________________________________
> >>>>> From: Hank Beatty <hb...@apache.org>
> >>>>> Sent: Wednesday, April 10, 2019 8:38 AM
> >>>>> To: dev@trafficcontrol.apache.org
> >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> >>>> Self-Service
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Are we seriously considering totally re-writing another component?
> >>>>>
> >>>>> -Hank
> >>>>>
> >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
> >>>>>> Some of you may have heard, but about two and a half weeks ago I
> >>>> opened a Pull Request to add something to the `/experimental`
> directory.
> >>>> It's basically a re-implementation of Traffic Portal, which I think is
> >>>> beneficial not only because Traffic Portal wasn't designed with
> >>>> self-service in mind, but also because it cleans up a few issues on
> the
> >>>> development side. First of all, it uses the most recent LTS version of
> >>>> Angular, while the one on which Traffic Portal is currently based is
> now
> >>>> deprecated (this new version can also compile projects for Electron,
> which
> >>>> would make TP distributable as a standalone/mobile app). It also uses
> >>>> Typescript which compiles more cleanly to an overall smaller product,
> and
> >>>> is much easier to read, write and document. Remember the SCSS compiler
> >>>> issues (compass) we keep having? Angular 7 comes with a compiler at
> project
> >>>> init, so we never need that as an externally-provided dependency
> again.
> >>>> Finally, it already has unit testing and end-to-end testing working
> in four
> >>>> different JS engines.
> >>>>>>
> >>>>>>
> >>>>>> I'm currently looking for a reviewer (
> >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can read
> more
> >>>> about what's implemented there, but a short summary:
> >>>>>>
> >>>>>>
> >>>>>> * Login/authentication and API proxy
> >>>>>> * Delivery Service view with bandwidth charts
> >>>>>> * New Delivery Service creation targeted at self-service users
> >>>> with limited advanced editing options
> >>>>>>
> >>>>>> * User listing (read-only)
> >>>>>>
> >>>>>> * Preliminary HTTPS support (currently only listens on 'localhost')
> >>>>>>
> >>>>>>
> >>>>>> Plus, if I do say so myself, it all looks pretty snappy on every
> >>>> screen I could test.
> >>>>>>
> >>>>>>
> >>>>>> Feedback is also appreciated, especially concerning the "New
> >>>> Delivery Service" form.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>
>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus
(UK) Limited -OBO at Cisco)" <ef...@cisco.com.INVALID>.
If there is a decision to keep a TPv2 in experimental state for a somewhat long term (1-2 years), who will be responsible for maintaining features equal with the current TP?
I don’t think its fair to ask contributors to write double the UI code.
—Eric
> On Apr 10, 2019, at 6:40 PM, Rawlin Peters <ra...@gmail.com> wrote:
>
> Yeah, I think this is just the nature of Javascript UI frameworks and
> the pace at which they are advancing, but eventually we will have to
> get off of AngularJS anyway since it will no longer be supported after
> June 30, 2021: https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c.
>
> So maybe it makes the most sense to try to get ahead of that and
> implement any significant new self-service features in TPv2 rather
> than trying to tack self-service features onto the existing TP. At
> least it seems like Angular 2+ (currently at 7 now) has some better
> staying power and clear upgrade paths.
>
> - Rawlin
>
> On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
> <Br...@comcast.com> wrote:
>>
>> They can be. There's no reason they can't. But the framework it's built on is on life support, TS > JS, fragile dependencies etc. etc.
>>
>> But the upshot is that I believe the effort to support self service would be just as much work either way, but done this way we eliminate/mitigate those problems at the same time.
>> ________________________________________
>> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
>> Sent: Wednesday, April 10, 2019 3:55 PM
>> To: dev@trafficcontrol.apache.org
>> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
>>
>> Why can’t the form wizards and other self-service features be built into the existing AngularJS Traffic Portal code?
>>
>> —Eric
>>
>>
>>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com> wrote:
>>>
>>> I think I agree with Chris about just using the "experimental" folder as we
>>> always have. Then it's pretty easy to look in there and see what's
>>> "cooking":
>>>
>>> experimental
>>> - traffic_router_golang
>>> - traffic-portal-angular7
>>> - traffic_ops_ruby_on_rails (just kidding :) )
>>>
>>> Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences
>>> for TP:
>>>
>>> 1. Admin/ops type users
>>> 2. self-service type users
>>>
>>> TP works well for #1 but not really for #2. The trick is to build a UI that
>>> works well for both OR have 2 distinct UIs. As developers, we don't like
>>> the idea of 2 UIs as that sounds like double the UI work when something
>>> changes.
>>>
>>> So we could either:
>>>
>>> a. make TP (angularJS) more self-service friendly
>>> b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and
>>> such) and focus on ds, user and tenant management and then slowly port the
>>> rest of TP functionality into it
>>> c. support 2 distinct UIs
>>>
>>> I think "b" makes sense and the effort can start (as many of our efforts
>>> do) as "experimental" and if it gets legs maybe it does replace TP or maybe
>>> it doesn't and it simply becomes a UI that you can use (or not use) to
>>> solve ds/user/tenant management in a simple/self-service type way.
>>>
>>> Jeremy
>>>
>>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com> wrote:
>>>
>>>>> Are we seriously considering totally re-writing another component?
>>>>
>>>> Depends how you count it. One of the most important parts of the
>>>> previous re-write (still in progress) is the "separation of powers"
>>>> that makes things like this relatively non-destructive and able to be
>>>> managed in parallel. I like experimental pokes into what the future
>>>> might hold, like this one. I'm not totally sold, but the scope isn't
>>>> crazy. It's mostly a UI on top of the existing API.
>>>>
>>>> Historically, experimental or alternate components have lived in the
>>>> main branch, but the experimental folder. That lets them be part of
>>>> the same process as the rest of the code, ensures code reviews as they
>>>> progress, and the CI will keep everything in license compliance.
>>>>
>>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
>>>> <Br...@comcast.com> wrote:
>>>>>
>>>>> Branching is fine with me, I doubt I have permission to create a branch
>>>> myself, though.
>>>>>
>>>>> As an aside based on that: should `traffic_router_golang` also be moved
>>>> to a branch? I think the branch idea is better than having an
>>>> `experimental` directory. Or maybe that experiment is dead and should just
>>>> be removed instead? The last change was 10 months ago.
>>>>> ________________________________________
>>>>> From: Gray, Jonathan <Jo...@comcast.com>
>>>>> Sent: Wednesday, April 10, 2019 9:09 AM
>>>>> To: dev@trafficcontrol.apache.org
>>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>>>> Self-Service
>>>>>
>>>>> Instead of merging it into master, could we merge it to a feature branch
>>>> like `experimental/TP.rewrite` if there is a desire for collaborative
>>>> efforts. This would allow changes to flow in without adding more code to
>>>> our normal review processes and polluting the changelog with WIP until it's
>>>> done and ready to be merged. As an additional bonus it provides a more
>>>> stable development for the new work since you'd be choosing when to pay the
>>>> merge costs of ongoing master changes.
>>>>>
>>>>> Jonathan G
>>>>>
>>>>>
>>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
>>>> wrote:
>>>>>
>>>>> I guess that depends what you mean by "we". I personally think it's
>>>> worthwhile, and I'll probably keep working on it until it reaches feature
>>>> parity with the existing TP.
>>>>>
>>>>> I'm not saying development on the existing AngularJS-based TP should
>>>> stop in the meantime, just that self-service be implemented separately in a
>>>> more modern and flexible framework. Then - and only then - should we
>>>> consider replacing the old TP with the new. Slowly, over time. The current
>>>> TP was built for admins, so I don't think it'd actually be more work to
>>>> implement a customer-facing interface this way than restructuring the
>>>> existing TP to support it.
>>>>> ________________________________________
>>>>> From: Hank Beatty <hb...@apache.org>
>>>>> Sent: Wednesday, April 10, 2019 8:38 AM
>>>>> To: dev@trafficcontrol.apache.org
>>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>>>> Self-Service
>>>>>
>>>>> Hello,
>>>>>
>>>>> Are we seriously considering totally re-writing another component?
>>>>>
>>>>> -Hank
>>>>>
>>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
>>>>>> Some of you may have heard, but about two and a half weeks ago I
>>>> opened a Pull Request to add something to the `/experimental` directory.
>>>> It's basically a re-implementation of Traffic Portal, which I think is
>>>> beneficial not only because Traffic Portal wasn't designed with
>>>> self-service in mind, but also because it cleans up a few issues on the
>>>> development side. First of all, it uses the most recent LTS version of
>>>> Angular, while the one on which Traffic Portal is currently based is now
>>>> deprecated (this new version can also compile projects for Electron, which
>>>> would make TP distributable as a standalone/mobile app). It also uses
>>>> Typescript which compiles more cleanly to an overall smaller product, and
>>>> is much easier to read, write and document. Remember the SCSS compiler
>>>> issues (compass) we keep having? Angular 7 comes with a compiler at project
>>>> init, so we never need that as an externally-provided dependency again.
>>>> Finally, it already has unit testing and end-to-end testing working in four
>>>> different JS engines.
>>>>>>
>>>>>>
>>>>>> I'm currently looking for a reviewer (
>>>> https://github.com/apache/trafficcontrol/pull/3419) and you can read more
>>>> about what's implemented there, but a short summary:
>>>>>>
>>>>>>
>>>>>> * Login/authentication and API proxy
>>>>>> * Delivery Service view with bandwidth charts
>>>>>> * New Delivery Service creation targeted at self-service users
>>>> with limited advanced editing options
>>>>>>
>>>>>> * User listing (read-only)
>>>>>>
>>>>>> * Preliminary HTTPS support (currently only listens on 'localhost')
>>>>>>
>>>>>>
>>>>>> Plus, if I do say so myself, it all looks pretty snappy on every
>>>> screen I could test.
>>>>>>
>>>>>>
>>>>>> Feedback is also appreciated, especially concerning the "New
>>>> Delivery Service" form.
>>>>>>
>>>>>
>>>>>
>>>>
>>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Rawlin Peters <ra...@gmail.com>.
Yeah, I think this is just the nature of Javascript UI frameworks and
the pace at which they are advancing, but eventually we will have to
get off of AngularJS anyway since it will no longer be supported after
June 30, 2021: https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c.
So maybe it makes the most sense to try to get ahead of that and
implement any significant new self-service features in TPv2 rather
than trying to tack self-service features onto the existing TP. At
least it seems like Angular 2+ (currently at 7 now) has some better
staying power and clear upgrade paths.
- Rawlin
On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan
<Br...@comcast.com> wrote:
>
> They can be. There's no reason they can't. But the framework it's built on is on life support, TS > JS, fragile dependencies etc. etc.
>
> But the upshot is that I believe the effort to support self service would be just as much work either way, but done this way we eliminate/mitigate those problems at the same time.
> ________________________________________
> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
> Sent: Wednesday, April 10, 2019 3:55 PM
> To: dev@trafficcontrol.apache.org
> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
>
> Why can’t the form wizards and other self-service features be built into the existing AngularJS Traffic Portal code?
>
> —Eric
>
>
> > On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com> wrote:
> >
> > I think I agree with Chris about just using the "experimental" folder as we
> > always have. Then it's pretty easy to look in there and see what's
> > "cooking":
> >
> > experimental
> > - traffic_router_golang
> > - traffic-portal-angular7
> > - traffic_ops_ruby_on_rails (just kidding :) )
> >
> > Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences
> > for TP:
> >
> > 1. Admin/ops type users
> > 2. self-service type users
> >
> > TP works well for #1 but not really for #2. The trick is to build a UI that
> > works well for both OR have 2 distinct UIs. As developers, we don't like
> > the idea of 2 UIs as that sounds like double the UI work when something
> > changes.
> >
> > So we could either:
> >
> > a. make TP (angularJS) more self-service friendly
> > b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and
> > such) and focus on ds, user and tenant management and then slowly port the
> > rest of TP functionality into it
> > c. support 2 distinct UIs
> >
> > I think "b" makes sense and the effort can start (as many of our efforts
> > do) as "experimental" and if it gets legs maybe it does replace TP or maybe
> > it doesn't and it simply becomes a UI that you can use (or not use) to
> > solve ds/user/tenant management in a simple/self-service type way.
> >
> > Jeremy
> >
> > On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com> wrote:
> >
> >>> Are we seriously considering totally re-writing another component?
> >>
> >> Depends how you count it. One of the most important parts of the
> >> previous re-write (still in progress) is the "separation of powers"
> >> that makes things like this relatively non-destructive and able to be
> >> managed in parallel. I like experimental pokes into what the future
> >> might hold, like this one. I'm not totally sold, but the scope isn't
> >> crazy. It's mostly a UI on top of the existing API.
> >>
> >> Historically, experimental or alternate components have lived in the
> >> main branch, but the experimental folder. That lets them be part of
> >> the same process as the rest of the code, ensures code reviews as they
> >> progress, and the CI will keep everything in license compliance.
> >>
> >> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
> >> <Br...@comcast.com> wrote:
> >>>
> >>> Branching is fine with me, I doubt I have permission to create a branch
> >> myself, though.
> >>>
> >>> As an aside based on that: should `traffic_router_golang` also be moved
> >> to a branch? I think the branch idea is better than having an
> >> `experimental` directory. Or maybe that experiment is dead and should just
> >> be removed instead? The last change was 10 months ago.
> >>> ________________________________________
> >>> From: Gray, Jonathan <Jo...@comcast.com>
> >>> Sent: Wednesday, April 10, 2019 9:09 AM
> >>> To: dev@trafficcontrol.apache.org
> >>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> >> Self-Service
> >>>
> >>> Instead of merging it into master, could we merge it to a feature branch
> >> like `experimental/TP.rewrite` if there is a desire for collaborative
> >> efforts. This would allow changes to flow in without adding more code to
> >> our normal review processes and polluting the changelog with WIP until it's
> >> done and ready to be merged. As an additional bonus it provides a more
> >> stable development for the new work since you'd be choosing when to pay the
> >> merge costs of ongoing master changes.
> >>>
> >>> Jonathan G
> >>>
> >>>
> >>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
> >> wrote:
> >>>
> >>> I guess that depends what you mean by "we". I personally think it's
> >> worthwhile, and I'll probably keep working on it until it reaches feature
> >> parity with the existing TP.
> >>>
> >>> I'm not saying development on the existing AngularJS-based TP should
> >> stop in the meantime, just that self-service be implemented separately in a
> >> more modern and flexible framework. Then - and only then - should we
> >> consider replacing the old TP with the new. Slowly, over time. The current
> >> TP was built for admins, so I don't think it'd actually be more work to
> >> implement a customer-facing interface this way than restructuring the
> >> existing TP to support it.
> >>> ________________________________________
> >>> From: Hank Beatty <hb...@apache.org>
> >>> Sent: Wednesday, April 10, 2019 8:38 AM
> >>> To: dev@trafficcontrol.apache.org
> >>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
> >> Self-Service
> >>>
> >>> Hello,
> >>>
> >>> Are we seriously considering totally re-writing another component?
> >>>
> >>> -Hank
> >>>
> >>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
> >>>> Some of you may have heard, but about two and a half weeks ago I
> >> opened a Pull Request to add something to the `/experimental` directory.
> >> It's basically a re-implementation of Traffic Portal, which I think is
> >> beneficial not only because Traffic Portal wasn't designed with
> >> self-service in mind, but also because it cleans up a few issues on the
> >> development side. First of all, it uses the most recent LTS version of
> >> Angular, while the one on which Traffic Portal is currently based is now
> >> deprecated (this new version can also compile projects for Electron, which
> >> would make TP distributable as a standalone/mobile app). It also uses
> >> Typescript which compiles more cleanly to an overall smaller product, and
> >> is much easier to read, write and document. Remember the SCSS compiler
> >> issues (compass) we keep having? Angular 7 comes with a compiler at project
> >> init, so we never need that as an externally-provided dependency again.
> >> Finally, it already has unit testing and end-to-end testing working in four
> >> different JS engines.
> >>>>
> >>>>
> >>>> I'm currently looking for a reviewer (
> >> https://github.com/apache/trafficcontrol/pull/3419) and you can read more
> >> about what's implemented there, but a short summary:
> >>>>
> >>>>
> >>>> * Login/authentication and API proxy
> >>>> * Delivery Service view with bandwidth charts
> >>>> * New Delivery Service creation targeted at self-service users
> >> with limited advanced editing options
> >>>>
> >>>> * User listing (read-only)
> >>>>
> >>>> * Preliminary HTTPS support (currently only listens on 'localhost')
> >>>>
> >>>>
> >>>> Plus, if I do say so myself, it all looks pretty snappy on every
> >> screen I could test.
> >>>>
> >>>>
> >>>> Feedback is also appreciated, especially concerning the "New
> >> Delivery Service" form.
> >>>>
> >>>
> >>>
> >>
>
Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Fieck, Brennan" <Br...@comcast.com>.
They can be. There's no reason they can't. But the framework it's built on is on life support, TS > JS, fragile dependencies etc. etc.
But the upshot is that I believe the effort to support self service would be just as much work either way, but done this way we eliminate/mitigate those problems at the same time.
________________________________________
From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <ef...@cisco.com.INVALID>
Sent: Wednesday, April 10, 2019 3:55 PM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ Self-Service
Why can’t the form wizards and other self-service features be built into the existing AngularJS Traffic Portal code?
—Eric
> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <mi...@gmail.com> wrote:
>
> I think I agree with Chris about just using the "experimental" folder as we
> always have. Then it's pretty easy to look in there and see what's
> "cooking":
>
> experimental
> - traffic_router_golang
> - traffic-portal-angular7
> - traffic_ops_ruby_on_rails (just kidding :) )
>
> Now regarding TP and TPv2. At comcast, there are (or will be) 2 audiences
> for TP:
>
> 1. Admin/ops type users
> 2. self-service type users
>
> TP works well for #1 but not really for #2. The trick is to build a UI that
> works well for both OR have 2 distinct UIs. As developers, we don't like
> the idea of 2 UIs as that sounds like double the UI work when something
> changes.
>
> So we could either:
>
> a. make TP (angularJS) more self-service friendly
> b. create TPv2 (angular7) with self-service in mind (i.e. form wizards and
> such) and focus on ds, user and tenant management and then slowly port the
> rest of TP functionality into it
> c. support 2 distinct UIs
>
> I think "b" makes sense and the effort can start (as many of our efforts
> do) as "experimental" and if it gets legs maybe it does replace TP or maybe
> it doesn't and it simply becomes a UI that you can use (or not use) to
> solve ds/user/tenant management in a simple/self-service type way.
>
> Jeremy
>
> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <al...@gmail.com> wrote:
>
>>> Are we seriously considering totally re-writing another component?
>>
>> Depends how you count it. One of the most important parts of the
>> previous re-write (still in progress) is the "separation of powers"
>> that makes things like this relatively non-destructive and able to be
>> managed in parallel. I like experimental pokes into what the future
>> might hold, like this one. I'm not totally sold, but the scope isn't
>> crazy. It's mostly a UI on top of the existing API.
>>
>> Historically, experimental or alternate components have lived in the
>> main branch, but the experimental folder. That lets them be part of
>> the same process as the rest of the code, ensures code reviews as they
>> progress, and the CI will keep everything in license compliance.
>>
>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan
>> <Br...@comcast.com> wrote:
>>>
>>> Branching is fine with me, I doubt I have permission to create a branch
>> myself, though.
>>>
>>> As an aside based on that: should `traffic_router_golang` also be moved
>> to a branch? I think the branch idea is better than having an
>> `experimental` directory. Or maybe that experiment is dead and should just
>> be removed instead? The last change was 10 months ago.
>>> ________________________________________
>>> From: Gray, Jonathan <Jo...@comcast.com>
>>> Sent: Wednesday, April 10, 2019 9:09 AM
>>> To: dev@trafficcontrol.apache.org
>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>> Self-Service
>>>
>>> Instead of merging it into master, could we merge it to a feature branch
>> like `experimental/TP.rewrite` if there is a desire for collaborative
>> efforts. This would allow changes to flow in without adding more code to
>> our normal review processes and polluting the changelog with WIP until it's
>> done and ready to be merged. As an additional bonus it provides a more
>> stable development for the new work since you'd be choosing when to pay the
>> merge costs of ongoing master changes.
>>>
>>> Jonathan G
>>>
>>>
>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <Br...@comcast.com>
>> wrote:
>>>
>>> I guess that depends what you mean by "we". I personally think it's
>> worthwhile, and I'll probably keep working on it until it reaches feature
>> parity with the existing TP.
>>>
>>> I'm not saying development on the existing AngularJS-based TP should
>> stop in the meantime, just that self-service be implemented separately in a
>> more modern and flexible framework. Then - and only then - should we
>> consider replacing the old TP with the new. Slowly, over time. The current
>> TP was built for admins, so I don't think it'd actually be more work to
>> implement a customer-facing interface this way than restructuring the
>> existing TP to support it.
>>> ________________________________________
>>> From: Hank Beatty <hb...@apache.org>
>>> Sent: Wednesday, April 10, 2019 8:38 AM
>>> To: dev@trafficcontrol.apache.org
>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/
>> Self-Service
>>>
>>> Hello,
>>>
>>> Are we seriously considering totally re-writing another component?
>>>
>>> -Hank
>>>
>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote:
>>>> Some of you may have heard, but about two and a half weeks ago I
>> opened a Pull Request to add something to the `/experimental` directory.
>> It's basically a re-implementation of Traffic Portal, which I think is
>> beneficial not only because Traffic Portal wasn't designed with
>> self-service in mind, but also because it cleans up a few issues on the
>> development side. First of all, it uses the most recent LTS version of
>> Angular, while the one on which Traffic Portal is currently based is now
>> deprecated (this new version can also compile projects for Electron, which
>> would make TP distributable as a standalone/mobile app). It also uses
>> Typescript which compiles more cleanly to an overall smaller product, and
>> is much easier to read, write and document. Remember the SCSS compiler
>> issues (compass) we keep having? Angular 7 comes with a compiler at project
>> init, so we never need that as an externally-provided dependency again.
>> Finally, it already has unit testing and end-to-end testing working in four
>> different JS engines.
>>>>
>>>>
>>>> I'm currently looking for a reviewer (
>> https://github.com/apache/trafficcontrol/pull/3419) and you can read more
>> about what's implemented there, but a short summary:
>>>>
>>>>
>>>> * Login/authentication and API proxy
>>>> * Delivery Service view with bandwidth charts
>>>> * New Delivery Service creation targeted at self-service users
>> with limited advanced editing options
>>>>
>>>> * User listing (read-only)
>>>>
>>>> * Preliminary HTTPS support (currently only listens on 'localhost')
>>>>
>>>>
>>>> Plus, if I do say so myself, it all looks pretty snappy on every
>> screen I could test.
>>>>
>>>>
>>>> Feedback is also appreciated, especially concerning the "New
>> Delivery Service" form.
>>>>
>>>
>>>
>>