Page Comparison

...

1. Sunbird-inQuiry/quml-service (for assessment-service )
   /quml-service/assessment-service
   /quml-service/assessment-actors
   /quml-service/qs-hierarchy-manager
   /quml-service/build (build script)
   /quml-service/schema (question & questionset schema)
   /quml-service/definition (sunbird supported primary category & its definition script for quml)
   /quml-service/tests (API Functional Test Script/Code)

2. Sunbird-inQuiry/quml-jobs (for backend jobs)
   /quml-jobs/questionset-publish (for Question/QuestionSet Publish)
   /quml-jobs/auto-creator-v2 (for import of Question/QuestionSet)

3. Sunbird-inQuiry/quml-editor (for questionset editor)

4. Sunbird-inQuiry/quml-player (for quml player)

5. Sunbird-inQuiry/devops (devops script for provisining, deployements)

6. Sunbird-inQuiry/devops-cred or devops-private (private repo)

7. Sunbird-inQuiry/quml-portal (dummy portal for experiencing inQuiry feature)

...

quml-service:

configuration change:

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

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

• Kafka topic confiuration will be updated as per 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 building block name in keyspaces.

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

code changes:

• all common module listed in Current Code Strucure 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 below options:

  • option 1:

    • Checkout all dependent repos along with 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 parameterised branch will be written for the same. so that inQuiry can point to a specific branch/tag for dependent component.

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

  • option 2:

    • Add all dependent modules as submodule.

    • 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 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 current service folder structure.

• graph-engine module need 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. this enhancement can be taken up in next release.