Alexey, thanks for sharing details and your reasoning behind the taken
actions. It makes sense. I've updated the machine learning pages on the new
website that will be released in several days.
-
Denis
On Tue, Mar 24, 2020 at 11:07 AM Alexey Zinoviev
wrote:
> Hi, Denis!
>
> Be honest, the
Hi, Denis!
Be honest, the significant amount of the ML contirbutors left the community
previous year in frustration with unfinished parts.
In this situation, I reduced the unsed and broken parts according our
previous discussions peer-to-peer (not on devlist, our mistake) to release
the stable
Alexey,
I missed this thread and only now realized that TensorFlow, genetic
algorithms and some other APIs were expelled from 2.8. I would encourage us
to start a dedicated discussion for any APIs removal or significant changes
to let other community members share their opinions or take
Hi, Igniters.
I'd like to remind you that cluster can be deactivated by user with 3
utilities: control.sh, *JMX and the REST*. Proposed in [1] solution is
not about control.sh. It suggests same approach regardless of the
utility user executes. The task touches *only* *API of the user calls*,
Hi, Igniters.
Note that DeactivateCommand#confirmationPrompt will be ignored in case
of auto confirmation.
I agree that the force flag should be removed when the user data and
datastructures will not be clearing on deactivation. For now, cmd, jmx
and rest interfaces should be covered.
вт, 24
Thank you for the clarification
On Mon, Mar 23, 2020, 11:28 PM Denis Magda wrote:
> Hi Kartik,
>
> Actually, it means quite the opposite. You should fill in the release notes
> field before the ticket is resolved/closed so that a release manager of a
> next Ignite version adds a proper line to
Hello Taras,
> My be add javadoc for each changed parameter instead of list?
Yep, this makes sense to me.
> But we cannot reference internal packages in public API.
Hmm, it is weird that out JMX beans reside are placed in internal packages.
Perhaps, it is just enough to mention that the property
Veena Mithare created IGNITE-12833:
--
Summary: JDBC thin client SELECT hangs under 2.8.0
Key: IGNITE-12833
URL: https://issues.apache.org/jira/browse/IGNITE-12833
Project: Ignite
Issue Type:
Nikolay Izhikov created IGNITE-12834:
Summary: [TeamCity] Suites fails with the execution timeout
Key: IGNITE-12834
URL: https://issues.apache.org/jira/browse/IGNITE-12834
Project: Ignite
Hello Nikolay,
I am talking about the interactive mode of the control utility, which
requires explicit confirmation from the user.
Please take a look at DeactivateCommand#prepareConfirmation and its usages.
It seems to me, this mode has the same aim as the forceDeactivation flag.
We can change
Hi, guys!
I agree that we should rework the security API, but it can take a long
time.
And currently, our users have certain impediments that are blockers for
their job.
I think we have to fix bugs that IEP-41 [1] contains as soon as possible to
support our users.
From my point of view,
We can manage that here.
> On 24 Mar 2020, at 13:29, Dmitriy Pavlov wrote:
>
> Hi,
>
> I could potentially update this version in the source code, but I'm not
> able to deploy new version to the server (since it is now sponsored by
> GrigGain, we need someone who will deploy).
>
> Sincerely,
>
> Hello, Alexey.
>
> I just repeat our agreement to be on the same page
>
> > The confirmation should only present in the user-facing interfaces.
>
> 1. We should add —force flag to the command.sh deactivation command.
> 2. We should throw the exception if cluster has in-memory caches and
>
Hi,
I could potentially update this version in the source code, but I'm not
able to deploy new version to the server (since it is now sponsored by
GrigGain, we need someone who will deploy).
Sincerely,
Dmitriy Pavlov
пн, 23 мар. 2020 г. в 08:59, Zhenya Stanilovsky :
> Igniters, 2.8 version
Hello, Slava.
Are you talking about this commit [1] (sorry for commit message it’s due to the
Github issue)?
The message for this command for now
«Deactivation stopped. Deactivation clears in-memory caches (without
persistence) including the system caches.»
Is it clear enough?
[1]
Hi Nikolay,
> 1. We should add —force flag to the command.sh deactivation command.
I just checked and it seems that the deactivation command
(control-utility.sh) already has a confirmation option.
Perhaps, we need to clearly state the consequences of using this command
with in-memory caches.
Hello, Alexey.
I just repeat our agreement to be on the same page
> The confirmation should only present in the user-facing interfaces.
1. We should add —force flag to the command.sh deactivation command.
2. We should throw the exception if cluster has in-memory caches and
—force=false.
3. We
Igniters, Ivan, Nikolay,
I am strongly against adding confirmation flags to any kind of APIs,
whether we change the deactivation behavior or not (even though I agree
that it makes sense to fix the deactivation to not clean up the in-memory
data). The confirmation should only present in the
>
> I can’t agree with the «temporary» design.
> We have neither design nor IEP or contributor who can fix current behavior.
> And, if I understand Alexey Goncharyuk correctly, current behavior was
> implemented intentionally.
Alex, what do you think? Are we on the same page that desired
Alexey,
That can be another version of our plan. If everyone agrees that
SecurityContext and SecuritySubject should be merged, such fix of thin
clients' issue will bring us closer to the final solution.
Denis, what do you think?
On Tue, Mar 24, 2020 at 10:38 AM Alexei Scherbakov <
Hello, Ivan.
> I believe we should fix the issue instead of adapting API to temporary flaws.
Agree. Let’s fix it.
> I think that clear description of active(false) impact in the documentation
> is more than enough
I can’t agree with this point.
We shouldn’t imply the assumption that every
Thank you for help ezhuravl,
Your proposal sample it is OK.
In my example tests.TestServiceImpl class extends another class with all the
fields (geters and seters) and work methods inside.
In 2.7.6 works in 2.8.0 @ runtime all fields are null on the same
conditions/environment (java 11.0.4).
If
>
> I think the only question is - Do we need —force flag in Java API or not.
From my perspective, there's also no agreement that it should be present
in the thin clients' API. For instance, I think it shouldn't.
As far as I know, IGNITE_REUSE_MEMORY_ON_DEACTIVATE is for *other* purpose.
> Can
Hi, folks.
I'd like to advance the final decision. Is it OK to:
1)Make IgniteService.serviceProxy() return proxy for locally deployed
service too.
2)Make the proxy collect metrics of service method invocations without
any additional conditions, interfaces, options.
3) Deprecate
Why can't we start gradually changing security API right now ?
I see no point in delaying with.
All changes will go to next 2.9 release anyway.
My proposal:
1. Get rid of security context. Doing this will bring security API to more
or less consistent state.
2. Remove IEP-41 because it's no longer
Alexey.
Having the way to silently vanish user data is even worse.
So I’m strictly against removing —force flag.
> 24 марта 2020 г., в 10:16, Alexei Scherbakov
> написал(а):
>
> Nikolay,
>
> I'm on the same page with Ivan.
>
> Having "force" flag in public API as preposterous as having it
Nikolay,
I'm on the same page with Ivan.
Having "force" flag in public API as preposterous as having it in
System.exit.
For me it looks like badly designed API.
If a call to some method is dangerous it should be clearly specified in the
javadoc.
I'm also against some "temporary" API.
We should:
27 matches
Mail list logo
