...
Agenda
- Architectural discussion : single entry point for services
- looking for 1 entry point to all of the microservices, discussed briefly how today smi services leverages zuul. Should this also be considered for on-taskgraph and other future RackHD services?
- currently smi services are also using the workflow engine as an entry point to those services. Looking to eliminate the smi/workflow engine dependency and leverage a standard api gateway.
- Zuul leverage for smi services as it met the smi service requirements
- Recommend looking at other technologies (including ngnix)
- Requirements: generate custom filters , load the config from a key-value store
- Generate a list of features for these technologies including a POC (how it would work with smi services and node.js)
- AI: Amy Mullinsto create epic and initial spike story(ies). Assignment can be coordinated through the managers. Recommending to go with a dev that knows the apis very well (redfish, 2.0)
- expectation is to have a report out on the various tech. including poc.
- Priority on RackHD backlog? AI: Thomas Sullivan to help determine where rackHD epics/racs are now prioritized.
- RackHD Release Cadence
- As we’re moving in to continuous delivery for the Concourse based CI (ie, deployed packages per merged PR), does that change the need or frequency for weekly RackHD sprint releases? Email thread started on 9/20.
- QRB discussion on 9/27 included having PR quality gates/Post Merge testing on virtual hardware and updating the weekly Sprint Release to run on physical hardware (Baremetal-Regression)
- Release process suggestions:
- Continuous deployment always overriding devel (debian) , latest (docker)
- Dockerhub not updating RackHD files tagged devel
- If we are releasing debians and docker containers AND the demo is moved to a docker image, do we still need to provide a script in the new CI env that allows users to generate a Vagrant based RackHD image
- 2 use cases: Vagrant based demo, Vagrant based dev environment
- Vagrant based demo becomes obsolete with the docker-compose based demo
- Vagrant based dev env also becomes obsolete with the docker-compose based demo (or other means/variations)
- 2 use cases: Vagrant based demo, Vagrant based dev environment
- As we’re moving in to continuous delivery for the Concourse based CI (ie, deployed packages per merged PR), does that change the need or frequency for weekly RackHD sprint releases? Email thread started on 9/20.
...