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', ]}
>>>
>>> That story would be 3.x materials since it's a breaking change.
>>>
>>
>> I should have said "quicker than adding roles management". :)
>>
>>>> Cons:
>>>> - will collide with roles management that we are bound to have at some
>>>> point (but not in a near future sadly)
>>> Why not define roles along the project description ? (as proposed above,
>>> the ptl and core groups could be listed there)
>>>
>>>> - you need to give commit rights on the config repos for it to be fully
>>>> usable.
>>> Everyone should be able to propose config-repo change, only admin should
>>> be able to approve... Isn't that the case already ?
>>>
>>>
>>
>> So how is this different from having the admin creating the project if the
>> change can only be validated by him ? That was the point I was trying to
>> make here.
>>
>
> I see 2 main advantages:
>
> * Self service where the requester fills all the blanks and operators
> only validate the needs.
> * History and formal definition of projects, it's no longer an out of
> bound ping to operator and we get a clear definition of what is
> hosted on a deployment.
As a follow up I wanted to share my thoughts about some changes that will bring
in SF:
* 90% of our REST API (managesf) can then be removed
** Only the backup management and the personal info of a users, could stay in
the API.
* The scope of python-sfmanager will also be reduced according to the removal
of 90% of the managesf REST API
* The actual UI of SF (expect the top menu) will disappeared as the entry point
for the configuration will be only the config repo.
IMO using the config repo "only" clarifies the functional configuration of SF
and by the way reduce the amount of work for to us to maintain a REST API,
a CLI, and a UI ...
For the UI we can think later of having nice display of the yaml(s) that
describe
projects, groups, roles, ... but allowing modification of (eg. a project conf)
via
the UI will challenging and difficult.
I'll be happy to discuss more about the design of this new exciting feature
in that thread but first we need to all align on that same goal so please
give your clear opinion on it.
Mine is: +2 you can count me in :)
Cheers,
Fabien Boucher
_______________________________________________
Softwarefactory-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/softwarefactory-dev
