[Pulp-dev] [Breaking] Minor change to typed repositories
There is a minor change for Pulp 3 plugin writers Repository models merging today. It's a very simple one-line code change. On your Repository subclass, define the CONTENT_TYPES constant as a list with all of the Content types (the classes) supported by this type of repository, like this: https://github.com/pulp/pulp_container/pull/25/files#diff-90a314d7b2d5ddb20d360be02a4ec146R189 This change will allow for better performance and validation inside of Pulpcore, as it knows what types it's dealing with ahead of time. ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Required fields for models at the DB level
I talked to @ttereshc this afternoon and a couple questions came up. First, in pulp_rpm we have a PackageSerializer[0] that handles creating and displaying packages. The problem is that the package field values are derived from the artifact and not the user so most fields are readonly and not required. I'm imagining we'll have to split this serializer in two (ie a PackageSerializer and a PackageUploadSerializer) in order to use it to validate package data. Does that make sense or is there a better way? Secondly, I don't think we're validating data during sync. What if a user syncs data from a remote that has bad data? I think we'll need to have the stages somehow use serializers as well? If others agree, I can file an issue. [0] https://github.com/pulp/pulp_rpm/blob/326d189bbae9267d59282d62ada1fa36467a2d8f/pulp_rpm/app/serializers.py#L69 David On Thu, Dec 5, 2019 at 6:32 AM David Davis wrote: > This makes sense to me. I wonder if we should document what you've > outlined in the plugin writers guide? If so, then maybe we should repurpose > 5828? > > David > > > On Tue, Dec 3, 2019 at 12:14 PM Brian Bouterse > wrote: > >> After some IRC discussion during open floor, I think the consensus is >> that we should not have BaseModel call full_clean(). Plugin writers doing a >> lot of object creation without involving DRF serializers should call >> full_clean() either in application code or their specific model's save() >> method. Here's some recap about the motivations for this: >> >> * By having full_clean() called with all model save it gives Pulp "two >> validation layers" when there only needs to be one. DRF's validation layer >> is the serializer, and it isn't prepared to do error handling from a >> "second" layer. This is partly an echo of the concerns from Tom Christie's >> writing. >> * DRF is primarily designed to have data flow through its serializers. >> This issue is more problematic in cases where data is not flowing through >> the serializer. Thus we should try to include the serializer whenever >> possible. >> * If we cannot include the serializer, those are cases where we would >> specifically benefit from calling full_clean manually. >> >> Other thoughts and concerns are welcome. If nothing major comes up then >> we can close https://pulp.plan.io/issues/5828 as WONTFIX. >> >> >> >> On Mon, Dec 2, 2019 at 6:52 PM Simon Baatz wrote: >> >>> On Mon, Dec 02, 2019 at 03:53:06PM -0500, Brian Bouterse wrote: >>> >If anyone has concerns with us enabling Model validation by default >>> on >>> >all models please let us know soon. >>> >>> I don't know (yet) if I have concerns, but DRF seems to have, see >>> >>> https://www.django-rest-framework.org/community/3.0-announcement/#differences-between-modelserializer-validation-and-modelform >>> >>> According to DRF's design, all validation logic should be at one >>> place, which is the serializer. This seems to be a controversial >>> issue, see e.g. >>> https://github.com/encode/django-rest-framework/issues/3144. From >>> that issue: >>> >>> What happens in the case where in your models you are forcing a >>> full_clean (perhaps by including it in the save method)? Will >>> serializers know how to handle an exception from an explicit >>> full_clean? >>> >>> And Tom Christie's answer: >>> >>> I'd recommend that application level validation should generally >>> happen prior to save, not during it. Personally I'd avoid >>> full_clean, and instead ensure that state changing operations on >>> model instances are only ever made via method calls that can provide >>> a boundary that ensures that only valid state changes may ever be >>> made by the rest of the application. >>> >>> >>> >>> We need to be aware that we are leaving the path recommended by DRF >>> if we implement this proposal and mix Django validation and DRF >>> validation. Unfortunately, I don't know what the alternative is. >>> Using DRF serializers to construct all model instances looks clumsy >>> when it comes to relations. >>> >>> ___ >> 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
Re: [Pulp-dev] pulpcore release freeze and release timeline details
Sounds good. I'm planning to wait on the docs push and official switchover until pulp_rpm and pulp_container are released. If that takes a little more time that is ok; there is a lot of value in announcing together. I'm excited! On Fri, Dec 6, 2019 at 5:32 AM Tatiana Tereshchenko wrote: > Thank you. > It sounds good for pulp_rpm. > However, since not all the blockers are resolved at this moment, there is > no full confidence that we'll be able to release pulp_rpm on Dec 12. > The likelihood of solving them by that day is high, so let's set it as a > goal for pulp_rpm. > > Tanya > > On Fri, Dec 6, 2019 at 1:54 AM Ina Panova wrote: > >> Brian, >> Thank you for the provided details. >> >> Ack, on releasing pulp_container on Dec 12. >> >> On Thu, 5 Dec 2019, 18:52 Brian Bouterse, wrote: >> >>> Releasing takes time, and we need pulpcore to be available before the >>> releasing of plugins can start. Here's a proposed timeline to allow that to >>> happen. >>> >>> Dec 10 - 22:00 all code merged to 'master' >>> Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to >>> pypi. Announce only to pulp-dev (not the official announcement) >>> Dec 12 - pulp_rpm, pulp_container release >>> Dec 12 - the docs.pulpproject.org and pulpproject.org website changes >>> are applied >>> Dec 12 - Send out announcement to pulp-dev, twitter, and blog >>> >>> @ttereshc and @ipanova how does this look to you for releasing pulp_rpm >>> and pulp_container on the 12th? >>> >>> Any feedback or adjustment is welcome; please let me know. >>> >>> Thanks! >>> Brian >>> >>> ___ >>> 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
Re: [Pulp-dev] pulpcore release freeze and release timeline details
Thank you. It sounds good for pulp_rpm. However, since not all the blockers are resolved at this moment, there is no full confidence that we'll be able to release pulp_rpm on Dec 12. The likelihood of solving them by that day is high, so let's set it as a goal for pulp_rpm. Tanya On Fri, Dec 6, 2019 at 1:54 AM Ina Panova wrote: > Brian, > Thank you for the provided details. > > Ack, on releasing pulp_container on Dec 12. > > On Thu, 5 Dec 2019, 18:52 Brian Bouterse, wrote: > >> Releasing takes time, and we need pulpcore to be available before the >> releasing of plugins can start. Here's a proposed timeline to allow that to >> happen. >> >> Dec 10 - 22:00 all code merged to 'master' >> Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to pypi. >> Announce only to pulp-dev (not the official announcement) >> Dec 12 - pulp_rpm, pulp_container release >> Dec 12 - the docs.pulpproject.org and pulpproject.org website changes >> are applied >> Dec 12 - Send out announcement to pulp-dev, twitter, and blog >> >> @ttereshc and @ipanova how does this look to you for releasing pulp_rpm >> and pulp_container on the 12th? >> >> Any feedback or adjustment is welcome; please let me know. >> >> Thanks! >> Brian >> >> ___ >> 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
