Hi the Solr Community
I’m the author of YASA (http://github.com/kezhenxu94/yasa), which is another
Solr Admin.
First thank you Jan for bringing YASA to the discussion, I just read the full
thread to hopefully get the full context.
I created YASA about 1.5 years ago, and it’s inactively
Gus, sorry for the delay. I did not see this email probably because of a
draft. There is module loader known as Webpack that has a feature known as
Hot Module Reload that enables hot reloads and preserves state when most
changes are made. It can be used with any framework. See here:
>From this one article (probably should read several) angular has a higher
learning curve, but a better tooling system, and is better for a one-page
app style - from the descriptions I tend to suspect there's also a greater
chance of react/vue turning into mush in the hands of less experienced UI
Jan, I think this is a great option. Angular's future is probably < 5
years. More and more people move to React and Vue every day it seems. Very
occasionally, people move to StencilJS (which we should avoid like the
plague). At least, thee insights are what the market and my friends tell me.
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
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 wrote:
> Re Parity:
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,
Also, as an aside, if the community decides to go with Vue, let me know. I
like it a lot more and had more experience with it than Angular in its new
carnation. I would be happy to help update YASA. I won't get into all the
UX considerations if it is more feature complete as much as I would update
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
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
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
> Kudos to Jan Høydahl to save Solr from potential lawsuit &
> embarrassment in the future.
Haha, I don't think there'll be any lawsuit or embarrassment. Jeremy
Branham has shared this on SOLR-12276. He might be willing to work on
this.
On Wed, Apr 22, 2020 at 3:01 PM Noble Paul wrote:
>
> As I
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
wrote:
>
> > The
> 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, wrote:
> WRT legal aspect, the original git repo
> https://github.com/savantly-net/solr-admin does not say
WRT legal aspect, the original git repo
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
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 wrote:
> SIP here:
> https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI
>
> On Mon, Apr 20, 2020 at 9:32 AM Gus Heck wrote:
>
>> If
SIP here:
https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI
On Mon, Apr 20, 2020 at 9:32 AM Gus Heck 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
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 wrote:
> Please retry. I gave edit access to
Please retry. I gave edit access to confluence user id ‘marcussorealheis’.
Jan
> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan :
>
> 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
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 wrote:
> Thanks. The PR is useful for people to try out the UI. But for overall
> replacement plan I really think we neeed
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 :
>
>
> I hope everybody is enjoying their weekend and is in good
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
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
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 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
>
> 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
Cassandra, Jan, et al.,
Looks like I cannot create a SIP. There is a Jira already, but perhaps I
will create a new Jira that answers these two very questions:
My wish for the SIP is to be very clear on exactly how the UI is proposed
shipped and whether any manual steps are needed to
And whether they can coexist at all. From the previous emails it seemed to me
this change will introduce changes to the existing APIS and I that means that
compatibility will be broken. I am also not sure if it we will maintain the
existing UI after that.
On Tue, 14 Apr 2020 09:51:23
Yes, please go through SIP before inviting us to review the actual PR.
And once you re-work the SIP page based on feedback and converge towards
consensus, I’d recommend starting a formal VOTE thread for the SIP, as outlined
in the SIP page. That way people can have a chance to speak up on the
Marcus,
A couple thoughts…
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
Mike and Gus,
I tried to share my SIP after writing it, and then it disappeared. I also
tried to write some and save it, but then it disappeared. I also tried to
write it outside the wiki and paste it again.
I'm not sure what's going on, but I will try again tomorrow I suppose. If I
fail again,
Gus,
SIP sounds good. I will share.
Marcus
On Mon, Apr 13, 2020 at 09:13 Gus Heck wrote:
> Maybe start collecting Design and Design choices in a SIP? This discussion
> has been good and there seems to be consensus that we want a new UI, we
> want it to be a package and we want the package
Maybe start collecting Design and Design choices in a SIP? This discussion
has been good and there seems to be consensus that we want a new UI, we
want it to be a package and we want the package to be available by default
and well tested. "Package" seems to imply that it can be added or removed
or
Hi Marcus,
The mailing list strips attachments for some folks, can you upload the
video somewhere else and link to it for us poor unfortunate souls? Thanks
for your work! Excited to see the progress as it happens.
Mike
On Mon, Apr 13, 2020 at 5:30 AM Marcus Eagan wrote:
> In general, I asked
+1 to David Smiley
On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan wrote:
> I don't see admin UI as non-core. I think that an application UI for
> end-users of an application consumes Solr non-core. I have to resign from
> arguing, though.
>
> I don't consider myself a UI expert. I can do the work.
I don't see admin UI as non-core. I think that an application UI for
end-users of an application consumes Solr non-core. I have to resign from
arguing, though.
I don't consider myself a UI expert. I can do the work.
On Fri, Apr 10, 2020 at 11:42 AM Ishan Chattopadhyaya <
David, you capture my thoughts well.
Having a UI as a package gives users more choice and gives our users more
flexibility.
1. Users would be able to use a latter version of the UI with an older
version of Solr, or vice versa.
2. Users should be able to install multiple types of UI, from
I agree with you.
On Fri, Apr 10, 2020 at 06:22 David Smiley wrote:
> I disagree that "package management frameworks are for loading
> non-essential features or features not enabled by default".
>
> I don't think the proposal of the UI being a "package" (in the new package
> system) implies
I disagree that "package management frameworks are for loading
non-essential features or features not enabled by default".
I don't think the proposal of the UI being a "package" (in the new package
system) implies that the UI (or _any_ package) is not a highly valuable
package that is so highly
I think package management frameworks are for loading non-essential
features or features not enabled by default. On essentialness, experts
should not decide what is essential based on how they use a system. They
should consider the community of users. Regarding UI, it is and should be
enabled by
My 2 cents (again)
if packages are disabled by default , how will UI work?
We can make an exception for this one and enable only this by default
Do we test the UI and certify it?
The UI package can be shipped along with Solr distro ,like the million
other jars that we ship with Solr today and
Solr has always had an admin UI and if anyone wants to propose it should not,
please start another thread or vote about that, and do not divert this thread
which is about how to improve and future proof the Admin UI.
I believe the Admin UI should be strengthened and enhanced, not removed. It
Thanks for your message, Gus. You touched on things I was thinking this morning
as I caught up to the thread, and had started to draft a message about.
I feel like there is an assumption underlying some of our discussion about
packages that says a feature or whatever has to either part of our
Gus:
Very thoughtful post. I think you raise an _extremely_ important point about
“how critical is the UI?” And by extension other packages. If they’re critical
to Solr, the question of how to keep them in sync becomes paramount.
I agree that the admin UI is important, if we have a mechanism
In my view this brings us up against a bit of an existential question. How
do we ensure quality of packages that are key to Solr? I'm sure that there
are folks who don't find the UI very useful, but it's important to others.
The rationale that "elastic keeps their's separate" has to be tempered by
Marcus:
re-reading the thread, it looks to me like the consensus from Noble and Ishan
and Jan is that as long as the new, nifty UI is a separate package, go ahead
and knock yourself out ;). The objection is to making it part of the Solr code
base… We’ll all be thrilled with if we can rip the
Hi,
However I'm not a "UI expert" but I worked on various webapps (Webshops,
Banking clients etc.) And I worked with several js libs (jquery, early
angular, extjs, React, Vue, etc).
>From my experience:
- From technical perspective there will be no "better" choice, all
frameworks has pros and cons
The advantage of hosting this outside are
* You can have ui experts as committers instead of back end devs like us
* You can iterate fast
* Users can update to the new version of UI without reinstalling Solr or
even restarting their nodes
* People can even downgrade to an older version if their
@Marcus Eagan
Is the current UI bad? totally yes.
Is a better UI welcome ? 100%
Is your proposal better ? 100%
My only concern is adding a huge amount of code into our already
bloated codebase
We have multiple options that can work
a) We already add so many jars in our distro. Can this be
Solr developers are not UI experts. We are a search service and such a
service should have nice clean APIs + documentation. Is a UI useful ? yes.
The last thing we want today is another complex component in Solr codebase
that nobody understands or cannot maintain.
So, Solr UI can be hosted
Thanks again Gus.
Lots of people indeed misuse REST so we could go on and on about whether
requests are stateless or not in another thread. Let's spare the group.
I think most everyone on this channel would be in agreement with you on
separate app. I'll be opening a new ticket and a PR that will
While running it in an external node does ensure separability, I don't
think it does a good job of addressing my other point of not needing to
manage a 3rd server. It's still a server if it's started by java, and one
still has to ensure it exists, and it will be extra hard to figure out how
to
I don't think *we* should build a UI. Moreover, I think we shouldn't keep
the current UI. The reason I say this is because as a community we don't
have UI expertise. Hence, I don't want us to support a UI that can break
over time as we add/deprecate/update our features without being able to fix
wrote:
>
> At the risk of displaying my ignorance for the current state of the art in
> front-end dev/tech:
> Why would we need a Node.js backend or any backend for that matter if this
> is purely a browser front-end based UI that will be deployed? I'm aware
> there needs to be a webserver of
I sympathize with what Gus wrote 100%. For "small" users, I even say run
ZK on those Solr nodes if you like, but that still leaves you with 3
machines.
At the risk of displaying my ignorance for the current state of the art in
front-end dev/tech:
Why would we need a Node.js backend or any
Gus,
Your $.02 are worth a lot more than $.02 USD, so thank you.
By separate app, I think I mean to endorse managed by a Node.js process
started by NPM. I don’t think that conflicts with what you have proposed.
The NPM command should be issued by Java || or Bash but I don’t think it
would add
+1 for Angular CLI / Typescript since I've fiddled with this in a minor way
recently, Also MIT license is super friendly.
Separate App - hmm... that's got some attraction, but also gives my stomach
some churning when I think about solr now requiring management of 3
different servers (solr,
Erick—it will be a lot of work. That’s good for me, er, I’m used to it.
Blame Ann Arbor and Solr.
Thanks Jan. I will do my best to move this effort along in a collaborative
yet productive manner. Thanks for the links. I’ve bookmarked them.
Jörn and Alex, I appreciate the input. I think the
I always wondered if Solr could benefit from Language Server Protocol:
https://microsoft.github.io/language-server-protocol/ , at least for
the Query screen. That would have allowed us to integrate with a bunch
of tools automatically rather than having a great query implementation
ourselves.
But
I think standalone would be very useful.
I propose Angular with Typescript - it fits to a more data centric approach
with data types etc.
Maybe even two types of UIs - Admin UI and a simple Search UI.
> Am 06.04.2020 um 16:53 schrieb Jan Høydahl :
>
> Thanks for kickstarting this and
Thanks for kickstarting this and bringing some fresh blood and enthusiasm :)
Looks like others have had similar wish for a standalone Solr Admin App, here’s
a quick GitHub search for inspiration:
https://github.com/savantly-net/solr-admin (Angular, nice screenshots, 1y old)
59 matches
Mail list logo
