Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aerolab cluster list -j outputs AGI instances #341

Open
colton-aerospike opened this issue Jun 18, 2024 · 1 comment
Open

aerolab cluster list -j outputs AGI instances #341

colton-aerospike opened this issue Jun 18, 2024 · 1 comment

Comments

@colton-aerospike
Copy link

aerolab cluster list -j prints out AGI instances if they exist, but aerolab cluster list does not.

MIght be better to make these two commands synced. Preferably better to NOT return AGI instances when expecting clusters. This may also help fix the other issue #340

@robertglonek
Copy link
Collaborator

@colton-aerospike
This is separate from 340, which Iresolved now. The issue here is that while GUI listings show nicely clusters separate from AGI, in reality AGI is just a cluster with extra features bolted on top. As such, there is not separate AGI listing at all in the system at all. What we do have is, if you look at the Cluster list json, you will notice the Features section, which will have Aerospike if aerospike server is installed, and will have AGI if AGI feature is installed.

To work out if a cluster is AGI or not, simply filter by the json [].Features which is a list. If the list contains ["AGI"], it's AGI.

This is getting reworked in 8.0.0 where every instance will be just that - an instance with a list of features added to it. There will be no more cluster/client separation, but Instance with Features installed on it - at least that's the current idea.

@dotyjim-work ^ this is how it currently works, which I do recognise is not ideal. Considering the work involved in separating logic for the same call to have separate json fills for AGI vs Cluster listing based on a feature, I would be leaning towards leaving it as is in v7 (as it may break existing scripts otherwise if we are not careful) and leave it for 8.0.0 cleanup which reworks the whole flow of definitions. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants