Pulp

I have the sense that we're going to end up having to rewrite just about everything. I also think that formalizing what we refer to as the pulp "platform" might be done by namespacing pulp'such as the s platform elements (such as the django project) as 'pulp.platform'. We could then import pulp.platform.models, for example.

We've already got a decent categorization going of our models, so at least in platform I think it makes sense to split the models up into multiple modules by category (e.g. repository, contentunit, tasking, lazy, etc). Django has guidelines for doing this: https://docs.djangoproject.com/en/1.9/topics/db/models/#organizing-models-in-a-package

To get started with a database, we're going to want to take a look at the existing server.conf loading code and use that to build the DB connection string in Django's settings.py. Additionally, we might want to customize the postgres connection class to handle our existing reconnect-on-failure behavior.

mhrivnak wrote:

I was also thinking today about the difference between pulp.plugins and pulp.server, and whether we want to tackle cleaning that up. I think a lot of it will happen naturally as stuff gets refactored. And moving code around isn't too big of a deal, so we can also do that later.

Since moving code around isn't too big of a deal, I'd rather put the the Django project in a new namespace to start, so it's easier to see what work's been done during the process.

semyers wrote:

mhrivnak wrote:

I was also thinking today about the difference between pulp.plugins and pulp.server, and whether we want to tackle cleaning that up. I think a lot of it will happen naturally as stuff gets refactored. And moving code around isn't too big of a deal, so we can also do that later.

Since moving code around isn't too big of a deal, I'd rather put the the Django project in a new namespace to start, so it's easier to see what work's been done during the process.

I see your point. Although while moving code isn't a big deal, deciding where to move it and why can be a big deal. That probably deserves its own discussion (which I am very interested to have), but I don't think that discussion should block this task.

After some more consideration, I think that adding the server.conf support to the django settings can be split out into its own task, and doesn't need to be part of the initial effort to get developers a working django env for development. Initially I think it's worthwhile to just get Vagrant working right, which means we can make reasonable assumptions about the database settings to start.

The existing code in rel-pulp that I'm converting to work in the current pulp codebase to start 3.0-dev is, at the moment, written to be python3 only (largely print statements), which makes it difficult to install in the current pulp dev env. My proposed solution is to bring in print_function from future where needed to get our "new" Django install working in the existing platform virtualenv.

3.0-dev branches are up in platform and devel:
https://github.com/pulp/pulp/tree/3.0-dev
https://github.com/pulp/devel/tree/3.0-dev

jortel and I are planning to add more implemented models to provide useful examples for folks picking up some of the many linked "create models" tasks, and we still need to add some basic docs about setting up the DB and getting Django to actually do stuff with the models being written.

This is also loosely related to #2194, in that having fixed bash aliases to manage the db would be useful when creating the "getting started" docs