Re: Introduce the ability for a user to manage binary types [IGNITE-13154]
Glad to see it coming! That was a pain in the neck. Could we also add a hint to the exception message when a type mismatch happens? Basically, the exception should not only report details about the mismatch but also suggest how to solve it. The text can mention these new control.sh commands and advise to remove the old metadata. - Denis On Thu, Jun 18, 2020 at 7:42 AM Taras Ledkov wrote: > Hi, > > I propose to introduce ability for a user to manage cluster binary types. > This functionality is useful when user needs to change schema without > cluster restart. > > Motivation: > Rid users of manual operations in the folder 'binary_meta' and cluster > restart when they need change schema. > > The proposed implementation contains restrictions (see [1]). > So I guess we add internal API and command for public command line tool > (control.sh) > with mode 'experimental' mode (the property > IGNITE_ENABLE_EXPERIMENTAL_COMMAND must be set). > > Please take a look at the ticket / patch. > > Any comments / suggestions? > > [1]. https://issues.apache.org/jira/browse/IGNITE-13154 > > -- > Taras Ledkov > Mail-To: tled...@gridgain.com > >
Re: [DISCUSSION] Add autocompletion for commands in control.sh
Autocompletion is a separate shell module that required installing along with adding separate modules for each system (git, etc.) It will require used to run script to install it in the system, so I would left it for RPM or DEB packages where that can be managed correctly. > On 18 Jun 2020, at 18:05, Alexey Goncharuk wrote: > > Definitely a +1 from me for moving the CLI tooling to a separate module. > > As for the autocompletion - can you elaborate how it works? Will it require > to run an additional tool when a user hits TAB? Or will it generate an > autocompletion file during the build? Will we require an install step for > Ignite tools for autocompletion to work then?
Re: [DISCUSSION] Add autocompletion for commands in control.sh
Definitely a +1 from me for moving the CLI tooling to a separate module. As for the autocompletion - can you elaborate how it works? Will it require to run an additional tool when a user hits TAB? Or will it generate an autocompletion file during the build? Will we require an install step for Ignite tools for autocompletion to work then?
Re: s390x support for Apache Ignite
Hi Anuja, What is the reason for adding this architecture? Do you have any issues assembling or deploying Ignite on IBM Z (or similar platforms supporting s390x architecture)? I don't think we should bother about TeamCity. It will require to provide the community with IBM-specific hardware. - Denis On Thu, Jun 18, 2020 at 7:55 AM Anuja Jakhade wrote: > > Hi, > > I had raised an issue on Apache Ignite GitHub for adding Travis support for > s390x. > The reply on the issue suggested me to get in contact with the dev list for > how s390x agent can be added to TeamCity. > Can you please guide on the same. > > Regards, > Anuja Jakhade >
s390x support for Apache Ignite
Hi, I had raised an issue on Apache Ignite GitHub for adding Travis support for s390x. The reply on the issue suggested me to get in contact with the dev list for how s390x agent can be added to TeamCity. Can you please guide on the same. Regards, Anuja Jakhade
Introduce the ability for a user to manage binary types [IGNITE-13154]
Hi, I propose to introduce ability for a user to manage cluster binary types. This functionality is useful when user needs to change schema without cluster restart. Motivation: Rid users of manual operations in the folder 'binary_meta' and cluster restart when they need change schema. The proposed implementation contains restrictions (see [1]). So I guess we add internal API and command for public command line tool (control.sh) with mode 'experimental' mode (the property IGNITE_ENABLE_EXPERIMENTAL_COMMAND must be set). Please take a look at the ticket / patch. Any comments / suggestions? [1]. https://issues.apache.org/jira/browse/IGNITE-13154 -- Taras Ledkov Mail-To: tled...@gridgain.com
Re: Reviewer request: [IGNITE-13144] Improve ClusterState enum and other minor improvements for the cluster read-only mode.
Guys, could someone review my patch, please? вт, 16 июн. 2020 г. в 10:50, Sergey Antonov : > Hello, Igniters! > > I'd like to get a review of the ticket [1]. The patch is ready [2]. > Can someone look at it, please? > > [1] https://issues.apache.org/jira/browse/IGNITE-13144 > [2] https://github.com/apache/ignite/pull/7924 > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13163) Data storage metrics are null if persistence not configured
Ilya Kasnacheev created IGNITE-13163: Summary: Data storage metrics are null if persistence not configured Key: IGNITE-13163 URL: https://issues.apache.org/jira/browse/IGNITE-13163 Project: Ignite Issue Type: Bug Components: general Reporter: Ilya Kasnacheev ignite.dataStorageMetrics() returns null if persistence in cluster is off. This is unexpected, not mentioned in javadocs, should be fixed. See attached test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13162) Slim docker image for Apache Ignite
Ilya Kasnacheev created IGNITE-13162: Summary: Slim docker image for Apache Ignite Key: IGNITE-13162 URL: https://issues.apache.org/jira/browse/IGNITE-13162 Project: Ignite Issue Type: New Feature Components: build Reporter: Ilya Kasnacheev We need to introduce slim docker image in line with slim binary downloadable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13161) Document & make available slim binary release
Ilya Kasnacheev created IGNITE-13161: Summary: Document & make available slim binary release Key: IGNITE-13161 URL: https://issues.apache.org/jira/browse/IGNITE-13161 Project: Ignite Issue Type: New Feature Components: documentation Affects Versions: 2.9 Reporter: Ilya Kasnacheev We can do that once 2.9 is out. Downloads page should be updated as well as web site and some docs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Slim binary release and docker image for Apache Ignite
Hello! I have fixed nightly and release builds. They should now build apache-ignite-slim. Please contact me if that does not happen. Regards, -- Ilya Kasnacheev ср, 17 июн. 2020 г. в 17:00, Ilya Kasnacheev : > Hello! > > I have just merged slim binary release to master. > > I will now try to tweak nightly builds TC suite to build this package > also. It may be broken for some brief period of time. > > Regards, > -- > Ilya Kasnacheev > > > вт, 10 мар. 2020 г. в 18:24, Ilya Kasnacheev : > >> Hello! >> >> I understand that procedures are courtesy Apache Ignite, but I assume >> that you went through them and can now repeat them reproducibly. >> >> Thank you! >> -- >> Ilya Kasnacheev >> >> >> вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov : >> >>> Ilya, >>> >>> It is not "mine" generic release procedures they are "ours" :-) >>> I've created the issue [1] based on current discussion thread. >>> >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-12765 >>> >>> On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev >>> wrote: >>> > >>> > Hello! >>> > >>> > It is currently included. >>> > >>> > Maxim, can you prepare a slim release package based on your generic >>> release >>> > procedures? We could take a look at it and then perhaps add it to >>> downloads >>> > page officially. >>> > >>> > What do you think? >>> > >>> > Regards, >>> > -- >>> > Ilya Kasnacheev >>> > >>> > >>> > пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov : >>> > >>> > > Ilya, >>> > > >>> > > `ignite-compress` is necessary for `wal page snapshot compression` >>> [1] >>> > > which in turn shows very good performance results. So, I suppose, >>> it's >>> > > better to include it to the "slim" binary. >>> > > >>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 >>> > > >>> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev < >>> ilya.kasnach...@gmail.com> >>> > > wrote: >>> > > > >>> > > > Hello! >>> > > > >>> > > > I added these because they are infrastructural to Ignite, as >>> opposed to >>> > > > integrations. They are also both very slim. >>> > > > >>> > > > Regards, >>> > > > -- >>> > > > Ilya Kasnacheev >>> > > > >>> > > > >>> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < >>> > > > stephen.darling...@gridgain.com>: >>> > > > >>> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I >>> know very >>> > > few >>> > > > > people who use either. >>> > > > > >>> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev < >>> ilya.kasnach...@gmail.com> >>> > > > > wrote: >>> > > > > > >>> > > > > > Hello! >>> > > > > > >>> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* >>> > > > > > >>> > > > > > I have prepared assemblies for Apache Ignite slim packaging: >>> > > > > > https://github.com/apache/ignite/tree/ignite-slim >>> > > > > > >>> > > > > > It is based on ignite-2.8 >>> > > > > > >>> > > > > > You can build it with mvn initialize -Prelease,lgpl >>> > > > > -Dignite.edition=apache- >>> > > > > > ignite-slim after a normal release build. >>> > > > > > >>> > > > > > Please consider the contents of resulting >>> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip >>> > > > > > It will be a 65M download as opposed to main 455M >>> apache-ignite-2.8.0 >>> > > > > > distribution. >>> > > > > > >>> > > > > > My suggestion is that we can publish it as a post-release step >>> since >>> > > it >>> > > > > > does not affect the release in any way. If we do, we should >>> probably >>> > > > > > indicate size for every kind of artifact in our download >>> section, so >>> > > our >>> > > > > > users can choose based on that information. >>> > > > > > >>> > > > > > The following modules are included: >>> > > > > > >>> > > > > > libs: >>> > > > > > core/shmem/jcache >>> > > > > > ignite-indexing >>> > > > > > ignite-spring >>> > > > > > >>> > > > > > libs/optional: >>> > > > > > ignite-compress ignite-kubernetes ignite-log4j2 >>> > > ignite-rest-http >>> > > > > > ignite-spring-data_2.2 >>> > > > > > ignite-jta ignite-log4j ignite-opencensus >>> ignite-slf4j >>> > > > > > ignite-urideploy >>> > > > > > >>> > > > > > I have kept examples, but removed benchmarks. sqlline still >>> present, >>> > > of >>> > > > > > course. >>> > > > > > >>> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not >>> > > update >>> > > > > > often enough (such as guava, curator, jackson), and which may >>> form an >>> > > > > > attack surface. >>> > > > > > >>> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper >>> users, since >>> > > > > they >>> > > > > > can re-import these dependencies with more recent versions >>> using >>> > > maven or >>> > > > > > gradle. >>> > > > > > But for our users who rely on binary package for all JARs, >>> outdated >>> > > > > > dependencies may pose a problem. >>> > > > > > >>> > > > > > Therefore my opinion is to exclude this dependency and not put >>> our >>> > > faith >>> > > > > on >>> > > > > > zookeeper dependency version. >>> > > > > > >>>
