Re: Apache Ignite Kubernetes Stateful deployment with parallel pod management

[Zaheer]

Thanks Alex for the response.

Parallel pod management is working.

Earlier I added readiness and liveness probes, with initial delay of 180
seconds for the Ignite pods in stateful set because of which no traffic was
allowed to pods, and hence the discovery failed.

After removing these probes, Parallel pod management is working fine.

Regards,
Syed Zaheer Basha



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Apache Ignite Kubernetes Stateful deployment with parallel pod management

[syed zaheer Basha]

Hi,

I am trying to deploy Apache Ignite using a Statefulset with four Ignite
pods  in Kubernetes. I have my Ignite service deployed already and ip
finder set properly in ignite configuration.

1. When I set pod management policy to "OrderedReady" in statefulset -
which means each Ignite pod starts after the other in a sequence, I can see
all pods joined the topology correctly.  (servers : 4)

2. However when I set pod management policy to "Parallel" in statefulset -
which means all Ignite pods start simultaneously, I see each pod is
behaving like a separate cluster.  (each pod has server :1 )

Can anyone help me understand why Ignite pods that start simultaneously are
unable to discover each other ?

Thanks,
Zaheer.

Re: Not able to start second server node due to authentication failure

[Zaheer]

Hi Sankar,

What Andei said is correct. We need to return a security subject. I faced
this problem and solved it like this : 

*1. Create your own SecurityPermissionSet class that implements
org.apache.ignite.plugin.security.SecurityPermissionSet .*

/public class TestSecurityPermissionSet implements SecurityPermissionSet,
Serializable {
private boolean defaultAllowAll;
private Map> taskPermissions;
private Map> cachePermissions;
private Map>
servicePermissions;
private Collection systemPermissions;

public TestSecurityPermissionSet(boolean defaultAllowAll, Map> taskPermissions, Map> cachePermissions, Map> servicePermissions,
Collection systemPermissions) {
this.defaultAllowAll = defaultAllowAll;
this.taskPermissions = taskPermissions;
this.cachePermissions = cachePermissions;
this.servicePermissions = servicePermissions;
this.systemPermissions = systemPermissions;
}

public boolean defaultAllowAll() {
return defaultAllowAll;
}

public Map> taskPermissions()
{
return taskPermissions;
}

public Map> cachePermissions()
{
return cachePermissions;
}

public Map>
servicePermissions() {
return servicePermissions;
}

@Nullable
public Collection systemPermissions() {
return systemPermissions;
}
}/
*2. Create your own security subject (say TestSecuritySubject) class that
implements org.apache.ignite.plugin.security.SecuritySubject.*
 /public class TestSecuritySubject implements SecuritySubject, Serializable
{

private SecuritySubjectType subjectType;
private UUID uuid;
private Object login;
private TestSecurityPermissionSet securityPermissionSet;

public TestSecuritySubject(SecuritySubjectType subjectType, UUID uuid,
Object login, TestSecurityPermissionSet securityPermissionSet) {
this.subjectType = subjectType;
this.uuid = uuid;
this.login = login;
this.securityPermissionSet = securityPermissionSet;
}

public UUID id() {
return uuid;
}

public SecuritySubjectType type() {
return subjectType;
}

public Object login() {
return login;
}

public InetSocketAddress address() {
return null;
}

public TestSecurityPermissionSet permissions() {
return securityPermissionSet;
}
}/
*3. Create your own security context class that implements
org.apache.ignite.internal.processors.security.SecurityContext , with a
TestSecuritySubject field in the class.*
/public class TestSecurityContext implements SecurityContext, Serializable {
private TestSecuritySubject securitySubject;

public TestSecurityContext(TestSecuritySubject securitySubject) {
this.securitySubject = securitySubject;
}

public SecuritySubject subject() {
return securitySubject;
}

public boolean taskOperationAllowed(String taskClsName,
SecurityPermission perm) {
//Check if the security subject task permissions contain the given
taskClsName and given perm and return true/false accordingly
}

public boolean cacheOperationAllowed(String cacheName,
SecurityPermission perm) {
//Check if the security subject cache permissions contain the given
cacheName and given perm and return true/false accordingly

}

public boolean serviceOperationAllowed(String srvcName,
SecurityPermission perm) {
   //Check if the security subject service permissions contain the given
srvcName and given perm and return true/false accordingly
}

public boolean systemOperationAllowed(SecurityPermission perm) {
//Check if the security subject system permissions contain the given 
perm and return true/false accordingly
}

   
}/

