You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Fieck, Brennan" <Br...@comcast.com> on 2019/04/10 14:58:41 UTC
Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ Self-Service
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.
>>>>
>>>
>>>
>>
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>.
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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Jeremy Mitchell <mi...@gmail.com>.
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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Chris Lemmons <al...@gmail.com>.
> 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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Fieck, Brennan" <Br...@comcast.com>.
> By "we" I mean everyone involved in the Traffic Control project.
Ah. Well, that's sort of what I was hoping to find out with this discussion.
> Is it not possible to add all of the features you are referring to in
> this email to the existing Traffic Portal code?
Oh, of course it's _possible_. It's just that the existing Traffic Portal code is using a dozen deprecated frameworks and has fragile external dependencies. The migration to a newer version of Angular _should_ happen at some point anyway, and as Jeremy mentioned there is no simple upgrade path from AngularJS to Angular because they aren't the same thing, really. And because there's no existing Self-Service scaffold to build on, it's my opinion that implementing it in the existing Traffic Portal would be the same amount of work (actually more imo, but that's certainly up for debate) as writing it fresh in a more modern way. Doing so will also provide the benefit of easing transition between AngularJS TP and Angular TP because a foundation for the latter will already exist. So I think that doing it this way is roughly the same amount of work _now_ and saves us potentially a ton of work _later_.
> I'm just wondering why we (Traffic Control project) need another
> re-write of an existing component.
That's a fair point, but so far it _isn't_ a re-write. The idea is implementing functionality that the existing Traffic Portal doesn't have - and wasn't designed for - and I think that at some point in the future the newer TP should "eat" the old one so that we wind up with one UI. But even if everyone else hates that idea, I still think it's worthwhile to go about implementing Self-Service like this from the ground-up because it'll make corner cases where advanced TP functionality peeks through easier to catch (because it won't exist yet :P). Plus have I mentioned that writing, reading, and testing Typescript is way easier than Javascript?
@Jonathan well, the hope is that other devs will want to work on this, but I can't guarantee that.
________________________________________
From: Gray, Jonathan <Jo...@comcast.com>
Sent: Wednesday, April 10, 2019 9:36 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Depends on if it's under active development by more than one person imho. I have an experimental PR out there for a sample graphql API, but I don't really expect anyone to merge it because it doesn't integrate with the solution. If something is a collaborative effort by the community I think it warrants a feature branch, but something being developed by a single developer is easier to just keep in a fork with an experimental PR (maybe even a new shiny draft PR). I make that distinction just because our mainline git branches come with overhead to maintain/merge/review and it removes the single contributors ability to rebase and force-push.
Jonathan G
On 4/10/19, 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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
Depends on if it's under active development by more than one person imho. I have an experimental PR out there for a sample graphql API, but I don't really expect anyone to merge it because it doesn't integrate with the solution. If something is a collaborative effort by the community I think it warrants a feature branch, but something being developed by a single developer is easier to just keep in a fork with an experimental PR (maybe even a new shiny draft PR). I make that distinction just because our mainline git branches come with overhead to maintain/merge/review and it removes the single contributors ability to rebase and force-push.
Jonathan G
On 4/10/19, 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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Fieck, Brennan" <Br...@comcast.com>.
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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
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] Re: Traffic Portal Angular7 rewrite w/ Self-Service
Posted by Hank Beatty <hb...@apache.org>.
Hello,
By "we" I mean everyone involved in the Traffic Control project.
Is it not possible to add all of the features you are referring to in
this email to the existing Traffic Portal code?
I'm just wondering why we (Traffic Control project) need another
re-write of an existing component.
-Hank
On 4/10/19 10:58 AM, Fieck, Brennan 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.
>>