| burnbrighter | bigjools: are juju/openstack questions best answered here or on a different channel? | 05:03 |
|---|---|---|
| bigjools | burnbrighter: #juju | 05:05 |
| bigjools | or #juju-dev | 05:05 |
| bigjools | jtv: http://celery.readthedocs.org/en/latest/django/first-steps-with-django.html | 05:05 |
| jtv | bigjools: https://github.com/KayEss/django-async | 05:10 |
| bigjools | jtv: https://github.com/chrisdoble/django-celery-transactions | 05:15 |
| burnbrighter | bigjools: what I see is subsequent nodes to the first admin node created by juju don't seem to bootsrap and pull over things like the ssh keys and such. | 05:48 |
| burnbrighter | do you have any ideas? | 05:48 |
| jtv | burnbrighter: we're just otp, hang on | 05:49 |
| burnbrighter | sure | 05:49 |
| jtv | burnbrighter: we should be almost done… but the standard thing to look out for is clock skew between the node and the server. That breaks things. | 05:52 |
| burnbrighter | yes. I've been paying very close attention to that. Make note that the nodes have already successfully commissioned via maas, but its the juju side that's having problems | 05:54 |
| burnbrighter | I can only ssh with key successfully to the first node bootstrapped by juju | 05:55 |
| lifeless | burnbrighter: thats expected, you need 'juju ssh $unit' for other nodes | 05:57 |
| lifeless | burnbrighter: or have you been trying that ? | 05:57 |
| burnbrighter | that doesn't work either - yes "juju ssh 1" | 05:57 |
| burnbrighter | I discovered this because my agents don't show up as running - then I started digging | 05:58 |
| burnbrighter | only the agent on the very first node | 05:58 |
| burnbrighter | in my case, it was my maas07 node | 05:58 |
| burnbrighter | all of the nodes however show status "Allocated to Admin" | 06:01 |
| jtv | At that point you should be able to ssh in, with an ssh key registered for the Admin user. | 06:02 |
| burnbrighter | "should" is the operative word :) | 06:02 |
| jtv | (Of course the ssh key must have been registered in maas before allocating the node, but I'm guessing it was) | 06:02 |
| burnbrighter | yes indeedy | 06:03 |
| burnbrighter | at what point and how does the ssh key get to each node? | 06:03 |
| burnbrighter | is there a second bootstrap that happens from juju? | 06:03 |
| burnbrighter | my assumption is yes | 06:04 |
| jtv | I don't think so… juju hands maas some metadata that maas then makes available to the booting node. But the ssh keys are sent over by maas, I forget how. | 06:04 |
| lifeless | juju provides the key you configure in your environment to cloud-init. | 06:04 |
| lifeless | jtv: ^ | 06:04 |
| bigjools | only for bootstrapping | 06:05 |
| burnbrighter | its like these nodes aren't picking up this metadata | 06:05 |
| bigjools | I thought it passed the key via its own means on the units | 06:05 |
| bigjools | but I dunno | 06:05 |
| burnbrighter | I know it sounds like a classic case of oauth (or whatever its called) and utc time clock skew, but its not | 06:06 |
| burnbrighter | I also configured a password in to maas.preseed in hopes of accessing the node to do further digging, but that isn't working either | 06:07 |
| burnbrighter | Does the ssh-key need to be in place prior to maas-commission, or only before juju bootstrap? | 06:11 |
| burnbrighter | my assumption is the latter | 06:12 |
| bigjools | the latter | 06:14 |
| burnbrighter | Do I need to destroy my environment then and start over? Is that the best way to move forward? | 06:15 |
| burnbrighter | ie juju destroy, not maas re-do | 06:15 |
| bigjools | I don't think so | 06:28 |
| bigjools | but I'd ask the juju people as it doesn't seem like a maas problem to me | 06:28 |
| burnbrighter | this is one of those weird issues that seems to sit in the in between ground somewhere between maas and juju. | 06:29 |
| bigjools | it's possibly a bug in the maas provider code in juju, who knows | 06:30 |
| burnbrighter | any suggestions on who would be the expert in this area? | 06:31 |
| bigjools | *cough* :) | 06:35 |
| burnbrighter | :) | 06:35 |
| bigjools | I'd ask in the juju channel first and they will offer broader pointers. Although I wrote the provider, it was slightly blind. | 06:35 |
| bigjools | I dont know juju very well and I was the only one available to do it :) | 06:35 |
| burnbrighter | were you able to get this to successfully work in the lab? | 06:36 |
| bigjools | yes | 06:42 |
| bigjools | and locally in my virtual machines | 06:43 |
| burnbrighter | that's what I'm using is VMs | 06:43 |
| bigjools | I'd start with the juju people, they'll ask better questions than me | 06:44 |
| burnbrighter | I've got the question posted | 06:44 |
| bigjools | cool | 06:44 |
| burnbrighter | are most of those people on your side of the globe? | 06:45 |
| bigjools | most are in the Americas | 06:45 |
| bigjools | IIRC | 06:45 |
| burnbrighter | ok, cool | 06:46 |
| burnbrighter | cause I'm tired | 06:46 |
| burnbrighter | :) | 06:46 |
| burnbrighter | going to bed... | 06:46 |
| bigjools | yeah late for you | 06:46 |
| burnbrighter | near midnight | 06:46 |
| burnbrighter | cheez0r and I have been bouncing ideas off each other | 06:47 |
| burnbrighter | we actually work for the same company we found out | 06:47 |
| burnbrighter | :) | 06:47 |
| bigjools | haha | 06:48 |
| bigjools | which company? | 06:48 |
| burnbrighter | ah, one of those big american telcos | 06:49 |
| burnbrighter | think of the biggest gsm carrier in the US and you'll be right | 06:49 |
| === matsubara-afk is now known as matsubara | ||
| burnbrighter | Ok, think I figured it out. I had to before I went to bed. You need to start with all nodes off (that is key), otherwise the nodes can't bootstrap | 07:32 |
| burnbrighter | I've been doing them one at a time, and it appears the key is being installed along with the new image | 07:33 |
| burnbrighter | not necessarily in that order - I do see cloud-init install the key at the end | 07:33 |
| === matsubara is now known as matsubara-lunch | ||
| rbasak | How does MAAS currently determine what releases are available? Is it using distro-info, or is this hardcoded in some way? | 11:21 |
| === matsubara-lunch is now known as matsubara | ||
| roaksoax | rvba: | 11:27 |
| roaksoax | rvba: howdy! | 11:27 |
| roaksoax | jtv: http://pastebin.ubuntu.com/1062430/ | 11:44 |
| roaksoax | jtv: maas-import-pxe-files failing ^^ | 11:44 |
| jtv | Thanks. | 11:44 |
| roaksoax | jtv: this is from a new package i'm preparing | 11:44 |
| jtv | Any idea where those templates _do_ get installed? | 11:45 |
| jtv | I guess the path only works from the source tree. | 11:45 |
| roaksoax | jtv: yeah they do get installed, see at the end of the pastebin | 11:45 |
| roaksoax | jtv: I had to patch MANIFEST.in though | 11:46 |
| jtv | So it ended up in /usr/share/pyshared instead of /usr/share/maas | 11:46 |
| jtv | Ah no | 11:46 |
| jtv | it's more wrong than that :( | 11:46 |
| roaksoax | jtv: if I add the file to MANIFEST.in it is going to get installed with the python modules under /usr/share/pyshared/maasprovisioning/etc/etc/ | 11:47 |
| jtv | Doesn't seem reasonable to expect it under “src,” does it? | 11:48 |
| roaksoax | jtv: if I don't add it there, then it won't get installed at all | 11:48 |
| roaksoax | jtv: and yes it doesn't | 11:48 |
| jtv | Is there a standard way to resolve this in python packages? | 11:48 |
| roaksoax | jtv: you mean where it is being installed? | 11:49 |
| roaksoax | that particular file? | 11:49 |
| jtv | No, I assume that's standardized. | 11:49 |
| jtv | I mean, generating paths to artifacts that will work both in a source tree and on an installed version of the program. | 11:49 |
| roaksoax | jtv: well, isn't that what PYTHONPATH is for? | 11:49 |
| jtv | I'm not thinking of python modules, but files such as the one that we're failing to find here. | 11:50 |
| jtv | “Other” files that need to be installed, somewhere under /usr/share | 11:50 |
| roaksoax | jtv: right, but I mean, the file is being installed in $PYTHONPATH/maasprovisioning/etc/etc | 11:50 |
| roaksoax | so you should be able to use it from there | 11:51 |
| jtv | I thought PYTHONPATH could have multiple entries. | 11:51 |
| roaksoax | jtv: yes, it is a list of path's | 11:51 |
| roaksoax | jtv: in this case we install python modules in /usr/share/pyshared which is part of PYTHONPATH | 11:52 |
| jtv | Okay, but is there a standard pattern for writing paths that will pick up these files both when running in the source tree and when running from an installed package? | 11:52 |
| jtv | I'm guessing, not using quite so much “..” | 11:53 |
| roaksoax | jtv: I don't know TBH | 11:53 |
| roaksoax | jtv: i guess you'd have to evaluate whether the file is in src for running from trunk, if not, search it in pythonpath | 11:54 |
| jtv | And of course the one guy who knows that particular piece of code best just left and won't be back for a while. :) | 11:54 |
| roaksoax | lol | 11:54 |
| jtv | Searching for it… what a pain. | 11:54 |
| roaksoax | jtv: i guess using something like this: os.path.join(os.path.dirname(__file__), "templates"), | 11:55 |
| jtv | Yeah — without the “..” would be easier. | 11:56 |
| roaksoax | self.path = os.path.join(basedir, power_type + ".template") | 11:57 |
| roaksoax | jtv: so you can do it similarlay to how it is being done with the power templates ig uess | 11:57 |
| roaksoax | power/poweraction.py: self.path = os.path.join(basedir, power_type + ".template") | 11:57 |
| jtv | Okay, several distracting phone conversations later… | 12:00 |
| jtv | Let's just have a look | 12:00 |
| jtv | Right after I deal with a difficult toddler | 12:01 |
| jtv | Ow argh | 12:02 |
| jtv | That's not the toddler. It's the code. | 12:03 |
| jtv | The path to those templates is configurable, which is good. | 12:03 |
| jtv | But it's set in etc/celeryconfig.py | 12:03 |
| jtv | —which means it's hard to get back to src/provisioningserver/pxe/ (where the path is actually needed) without the ..! | 12:03 |
| jtv | I think there's an easier way. | 12:04 |
| jtv | Have a built-in default: os.path.join( os.path.dirname(__file__), 'templates' ) | 12:05 |
| jtv | Give etc/celeryconfig.py the ability to override that | 12:05 |
| jtv | But have it default to None, which means use the built-in default. | 12:05 |
| jtv | roaksoax: I don't suppose we could just stall src/provisioningserver/pxe/pxeconfig.py and src/provisioningserver/pxe/templates/ into the same location? | 12:07 |
| roaksoax | jtv: but isn't it easier to join path of pxeconfig.py + templates | 12:08 |
| roaksoax | ? | 12:08 |
| jtv | That won't work if the two ain't in the same location, will it? | 12:08 |
| jtv | By “stall” I meant “install.” | 12:08 |
| jtv | Typo. | 12:08 |
| jtv | So: can we install things such that os.path.join( os.path.dirname(__file__), 'templates' ) will actually work? | 12:11 |
| jtv | And yes, that is the same thing as joining the path of pxeconfig.py + templates. | 12:11 |
| * roaksoax looks | 12:11 | |
| roaksoax | jtv: ok so it seems that there's a few things to improve | 12:18 |
| roaksoax | jtv: 1. celeryconfig.py should be taken out of "etc/" and should be placed somewhere in the PYTHONPATH as this file is not meant to be modified. | 12:19 |
| jtv | Isn't it? I have no idea. | 12:19 |
| roaksoax | jtv: check at the source, it is being shipped in etc/celeryconfig.py | 12:19 |
| roaksoax | jtv: which makes me understand that this is meant to be installed into /etc/maas/ | 12:19 |
| roaksoax | however, this should be treated as how we are treating settings.py and maas_local_settings.py | 12:20 |
| jtv | Probably, yes. | 12:22 |
| jtv | How does the packaging treat those? | 12:22 |
| roaksoax | jtv: src/maas/* is installed in /usr/share/maas/maas/* which contains the settings.py. Then maas_local_settings.py is installed in /etc/maas and symlinked into /usr/share/maas. So, since celeryconfig.py is meant to not be modified, should be installed in a location like /usr/share/maas/maas or /usr/share/pyshared/provisioningserver/ (and need to change the location in of it in trunk to not be under the 'etc/' dir), and then we ship a user_maasceleryconfi | 12:25 |
| jtv | Ah, so /usr/share/* can symlink to files in /etc? | 12:26 |
| roaksoax | jtv: we are symlinking from /etc/maas/ to /usr/share/maas, not from /usr/share to /etc | 12:27 |
| jtv | So the actual file is in /usr/share/maas? | 12:27 |
| roaksoax | jtv: the actual file is in /etc/maas/maas_local_settings.py | 12:27 |
| roaksoax | jtv: and it gets symlinked in /usr/share/maas/ | 12:28 |
| rvba | roaksoax: hey. | 12:28 |
| roaksoax | rvba: o/ good timing! :) | 12:28 |
| roaksoax | rvba: can you explain jtv and me how can we effectively resolve http://pastebin.ubuntu.com/1062430/ | 12:29 |
| * rvba looks. | 12:29 | |
| roaksoax | since you've dealt with issues like these | 12:29 |
| jtv | Now, as I was asking, can src/provisioningserver/pxe/pxeconfig.py and src/provisioningserver/pxe/templates/ be installed to the same location? Or at least can we have a symlink there? | 12:29 |
| rvba | OMG | 12:31 |
| jtv | Yeah. It's actually quite easy to simplify though. | 12:32 |
| rvba | I don't think relative paths should be defined in etc/celeryconfig.py | 12:32 |
| roaksoax | jtv: if you ship those in the same location in trunk, I can ship those in the same location in packaging. Otherwise, symlinking is adding to much risk | 12:32 |
| rvba | They should be defined inside the modules themselves and relative to, say, src/provisioningserver | 12:32 |
| jtv | Either is fine by me. | 12:32 |
| jtv | rvba: yes, that's what I outlined above. | 12:32 |
| rvba | jtv: Then I agree :) | 12:33 |
| jtv | Nice. :) | 12:33 |
| jtv | In fact we may not need a setting at all. | 12:33 |
| rvba | I also don't see why it's a setting. | 12:33 |
| rvba | Looks like module-level constant to me. | 12:34 |
| jtv | I'm guessing it may become useful for node-group workers, _if_ we go with distributed TFTP. | 12:34 |
| jtv | It's not used anywhere else, so yeah, we can shortcut the whole thing now. | 12:34 |
| rvba | Well, each and every worker will ship its own copy of the templates. | 12:34 |
| jtv | At that point I guess the maasserver won't need them at all anyway. | 12:35 |
| rvba | As a rule of thumb, nothing in the code/config should reference 'src'. | 12:36 |
| jtv | The way we're planning to do things now, for now only the maasserver needs them. And then later, only the celery worker on the maas server will need them. | 12:36 |
| jtv | Duh. :) | 12:36 |
| rvba | :) | 12:36 |
| roaksoax | rvba: btw.. we have a segfaulting apache now :) | 12:36 |
| rvba | roaksoax: uh oh | 12:36 |
| jtv | Congratulations! | 12:36 |
| roaksoax | rvba: I have yet to finish the celeryd stuff, but as of now, for some reason, it segfaults | 12:37 |
| rvba | roaksoax: maybe that's related to the changes to the wsgi file… but I was able to test that in a prod environment so I'm surprised. | 12:37 |
| rvba | roaksoax: do you have a half-finisehd package I could play with? | 12:38 |
| roaksoax | rvba: yeah I tested those, and removed them, and it shows a different error | 12:38 |
| roaksoax | rvba: i had to add this though: WSGIImportScript /usr/share/maas/wsgi.py process-group=maas application-group=maas | 12:38 |
| roaksoax | the application-group part | 12:38 |
| rvba | Ok. | 12:38 |
| rvba | I think I need to read the wsgi doc again. | 12:38 |
| roaksoax | rvba: I need to do one more thing. Since I lost my notes, what was needed to start celeryd? | 12:38 |
| rvba | roaksoax: nothing really, just make sure celeryconfig.py in on the path and also the provisioning server module. | 12:39 |
| roaksoax | rvba: right, but what was the command? | 12:39 |
| rvba | roaksoax: celeryd | 12:39 |
| roaksoax | just that, no args? | 12:39 |
| rvba | roaksoax: "celeryd -l INFO" with the required modules on the PYTHONPATH. | 12:40 |
| rvba | And that's it. | 12:40 |
| rvba | roaksoax: oh, one more thing: "-f logfile" | 12:41 |
| roaksoax | [Wed Jun 27 08:40:35 2012] [error] [client 127.0.0.1] Premature end of script headers: wsgi.py | 12:41 |
| roaksoax | [Wed Jun 27 08:40:35 2012] [notice] child pid 31318 exit signal Segmentation fault (11) | 12:42 |
| roaksoax | rvba: (i removed the above line you added to maas-http.conf | 12:42 |
| roaksoax | rvba: ok so let me add the upstart job and you will have a package | 12:42 |
| rvba | roaksoax: ok, I'll then give you a hand with that segfault. | 12:42 |
| roaksoax | rvba: exec /usr/bin/celeryd --pidfile=/run/maas-celeryd.pid --logfile=/var/log/maas/celeryd.log --loglevel=INFO | 12:45 |
| roaksoax | that should be enough then | 12:46 |
| roaksoax | rvba: there's no --app instance of celery to use right? | 12:49 |
| rvba | roaksoax: "--app"? | 12:49 |
| roaksoax | rvba: --app=APP Name of the app instance to use. | 12:50 |
| roaksoax | celeryd --help | 12:50 |
| rvba | roaksoax: no | 12:51 |
| rvba | Daviey: I'd like to talk to you briefly about DNS in MAAS. Would you be available sometime later today or tomorrow? | 13:10 |
| Daviey | rvba: 2hrs from now? | 13:14 |
| rvba | Daviey: that would be prefect, please ping me when you'll be available. | 13:16 |
| jtv | roaksoax: rvba asked me if I could let you cut your teeth on this review… https://code.launchpad.net/~jtv/maas/import-ephemerals-tftp/+merge/112353 | 13:17 |
| rvba | frankban: A review for you ^ | 13:18 |
| rvba | roaksoax: I think jtv meant frankban. | 13:18 |
| jtv | Oh, frankban. | 13:18 |
| jtv | Got my names confused I guess. | 13:18 |
| rvba | Guess so :) | 13:18 |
| frankban | jtv :-) ok will take a look. | 13:18 |
| jtv | Thanks. | 13:18 |
| roaksoax | rvba: uhmmm | 13:23 |
| roaksoax | rvba: when I try to run celeryd as user/group 'maas' | 13:23 |
| roaksoax | /usr/lib/python2.7/dist-packages/celery/loaders/default.py:45: NotConfigured: No 'celeryconfig' module found! Please make sure it exists and is available to Python. "is available to Python." % (configname, ))) | 13:23 |
| rvba | roaksoax: as you probably have guessed, this means that celeryconfig.py is not on the path. | 13:29 |
| roaksoax | rvba: figured it out :) | 13:29 |
| roaksoax | rvba: ok, got a package for you. Are you running quantal by any chance? | 13:35 |
| rvba | roaksoax: I'm not but I'll spin up a canonistack instance. | 13:35 |
| roaksoax | rvba: ok, I'll upload to the testing PPA then | 13:35 |
| roaksoax | rvba: don't upgrade though otherwise it might be broken :) | 13:36 |
| rvba | k | 13:36 |
| rvba | roaksoax: I see the package has been uploaded… but 'apt-get install maas' wants to install the old version 0.1+bzr482+dfsg-0ubuntu1). Any idea why that might be? | 14:06 |
| roaksoax | rvba: it is still waiting to be published | 14:08 |
| rvba | roaksoax: ah… also, "apt-get install raphael" says "Unable to locate package raphael" | 14:08 |
| roaksoax | rvba: libjs-raphael | 14:09 |
| rvba | rarg, silly me. | 14:09 |
| roaksoax | :) | 14:11 |
| roaksoax | rvba: maas should be installable now, (sudo apt-get update && sudo apt-get install maas) | 14:13 |
| rvba | roaksoax: cool, I'm installing the last version right now. | 14:14 |
| roaksoax | awesome | 14:16 |
| rvba | roaksoax: I get that error when installing the package http://paste.ubuntu.com/1062592/ | 14:16 |
| roaksoax | let me test | 14:17 |
| rvba | This happens in one of the migration scripts. I'll investigate but I wanted to make sure you were seeing that error too. | 14:17 |
| roaksoax | i wwasn't actually | 14:17 |
| rvba | roaksoax: looks like it's an incompatibility in our code with south version 0.7.5 | 14:23 |
| roaksoax | rvba: ah, so maybe just download python-django-maas and maas deb packages and install them in precise | 14:23 |
| rvba | Also, I'm surprised to see that Django is still version 1.3 in quantal. | 14:23 |
| rvba | Django 1.4 has been released in March 2012. | 14:24 |
| rvba | roaksoax: I'll try that. But I'll fix the code too. | 14:25 |
| roaksoax | rvba: it's probably because it hasn't yet been merged into ubuntu from debian | 14:25 |
| roaksoax | rvba: python-django is 1.4 | 14:27 |
| roaksoax | rvba: https://launchpad.net/ubuntu/+source/python-django/1.4-1 | 14:27 |
| rvba | roaksoax: arg, you're right, wrong terminal, sorry ;) | 14:28 |
| roaksoax | hehe | 14:28 |
| jtv | Yigh. What am I doing wrong!? My test does: self.patch(celeryconfig, 'PXE_TEMPLATES_DIR', path) but it never seems to affect celeryconfig.PXE_TEMPLATES_DIR. | 14:31 |
| rvba | O_o | 14:31 |
| rvba | jtv: care to paste the whole test? | 14:32 |
| jtv | I'll give you the relevant bits. | 14:32 |
| jtv | rvba: example of failing test: http://paste.ubuntu.com/1062616/ | 14:34 |
| jtv | Excerpt of the affected code follows. | 14:34 |
| jtv | Code being tested: http://paste.ubuntu.com/1062618/ | 14:35 |
| jtv | In etc/celeryconfig.py, I changed the default value for PXE_TEMPLATES_DIR to None. | 14:35 |
| rvba | jtv: when exactly is template_basedir computed? Maybe before patch(...) is called. | 14:35 |
| jtv | It's not cached AFAICS | 14:36 |
| rvba | How is PXE_TEMPLATES_DIR defined? | 14:36 |
| rvba | If it's done at module level then that happens before anything is patched. | 14:36 |
| jtv | It's initialized to None at the module level, yes. I thought you could patch at the module level. | 14:37 |
| jtv | I mean, sure it gets defined, but the point of the patch is to override its value, right? | 14:37 |
| rvba | Right. | 14:38 |
| jtv | So PXE_TEMPLATES_DIR should already be imported and initialized at this point, and AFAICS the patch should override its value. | 14:38 |
| jtv | Maybe import_settings messes with it somehow? I can't really imagine it. | 14:39 |
| rvba | Maybe the patch() does not impact the value imported and used by PXEConfig. | 14:41 |
| rvba | jtv: cuold you simply try to use celeryconfig.PXE_TEMPLATES_DIR in def template_basedir ? | 14:42 |
| jtv | Sure, I'll try that | 14:42 |
| jtv | Nope. That's still always None, even when I patch it. | 14:44 |
| rvba | roaksoax: it's a struggle to install the mew maas package on precise. | 14:51 |
| rvba | roaksoax: I'll fix the incompatibility instead. | 14:52 |
| roaksoax | rvba: sudo dpkg -i python-django-maas*.deb maas*.deb | 14:52 |
| roaksoax | rvba: and then: sudo apt-get -f install | 14:52 |
| roaksoax | and that should be all you need | 14:52 |
| jtv | rvba: no new insights on why my patch isn't working. :( I'm pretty sure it's supposed to work for modules. | 14:53 |
| rvba | roaksoax: temporary glitch in the archives? http://paste.ubuntu.com/1062648/ | 14:54 |
| rvba | jtv: pretty sure too… really a weird problem. | 14:54 |
| roaksoax | rvba: sudo apt-get update && sudo apt-get -f install | 14:54 |
| jtv | rvba: I had something similar with django.config, but at least there we knew that weird stuff was going on. | 14:55 |
| rvba | roaksoax: thanks. | 14:55 |
| jtv | Maybe I should leave it for ye morrow. | 14:55 |
| * rvba checks the world clock. | 14:56 | |
| rvba | Indeed :) | 14:56 |
| jtv | Yawn. nn folks! | 14:56 |
| rvba | \o jtv. | 14:56 |
| rvba | Daviey: roaksoax there is actually a bug in piston that prevents it from working with Django 1.4. That bug seems fixed in piston upsteam https://bitbucket.org/jespern/django-piston/changeset/7c90898072ce#chg-piston/resource.py | 16:01 |
| rvba | But it's not yet packaged. | 16:01 |
| rvba | I'll test if that fix solves the problem I'm having with MAAS and Django 1.4. | 16:02 |
| Daviey | rvba: if you want to validate that, i'll get it uploaded | 16:07 |
| roaksoax | rvba: I should also have a new yui3 package soonish | 16:09 |
| rvba | Daviey: test done, I have other problems with MAAS and Django 1.4 that I need to investigate but all the piston related problems are gone with the trunk version. Also, from what I understand of the problem, the fix in piston completely makes sense. | 16:09 |
| rvba | Our 173 API tests pass with piston trunk version. | 16:10 |
| Daviey | rvba: to confirm, you used quantal piston and that patch applied? | 16:11 |
| rvba | Daviey: no, I changed the Django version in versions.cfg to 1.4 and then I used piston trunk version. | 16:12 |
| Daviey | rvba: ah, i hoped you validated just that changeset :) | 16:13 |
| rvba | Daviey: I can do that. | 16:13 |
| roaksoax | rvba: btw were you able to find out why the errors with wsgi? | 16:21 |
| rvba | roaksoax: no, I was stopped by this Django 1.4 incompatibility problem. | 16:23 |
| rvba | Daviey: ok, so we need these changesets: https://bitbucket.org/jespern/django-piston/changeset/3a0d021dd042#files https://bitbucket.org/jespern/django-piston/changeset/7c90898072ce | 16:24 |
| rvba | Daviey: with these two patches all the API test pass with Django 1.4. | 16:24 |
| rvba | tests* | 16:24 |
| rvba | roaksoax: I need to go now but tomorrow I'll fix the problem which prevent the package from being installed. Then with the new package we will be able to investigate that wsgi problem. How does that sound? | 16:26 |
| rvba | prevents* | 16:26 |
| roaksoax | rvba: sounds good to me | 16:28 |
| roaksoax | I'll have a new yui3 package on PPA too which MAAS will be depending on | 16:28 |
| Daviey | roaksoax: Do you want to cherry pick those two commits that rvba outlined? | 16:29 |
| Daviey | Best to upload to -proposed as it's seeded. | 16:29 |
| roaksoax | Daviey: sure, I'll cherry pick those and upload python-piston to -proposed | 16:30 |
| Daviey | ta | 16:30 |
| rvba | roaksoax: ta | 16:31 |
| roaksoax | Daviey: btw.. is the installer already with squashfs? | 16:57 |
| Daviey | roaksoax: no | 16:58 |
| Daviey | roaksoax: I hit a blocker trying to do it... needs some cjwatson love. | 16:58 |
| === matsubara is now known as matsubara-afk | ||
| Daviey | roaksoax: i do have a squashfs if you wanted to play with it? | 16:58 |
| Daviey | but the d-i part seemed to wedge, when the squash is co-located on cd | 16:59 |
| Daviey | (cd/usb) | 16:59 |
| roaksoax | Daviey: sure, point me to your squashfs image and I'll play with it | 16:59 |
| roaksoax | Daviey: python-django-piston has just been uploaded | 17:03 |
| Daviey | roaksoax: thanks | 17:06 |
| Daviey | roaksoax: I'll create a new squashfs tomorrow, and send it along | 17:07 |
| roaksoax | Daviey: awesome! | 17:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!