Le 12/08/2016 à 14:35, Tristan Cacqueray a écrit :
> 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
Yes you are right the default way to propose a change will be via Gerrit
on the config repo and once a change is approved then it will be apply by
the config-update (triggering managesf REST interface).
And then for the CLI or UI displaying informations will be just reading
the YAML via a GET. If we want supporting changes the CLI and UI will need
to request the API (POST) that will one behalf of the user propose a change
on the config repo and return the changeID to the user.
> 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:
The namespace was more to group projects
(eg: namespace: SF, - project: a, project: b, ..., namespace DCI: project a,
...)
>
> 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
>>
>
>
>
>
> _______________________________________________
> Softwarefactory-dev mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/softwarefactory-dev
>
_______________________________________________
Softwarefactory-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/softwarefactory-dev
