Thank you for the update, my notes based on the grooming we had: On 08/12/2016 10:52 AM, Fabien Boucher wrote: > Hi, > > A follow up on that. For the current sprint we decided to deal with the > story http://softwarefactory-project.io/redmine/issues/1500. But thinking > about > the list action of the project endpoint and thinking about the future plan > of having resources defined in a projects.yaml or a couple of yaml files then > IMO we should start storing internally in managesf projects details in > a yaml DB to start create code compatible with this yaml format. > > The idea is too: > - Put this story 1500 in the corner > > And create a new story for: > - Create a minimal YAML backend driver > - Define a beta format for the project YAML structure > - Make the project endpoint compatible with this new backend (existing action > should still work as before) > - Create an update task that will read the current state of the platform to > populate that YAML backend > of an existing SF > > > The first implementation will be as follow: > CLI or UI -> REST managesf/project -> services plugins (gerrit, redmine, > storyboard) > | > | > ↓ > YAML Backend > > Later when all is described in the new YAML format then we can move to > something like: > CLI or UI --------- > \ > \ > \ > config-update -> REST (POST/GET) managesf/resources -> services plugins > | > | > ↓ > GIT config Backend >
The above schema doesn't compute, it seems like we need to support 2 flow:
CLI/UI -> REST (POST/GET) -> GIT config backend -> config-update
Code Review -> config-update
And then:
config-update -> REST (POST) -> service plugins
So perhaps two REST controller/api version to support those 2 distincts
flow.
> Where the POST and GET will only update or return YAML sections and endpoints
> such as
> project, memberships will be removed.
>
> I propose we start to deal with the first implementation as a POC.
>
> A beta project YAML structure could be as follow:
>
> resources:
> projects:
> - namespace: software-factory
> - git-repo: software-factory
> name: ...
> description: ...
> gitweb: ...
> website: ...
> tracker: ...
> git-replica: ...
> - project: cauth
> name: ...
> description: ...
> gitweb: ...
> website: ...
> tracker: ...
> git-replica: ...
> - namespace: DCI
> - git-repo: dci-control-server
> name: ...
> description: ...
> ...
>
Why using a namespace key ? It seems like the format proposed bellow is
more yaml friendly... How about a mix of both:
projects:
"project-name":
description: blah
url: blah
deliverables:
...
roles:
"ptl": {}
"core": {}
"..."
other_resources: {}
> I think this format could be a good starting point.
>
> Let me know what do you think.
>
> Fabien
>
> Le 24/06/2016 à 11:09, Fabien Boucher a écrit :
>> Hi,
>>
>> Le 23/02/2016 à 17:48, Tristan Cacqueray a écrit :
>>
>>>>> "sf":
>>>>> ptl: {name: ..., irc: ..., email: ...}
>>>>> irc-channell: ...
>>>>> description: ...
>>>>> url: ... (for pages controller)
>>>>> tags: lxc-based-ci, nested-rdo-ci
>>>>> deliverables:
>>>>> 'image': {repos: ['software-factory', ], ci: 'functional-tests'}
>>>>> 'client': {repos: ['python-sfmanager', ] ci: 'unit-test'}
>>>>> 'server': {repos: ['managesf', ]}
>
> _______________________________________________
> Softwarefactory-dev mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/softwarefactory-dev
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
