Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Ilya. > I'm just saying that we can make it possible as a general principle. +1 to remove as many internal flags as possible. > 7 сент. 2020 г., в 20:20, Ilya Kasnacheev > написал(а): > > Hello! > > I'm not arguing that it should not be discussed. I'm just saying that we > can make it possi

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! I'm not arguing that it should not be discussed. I'm just saying that we can make it possible as a general principle. Regards, -- Ilya Kasnacheev пн, 7 сент. 2020 г. в 19:01, Nikolay Izhikov : > > We can make a compromise here: we list flags explicitly *but then, we > > > > decide that

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

> We can make a compromise here: we list flags explicitly *but then, we > > decide that we don't keep backward compatibility anymore*, since the user > of a new version can check whether their flag is still supported by using > control.sh. It seems removal of any IgniteSystemProperty flag should

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! We do replace some flags with cfg properties, such as inline size, for example. A lot of other flags just duplicate cfg properties. We can make a compromise here: we list flags explicitly *but then, we decide that we don't keep backward compatibility anymore*, since the user of a new versi

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Ilya. > to remove any expectation of forward compatibility. AFAIK we must keep these flags before Ignite3, due to the backward compatibility. > Flags should be a temporary measure This is not true, for now. I feel your pain :) Personally, I hate these flags, also. But they exist and the whol

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Let me notice that in Ignite 3.0 Wishlist [1] we have a bullet point "Remove as many IGNITE_ parameters as possible from IgniteSystemProperties " [1] https://cwiki.apache.org/confluence/display/IGNITE

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! Okay, we can do a simple list of these flags, but I would argue that we should: - Avoid adding extra infrastructure such as flags' human readable names, embedded docs, etc. Flags should be a temporary measure. They are now. Let's not make it look like they're there to stay. - Explicitly men

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

> what’s the logic? I assume that this is a question to the author of these flags. If you have a specific flag you are interested in, please, write it. My point is simple - we already have these flags. We should explain to the user what we have and what can be configured with these flags. Ther

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

But to Ilya’s point, what’s the logic? Why are some things set using IGNITE_ properties, others on the command line and others in IgniteConfiguration? It’s confusing for the user and makes maintenance harder. I’m not necessarily arguing against this change, though. Perfect being the enemy of go

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Ilya. > I think this is a bad idea since it legitimizes wide use of IGNITE_ > properties, which shows weakness of our configuration API, etc. We already have IGNITE options in the product as a part of public API. See `org.apache.ignite.IgniteSystemProperties`. > 7 сент. 2020 г., в 14:40

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello! I think this is a bad idea since it legitimizes wide use of IGNITE_ properties, which shows weakness of our configuration API, etc. My take: All of IGNITE_ properties which are useful (and will go to -X) should instead be turned into configuration/metastore settings. All of IGNITE_ proper

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

I think this is a helpful feature. I have created the issue: https://issues.apache.org/jira/browse/IGNITE-13380

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Denis. Thanks, for the support. The name of the parameter is the matter of discussion, of course. I just take the JVM approach as an example. Let’s go with the -systemProps :) > 21 авг. 2020 г., в 18:04, Denis Magda написал(а): > > Nikolay, > > I fully support the idea as well but won

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Nikolay, I fully support the idea as well but wonder if the "-X" is the best name. Is this a common practice to use the "-X"? Should we consider a longer name such as "-systemProps"? - Denis On Fri, Aug 21, 2020 at 7:57 AM Николай Ижиков wrote: > Yes, of course. > I think we have to make Ign

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Yes, of course. I think we have to make IgniteSystemProperties enum and traverse it in runtime. Отправлено с iPhone > 21 авг. 2020 г., в 17:54, Zhenya Stanilovsky > написал(а): > >  > > Good catch, as for me, do you plan some autogeneration here? > >> >>> Hello, Igniters. >>

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Good catch, as for me, do you plan some autogeneration here?   >  >>  >>>Hello, Igniters. >>> >>>For now, we have dozens of the `IgniteSystemProperties` [1] that can tweak >>>Ignite behaviour in the very wide limits. >>>But, the issue, for the administrator is the following >>> >>>- Documentatio

[DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Igniters. For now, we have dozens of the `IgniteSystemProperties` [1] that can tweak Ignite behaviour in the very wide limits. But, the issue, for the administrator is the following - Documentation about existing properties can be outdated. - The only place of the truth is the source cod