*4. In the authenticateNode method, create an instance of your
SecuritySubject and set it in your SecurityContext instance and return it*. 

/public SecurityContext authenticateNode(ClusterNode node,
SecurityCredentials cred) throws IgniteCheckedException {
 TestSecurityPermissionSet permissionSet = new
TestSecurityPermissionSet(true, null, null, null, null);

TestSecuritySubject securitySubject = new
TestSecuritySubject(SecuritySubjectType.REMOTE_NODE, node.id(), "",
permissionSet);

return new TestSecurityContext(securitySubject);

}/

*In the above snippet, I gave
TestSecurityPermissionSet(true,null,null,null,null) ==> That is default
allow all is true. This way, you returned a security context with proper
subject and proper permissions.*

Let me know if you need more clarification. 







--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite backup/restore Cache-wise

[syed zaheer Basha]

Thank you Stephen,

I want to achieve specific cache backup/restore not all caches. So If I
take backup of WAL folder as well, when I restore, all other caches state
will also get restored.

So Is there a way to distinguish  WAL records of a specific cache and take
backup ?

What is the best solution to achieve specific cache backup/restore without
using Gridgain snapshot utility ?

On Mon, 29 Jul 2019 at 18:39, Stephen Darlington <
stephen.darling...@gridgain.com> wrote:

>
> Is *WAL* bringing cache to latest state (since I am not doing anthing
> with wal folder in backup/restore ) ?
>
>
> Basically, yes. The WAL contains all the changes since the last snapshot.
> To do a backup you’ll need both the data files and the WAL files. The WAL
> archives files wouldn’t hurt, too.
>
> A description of how the persistent store works can be found here:
>
>
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
>
> GridGain supports snapshot backup/restore of all caches on a live cluster.
>
> Regards,
> Stephen
>
> On 29 Jul 2019, at 12:48, syed zaheer Basha 
> wrote:
>
> Hi,
>
> I have gone through the following link :
>
>
> http://apache-ignite-users.70518.x6.nabble.com/Snapshot-backup-of-Ignite-native-persistance-data-tp20103.html
>
>
> And came up with an idea of cache-wise backup/restore. I am describing the
> steps followed :
>
> 1. Let us say an Ignite cluster exists with persistence (Native
> persistence) and wal enabled on Kubernetes. I create a cache *a1* and put
> *key=a* , *val=oldA* into it.
>
> 2. Now I deactivated the cluster, and copied *cache-a1* folder from
> storage path of each node in Ignite cluster (keeping track of consistent
> node ids) to some disk or s3 bucket and activated the cluster. This step I
> call as taking a backup.
>
> 3. Now I change value of *key=a* to *val=newA* . If I fetch the *key=a*
>  on *cache-a1* I will now get *val=newA* .
>
> 4. Now I deactivate the cluster again, copy the previously stored
> *cache-a1* folder into the Ignite nodes (making sure I copy correct
> folder into correct consistent id node folder) and activate it. This is
> restore step.
>
> If I fetch *key=a* on *cache-a1* I was hoping to get *val=oldA* . But I
> get *val=newA* most times. In some cases I get *val=oldA*.
>
> What is happenning here ?
>
> Is *WAL* bringing cache to latest state (since I am not doing anthing
> with wal folder in backup/restore ) ?
>
> Did anyone try cache-wise backup and restore without Gridgain utility ?
>
> Does *gridgain* snapshot utility support cache-wise backup and restore ?
>
>
>
>

Ignite backup/restore Cache-wise

[syed zaheer Basha]

Hi,

I have gone through the following link :

http://apache-ignite-users.70518.x6.nabble.com/Snapshot-backup-of-Ignite-native-persistance-data-tp20103.html


And came up with an idea of cache-wise backup/restore. I am describing the
steps followed :

1. Let us say an Ignite cluster exists with persistence (Native
persistence) and wal enabled on Kubernetes. I create a cache *a1* and put
*key=a* , *val=oldA* into it.

