Opus-devel April 2010

opus-devel@lists.fedorahosted.org

5 participants
15 discussions

Deltacloud Support
by Michael Brown 28 Apr '10

28 Apr '10

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

1 1

Revamp Settings.py
by Eric D Helms 27 Apr '10

27 Apr '10

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

2 1

Dynamic urls.py population
by Eric D Helms 27 Apr '10

27 Apr '10

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

3 3

26 Apr '10

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

1 0

Database model change
by Michael Brown 26 Apr '10

26 Apr '10

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

1 0

Development Procedures
by Michael Brown 25 Apr '10

25 Apr '10

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

1 0

Log level setting
by Michael Brown 24 Apr '10

24 Apr '10

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

1 0

Re: [Opus-devel] Fwd: [celery-users] Re: Tasks being executed twice
by John Bass 22 Apr '10

22 Apr '10

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 > >

1 0

Django Groups vs. Custom Roles
by Eric D Helms 21 Apr '10

21 Apr '10

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

1 0

IdpAuth Changes
by Eric D Helms 20 Apr '10

20 Apr '10

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Opus-devel April 2010