+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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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) > > > <[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. > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >> > > > > > > > > > > > >
