Deltacloud Support
by Michael Brown
The long awaited support for Deltacloud has come. The ec2 credentials have
been replaced with 3 deltacloud settings.
DELTACLOUD_API_URI - Should be a valid deltacloud api uri.
DELTACLOUD_USERNAME - You can use your ec2 access key here
DELTACLOUD_PASSWORD - You can use your ec2 secret key here
At the moment, there are problems when the API_URI is not set to something
valid. I will fix these shortly and send out another email when that's
done.
--Michael Brown
14 years
Revamp Settings.py
by Eric D Helms
This is to follow-up on how to handle settings.py in an application specific
way. Generally speaking - the Django community does not feel that the this
issue requires a single encouraged solution. The feeling is that different
situations and deployments call for different needs and thus it should be up
to the developer to decide.
The link below is from the Django wiki, and enumerates ideas and concepts
for splitting up the settings file.
http://code.djangoproject.com/wiki/SplitSettings
I feel we should review and decide what idea will work best for us and
enforce it as part of our own development procedure.
- Eric Helms
14 years
Dynamic urls.py population
by Eric D Helms
I did some digging today on the Django developer's list about solutions to
the dynamix population of urls.py based on a setting in the settings.py
file. A little bit of history, it would appear they discussed this very
concept 4ish years ago. There has also been a good amount of discussion
related to revamping the application loading process of Django in order to
make it more straightforward. The complaint most often has is that if an
application is put under installed_apps, shouldn't that take care of all
this setup for you?
With that being said - the consensus against having a dynamic generator is
that it introduces code that is somewhat 'magical' and has more break
potential. (And a guiding principle of Django is to avoid 'magic' code at
all costs) Rather, the potential answer seems to lie in thinking about and
treating urls.py as a settings file itself. (And thus, a urls.py.sample
could be used for version control while urls.py contains your local
settings)
To reiterate the options:
1) Create a dynamic urls.py pattern generator for a custom setting in
settings.py that lists all applications that need a urls.py entry
2) Treat urls.py like a settings file and have a urls.py.sample for version
control
My opinion is that while the first option is more powerful, the second is
simpler to implement (and the Django community seems to have bigger things
in the works that would potentially handle this in future releases).
Eric Helms
14 years
Login Redirects
by Eric D Helms
A quick update for anyone creating views in their apps that they want to
restrict to authenticated users. Previously all logins were redirected to
VDI as per the original model. With the integration of Django's
authentication backends, and a recent change to the login views and
templates, any view that has the @login_required decorator will redirect an
un-authenticated user to the proper login page. Upon successful
authentication with whatever identity provider, the authenticated user will
be redirected to the original page they attempted to access.
Eric
14 years
Database model change
by Michael Brown
I've pushed a commit which made a change to the vdi_applications table. You
will need to delete the table and re sync the database.
--Michael Brown
14 years
Development Procedures
by Michael Brown
The development procedures page is mostly complete. Check it out here:
https://fedorahosted.org/opus/wiki/development
Please read through and reply with suggestions. I'm sure there's a lot that
is missing. If there isn't already a TODO for something, create it or just
reply to this email.
--Michael Brown
14 years
Log level setting
by Michael Brown
There is now a way to specify the log level. There is a new setting in
settings.py called LOG_LEVEL. After pulling you will need to copy the
declaration over to your settings file.
--Michael Brown
14 years
Re: [Opus-devel] Fwd: [celery-users] Re: Tasks being executed twice
by John Bass
i'd like to talk about this sometime. all the import options are a bit
mysterious to me...
John Bass
ITng Services
(919) 515-0154
On Thu, Apr 15, 2010 at 7:13 AM, Brian Bouterse <bmbouter(a)gmail.com> wrote:
> Here is an example of a problem that comes from using import blah instead
> of from blah import x. If it isn't obvious what these folks are talking
> about we can talk more on the list or in person. Just some food for thought
> I wanted to share.
>
> Best,
> Brian
>
> ---------- Forwarded message ----------
> From: Wes Winham <winhamwr(a)gmail.com>
> Date: Wed, Apr 14, 2010 at 10:45 AM
> Subject: [celery-users] Re: Tasks being executed twice
> To: celery-users <celery-users(a)googlegroups.com>
>
>
> I was actually having this exact same problem. It was precipitated by
> my sloppy path management I think. When I started the project in
> question, my understanding of python was pretty limited, so I had put
> both my django project directory and the directory above my project on
> the python path, which meant all of my apps were addressable as both
> project.appname and appname. I then proceeded to be inconsistent about
> which path I used when I imported different things, which lead to a
> general mess of this class of problem.
>
> Anyway, I tried to clean up my code, but I still haven't eliminated
> all of the "import appname" style references, which was causing me to
> duplicate all of the tasks contained in apps inside my project
> directory. I upgraded to 1.0.2 yesterday though, and the problem has
> somehow disappeared. I'm not 100% convinced that it was just the
> upgrade that fixed it, as I changed some other code in the interim,
> but it's definitely the most likely candidate. One thing I'm doing
> that might be different is that I'm explicitly registering all of my
> tasks still (after an upgrade from 0.something => 0.8 => 1.02) using
> celery.registry.tasks.register(MyTask).
>
> -wes
>
> On Apr 14, 6:25 am, Rickard Böttcher <rickard.bottc...(a)gmail.com>
> wrote:
> > Hi, I use celery in a django project. I have an issue where my tasks
> > are being
> > loaded/scheduled/executed twice for each task, once for
> > projectname.appname.tasks.taskname and once for
> > appname.tasks.taskname.
> >
> > Using RabbitMQ v1.7.2, celery 1.0.1.
> >
> > The log from celeryd shows the tasks being loaded twice as well as
> > executed twice:
> > (check_status task is a periodic task)
> >
> > Configuration ->
> > . broker -> amqp://projectname@localhost:5672/projectname
> > . queues ->
> > . celery -> exchange:celery (direct) binding:celery
> > . concurrency -> 1
> > . loader -> celery.loaders.djangoapp.Loader
> > . logfile -> [stderr]@INFO
> > . events -> OFF
> > . beat -> ON
> > . tasks ->
> > . projectname.appname.tasks.check_status
> > . appname.tasks.check_status
> >
> > [2010-04-14 11:42:31,006: INFO/PoolWorker-2] child process calling
> > self.run()
> > celery@localhost has started.
> > [2010-04-14 11:42:31,015: INFO/_Process-1] child process calling
> > self.run()
> > [2010-04-14 11:42:31,017: INFO/_Process-1] ClockService: Starting...
> > [2010-04-14 11:47:00,018: INFO/MainProcess] Got task from broker:
> > projectname.appname.tasks.check_status[811eeb14-3437-4a0a-
> > bcd2-221ed52ba2d6]
> > [2010-04-14 11:47:00,030: INFO/MainProcess] Got task from broker:
> > appname.tasks.check_status[fccbeb3d-d0ee-47d0-a8eb-8dfe905061e9]
> > [2010-04-14 11:47:00,131: INFO/PoolWorker-2] check_status()
> > [2010-04-14 11:47:00,614: INFO/PoolWorker-2] check_status()
> > [2010-04-14 11:47:00,614: INFO/MainProcess] Task
> > appname.tasks.check_status[fccbeb3d-d0ee-47d0-a8eb-8dfe905061e9]
> > processed: None
> > [2010-04-14 11:47:01,083: INFO/MainProcess] Task
> > projectname.appname.tasks.check_status[811eeb14-3437-4a0a-
> > bcd2-221ed52ba2d6] processed: None
> >
> > Any ideas what might cause this behavior?
> >
> > /Rickard
>
> --
> You received this message because you are subscribed to the Google Groups
> "celery-users" group.
> To post to this group, send email to celery-users(a)googlegroups.com.
> To unsubscribe from this group, send email to
> celery-users+unsubscribe(a)googlegroups.com<celery-users%2Bunsubscribe(a)googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/celery-users?hl=en.
>
>
>
>
> --
> Brian Bouterse
> ITng Services
>
> _______________________________________________
> Opus-devel mailing list
> Opus-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/opus-devel
>
>
14 years
Django Groups vs. Custom Roles
by Eric D Helms
Hey all,
I wanted to get some input on Django Groups vs. Custom Role objects similar
to what we had before. First let me expound on the idea and then offer my
potential solutions.
The Django group, which is a collection of permissions, is very basic and
doesn't have much extra support. You can assign it permissions and give it
a name but there is no direct way to extend it. This presents the question
of how to tie an IdP to a set of groups.
The possible options I see:
1) Create a separate model that essentially connects an IdP to a set of
groups.
2) Create a custom Role model that contains an IdP, and a set of permissions
(and any other fields that might be necessary).
3) Add a field such that when you create (or edit) the IdP the Django groups
are stored within the IdP model itself.
Let me know your thoughts.
Thanks,
Eric Helms
14 years
IdpAuth Changes
by Eric D Helms
I have made and committed changes that have turned IdpAuth into a custom
authentication backend. This requires a few additions to your settings file
but no model changes. All functions wanting to require a logged in user
should use the Django framework decorators instead of the
user_tools.login_required.
While I have tested each login type to ensure functionality, please post
tickets with any bug reports encountered.
Also, the next step is to begin use of the permissions side of the
authentication framework for Django.
I am looking for input into a good and useful permission to work with and
test against.
- Eric Helms
14 years