2. Now I deactivated the cluster, and copied *cache-a1* folder from storage
path of each node in Ignite cluster (keeping track of consistent node ids)
to some disk or s3 bucket and activated the cluster. This step I call as
taking a backup.

3. Now I change value of *key=a* to *val=newA* . If I fetch the *key=a* on
*cache-a1* I will now get *val=newA* .

4. Now I deactivate the cluster again, copy the previously stored
*cache-a1* folder
into the Ignite nodes (making sure I copy correct folder into correct
consistent id node folder) and activate it. This is restore step.

If I fetch *key=a* on *cache-a1* I was hoping to get *val=oldA* . But I get
*val=newA* most times. In some cases I get *val=oldA*.

What is happenning here ?

Is *WAL* bringing cache to latest state (since I am not doing anthing with
wal folder in backup/restore ) ?

Did anyone try cache-wise backup and restore without Gridgain utility ?

Does *gridgain* snapshot utility support cache-wise backup and restore ?

Re: Regarding IGNITE_HOME/work/db folder - Snapshot and recovery

[Zaheer]

Thank you Andrei



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Fwd: Regarding IGNITE_HOME/work/db folder - Snapshot and recovery

[Zaheer]

Thank you Ilya



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Regarding IGNITE_HOME/work/db folder - Snapshot and recovery

[Zaheer]

Hi,

In this post it has been mentioned that to manually take a snapshot of
Ignite without using commercial solutions, we need to deactivate the cluster
, copy work/db folder to our backup location and activate cluster. And to
restore we deactivate, copy the backed up data and activate.

http://apache-ignite-users.70518.x6.nabble.com/Snapshot-backup-of-Ignite-native-persistance-data-tp20103.html

When I was trying this, I faced these errors : 

1. WAL error : On restoring it says critical WAL archive missing and the
nodes crash.
2. Node Lock : This lock in node00-UUID folder is held from start to stop of
a node. So deactivating the cluster will not remove the lock.

I tried copying only the node00-UUID folders without WAL and I was able to
restore my caches. Is this approach correct ? Will WAL overwrite the
restored node00-UUID folders' data ? 







--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: failed to get the security context object

[Zaheer]

Hi,

I am also trying to develop a security plugin for Ignite. Security context
in case of visor call is null and even the SecurityContextHolder wont work.
Because,

1. *SecurityContextHolder* has a ThreadLocal variable holding the
*SecurityContext*. So if your calls of authenticate and authorize happen in
same thread like the *REST* call, it will work. Try printing
Thread.currentThread().getName() in your calls. You will understand what I
am saying.

2. When you connect visor to the grid, *authenticateNode* method is called.
And after that any call you make calls *authorize* method only , that too 
if plugin was configured on visor. So *SecurityContextHolder.set()* happens
in the *authenticateNode* which is called in *tcp-dicovery-worker* thread.
And *SecurityContextHolder.get()* happens in *authorize* method which is
called in a separate thread depending on the visor call. So here
*SecurityContextHolder* will not work. 



For cases of visor or any server node, thick client joining the cluster,
*SecurityContext* is passed null. To overcome this, you need to store local
nodes security context in a field in your plugin say *localSecurityContext*
representing security context of local node. You can try something like this
: 

/public class MySecurityProcessor extends GridProcessorAdapter implements
DiscoverySpiNodeAuthenticator, GridSecurityProcessor, IgnitePlugin {

*private MySecurityContext localSecurityContext;*


public SecurityContext authenticateNode(ClusterNode node,
SecurityCredentials cred) throws IgniteCheckedException {

 
 //write your logic to authenticate node and return Security Context

 //Check if node is local, and store the security context in your local
variable before returning
* if(node.isLocal())  localSecurityContext= ...*

}

public SecurityContext authenticate(AuthenticationContext
authenticationContext) throws IgniteCheckedException {
   SecuritySubject secureSecuritySubject = new SecuritySubject(
authenticationContext.subjectId(),
authenticationContext.subjectType(),
authenticationContext.credentials().getLogin(),
authenticationContext.address()
);
SecurityContext securityContext = new
MySecurityContext(secureSecuritySubject, accessToken);
SecurityContextHolder.set(securityContext);
return securityContext;
}
public void authorize(String name, SecurityPermission perm, SecurityContext
securityCtx) throws SecurityException {
System.out.println(   SecurityContextHolder.get());
System.out.println( securityCtx );
//If context is null use localSecurityContext
*if(securityCtx==null) securityCtx=localSecurityContext;*
//do some authorization 
 .
}

..
}/


