Folks,
We have discussed this earlier as well but the discussion died down (the
primary node's queue flush issue.) I would like to restart the thread.
Please provide your inputs and thoughts. We have a JIRA that I opened
around this but have forgotten the number.
Hi,
I have been through examples in ignite repo.I wanted to work on this bug
https://issues.apache.org/jira/browse/IGNITE-944
Please tell me how to proceed.
Thanks
On Tue, Jul 21, 2015 at 5:00 PM, chandresh pancholi <
chandreshpancholi...@gmail.com> wrote:
> Cool. Will go through it
>
> On Tue,
How difficult is it to implement this please?
On 29 Jul 2015 12:12, "Yakov Zhdanov (JIRA)" wrote:
> Yakov Zhdanov created IGNITE-1169:
> -
>
> Summary: Need to add TcpCommunicationSpi.sendWithAck
> Key: IGNITE-1169
>
Yakov Zhdanov created IGNITE-1169:
-
Summary: Need to add TcpCommunicationSpi.sendWithAck
Key: IGNITE-1169
URL: https://issues.apache.org/jira/browse/IGNITE-1169
Project: Ignite
Issue Type: Ne
Andrey Novikov created IGNITE-1168:
--
Summary: REST API: type metadata for cache
Key: IGNITE-1168
URL: https://issues.apache.org/jira/browse/IGNITE-1168
Project: Ignite
Issue Type: Sub-task
Fixed restart nodes in interactive mode by host. Attached path. Submitted
for review to Alexey Kuznetsov.
On Wed, Jul 29, 2015 at 10:38 AM, Vasiliy Sisko wrote:
> Bug with restart of node from console in interactive mode by host has been
> found.
> Created issue: https://issues.apache.org/jira/b
Andrey Novikov created IGNITE-1167:
--
Summary: HTTP REST topology command doesn't return caches.
Key: IGNITE-1167
URL: https://issues.apache.org/jira/browse/IGNITE-1167
Project: Ignite
Issue
Bug with restart of node from console in interactive mode by host has been
found.
Created issue: https://issues.apache.org/jira/browse/IGNITE-1166. Work
started.
--
Vasiliy Sisko
GridGain Systems
www.gridgain.com
Vasiliy Sisko created IGNITE-1166:
-
Summary: Visor CMD. Node does not restart in interactive mode by
host
Key: IGNITE-1166
URL: https://issues.apache.org/jira/browse/IGNITE-1166
Project: Ignite
Guys,
I'm not sure I understand the purpose of this discussion. Maven-based and
Git-based providers are just examples of pluggable implementations that we
can provide out of the box - user is never forced to use them.
I see two main use cases for the feature:
- Dynamic deployment and redeploy
Igniters,
Today I noticed that there is no documentation on JTA integration we
provide and wanted to add it, but got really confused by configuration we
currently have.
Essentially, the only configuration property we have is
TransactionConfiguration.setTxManagerLookupClassName(String
tmLookupClsN
>
> It's called a remote code execution exploit. Anyone who has write access
> to the repo (i.e., anyone who can hack in) can change the deployed code
> and DOS your whole cluster.
>
I believe these decisions are best left to the end user, the mechanism
proposed may or may not have valid uses for
Alexey Goncharuk created IGNITE-1165:
Summary: Assertion error is thrown in OFFHEAP_TIERED mode and near
cache enabled.
Key: IGNITE-1165
URL: https://issues.apache.org/jira/browse/IGNITE-1165
Proj
On Tue, Jul 28, 2015 at 10:16PM, Branko Čibej wrote:
> On 28.07.2015 21:36, Dmitriy Setrakyan wrote:
> >> Cos, we are not talking about checking binaries. We are planning to
> > support
> >
> >>> GIT/SVN/etc repositories with a POM file. This way we simply build it
> >>> using maven ourselves and
On 28.07.2015 21:36, Dmitriy Setrakyan wrote:
>> Cos, we are not talking about checking binaries. We are planning to
> support
>
>>> GIT/SVN/etc repositories with a POM file. This way we simply build it
>>> using maven ourselves and deploy it.
>> Well, even worst IMO. Why would you want to run an
On Tue, Jul 28, 2015 at 12:36PM, Dmitriy Setrakyan wrote:
> > Cos, we are not talking about checking binaries. We are planning to
> support
>
> > > GIT/SVN/etc repositories with a POM file. This way we simply build it
> > > using maven ourselves and deploy it.
> >
> > Well, even worst IMO. Why wo
> Cos, we are not talking about checking binaries. We are planning to
support
> > GIT/SVN/etc repositories with a POM file. This way we simply build it
> > using maven ourselves and deploy it.
>
> Well, even worst IMO. Why would you want to run an external build
> process as a part of the nodes d
On Tue, Jul 28, 2015 at 11:31AM, Dmitriy Setrakyan wrote:
> On Tue, Jul 28, 2015 at 11:20 AM, Konstantin Boudnik wrote:
>
> > On Tue, Jul 28, 2015 at 10:29AM, Dmitriy Setrakyan wrote:
> > > Alexey,
> > >
> > > I probably was not clear in my email earlier. I think that
> > > DeploymentProvider is
On Tue, Jul 28, 2015 at 11:20 AM, Konstantin Boudnik wrote:
> On Tue, Jul 28, 2015 at 10:29AM, Dmitriy Setrakyan wrote:
> > Alexey,
> >
> > I probably was not clear in my email earlier. I think that
> > DeploymentProvider is a good abstraction and we should have it. My
> comment
> > was that I wo
+1 for RTC. For now rules to become a committer are pretty "soft", CI and
JIRA processes are still changing, etc. I believe without additional
control quality of our product will deteriorate in such environment.
Let's graduate first, establish development processes, define requirements
to become a
On Tue, Jul 28, 2015 at 10:29AM, Dmitriy Setrakyan wrote:
> Alexey,
>
> I probably was not clear in my email earlier. I think that
> DeploymentProvider is a good abstraction and we should have it. My comment
> was that I would like it to be exposed as a URI string vs. "new
> DeploymentProvider(...
On Tue, Jul 28, 2015 at 11:02AM, Dmitriy Setrakyan wrote:
> On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn
> wrote:
>
> > As said above, squash should be used when merging to master (git merge
> > branchName --squash "Message"; there are checkboxes in Idea, too).
> > This way there is a single
On Tue, Jul 28, 2015 at 06:23AM, Vasilisa Sidorova wrote:
> In a perfect world I agree with Brane.
>
> But there is top class from each igniter to trust each others on the 1000%
> and always to be ready that something go sideways. This process take time.
Actually, no one is talking about 100% t
On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn
wrote:
> As said above, squash should be used when merging to master (git merge
> branchName --squash "Message"; there are checkboxes in Idea, too).
> This way there is a single commit with a meaningful message in master,
> and it does not matter w
You can use squash independent from merge. It is done via simple interactive
rebase and can be used at any time at one's convenience. However, it is
important to remember not to squash someone's else commits as it changes the
SHAs of the object.
I'd be happy to do a session for anyone who needs a
On Tue, Jul 28, 2015 at 12:56AM, Dmitriy Setrakyan wrote:
> I want to address the following point made by Brane and Cos:
>
>
> *if you don't trust a committer to make the changes in the VCSsystem - that
> committer shouldn't be having the commit-bit in the first place.*
>
>
> I don't be
As said above, squash should be used when merging to master (git merge
branchName --squash "Message"; there are checkboxes in Idea, too).
This way there is a single commit with a meaningful message in master, and
it does not matter what happened in the personal branch.
I think this is the simplest
Alexey,
I probably was not clear in my email earlier. I think that
DeploymentProvider is a good abstraction and we should have it. My comment
was that I would like it to be exposed as a URI string vs. "new
DeploymentProvider(...)".
For example, GitDeploymentProvider would be configured as
"git://
Agree. URIs are not flexible enough. But we still can have
UriDeploymentProvider for protocols that fit there (file, HTTP, FTP, etc.).
Definitely no need to create a separate provider for each of them.
-Val
On Tue, Jul 28, 2015 at 10:19 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
>
On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > I hope so, it'd be horrible to do that on master!
>
> Exactly!
> But I do not see much sense in enforcing any kind of policy in personal
> branches. Sometimes rebase may be better, sometimes I may want to use merge
> so I see when and whic
I still do not like this approach. Maven artifacts may require another URL
for an external repository, now we would have to encode a URI into another
URI. The git repository may require some settings for a build system, which
also may not always be expressed in terms of URI parameters.
Besides, if
In a perfect world I agree with Brane.
But there is top class from each igniter to trust each others on the 1000%
and always to be ready that something go sideways. This process take time.
So I think that our Jira process should be flexible because Ignite is young
project.
As a first step we c
On 28.07.2015 09:56, Dmitriy Setrakyan wrote:
> I want to address the following point made by Brane and Cos:
>
>
> *if you don't trust a committer to make the changes in the VCSsystem - that
> committer shouldn't be having the commit-bit in the first place.*
>
>
> I don't believe this poi
Alexey, we were talking about master->personal.
As for merging to master, there should be strictly one commit per feature.
This can be achieved in multiple ways (patch, merge/pull with squash). And
with squash, it does not matter how personal branch history looks.
On Tue, Jul 28, 2015 at 1:38 PM,
On 28.07.2015 12:12, Yakov Zhdanov wrote:
> I am for RTC.
>
> Agree with Val, that significant part of the concurrency issues are very
> hard to catch with CI. They are caught on review (and some unfortunately
> slip through). And Sergi's points seems very valid to me - complex changes
> should be
So we are going to work only with patches?
No more merges from personal branches into master?
On Tue, Jul 28, 2015 at 5:33 PM, Pavel Tupitsyn
wrote:
> > I hope so, it'd be horrible to do that on master!
>
> Exactly!
> But I do not see much sense in enforcing any kind of policy in personal
> bran
> I hope so, it'd be horrible to do that on master!
Exactly!
But I do not see much sense in enforcing any kind of policy in personal
branches. Sometimes rebase may be better, sometimes I may want to use merge
so I see when and which changes came from master branch, etc.
Only the implementer cares
One more. Could I use rebase in my branch if I already use merge on this
branch before?
On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov
wrote:
> I can start user rebase at any moment? Or I should wait for day X ?
> Or we will start vote?
>
> Also what will happen if someone will do merge but o
I can start user rebase at any moment? Or I should wait for day X ?
Or we will start vote?
Also what will happen if someone will do merge but other rebase?
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
On 28.07.2015 12:15, Pavel Tupitsyn wrote:
> Hi, I'm a bit confused, are we talking about merge vs rebase in a feature
> (personal) branches?
I hope so, it'd be horrible to do that on master!
-- Brane
Hi, I'm a bit confused, are we talking about merge vs rebase in a feature
(personal) branches?
On Tue, Jul 28, 2015 at 12:49 PM, Yakov Zhdanov wrote:
> This can be done from command line.
>
> I think here is a very good article on merge vs rebase -
> https://www.atlassian.com/git/tutorials/mergi
I am for RTC.
Agree with Val, that significant part of the concurrency issues are very
hard to catch with CI. They are caught on review (and some unfortunately
slip through). And Sergi's points seems very valid to me - complex changes
should be reviewed to make the best effort to avoid issues of a
AWS and GCE images based on Docker image. I'll update documentation that is
will be more clear.
On Tue, Jul 28, 2015 at 11:54 AM, Dmitriy Setrakyan
wrote:
> Nick,
>
> (resending with correct subject)
>
> I think the original question what happens in AWS and GCE images. Please
> don't delete the
This can be done from command line.
I think here is a very good article on merge vs rebase -
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
As for me, I think we should switch to rebase.
--Yakov
2015-07-28 11:12 GMT+03:00 Alexey Kuznetsov :
> I,m not a git ninja.
>
> And will be v
Good point.
Does anyone have any other suggestions for some Ignite-related projects we
can propose?
D.
On Mon, Jul 27, 2015 at 5:11 PM, Alexey Kuznetsov
wrote:
> Just a thought: there also a Google Summer of Code (we are late this year).
> We could participate next year.
>
> On Mon, Jul 27, 20
Nick,
(resending with correct subject)
I think the original question what happens in AWS and GCE images. Please
don't delete the original question entirely, as in this case it was
absolutely unclear what was originally asked.
The documentation you provided is for the Docker image, which I think
Hm...
I actually don't like the complexity of creating a DeploymentProvider for
every deployment source. How about we just use URI-like approach?
git://my.git.repository/master
svn://...
file:///
mvn:my.maven.artifact
etc...
This way we can simply have a collection of URIs as a parameter to
>
> Is this reflected somewhere in documentation? If yes, then I missed it.
>
Yes. This information is on this page
http://apacheignite.readme.io/docs/docker-deployment.
I tend to agree on points brought by Brane and Cos. Having a formality that
review is always required regardless of what the change actually implies
looks like an overkill.
At the same time, I usually feel uncomfortable without a review. Ignite is
not just a "complicated" project. It has a lot of c
I,m not a git ninja.
And will be very pleased if some one add a screenshot to our wiki how to do
rebase from Idea UI.
On Tue, Jul 28, 2015 at 3:06 PM, Atri Sharma wrote:
> +1
>
> On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan
> wrote:
>
> > I actually agree with Cos and think we can switch
+1
On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan
wrote:
> I actually agree with Cos and think we can switch to "rebase" instead of
> "merge".
>
> Does anyone foresee any problems with this change?
>
> D.
>
> On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik
> wrote:
>
> > I would like to
I actually agree with Cos and think we can switch to "rebase" instead of
"merge".
Does anyone foresee any problems with this change?
D.
On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik wrote:
> I would like to propose the following modification of the process, offered
> in
> this page (and
I want to address the following point made by Brane and Cos:
*if you don't trust a committer to make the changes in the VCSsystem - that
committer shouldn't be having the commit-bit in the first place.*
I don't believe this point actually applies to Ignite.
As all of us are aware, Igni
Pavel Konstantinov created IGNITE-1164:
--
Summary: NullPointerException at ServerImpl.java:2758
Key: IGNITE-1164
URL: https://issues.apache.org/jira/browse/IGNITE-1164
Project: Ignite
Iss
In my experience RTC is better.
As I can see Ignite evolving very fast with this model.
Why some one expects that RTC will slow down development?
I'm for RTC.
On Tue, Jul 28, 2015 at 6:30 AM, Konstantin Boudnik wrote:
> On Tue, Jul 28, 2015 at 01:09AM, Branko Čibej wrote:
> > On 27.07.2015 18
55 matches
Mail list logo
