Page Comparison

...

1. Currently, all common modules are part of knowlg BB and are tightly coupled with knowlg/inQuiry services/jobs.

2. inQuiry uses below api’s

• category definition api’s, framework api’s - taxonomy-service

• search api - search-service

• asset api’s, content api’s, channel api - content-service

Open Questions:

1. Is separate infra monitoring (e.g: monitoring service, grafana dashboard) will be installed for inQuiry?

2. How load testing will be performed for inQuiry components? Do we get common load test infra?

3. Currently, all assessment APIs are onboarded with Content Role (e.g: Content Create or Content Update). Should we change the API roles to Question/QuestionSet Role (e.g: Question Create)?
   Note: this will have an impact on SunbirdEd/Diksha/etc)

4. What will happen to service telemetry (e.g: info/error logs) dashboard such as Graylog? Do we need it? If yes, what all services/components need to be installed?

5. Some basic functionalities around any objects (e.g: audit history, audit-event ) are currently with Knowlg. Should inQuiry also have these?

...

• quml-player code is already independent. So just we need to move from project-sunbird to inQuiry Github repo.

Databases/Streams/Tools:

Neo4j:

• inQuiry will have its own neo4j graph database.

• No data migration will be done.

• A Post-installation script will be created to create necessary objects in graph DB.

Cassandra:

• inQuiry will share the Cassandra DB with Knowlg BB but will have its own keyspaces having building block names.

• No data from SunbirdEd will be migrated.

Redis:

• inQuiry will share the Redis DB with Knowlg BB but will have its own DB number specific to the building block.

• No data from SunbirdEd will be migrated.

Elasticsearch:

• inQuiry BB will share the ES DB with Knowlg BB but will have its own DB index specific to the building block.

• search indexer and other jobs will be configured to write data to inQuiry specific ES index.

• search-service will be configured to inQuiry specific ES index to consume the data.

• No data from SunbirdEd will be migrated.

Kafka:

• inQuiry will share the Kafka server with Knowlg BB but will have its own topic name specific to building block.

• inQuiry will not install the data product which performs Kafka topic backup.

Jenkins:

• inQuiry will have its own Jenkins Server.

K8s Cluster:

...

Deployment Structure:

• inQuiry is dependent on below services and jobs from Knowlg BB:

  • search-service

  • taxonomy-service

  • content-service

  • search-indexer flink job

• inQuiry will install all dependent services/jobs in its own infra.

inQuiry with Knowlg using Same DB:

inQuiry portal will use Knowlg channel, category definition & search api's.

• assessment-service:

  • assessment-service will be deployed with its own configuration.

  • assessment-service will be configured to make db calls for category definitions.

• flink jobs:

  • questionset-publish:

    • It will be installed with inQuiry specific configuration.

  • auto-creator-v2:

    • the job makes 2 api call (get hierarchy & add to hierarchy).

    • the api calls will be made using internal content-service url and end points (url & endpoint will be a configuration)

  • search-indexer:

    • No need to install search-indexer job for inQuiry, as graph db is same.

• Neo4j:

  • inQuiry doesn't need to install db extension, if graph db is same.

• Logstash:

  • No need to install for inQuiry

• Kafka:

  • assessment-service will use its own kafka topic for publishing question/questionset.

• Cassandra:

  • inQuiry will have its own keyspace names.

• Redis:

  • inQuiry will use db number assigned to BB.

• ES:

  • inQuiry will use Knowlg search-indexer job and will write data to Knowlg Index (e.g: compositesearch)

  • inQuiry will use Knowlg search-service and consume data

inQuiry without Knowlg using Different DB:

inQuiry portal will use Knowlg channel, category definition & search api's.

• assessment-service:

  • assessment-service will be configured to make db calls to get the category definition as taxonomy-service will be installed.

• flink jobs:

  • questionset-publish:

    • It will be installed with inQuiry specific configuration.

  • auto-creator-v2:

    • the job makes 2 api call (get hierarchy & add to hierarchy).

    • the api calls will be made using internal content-service url and end points (url & endpoint will be a configuration)

  • search-indexer:

    • inQuiry will install search-indexer job with inQuiry specific configuration.

    • The job will write data to inQuiry Index (e.g: inquiry_searchindex)

• Neo4j:

  • inQuiry need to install db extension, because graph db server is different.

• Logstash:

  • Need to install for inQuiry

• Kafka:

  • a inQuiry specific topic need to create for search-indexer job also.

  • assessment-service will use its own kafka topic for publishing question/questionset.

• Cassandra:

  • inQuiry will have its own keyspace names.

• Redis:

  • inQuiry will use db number assigned to BB.

• ES:

  • inQuiry will use its own search-indexer job and will write data to own Index (e.g: inquiry_searchindex)

  • inQuiry need to deploy search-service from Knowlg BB to consume the data. the service will point to inQuiry index.