On Wed, Mar 28, 2018 at 12:20 PM, Ina Panova <ipan...@redhat.com> wrote:
> I do not think that it's a valid argument to ban the proposal just because > the proposal will bring changes to the existing plugins. Because: > > 1) i think it would be fair to think of other plugins and find a solution > all plugins will be happy with --> so we are back to the generic > correctness problem > 2) we are not GA, not even Beta, we are free and eligible to make changes, > no promises made yet. > 3) if we bring changes *this* exactly is the time to do because we have > just 2 plugins working with basic functionality :) > > W/r to the "Pulp turning into a task running system" ..and yet that's a > system based on distributed task system > Pulp may rely on a tasking system to get work done, but we don't want users thinking of it as a tasking system. We want our users to think of Pulp as a repository management system. > > I suggest to organize a meeting with an agenda in advance that would list > 1) concerns 2) questions > I also think it would be valuable to hear Jeff's feedback. > > If the team finds that meeting idea is beneficial with the believe that > after the meeting we will: > 1) i am not naive to believe that we would reach consensus but at least we > would move forward > 2) we will decrease the frustration level, because face2face conversation > is more profitable, since we do see faces, have social interaction and not > type onto keyboard and stare at the text on the monitor. > > then...I will take the action item and schedule the meeting. > > Meanwhile we'll have time to chew on Easter eggs and give to the proposal > a deeper, unbiased, full of protein (that helps brain thinking) thought. > > I am against having a meeting to discuss this. The discussion on the list has gotten traction and I'd like it to continue on here. > > > > -------- > Regards, > > Ina Panova > Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > On Wed, Mar 28, 2018 at 12:11 AM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> In terms of removing POST /api/v3/repositories/<uuid>/versions/ from >> core, I want to bring it back to the MVP language and REST which drove the >> original design. The MVP has: "As an authenticated user, I can create a new >> version by adding or removing content to the latest version." To >> facilitate that in a generic way, we need a core endpoint to do that, i.e. >> /api/v3/repositories/<uuid>/versions/. My concern is that removing it >> would cause us to not fulfill our use cases without requiring more code >> from some plugin writers. Also in terms of REST philosophy, POSTing to the >> RespotoryVersion resource to create a new RepositoryVersion is the >> traditional url design. >> >> For pulp_ansible, for example, the generic add/remove functionality at >> core endpoint ^ would be meet all of the pulp_ansible user's needs because >> of the way the pulp_ansible content is modelled. So removing this endpoint >> means more work for pulp_ansible developers w.r.t creating repo versions >> and providing tasks and endpoints. I don't see this extra responsibility on >> plugin writers coming with a clear benefit. >> >> One idea I liked in this discussion is to have a documented convention >> that encourages plugin writers to put their viewsets in a namespaced area. >> They still need the ability to put them anywhere due to live API >> goals/requirements so this would only be a convention for those tasks they >> are offering directly to their users. >> >> >> >> >> >> On Tue, Mar 27, 2018 at 5:40 PM, David Davis <davidda...@redhat.com> >> wrote: >> >>> I like Austin’s task proposal in that the plugin writers can focus on >>> serializers and tasks that can be easily integrated with core. That said, I >>> agree on the counterpoints raise about the new resource endpoints and >>> turning much of pulp into a task running system. So I am a bit mixed on >>> which approach is better. >>> >>> I do think that we should remove POST /api/v3/repositories/<uuid>/versions/ >>> from core. >>> >>> >>> David >>> >>> On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald <amacd...@redhat.com> >>> wrote: >>> >>>> >>>>> - /api/v3/repositories/<uuid>/versions/ endpoint does not perform >>>>> plugin specific validation which can lead to "broken" repository >>>>> versions. >>>>> - Plugin authors don't have any convention to follow when creating >>>>> custom REST API endpoints for creating repository versions. >>>>> - As a result of ^, a user will have a hard time identifying >>>>> repository version creation APIs in different plugins. >>>>> >>>>> >>>> I agree with these points. >>>> >>>>> >>>>> - >>>>> >>>>> My first inclination is to disable the ability to POST to >>>>> /api/v3/repositories/<uuid>/versions/ and require users to use the >>>>> plugin specific APIs for creating repository versions. However, I think >>>>> that integrators of build systems that produce a variety of content types >>>>> would have a lot more flexibility if they could use a single generic API >>>>> endpoint to create a repository version independent of the content type. >>>>> >>>>> Let's continue this discussion by answering the following question: >>>>> >>>>> - Should we disable the ability to POST to >>>>> /api/v3/repositories/<uuid>/versions/ and require users to always >>>>> use a plugin specific repository version creation API? >>>>> >>>>> Yes, I think we should disable POST to /api/v3/repositories/<uuid>/ve >>>> rsions/ >>>> >>>> Simplifying integration is important, but we should not sacrifice >>>> correctness enforcement. >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
