Pulp

This is pretty focused on master/detail right now, but I suspect that we'll want to expand the acceptance criteria from here to include some other things that I may have left out here that are essential goals for a test app.

I thought I posted this on Friday, but apparently not. :(

I dabbled with the code side of this a little bit to see how loading the test app might work. Here's what I came up with as a sort of PoC:
https://github.com/pulp/pulp/compare/3.0-dev...seandst:rm2369

That code looks good. How should we deliver this code to developers for testing? One way would be to make this the file plugin. Having this code used for more than just testing will likely keep it maintained and usable. If we don't plan to keep this around for a long time then just having it on a branch that we can grab from time to time would be fine too.

bmbouter wrote:

That code looks good. How should we deliver this code to developers for testing?

I was thinking pretty much as-is, embedded in the pulp.app.tests namespace. There's not enough functionality here to really help any developer out, though.

One way would be to make this the file plugin.

If that's the case, we should kill this story and do the ones about creating the file plugin. I don't think that's what this story is about, though.

Having this code used for more than just testing will likely keep it maintained and usable.

I think that having this code used solely for testing will have the same result. The point (as I see it, at least) isn't that the code is usable so much as the code is testable, and is usable as an example. I think we need a way to make sure the Master/Detail stuff is working as intended from Model to API ViewSet without using any single plugin to verify its functionality. This story (again, as I see it) is about providing that ability to validate critical platform functionality without doing it through a plugin (like we do now mostly with pulp_rpm and smash runs).

In the conversations about what to test and what not to test, I think we absolutely must test that our custom stuff (Master/Detail Models and related API objects, GenericKeyValueStore and related API objects, other custom model/manager behaviors, etc) works with every commit.

If we don't plan to keep this around for a long time then just having it on a branch that we can grab from time to time would be fine too.

I'd like to keep this around forever.

semyers, I better understand this now. Thanks for writing.