>> . Remove @Deprecated from old API (because it strange to have one
>> deprecated API and second experimental API)
>> 2. Add @IgniteExperimetnal to new API (because... see item. 1)
-1
We should have all the options.
Deprecated -> will be removed at major release (because this way is slow or
The statement seems to be correct for cases when we'd like to perform fast
loading and computation and not afraid of data loss.
Performance boost always means we lose some guarantee.
Let's just update the proposal with the explicit warning that reducing
backups to zero may lead to data loss on any
Looks good to me.
On Thu, Feb 6, 2020 at 11:45 AM Ivan Pavlukhin wrote:
> Igniters,
>
> I raised a PR for a ticket [1] removing section from
> parent pom.xml. I described the motivation in the ticket. Shortly,
> this section has a little meaning today and even worse is misleading.
>
> Please
> I'm quite sure most users do not want to lose data by default.
>
> It's not wise to recommend such thing even with explicit warning.
>
> чт, 6 февр. 2020 г. в 13:30, Anton Vinogradov :
>
> > The statement seems to be correct for cases when we'd like to perform
> fast
> &
Seems, we already started the separation by atomic operations restriction
inside the transactions [1].
See no reason to allow mixes in this case.
[1] https://issues.apache.org/jira/browse/IGNITE-2313
On Tue, Feb 4, 2020 at 2:28 PM Ivan Rakov wrote:
> Igniters,
>
> Apparently it's possible in
-1 Prohibit
On Mon, Feb 10, 2020 at 5:30 PM Alexey Kuznetsov
wrote:
> -1 Prohibit
>
> From my point of view, we should not deprecate the old API if the new API
> is marked as experemental.
>
>
> On Mon, Feb 10, 2020 at 4:47 PM Konstantin Orlov
> wrote:
>
> > -1 Prohibit
> >
> > We should not
at release attempt?
2) Any objection to merging assertion instead of weird return to the master
branch?
3) Any Idea why the exception happens?
[1]
https://gist.githubusercontent.com/anton-vinogradov/834fc63114a3e8d46b89ea4ccec8148b/raw/6438930c7fef119d0ad60df76d821fe7bd100c5e/gistfile1.txt
[2]
https
Also, is it possible to perform the same check on the merge attempt?
Each PR can be merged from GitHub page, can we append check to the "megre
button" flow?
Can we restrict merges bypassing this button?
On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote:
> Should we perform
gt; "Visa" truly works only when master is in the same state during the merge
> as it was during TC run.
>
> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote:
>
> > It seems, this because of IGNITE-12227 fix [1].
> > Main question is "how this may happen
+1 to @IgniteExperimental
On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> After giving it some thought, I agree with Denis - there is nothing wrong
> with exposing the new APIs, we just need to make it clear that we are still
> going to change it.
>
>
It seems, this because of IGNITE-12227 fix [1].
Main question is "how this may happen in case fix got the Visa [2] ?".
[1]
https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles
[2]
Good Idea, this will also check that the release process is alive.
On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Folks, Maxim,
>
> Do you mind if I build the current state of ignite-2.8 branch and upload a
> maven staging as rc0 (step 4.3.2 of the
Everything is fine.
Merged to master branch.
On Fri, Jan 10, 2020 at 9:48 AM Anton Vinogradov wrote:
> >> Does the issue reproduce in
> >> subsequent runs?
> Unfortunately no.
> We performed 30+ runs without "success".
>
> >> I think we can add an a
t; eviction/renting code looks overly complicated, perhaps, there is a bug
> somewhere there? I think we can add an assertion to
> GridDhtLocalPartition#destroy() method to check that reservations is 0 when
> this method is called (there is a check for EVICTED state already there)
>
> --
des leaves almost at the same
> time (perhaps due to some network connectivity issues). With a delay
> recovering multiple failed nodes will be grouped into one recovery
> round (+PME). Correct me if my understanding is wrong. Was there any
> performance measurements for such multiple left nod
Rechecked TC two more times.
Going to merge to master in case no objections here.
On Mon, Dec 23, 2019 at 1:44 PM Anton Vinogradov wrote:
> Igniters,
>
> One more PME optimization ready to be reviewed.
> I found a strange tx recovery delay caused by IGNITE_TX_SALVAGE_TIMEOUT.
&g
ailed node was in the baseline topology? How
> about pure in-memory clusters and clusters with CacheStore?
>
> -
> Denis
>
>
> On Tue, Mar 10, 2020 at 12:40 AM Anton Vinogradov wrote:
>
> > Denis,
> >
> > >> the blocking PME no longer happens if a
Artem,
I've updated the Read Repair page
On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov
wrote:
> Anton,
>
> Could you please review the page about Read Rapair?
>
> https://apacheignite.readme.io/docs/read-repair
>
> -Artem
>
> On 05.03.2020 12:20, Artem Budnikov wrote:
> > OK, I'll recreate it.
Please feel free to share feedback before
> it's published. You can use the comment feature of Google Docs:
>
> https://docs.google.com/document/d/1ssTC1Jf_reqZFWgl4ayhaohiAJCpzdL4tPrHTxvfvAM/edit?usp=sharing
>
>
> @Alexey Zinoviev , @Andrey Gura
> , @Nikolay Izhikov , @Anto
Igniters,
Do we have some feature allows to check nodes aliveness on a regular basis?
Scenario:
Precondition
The cluster has no load but some node's JVM crashed.
Expected actual
The user performs an operation (eg. cache put) related to this node (via
another node) and waits for some timeout
more complex… like there’s the partition loss policy and
> rebalancing doesn’t always happen (configurable, persistence, etc)… but
> broadly it does as you expect.
>
> Regards,
> Stephen
>
> > On 8 Apr 2020, at 08:40, Anton Vinogradov wrote:
> >
> > Ignite
/ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.html
>
> Other people would be better placed to discuss the internals.
>
> Regards.
> Stephen
>
> > On 8 Apr 2020, at 09:32, Anton Vinogradov wrote:
> >
> > Stephe
gnite/blob/e9b3c4cebaecbeec9fa51bd6ec32a879fb89948a/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/messages/TcpDiscoveryStatusCheckMessage.java
> >
> > Regards,
> > Stephen
> >
> >> On 8 Apr 2020, at 10:04, Anton Vinogradov wrote:
> >>
>
Folks,
The question is not about "+1" or "-1".
The question is "why?".
This looks like some special feature to solve some special security issue
but may be just a bad/broken/obsolete/unrefactored code.
Changing this semantic we'll fix bad code or break some contract. 50% to
50%.
Let's keep REST
llo, Anton.
>
> What is «contract» for you?
> Do we have this contract written somewhere?
>
>
> > 1 апр. 2020 г., в 11:35, Anton Vinogradov написал(а):
> >
> > Folks,
> >
> > The question is not about "+1" or "-1".
> > The ques
Folks,
Found we still use @Nullable annotation.
What's the reason for using it?
Everything is Object and Nullable :)
How about get rid of @Nullable usages and restrict its usage by checkstyle
plugin?
BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines [1]
which may have some
gt; >
> > > > Intellij idea IDE has a static code analysis, which uses that
> > > > annotation too. IDE highlights possible problems. It helps to make
> > > > our code more stable and bugless.
> > > >
> > > > пт, 27 мар. 2020 г. в 12:06, Pa
>> +1 to force upper case for `static final` variables.
+1 too
On Mon, Apr 27, 2020 at 12:08 PM Nikolay Izhikov
wrote:
> +1 to force upper case for `static final` variables.
>
> > 25 апр. 2020 г., в 07:39, Ivan Pavlukhin
> написал(а):
> >
> > Maxim,
> >
> > Thank you for efforts in a code
Folks,
I keep working on crash recovery speed-up.
The main goal is to have put/get operations latency less than 500 ms on
node fail/left.
Currently, latency can be increased to seconds or even dozens of seconds.
The task is split to 2 threads
- Switch and tx recovery speed-up.
Speed-up can be
ton,
>
> Thanks for sharing the plans with details. Could you please do us a favor
> and add this item to the roadmap page? I will also help if you link the
> item to a JIRA ticket or IEP that includes the details you shared here.
>
> -
> Denis
>
>
> On Tue, Apr 28,
at 8:02 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> ср, 6 мая 2020 г. в 12:54, Anton Vinogradov :
>
> > Alexei,
> >
> > 1,2,4,5 - looks good to me, no objections here.
> >
> > >> 3. Lost state is impossible to reset if a topology doesn'
Folks,
It seems, we have tacit agreement here.
Going to merge fix May 15.
On Tue, May 12, 2020 at 10:08 AM Anton Vinogradov wrote:
> Denis,
>
> Rebalance is not expected here since this optimization works only on a
> fully rebalanced cluster with baseline.
>
> On Sat, May 9
+1
On Mon, May 18, 2020 at 9:45 PM Sergey Antonov
wrote:
> +1
>
> пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov :
>
> > +1
> >
> > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov
> wrote:
> >
> > > Hi Igniters,
> > >
> > > I have a very simple proposal. Let's set default TX timeout to 5
> minutes
>
+1 to "In place re-encryption".
- It has a simple design.
- Clusters under load may require just load to re-encrypt the data.
(Friendly to load).
- Easy to throttle.
- Easy to continue.
- Design compatible with the multi-key architecture.
- It can be optimized to use own WAL buffer and to
Denis,
In addition to extending the features list it's also important to find some
way to allow customization of control.sh connection configuration/code.
For example, it may be useful to set some attributes to binary rest client.
On Thu, May 14, 2020 at 2:09 AM Denis Magda wrote:
> Perfect
such configuration to Ignite. Or am I missing something?
>
> Denis
>
> On 14.05.2020 11:43, Anton Vinogradov wrote:
> > Denis,
> >
> > In addition to extending the features list it's also important to find
> some
> > way to allow customization of control.sh c
Alexei,
1,2,4,5 - looks good to me, no objections here.
>> 3. Lost state is impossible to reset if a topology doesn't have at least
>> one owner for each lost partition.
Do you mean that, according to your example, where
>> a node2 has left, soon a node3 has left. If the node2 is returned to
>>
le.com/Non-blocking-PME-Phase-One-Node-fail-tp43531p44586.html
[2]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-45%3A+Crash+Recovery+Speed-Up#IEP-45:CrashRecoverySpeed-Up-Cellularswitch
[3]
https://gist.github.com/anton-vinogradov/c50f9d0ce3e3e2997646f84ba7eba5f5#file-bench-java-L417
t are mapped into the partitions of those cells that won't be
> rebalanced, is that correct?
>
> -
> Denis
>
>
> On Wed, May 6, 2020 at 3:24 AM Anton Vinogradov wrote:
>
> > Igniters,
> >
> > PME-free switch [1] (since 2.8) skips PME on node left when possible
> &
Nikolay,
Great proposal!
Could you please explain how to perform testing on the different
environments?
For Example, you provided a rebalance test.
Is it possible to perform this test with TDE enabled?
Is it possible to perform it on custom OS (eg. Windows)?
Is it possible to perform in on bare
+1 to start the 2.9.1 release process once as soon as 2.9 released.
On Mon, Oct 19, 2020 at 8:49 PM Nikolay Izhikov wrote:
> Hello, Yaroslav.
>
> I support the idea.
> But, we should carefully work with the release scope.
>
> IGNITE-13477 - fix for a SQL tracing that will be available only in
Folks,
Modern OS never ask you to schedule defragmentation and turn your PC off,
it performs it while you're browsing.
Why we're going to implement distributed system defragmentation in the old
(offline) way?
All you need is to implement free/reuse-list sorting. They should provide
pages closest
gmentation in the old
> (offline) way?*
> - because it's easier and safer, and it won't introduce any performance
> degradation.
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS
Folks,
First, I've created PR [1] with ducktests improvements
PR contains the following changes
- Pme-free switch proof-benchmark (2.7.6 vs master)
- Ability to check (compare with) previous releases (eg. 2.7.6 & 2.8)
- Global refactoring
-- benchmarks javacode simplification
-- services python
chTest.test.version=dev
> status: PASS
> run time: 1 minute 57.257 seconds
> {"Streamed txs": "32924", "Measure duration (ms)": "48252", "Worst
> latency (ms)": "1010"}
>
> -
use script [2]) and rerun the tests.
[1]
https://github.com/anton-vinogradov/ignite/blob/dc98ee9df90b25eb5d928090b0e78b48cae2392e/modules/ducktests/tests/docker/clean_up.sh
[2]
https://github.com/anton-vinogradov/ignite/blob/3c39983005bd9eaf8cb458950d942fb592fff85c/scripts/build.sh
On Mon, Jul 6, 2
gt; > - 10 server nodes, preloaded with 1M of keys
> > - 4 client nodes perform transactional load (client nodes physically
> separated from server nodes)
> > - during load:
> > -- 5 server nodes stopped in parallel
> > -- after 1 minute, all 5 nodes are started in parallel
> >
You're now at the "Ignite Release Managers" group.
Please check you gain access.
On Fri, Jun 26, 2020 at 9:38 PM Alex Plehanov
wrote:
> Guys,
>
> I've created the 2.9 release confluence page [1].
> Also, I found that I don't have permission to Team City release tasks. Can
> anyone give me such
Cellular switch
On Wed, Jun 3, 2020 at 4:10 PM Nikolay Izhikov wrote:
> Snapshots.
>
> > 3 июня 2020 г., в 16:10, Ilya Kasnacheev
> написал(а):
> >
> > Hello!
> >
> > Can you please clarify what is the scope of 2.9 release?
> >
> > I have a feeling that we don't really have any big features in
Ivan,
Sound like an obsolete compromise partial solution kept just because of the
"Zookeeper" word at its name, not because of some profit.
>> So I suggest to move this single class with tests to separate module in
>> ignite-extensions.
+1
On Fri, Jul 24, 2020 at 11:27 AM Ivan Daschinsky
-
>
> >
> > test_id:
> >
> ignitetest.tests.benchmarks.pme_free_switch_test.PmeFreeSwitchTest.test.version=2.7.6
>
> >
> > status: PASS
> > run time: 1 minute 12.659 seconds
>
+1
On Tue, Nov 24, 2020 at 10:24 AM Pavel Tupitsyn
wrote:
> +1
>
> On Tue, Nov 24, 2020 at 3:25 AM Saikat Maitra
> wrote:
>
> > +1
> >
> > On Mon, Nov 23, 2020 at 4:55 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Mon, Nov 23, 2020 at 2:44 PM
>> a
> >> > TeamCity to run them?
> >> >
> >> > 2. Some tests marked as failed, I'll create corresponding tickets for
> >> them
> >> > after PR approved:
> >> > - IgnitePKIndexesMigrationToUnwrapPkTest
> >>
Folks,
I've found an interesting thing about delays on node failed detection
depending on discovery type.
For example, when we have 33 nodes cluster (33 vms in the cloud in my
case), we have the following failure detection delays:
~ 10 seconds on TcpDiscovery
~ 8.5 seconds on ZookeeperDiscovery
rowse/IGNITE-13643
>
> [2] https://issues.apache.org/jira/browse/IGNITE-13662
>
> 05.11.2020 11:00, Anton Vinogradov пишет:
> > Folks,
> > Seems, we've got an agreement that the fix is necessary.
> > Do we need to do except the following?
> >>> zero linger as
> - Distributed environment tests [2] (Nikolay Izhikov, Anton
> Vinogradov, Ivan Daschinskiy)
> Will all related issues be included in the 2.10?
We're at the final preparations phase. Going to start the merge discussion
soon.
On Wed, Nov 11, 2020 at 4:48 PM Alexey Zinoviev
wrote:
>
Folks,
What's the current state of this thread?
AFAIU, we found unused and wrongly located tests and developed some
checker, could we split this to some PRs?
Let's merge tests usage fix and location fixes first, this will provide us
an ability to automate check using Travis.
On Tue, Oct 20, 2020
S 1.3, this option is unnecessary, even
> if you use TLS 1.2
>
>
> пт, 30 окт. 2020 г. в 14:46, Anton Vinogradov :
>
> > Ilya
> > > I think we should still keep setting linger if SSL is enabled
> > Modern (updated) JVMs do not require this.
> > AFAIK, P
Ilya
> I think we should still keep setting linger if SSL is enabled
Modern (updated) JVMs do not require this.
AFAIK, Problem caused this workaround already fixed everywhere, including
JDK 8.
> If SSL only works with TLSv1.3 and no linger
SSL works if
-- TLSv1.3 with any linger
-- TLSv1.2- with
Alexey,
Do we have any estimates of how fast we'll be able to gain production-ready
AI 3.0 in case of a "new repo" choice?
On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk
wrote:
> Nikolay,
>
> What new features are we planning to implement for Ignite 2.x? I think once
> we commence working on
he new class suite. It does not look
> >> pretty enough, but I think It's a path of least resistance. WDYT?
> >>
> >> BEFORE:
> >> Module A -> SuiteA -> testA1, testA2, testB1, testB2
> >> Module B -> testB1, testB2
> >>
> >> A
Folks,
Seems, we've got an agreement that the fix is necessary.
Do we need to do except the following?
>> zero linger as default + warning on SSL enabled on JVM before the fix +
warning at documentation + migration notes
On Tue, Nov 3, 2020 at 2:38 PM Steshin Vladimir wrote:
> Ilya, hi.
>
>>>>>
> > > > > >>>>>> We have bugs and issues that can be fixed in 2.x without
> > > breaking
> > > > > >>>> backward
> > > > > >>>>> compatibility.
> > > > > &
;>> Konstantin, thanks for chiming in.
> >>>>>>>>
> >>>>>>>> That's exactly my concern. Overformalization is generally not a
> good
> >>>>>>>> thing.
> >>>>>>>> Someone used "mes
Folks,
Here's the video [1] that explains the proposal in detail.
Feel free to ask questions here.
[1] https://www.youtube.com/watch?v=f-i9COU5uAQ (in Russian)
On Tue, Jun 8, 2021 at 2:51 PM Anton Vinogradov wrote:
> Igniters,
> Let me present a framework, we developed, that allows auto
Igniters,
Let me present a framework, we developed, that allows automating Apache
Ignite testing on a real cluster.
The framework was initially presented at Ignite Summit.
In brief,
The framework allows automating operations with any applications on a real
cluster using ssh in a form of a python
-1 here.
We can fix the code and set up the rule.
This will help to prevent having a weird abbreviation like "mess" (from
"message") or "ign" (from "Ignite").
Also, the abbreviations list (hardcoded at IDEA plugin) allows to have same
names across the whole code, this should simplify the reading.
Summit and wonder if you should share that recording with an
> English-speaking part of the community?
>
> -
> Denis
>
> On Wed, Jun 23, 2021 at 7:37 AM Anton Vinogradov wrote:
>
> > Folks,
> >
> > Here's the video [1] that explains the proposal in detail.
> >
> --
> > Denis
> >
> > -
> > Denis
> >
> > On Thu, Jun 24, 2021 at 3:43 AM Anton Vinogradov wrote:
> >
> >> Denis,
> >>
> >> Unfortunately, we had some issues with this recording (low slides
> recording
> >> reso
Folks, we already have Ignite release semi-automated at TeamCity.
We able to assembly, publish as RC and check published.
Seems, we must do the same at extensions.
This way we'll check issues like this even before starting the vote.
On Mon, Jun 28, 2021 at 2:14 PM Ilya Kasnacheev
wrote:
>
Seems, we have a silent agreement here :)
We also discussed the proposal with the Ignite QA Meetup participants and
found this contribution useful.
Going to merge tomorrow, if there are no objections.
On Mon, Jun 28, 2021 at 3:21 PM Anton Vinogradov wrote:
> With regard to the request of I
-authored-by: Dmitriy Sorokin
Co-authored-by: emvdovets
On Mon, Jun 28, 2021 at 6:01 PM Anton Vinogradov wrote:
> Seems, we have a silent agreement here :)
> We also discussed the proposal with the Ignite QA Meetup participants and
> found this contribution useful.
>
> Going to
Folks, seems we MUST automate such a check, as well as the whole
extension release process before the next release attempt?
We may (must?) use AI release automation as a booster.
Please let me know if any help required.
On Tue, Jun 29, 2021 at 11:59 AM Ilya Kasnacheev
wrote:
> Hello!
>
> -1
Maxim,
https://issues.apache.org/jira/browse/IGNITE-13873
Is ready for review, is it possible to wait for it?
On Wed, Feb 24, 2021 at 12:01 AM Maxim Muzafarov wrote:
> Folks,
>
>
> I'd like to cherry-pick to the release branch the following fixes:
>
> Fix security context for JDBC bulk-load
Checked the installation from sources.
+1
On Sat, Apr 17, 2021 at 7:47 PM Ivan Daschinsky
wrote:
> Another reason why whe should host docs on readthedocs.io only is the
> fact,
> that
> pyignite has a separate release cycle. We will release and add more
> features frequently. It's strange to
Also checked the hashcode generation
>> from pyignite import _cutils
>> print(_cutils.hashcode('test'))
>> 3556498
On Mon, Apr 19, 2021 at 11:01 AM Anton Vinogradov wrote:
> Checked the installation from sources.
> +1
>
> On Sat, Apr 17, 2021 at 7:47 PM Ivan Das
> I think TC config should be stored in the same repo as the corresponding
> code (2.x config in 2.x repo, 3.x in 3.x, etc).
This will kill repo history.
You'll see dozens of TC config updates vs a single Ignite fix
> it would be great to be able to test them by simply creating a new branch
> in
My regards!
On Thu, Aug 19, 2021 at 1:11 PM andrei wrote:
> Congrats, Petr!
>
> 8/19/2021 1:00 PM, Andrey Mashenkov пишет:
> > Congrats, Petr!
> >
> > On Thu, Aug 19, 2021 at 12:58 PM Dmitry Pavlov
> wrote:
> >
> >> Hello Ignite community,
> >>
> >> The Project Management Committee (PMC) for
> 1. What is expected behaviour if an old thin client requests creation of
> LOCAL cache on the newest ignite cluster?
Unsupported operation exception.
> 2. Should we completely remove LOCAL caches support in thin clients (i.e.
pyignite) before 2.13 release?
Removal should happen at 2.13.
On
+1 to keeping the dev list clean.
On Mon, Aug 9, 2021 at 11:00 AM Pavel Tupitsyn wrote:
> I agree, let's keep the dev list clean.
> Automated notifications of any kind should not be sent to dev@i.a.o.
>
> PS Ivan, links 2 and 3 are the same.
>
> On Mon, Aug 9, 2021 at 8:54 AM Ivan Pavlukhin
Congrats!
On Fri, Jul 30, 2021 at 10:19 AM ткаленко кирилл
wrote:
> Zhenya, congratulations!
>
> Пересылаемое сообщение
> 30.07.2021, 09:50, "Ivan Daschinsky" :
>
>
> Zhenya, congrats, well deserved!
>
> пт, 30 июл. 2021 г. в 00:44, Andrey Mashenkov >:
>
> > Congratulations
Great news!
Wish you good luck with this undertaking!
P.s. ci2.i.a.o sounds good to me.
On Tue, Aug 3, 2021 at 7:36 PM Petr Ivanov wrote:
> Seems that preserving and syncing users will be difficult to achieve —
> that info is stored in DB, and partial DB replication is tricky.
>
> Also
+1
On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev
wrote:
> +1 for deprecation in the 2.12 release
>
> пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov :
> >
> > Hello, Igniters.
> >
> > I’ve prepared IEP-80 [1] to track breaking changes that should be done
> in Ignite 2.x.
> >
> > We agreed on the
Let's move all GCC-related parts to ignite-extensions, release, and use
them as a maven dependency.
On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky wrote:
> Ok, TC suite is ready [1].
> If there is no objections, I will merge it soon.
>
> Possible concerns -- now it is required to install
Welcome aboard!
On Wed, Dec 1, 2021 at 12:30 PM Вячеслав Коптилин
wrote:
> Hi,
>
> Congrats, Maxim!
>
> Thanks,
> S.
>
> вт, 30 нояб. 2021 г. в 20:13, Maksim Timonin :
>
> > Hi, guys!
> >
> > Thanks everyone :)
> >
> > On Tue, Nov 30, 2021 at 1:16 PM Petr Ivanov wrote:
> >
> > > Great news!
Anton, I disagree.
> >
> >1. This should be released with main distro.
> >2. This should not be abandoned.
> >3. There is not any release process in ignite-extensions.
> >4. Everything is working now and working good.
> >
> >
> >So lets
of single project.
>
>
> > On 17 Dec 2021, at 15:14, Anton Vinogradov wrote:
> >
> > Petr,
> >
> >> I strongly suggest avoiding a separate repository for project settings.
> >> Let's store them in https://github.com/apache/ignite
> >
> > Sou
Petr,
> I strongly suggest avoiding a separate repository for project settings.
> Let's store them in https://github.com/apache/ignite
Sounds good, but we must avoid dozens of additional commits in this case.
Each commit should be properly formalized and related to the issue.
We may create a
Thanks for the update!
On Thu, Dec 16, 2021 at 9:07 PM Виталий Осилов
wrote:
> Hi!
> TeamCity server https://ci2.ignite.apache.org/ will be unavailable on
> Friday 17.12 from 22:00 MSK to 00:00 MSK
> Works will be done to synchronize the TeamCity configuration
> https://ci2.ignite.apache.org/
ous vulnerability and it is
> recommended to update log4j asap.
>
> пн, 20 дек. 2021 г. в 14:00, Anton Vinogradov :
>
> > Maxim,
> > Look like an issue is not related to security problems we fix.
> > Any reason to cancel the vote (delay release) to include this bugfix?
Maxim,
Look like an issue is not related to security problems we fix.
Any reason to cancel the vote (delay release) to include this bugfix?
On Mon, Dec 20, 2021 at 1:28 PM Maxim Muzafarov wrote:
> Cancelling the vote.
>
> I'll cherry-pick the following [1] to the release branch and prepare a
>
Welcome aboard!
On Thu, Dec 23, 2021 at 10:24 AM Ivan Pavlukhin wrote:
> Congrats, Vlad!
>
> 2021-12-22 20:48 GMT+03:00, Ivan Daschinsky :
> > Vlad, congrats! You have definitely deserved it!
> >
> > ср, 22 дек. 2021 г. в 20:40, Andrey Mashenkov <
> andrey.mashen...@gmail.com>:
> >
> >>
> it would be great to release a new SQL engine in 2.13 as an
experimental feature.
++1
On Thu, Dec 30, 2021 at 12:55 PM Alex Plehanov
wrote:
> Andrey,
>
> > Is this [1] a full scope of the tickets that MUST be resolved before the
> engine could be merged?
> Yes, we must resolve at least these
Sergei,
Please make sure this will not break the Ducktests.
AFAIK, we have zookeeper tests there.
On Wed, Dec 22, 2021 at 12:09 PM Sergei Ryzhov
wrote:
> Hi, igniters,
>
> I've created an issue [1] to move the zookeeper IP-finder to the
> ignite-extensions. The motivation is the same as with
My -0 here, since the is no automated RC preparation and testing at Apache
TeamCity again.
Next time, I will vote with -1 if a new vote is not covered by public
automated preparation/testing as the AI release does.
On Wed, Oct 27, 2021 at 11:48 AM Nikita Amelchev
wrote:
> Dear Ignite Community,
Folks,
Could we have a kick-off call to determine the roadmap?
On Thu, Oct 21, 2021 at 6:52 PM Denis Magda wrote:
> Folks, you don't need me on that call. I'm of a little value/help here.
>
> -
> Denis
>
>
> On Thu, Oct 21, 2021 at 9:51 AM Nikolay Izhikov
> wrote:
>
> > Hello, Igniters.
> >
>
Folks,
My 200 rubles here,
> I want to include it to the 2.12 scope.
Why not 2.11.1 as well?
We should provide a fixed version for current customers asap.
2.12 require migration, while 2.11.1 can be applied as-is.
On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
> What is the issue if third-party plugins will create «ignite-sys-cache»
from the code?
Great idea!
On Fri, Dec 3, 2021 at 2:15 PM Nikolay Izhikov wrote:
> Vyacheslav, Val, can you please clarify - What is the issue if third-party
> plugins will create «ignite-sys-cache» from the code?
>
>
+1 to option 4
On Thu, Jan 13, 2022 at 5:15 PM Pavel Tupitsyn wrote:
> +1 to option 2
>
> On Thu, Jan 13, 2022 at 3:52 PM Roman Puchkovskiy <
> roman.puchkovs...@gmail.com> wrote:
>
> > +1 to option 2
> >
> > чт, 13 янв. 2022 г. в 15:58, Sergey :
> > >
> > > +1 for option2 (only @Nullable)
> >
+1
On Tue, Jan 11, 2022 at 11:35 AM Maxim Muzafarov wrote:
> +1
>
> On Tue, 11 Jan 2022 at 11:31, Nikolay Izhikov wrote:
> >
> > +1
> >
> > > 11 янв. 2022 г., в 02:38, Vladimir Steshin
> написал(а):
> > >
> > > +1
> > >
> > > 10.01.2022 15:52, Nikita Amelchev пишет:
> > >> Dear Community,
> >
601 - 700 of 874 matches
Mail list logo
