Hi, Thanks for bringing that subject.
Le 21/11/2016 à 03:29, Tristan Cacqueray a écrit : > Hello Folks, > > with the resources management in place, it's a good time to think about > the API V2 of managesf. Here is a review of the current controllers and > some proposition to improve them. > > # ProjectController and GroupController > It seems like we need to drop those legacy controller since the > resources controller cover those features. However we will lose an easyor > way to create project, where it used to be a one liner call to > sfmanager, it now involves creating quite a complex yaml description and > going through the ci/cd workflow of the config repo. Yes we no longer need them as well as the memberships controller. The direct_apply endpoint of the resources controller allow to bypass the CICD workflow for a rapid way of creating resources. > It seems like we could keep those controllers as a simple interface to > create and delete resources for test purpose. But we could also do that > entirely from the client side, e.g. provides a simple CLI method to > create resources and submit the change to the resources controller. The direct_apply controller use the diff strategy of the resources engine. Creating/Deleting a resource is a simple as providing two yaml (previous state and wanting state). But again the change won't be reflecting in the config repo resources/. It is just for tests use cases or really special production use cases. > I'll be in favor of the later so that we keep the API simple. Though it > may certainly be a problem for the GUI based work-flow. Same. But, maybe, having it in in form of API can be a good idea too: Two modes of submission: * direct_apply * CI/CD workflow Project templates available: * For now we can by default only provide the layout we use today with two groups and the related ACLs Then the UI will be able to provide a button to let the user easily propose a new project (repo + groups + acls) according to the selected template. We can even force the managesf API to propose the change with the caller identity ... And for the tests we use the same endpoint but with the mode direct_apply. > # LocalUserController > Change from /user to /local_user endpoint for clarity. > > # LocalUserBindController > Change from /bind to /local_user/bind for simplicity > > # ServicesUsersController > Change from /services_users to /user for clarity. I personally find it > difficult to remember the difference between user, services_users and > the actual service_user. Since services_users are actually users, let's > use the correct path: /user. > > We also need to unify the interface parameters, it currently uses > "full_name" for post and it returns "fullname" in get... Let's define an > user object with a single set of key names, e.g.: email, username, fullname. > > # ConfigController > IIUC, this is just to tell if a user can create projects... I propose we > drop that controller, and start designing a dashboard controller instead > as suggested here: https://softwarefactory-project.io/storyboard/#!/story/2 > > The idea would be to have a controller that the dashboard would call to > retrieve the informations, such as which project are relevant to a user. Ok. I see that as a really advanced feature. My idea was just to provide a page that list all the projects/repos hosted on the platform and use that page as the platform welcome page. > # TestsController and PagesController > Likewise the Project and Group controllers, shouldn't this one be > integrated in the resources management? For the TestsController why not simply remove it. I don't see the real value of it. The PagesController is a good candidate to be moved in the resources git style. Cheers, Fabien > > That's it for my thoughts, I'd like to get your feedback and start > creating the stories to implement those changes for the new /managesf/v2 > root controller. > > Yours, > -Tristan > > > > _______________________________________________ > 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
