On 06/24/2016 09:09 AM, Fabien Boucher wrote: > Hi, Hello Fabien,
thank you for reviving that thread, this really needs an open discussion :)
>
> 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
>
It seems like issue, project and group management are still relevant.
It's quite convenient to have managesf services to abstract CRUD
operation for each service. The main different would be that ~90% of the
REST API will be mostly used internally by the config-update job.
> * The actual UI of SF (expect the top menu) will disappeared as the entry
> point
> for the configuration will be only the config repo.
>
The UI could indeed consume the projects.yaml directly to display a
graphic representation of hosted projects. However it could still
benefit from the REST API to query live-data not present in the
projects.yaml, such as open issues.
> 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 ...
>
Agreed, code-review and ci job do sounds more efficient than manual rest
api call.
> 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.
>
IMO, removing write/modification action from the UI is acceptable since
it's currently sub-optimal and afaik, barely used.
> 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.
>
Again, thank you for reviving that thread, personally I'm mostly worried
about the migration to such architecture as well as the documentation
effort. It's really a disruptive change and it's probably a good
candidate for a major release, e.g. software-factory-3.0.0.
What really needs to be well defined is the format of the so-called
"projects.yaml"
> Mine is: +2 you can count me in :)
>
> Cheers,
> Fabien Boucher
>
Assuming the team agrees, I also believe it's a worthy effort :)
-Tristan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
