...

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?

Proposed inQuiry BB Changes:

...

• Cassandra's keyspace configuration will be updated as per the new keyspace format.

• New Keyspace Format: [env_name]_[bb_name]_[keyspace_name] . e.g: dev_inquiry_hierarchy_store

• Kafka topic configuration will be updated as per the new format. New format: [env_name]_[bb_name]_[topic_name]

• if any other dependent services (e.g: taxonomy-service) will be deployed to inQuiry infra, that will also have similar inQuiry specific configuration changes.

schema/script change:

• Cassandra database script will be modified to have a building block name in keyspaces.

• Kafka topic creation script will be modified to have a building block name.

...

• all common modules listed in the Current Code Structure section will be pushed to either a common repo or different repo for each module - Need to decide by considering maven central movement for each component?

• For resolving common module dependency, we have the below options:

  • option 1:

    • Check out all dependent repos along with the main repo and do a sequential build (dependent module first. e.g: platform-core then graph-engine) and then build the main repo.

    • A custom Jenkins build script with the parameterised branch will be written for the same. so that inQuiry can point to a specific branch/tag for the dependent component.

    • We need to have a similar build script for local checkout and development.

  • option 2:

    • Add all dependent modules as submodules.

    • Modify the Jenkins build script to checkout the main repo along with all submodules.

    • For all submodules, a specific branch (e.g: 4.9.0) will be configured.

• For service level code movement, we have the below option:

  • option 1:

    • only assessment-service related code will be committed manually in the proposed structure because we need to take the code out from knowledge-platform/assessment-api folder.

  • option 2:

    • the entire knowledge-platform repo can be moved and then we can delete the unused code and modify the current service folder structure.

• the graph-engine module needs to be enhanced to either use a DB connection or API call for fetching category definition. the default option would be DB call unless it is configured for API call. - for now, we can deploy taxonomy-service under inQuiry BB and use the DB call or can directly point to Knowlg keyspace. this enhancement can be taken up in the next release.

Note:
1. inQuiry will build & deploy specific release versions of other services (e.g: taxonomy-service, search-service, etc) and upgrade these services as and when requiredalways make Knowlg api calls for dependent services. inQuiry won’t deploy any of them.

2. inQuiry will deploy search-indexer job, if graph db is going to be different for assessment-service.

quml-jobs:

• Two Jobs (questionset-publish & auto-creator-v2) will be moved to the inQuiry Github repo.

• For the above two jobs, two dependent components jobs-core and publish-core are required.

• These two common components should be present in the separate repo and should be pulled during the build of inQuiry specific jobs.

• Three other common jobs (search-indexer, audit-event-generator, audit-history-indexer) can be build and deployed under inQuiry infra from Knowlg BB.

• the inQuiry will maintain only the build & deployment script and BB Specific configuration for other jobs. the codebase will remain under Knowlg BB.

...