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) <[email protected]> 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 <[email protected]> > 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 > > <[email protected]> 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) <[email protected]> > >> Sent: Wednesday, April 10, 2019 3:55 PM > >> To: [email protected] > >> 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 <[email protected]> > 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 <[email protected]> > 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 > >>>> <[email protected]> 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 <[email protected]> > >>>>> Sent: Wednesday, April 10, 2019 9:09 AM > >>>>> To: [email protected] > >>>>> 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" <[email protected]> > >>>> 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 <[email protected]> > >>>>> Sent: Wednesday, April 10, 2019 8:38 AM > >>>>> To: [email protected] > >>>>> 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. > >>>>>> > >>>>> > >>>>> > >>>> > >> > >