Note that this will work if *isGlobalNodeAuthentication* is true. Because
only then *authenticateNode* method is called on each joining node (instead
of coordinator) and you can save the context in local variable. Also the
joining node must also have the plugin configured for this to work.





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Java Thin Client support to deploy services on a cluster

[Zaheer]

Hi,

I saw from documentation about Thin clients used to create, destroy caches.
I wanted to know if there is any way to deploy services on my cluster
through thin client. (Service implementation already placed in libs). 

I went through Javadoc of Ignite Client and found no method related to
services.

If it was a thick client we could have used ignite.services.deploy() right ?
So I need to know if thin client supports such deployment of services.

Thanks in advance.

Regards
Zaheer.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Copying My Service classes to the lib folder of already started nodes (not via visor)

[Zaheer]

Thank you very much for the replies.

Regards
Zaheer



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Copying My Service classes to the lib folder of already started nodes (not via visor)

[Zaheer]

Thank you very much for the replies Denis and Ilya

Regards
Zaheer



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Copying My Service classes to the lib folder of already started nodes (not via visor)

[Zaheer]

Hi,

I have a use case, where a node is already started and I want to copy some
jars into that node's libs folder.
Visor has the deploy command. But without using visor can we do it somehow? 

I know peer class loading happens in data and compute. But for services the
documentation says no peer class loading. So If I have a node started
already(A) and I start one more service node(B), My service implementation
class will not be copied to A. I want to do this copying in runtime.

Regards
Zaheer



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Expose service deployed on service node in ignite via REST

[Zaheer]

Update :

I was able to solve that error by using 

localhost:8080/ignite?cmd=exe=com.***.***.MyComputeTask.





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Expose service deployed on service node in ignite via REST

[Zaheer]

So lets say I create a compute task extending compute-task-split-adapter and
I write my code inside split and reduce methods. After that is it enough
just to package my file as jar and place in libs folder of ignite
installation , for the rest api to recognize. 

Ex : 
/
public class MyComputeTask extends ComputeTaskSplitAdapter { 
@IgniteInstanceResource 
private Ignite ignite; 

@Override 
public R reduce(List results) throws
IgniteException { 
some code*** 
return R; 

} 

@Override 
protected Collection split(int gridSize,
String arg) throws IgniteException { 

String[] words = arg.split(" "); 
List jobs = new ArrayList<>(words.length); 

for (final String word : words) { 
jobs.add(new ComputeJobAdapter() { 
@Override 
public Object execute() { 
**call my service here and do my
computation** 
MyService svc=
ignite.services().serviceProxy(...,...,...); 
**use this svc to add some data to
cache*** 
return Object; 
} 
}); 
} 

return jobs; 

} 

}
/
Now this class I will keep as a jar inside my libs folder. 

*
localhost:8080/ignite?cmd=exe=MyComputeTask*  

Should this REST call successfully work? 

I am getting an error. That failed to auto-deploy. So what should I do so
that REST api can recognise my task. 

Regards 
Zaheer.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Expose service deployed on service node in ignite via REST

[Zaheer]

Thank you very much :D . 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Expose service deployed on service node in ignite via REST

[Zaheer]

Hi Denis,

Thanks for the reply. I will look into that section about executing the
compute task from REST. 

But I require to call the service via REST. Some forum posts suggested using
jetty inside *init()* method of service implementation. I would like to know
more about exposing the service via REST.

Zaheer



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Expose service deployed on service node in ignite via REST

[Zaheer]

Hi,

In Ignite cluster, I have a cache data node and a service node with a
deployed service that performs some actions on the cache. My aim is to use
the methods of this deployed service through REST. How to expose my deployed
service's methods to outside world like browsers, or other REST clients ?

I had a look at the REST api of Ignite and I only found methods to access
the cache and modify it. But I do not want to use those methods to modify my
cache. Instead I want to use my service's methods to modify my cache. kindly
reply.

Thanks in advance.

Regards,
Zaheer.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/