The old UI is not perfect, and it cannot do everything, i.e. you cannot choose replica types when creating a collection, it has no support for authoring Autoscaling rules, no support for doing backup/restore etc. The dream would of course be that the new UI is so sweet to work with that almost any new feature added to the backend also gets a simple UI component, if not in the same release or by the same developer, then at least a release or two further down the road.
Why I put the three github links in this thread was not because it is a thorough survey of everything that is out there. It was 30min search on github just to find prior art. I expect whoever drives the SIP work to do even more thorough investigation as to what our options are. Not being a full-time frontend engineer, I cannot speak for Angular’s future. It would of course be a pity if we choose the framework that happens to be the next one to go extinct :) so Vue feels more secure than Angular but what do I know? Finally, I hope the SIP, in addition to surveying existing code and possible frameworks, should also list the deployment options we have (jetty inside solr app, jetty separate webapp, jetty, different port, standalone node, package system…), and recommend one. Perhaps lay out a roadmap starting with drop-in replacement as first step? When it comes to the question of covernance and where the code lives, I came to think of another option we have not yet discussed. It goes like this: Solr Admin UI could be another sub project of Lucene/Solr, as PyLucene is, with its own git repo and its own releases. The release would be a ZIP with the compiled UI and instructions on how to deploy as part of Solr or standalone. Then Solr core build would pull in the zip as a dependency and serve it up as today or in a new way. Benefits of this solution includes: + The core codebase remains Java only (with versioned UI as dependency) + The UI is still governed and released by the project + The UI gets its own repo, and its own GitHub home, which can maybe easier attract PRs from newcomers? + UI can do releases out-of-band. Solr can stay on same UI-release for several versions if it wants, and we can publish UI-only bugfixes for XSS or whatever, with easy patch instructions + End users may choose to disable UI in solr.in.sh and deploy the UI release standalone, i.e. more choice The downsides are of course - More moving parts, separate releases, more bureaucracy - May be a problem to obtain enough PMC members vote (ask Andi), need a separate smoketester? - UI is not tested as part of Solr, breaking changes may be merged unnoticed. (This can be mitigated with e2e Jenkins tests) There may be downsides I have not thought of, but interested in your thoughts Jan > 22. apr. 2020 kl. 18:54 skrev Marcus Eagan <[email protected]>: > > Nothing is ever finished. > > Yet I agree with you one hundred percent. I don't like the idea that you can > delete a collection from the UI, but that's just me. I didn't want to get in > to the discussion until I was further along. > > Marcus > > On Wed, Apr 22, 2020 at 9:50 AM Gus Heck <[email protected] > <mailto:[email protected]>> wrote: > Re Parity: If we are going to drop a feature from the UI it should be an > explicit decision to do so. I think until we have either > > 1) a decision to drop (expressed in the SIP or Jira) > 2) a working re-implementation > > For each feature the new UI should not be considered finished. > > > On Wed, Apr 22, 2020 at 12:14 PM Marcus Eagan <[email protected] > <mailto:[email protected]>> wrote: > Parity is not necessarily a good thing. Maintaining most of the existing > functionality is good. I would recommend some of it is removed because it’s > dangerous. > > My choice to pick up the project I did was because it was the most updated of > them all and I can change one variable rather than multiple because the > Angular name was the same. > > Thanks Jan and Houston. I need to try the project out later tonight. > > I’m happy to contribute to any of them. > As for the test, the scaffolds are the first step to adding tests. They can > be added relatively quickly but even the scaffolds ensure the components > compile, which is step forward for the project where it is today. There are a > couple months of work on it. I did not intend for anything to be merged yet, > but for code to exist for people to test it out. > > The Angular project is a pain. However, I will keep the project up and work > to support whatever the community needs. > > My goal is to get an updated Solr Admin UI Im the project to help developers > get started, and improve security. Whichever one the community decides on, I > will work with everyone to help get it done. > > Thank you, > > Marcus > > > On Wed, Apr 22, 2020 at 08:24 Houston Putman <[email protected] > <mailto:[email protected]>> wrote: > I agree with Jan, I think we need some discussions on alternatives and the > pros/cons of each before we invest in implementing a solution. > > I personally have the most experience with React and don't know much about > other frameworks, but I'd love to understand why Angular or Vue.JS might be a > better option. > (Having an implementation to start with is definitely a plus, and it doesn't > look like there is one for React) > > Yasa looks more complete than savantly-net/solr-admin to me, and definitely > warrants at least a look. > > - Houston > > On Wed, Apr 22, 2020 at 7:27 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > I spun up the proposed app for the first time today, clicked around and > browsed the code. > It appears to me that the app is far less developed than I thought, which > agrees well with only 12 commits. > The collections component only knows how to list collections, the «create > collection» button is dead etc. > It will be a HUGE effort to bring this to feature parity with current AdminUI. > I cannot find any substantial tests other than scaffold tests verifying that > ng components are created ok. Could be because there is not that much > functionality to really test yet? > > Which makes me question again the perhaps premature decision on using this > repo as a basis. > > > So I did a quick test with the VueJS based YASA app > (https://github.com/kezhenxu94/yasa <https://github.com/kezhenxu94/yasa>) and > got up and running in a few minutes, with a much more feature complete UI. > It is also a complete drop-in replacement for the old UI, once compiled. > Downside is that it is older and needs upgrade and to play well with CPF. > So let’s step back for a while and not make hasty choices too early. I worked > with VueJS in a project and really like it. Vue is the 2nd coolest kid on the > block after React > according to https://2019.stateofjs.com/front-end-frameworks/ > <https://2019.stateofjs.com/front-end-frameworks/> and Wikipedia just chose > it over React for their UI makeover. > > Anyway, if you want to test YASA locally, here is a 3 minutes recipe for > doing so: > > https://gist.github.com/janhoy/0f7cddc0d92f9e53db7522fe93ff7003 > <https://gist.github.com/janhoy/0f7cddc0d92f9e53db7522fe93ff7003> > > To me, this looks like a much better starting point, and the project has 2x > the contributors, 3x the commits and a MIT license :-) > > Another reason to spend more time in SIP mode, iterating on what is best for > the project, what alternatives were considered and why certain frameworks > were selected/rejected etc etc, before spending much more time coding. > > Jan > > > 22. apr. 2020 kl. 11:30 skrev Noble Paul <[email protected] > > <mailto:[email protected]>>: > > > > As I see it all the 12 commits to that project is made by Jeremy Branham. > > > > Kudos to Jan Høydahl to save Solr from potential lawsuit & > > embarrassment in the future. Awesome, I guess you are a part time > > private detective > > > > On Wed, Apr 22, 2020 at 7:25 PM Ishan Chattopadhyaya > > <[email protected] <mailto:[email protected]>> wrote: > >> > >>> The shoulders of the homie that put that scaffold together are broad! > >>> Props to him. > >> Marcus, are you working with Jeremy Branham on this? > >> > >> On Wed, 22 Apr, 2020, 2:25 pm Jan Høydahl, <[email protected] > >> <mailto:[email protected]>> wrote: > >>> > >>> WRT legal aspect, the original git repo > >>> https://github.com/savantly-net/solr-admin > >>> <https://github.com/savantly-net/solr-admin> does not say anything about > >>> copyright or license. I encourage you to reach out to the copyright > >>> holder to let them/him know about your intentions and get a temporary OK. > >>> They may later need to sign a code grant (SGA) in order for the project > >>> to legally integrate the code. > >>> > >>> Jan > >>> > >>> 22. apr. 2020 kl. 07:42 skrev Mike Drob <[email protected] > >>> <mailto:[email protected]>>: > >>> > >>> In phase 2, will the admin ui be running in the same jetty container as > >>> the solr application? > >>> > >>> On Mon, Apr 20, 2020 at 4:35 PM Marcus Eagan <[email protected] > >>> <mailto:[email protected]>> wrote: > >>>> > >>>> SIP here: > >>>> https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI > >>>> <https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI> > >>>> > >>>> On Mon, Apr 20, 2020 at 9:32 AM Gus Heck <[email protected] > >>>> <mailto:[email protected]>> wrote: > >>>>> > >>>>> If Marcus has ability to edit existing pages, why don't we create the > >>>>> empty page for him and sort out access granting issues later. I'd hate > >>>>> for this much needed SIP to bog down on a technical issue. > >>>>> > >>>>> -Gus > >>>>> > >>>>> On Mon, Apr 20, 2020 at 7:10 AM Jan Høydahl <[email protected] > >>>>> <mailto:[email protected]>> wrote: > >>>>>> > >>>>>> Please retry. I gave edit access to confluence user id > >>>>>> ‘marcussorealheis’. > >>>>>> > >>>>>> Jan > >>>>>> > >>>>>> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan <[email protected] > >>>>>> <mailto:[email protected]>>: > >>>>>> > >>>>>> I do need help. I am not allowed to create a SIP. Or, I have been > >>>>>> unable to create a SIP in three previous attempts. > >>>>>> > >>>>>> Marcus > >>>>>> > >>>>>> On Sun, Apr 19, 2020 at 3:45 AM Jan Høydahl <[email protected] > >>>>>> <mailto:[email protected]>> wrote: > >>>>>>> > >>>>>>> Thanks. The PR is useful for people to try out the UI. But for > >>>>>>> overall replacement plan I really think we neeed that SIP, do you > >>>>>>> still need help with Confluence? > >>>>>>> > >>>>>>> Jan Høydahl > >>>>>>> > >>>>>>> 19. apr. 2020 kl. 06:30 skrev Marcus Eagan <[email protected] > >>>>>>> <mailto:[email protected]>>: > >>>>>>> > >>>>>>> > >>>>>>> I hope everybody is enjoying their weekend and is in good health. > >>>>>>> > >>>>>>> Filed a Jira, made a PR: > >>>>>>> https://issues.apache.org/jira/browse/SOLR-14414 > >>>>>>> <https://issues.apache.org/jira/browse/SOLR-14414> > >>>>>>> > >>>>>>> Still, quite a bit more work to do. I need to spend some time on the > >>>>>>> query screen, improving the cluster view, and adding alias, and more > >>>>>>> tests. The last three should be pretty easy. Would probably spend a > >>>>>>> couple weeks working on style as well, but that can be an ongoing > >>>>>>> effort, just as making it package manager compatible and using v2 > >>>>>>> commands. There are also many areas where the Use of TypeScript or > >>>>>>> the Angular framework will improve. That will come with time, some > >>>>>>> involvement from a few Angular wizards, and a bit of research. > >>>>>>> > >>>>>>> Thank you everyone, > >>>>>>> > >>>>>>> Marcus > >>>>>>> > >>>>>>> On Tue, Apr 14, 2020 at 2:01 PM Marcus Eagan <[email protected] > >>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Gus, At first it looked like it let me, but today it seemed that it > >>>>>>>> did not allow me to create a SIP. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Apr 14, 2020 at 8:57 AM Gus Heck <[email protected] > >>>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>>>> > >>>>>>>>>> First, sorry you’re having problems with Confluence. I suspect the > >>>>>>>>>> issue is permissions. There are only two groups allowed to add > >>>>>>>>>> pages to the SOLR space, “lucene” and “lucene-pmc”. I believe > >>>>>>>>>> these correspond to ASF LDAP groups, which would mean they include > >>>>>>>>>> committers and PMC members only. We can grant you individual > >>>>>>>>>> permission to add/edit pages, however; we’ve done this for a > >>>>>>>>>> handful of others. I could do this for you, just ping me > >>>>>>>>>> off-thread so I can confirm your username. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> If that is the issue, then we should advertise clearly on the SIP > >>>>>>>>> page that non-committers wishing to create a SIP should request > >>>>>>>>> access on this list. That's probably a good mechanic because it > >>>>>>>>> ensures that contact with this list is established first. And it > >>>>>>>>> sounds like confluence is allowing him to start editing and then > >>>>>>>>> throwing away all his work on submission which is VERY bad > >>>>>>>>> behavior... Possibly an INFRA ticket if that is indeed the case... > >>>>>>>>> > >>>>>>>>> @Marcus can you confirm that you tried to create a page, it > >>>>>>>>> appeared to let you and then threw out your work on submission? (or > >>>>>>>>> am I reading what you wrote wrong?) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Marcus Eagan > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Marcus Eagan > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Marcus Eagan > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > >>>>> http://www.the111shift.com <http://www.the111shift.com/> (play) > >>>> > >>>> > >>>> > >>>> -- > >>>> Marcus Eagan > >>>> > >>> > > > > > > -- > > ----------------------------------------------------- > > Noble Paul > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > <mailto:[email protected]> > > For additional commands, e-mail: [email protected] > > <mailto:[email protected]> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > -- > Marcus Eagan > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play) > > > -- > Marcus Eagan >
