I agree in principle that there should be a way to download,store and restore configuration. Isn't it better achieved through the configset API?
like bin/solr save-config gettingstarted <gettingstarted.zip> bin/solr restore-config gettingstarted.zip gettingstarted The problem with saving a single file is that most of them are interdependent and saving a single file alone will break stuff. Users still can download and save a single file from the /admin/zookeeper path. I know it is not very friendly today but we can make it better. On Mon, Sep 26, 2016 at 1:19 PM, Jan Høydahl <jan....@cominvent.com> wrote: > I agree that configuring Solr through the APIs is a better option than > uploading huge XMLs, but we should strive for copy/paste-ability wherever > possible. Ideally it should be possible to store your config/schema > information > in JSON format in GIT and easily POST it after creating a new collection. > The exact same JSON should also be possible to paste into the Admin UI > in order to reproduce the same config/schema. And if you do a GET request > to fetch config/schema, the resulting JSON should ideally be in a format > that > can be again checked into GIT and work when re-creating the same collection. > > Am I right that the bulk API style of embedding the verb into the data > object > itself, e.g. "add-field-type”, is the main source of the difference here, or > is it more > complex than that? Looks to me that the JSON object after “add-field-type” > and > “replace-field-type” is exactly the same as the one you get from a call to > GET /solr/collection/schema/fieldtypes/name?omitHeader=true except from > the latter being wrapped in a “fieldType” object. > > I’m not totally against the “add-field-type” bulk style API, but perhaps we > should also have a GET/POST /solr/collection/schema endpoint which > supports roundtrip of the whole schema in JSON format? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 26. sep. 2016 kl. 09.10 skrev Noble Paul <noble.p...@gmail.com>: > > As the main culprit here let me put forward my few cents > > * The intent is to go away from config files. Users should use APIs to > read and edit configurations. Editing configuration is both error > prone and old school > * I prefer to store everything is JSON. json is modern and simple. > * Even today it is totally possible to put an empty solrconfig.xml and > move everything to configoverlay.json. We may not need to wait for a > big release to do that > * schema is still in xml . there is significant effort involved in > changing it over > * There is a reason why the /config output has solrconfig.xml and > overlay.json merged because they don't make sense individually. params > are not relevant unless there is a reference to it in the config. If a > requesthandler refers to a paramset, we probably should show it inline > * Yes , you can't round-trip the output of config. I thought of adding > a wt which emits a "round-trippable" JSON (like the SHOW CREATE TABLE > functionality in RDBMS) > > On Mon, Sep 26, 2016 at 5:35 AM, Alexandre Rafalovitch > <arafa...@gmail.com> wrote: > > Did you know about configoverlay.json? > > +1 to the discussion. > > Additional fuel to the fire is that /config endpoint will return > solrconfig.xml + overlay.json merged, but not params.json. Confusing. > > Additionally, /config output is JSON but not one that can round-trip AFAIK. > > Regards, > Alex > > > On 26 Sep 2016 12:42 AM, "Shawn Heisey" <apa...@elyograg.org> wrote: > > > There seems to be some fracturing in the format of various Solr > configs. Most of the config uses XML, but some new features in the last > few years are using JSON, particularly where SolrCloud and Zookeeper are > concerned. When notifications about SOLR-9557 came through, it revealed > that there is a config file sitting next to solrconfig.xml named > "params.json" that Solr will use. I wasn't aware of this until reading > that issue. > > This leads me to suggest something rather drastic for 7.0: Consolidate > all configuration formats and agree to consistent format usage unless > there is another major discussion and agreement to change formats. > > I did consider starting this discussion in Jira, but it's fairly major, > so the dev list seemed like the right place to start. > > Comments from some new users have come my way along the lines of "XML is > so 90's ... get with the times!" Image problems like that can be fatal > to a software project, even if there's no technical problem. > > The likely winner in the format discussion is pure unmodified JSON, but > I'm not going to make any assumptions. SOLR-8029 has some format > discussions that may be relevant here. > > IMHO, in order to make the idea successful, Solr 7.0 will need to > automatically convert most configs on startup from the old format to the > new format without user intervention. If there's something that we find > we can't convert automatically, that should result in a failure to > start, with a helpful message so the user has some idea what they need > to do. > > Thoughts? Is this too scary to contemplate? Should I open an umbrella > issue in Jira to get the ball rolling? > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
