| roaksoax | rvba: howdy | 13:50 |
|---|---|---|
| roaksoax | rvba: so what's the status of the SRU stuff ? | 13:50 |
| roaksoax | rvba: is it ready for upload? | 13:51 |
| rvba | roaksoax: Hi Andres. | 14:03 |
| rvba | roaksoax: upstream is good. But there is bug 1090334 for the packaging. | 14:04 |
| ubot5 | bug 1090334 in maas (Ubuntu) "MAAS (in precise) requires django >= 1.3.1-4ubuntu1.5" [High,Confirmed] https://launchpad.net/bugs/1090334 | 14:04 |
| roaksoax | rvba: right, there's an SRU for that | 14:06 |
| rvba | roaksoax: I thought the SRU was for the python-django package. This is for updating the dependencies of maas with the right version of python-django. | 14:07 |
| roaksoax | rvba: nope, there's SRU bugs with the stuff we require, such as GenericIPAddressField etc etc | 14:08 |
| rvba | roaksoax: right now, if you already have python-django and maas installed on precise and upgrade to the the SRU maas, the upgrade fails. | 14:08 |
| roaksoax | rvba: https://bugs.launchpad.net/ubuntu/precise/+source/python-django/+bug/1081392 | 14:09 |
| rvba | roaksoax: ok, so maybe you should close this bug with a pointer to the right SRU bug. | 14:09 |
| ubot5 | Launchpad bug 1081392 in python-django (Ubuntu Precise) "[SRU] Include upstream fix for bug 15496" [High,New] | 14:09 |
| rvba | roaksoax: ok, but shouldn't we also update the dependencies needed by maas? | 14:10 |
| rvba | Even if the new version of python-django gets released, it will still be possible to break maas unless we force the version of python-django right? | 14:10 |
| roaksoax | rvba: in packaging? no not really | 14:12 |
| roaksoax | it will be released in -updates and as part of upgrading, it will also upgrade dependencies frist | 14:12 |
| rvba | Is the behaviour of apt-get different when the package is in a ppa then? | 14:13 |
| rvba | Because it's easy to break maas right now: | 14:13 |
| rvba | - on precise, install maas (the one which was released with precise) | 14:14 |
| rvba | - add the testing ppa | 14:14 |
| roaksoax | rvba: yes, the one in PPA has a higher version from the one in arcdhives, and that's why you are able to use that instead | 14:14 |
| rvba | - apt-get install maas => upgrade broken because python-django was not upgrade (although a new version is available in the ppa) | 14:14 |
| roaksoax | maybe there's a newer version on the archives now | 14:15 |
| rvba | All I'm saying is that if there is an old version already installed, upgrading maas does not automatically upgrade python-django, and this results in a broken maas. | 14:15 |
| roaksoax | rvba: right, so a sudo apt-get upgrade or (dist-upgrade) will upgrade dependencies first | 14:16 |
| roaksoax | hence, upgrading python-django | 14:17 |
| roaksoax | rvba: in any case, we can always add a hard requirement | 14:17 |
| roaksoax | for that particular version | 14:17 |
| roaksoax | but we shouldn'y really need on | 14:17 |
| roaksoax | lets just wait till django hits archives | 14:17 |
| rvba | Ok, you're the expert here. It's just weird to open up the door for breakages. | 14:17 |
| roaksoax | right | 14:18 |
| roaksoax | i agree, lets just wait for the dependencies to be released, then we take care of the final upgrade testing | 14:18 |
| rvba | roaksoax: same thing with isc-dhcp-server | 14:19 |
| roaksoax | yep | 14:20 |
| rvba | (there is no bug for that one) | 14:20 |
| roaksoax | rvba: there is | 14:21 |
| rvba | roaksoax: if you're going to update the packaging (to add hard requirements), that's probably something you can do now. After all, the right versions are in the ppa that we use for testing. | 14:21 |
| roaksoax | rvba: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-maas-next-steps | 14:22 |
| rvba | roaksoax: I suppose somewhere in that page there is the mention of the need to add a hard requirement for maas with the right version of isc-dhcp-server ;) | 14:24 |
| roaksoax | rvba: sure i don't have any objections on adding them | 14:25 |
| roaksoax | rvba: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1049177 | 14:25 |
| ubot5 | Launchpad bug 1049177 in maas (Ubuntu Precise) "isc-dhcp-server apparmor profile should have include ".d" " [Undecided,New] | 14:25 |
| rvba | roaksoax: Again, I leave these changes up to you. But one user managed to break its maas installation while testing the package the other day. | 14:25 |
| roaksoax | rvba: TBH i have no objections on making those changes | 14:26 |
| roaksoax | since it shouldn't break anything | 14:26 |
| roaksoax | rvba: btw.. i'm gonna do this. 1. upload quantal changes to raring | 14:27 |
| roaksoax | rvba: 2. bug someone over getting the SRU's processed | 14:27 |
| roaksoax | 3. check if there's something else to upload to raring again.. and then SRU back to both quantal and precise | 14:27 |
| rvba | roaksoax: I think the most important right now is to get the SRU uploaded. | 14:28 |
| rvba | roaksoax: we have a weird problem with raring right now. | 14:28 |
| rvba | roaksoax: when we package trunk for quantal, all is fine, the integration tests pass. When we package the same thing for raring, some of the tests fail. | 14:29 |
| roaksoax | rvba: the quantal version we have *has* to be uploaded to raring in order for us to SRU | 14:29 |
| rvba | (but the package installs ok) | 14:29 |
| roaksoax | weird | 14:29 |
| rvba | roaksoax: ok then | 14:29 |
| roaksoax | rvba: so the thing is that since we are backporting a new upstream release | 14:29 |
| roaksoax | the release hsa to be released in ubuntu+1 | 14:30 |
| rvba | roaksoax: I see | 14:30 |
| roaksoax | then backported(SRU) back to previous releases | 14:30 |
| roaksoax | so we *have* to upload it to raring | 14:30 |
| === matsubara is now known as matsubara-lunch | ||
| roaksoax | rvba: are there other changes we'd like to add to the stabilization branch? | 14:32 |
| rvba | roaksoax: there is one fix that we did not backport. It's a very minor fix that fixes a tiny problem on the dev instance only (r 1279). It does not affect the prod environment at all. It is worth backporting that? | 14:34 |
| roaksoax | rvba: not really | 14:35 |
| rvba | roaksoax: ok, then we're good. | 14:35 |
| roaksoax | rvba: ok, I'd like to squeeze in the fence_cud power method for the QA team to use | 14:36 |
| rvba | roaksoax: as I said on the ML yesterday, the packages I've uploaded to the testing ppa have been tested (both using the integration test suite and manually) | 14:36 |
| roaksoax | I'll work on it now though | 14:36 |
| roaksoax | rvba: great! | 14:36 |
| jtv | smoser: hi scott — question: do I remember correctly that user_data as retrieved from the metadata API really isn't supposed to be more than 16KB? | 14:41 |
| smoser | in ec2 it is 16kb binary blob. | 14:42 |
| smoser | but that isnt any sort of requirement for maas | 14:42 |
| jtv | Ah OK | 14:43 |
| jtv | So then I wasted my time explaining in my MP why "kilobyte vs kibibyte" is missing the point entirely. | 14:43 |
| smoser | jtv, you probably do want some limit though. | 14:47 |
| jtv | Well... we no longer need it user-editable AFAICS; we have custom commissioning scripts now. | 14:48 |
| smoser | as the user storing that in the database could gro quite large. | 14:48 |
| smoser | user-data is user-editable | 14:48 |
| jtv | And it looks to me as if some ¾ of the script could be moved into that mechanism, cutting the main thing down to 5KB. | 14:48 |
| smoser | that *is* a requirement. | 14:48 |
| jtv | User-data, or the commissioning script which we send to a commissioning node as user-data? | 14:49 |
| smoser | the former. | 14:49 |
| jtv | Ah OK | 14:49 |
| jtv | I've been neck-deep in the commissioning script today, so I'm rather conflating the two now. | 14:49 |
| jtv | The main commissioning script AFAICS no longer needs to be editable because there's a way for admins to inject their own code there. | 14:50 |
| jtv | And the IPMI code & configs look like prime candidates for moving into that mechanism. The main commissioning script is far too large and unwieldy, and if we're going to download a tarball from the server anyway, we might as well put that code there. | 14:53 |
| roaksoax | jtv: i already have plans to move the IPMI stuff out of commissioning and enlisting | 14:56 |
| roaksoax | jtv: by moving them into their own scripts and used by commissioning/enlistment user dat | 14:56 |
| jtv | roaksoax: great — we have a mechanism that can accommodate this easily | 15:01 |
| roaksoax | jtv: yeah, but we were thinking on putting these in a separate package | 15:02 |
| roaksoax | jtv: because maas-enlist is a utility being used to enlist machines manually, and detecting ipmi could be used as well | 15:02 |
| roaksoax | jtv: not only for commissioning/enlistment | 15:02 |
| jtv | roaksoax: being able to unit-test the code separately, or even to make manual tests easier, would be a big advantage. | 15:19 |
| roaksoax | jtv: that's the plan | 15:20 |
| === matsubara-lunch is now known as matsubara | ||
| jtv | rvba: did you find the problem with the packaging? I guess only user_data.template is not being installed, since the rest of the files are python? | 16:53 |
| rvba | jtv: I don't know. The html templates in ./src/maasserver/templates are shipped all right. | 16:55 |
| jtv | roaksoax, do you know what it would take to make the packaging install this new file, src/metadataserver/commissioning/user_data.template alongside the surrounding python files? | 16:56 |
| roaksoax | jtv: yes, setup.py | 16:56 |
| roaksoax | jtv: let check | 16:56 |
| roaksoax | jtv: wasn't there a file in the source that listed what to include and what to exclude? | 17:01 |
| rvba | roaksoax: probably MANIFEST.in | 17:03 |
| roaksoax | rvba: ah yes thanks!! | 17:05 |
| roaksoax | jtv: yeah add something to fence_cdu -a 192.168.1.11 -n Panda_a42 -l ubuntu -p ubuntu -o status | 17:06 |
| jtv | \o/ | 17:06 |
| jtv | roaksoax: that last one was meant for someone else I guess? | 17:06 |
| roaksoax | jtv: yeah :) | 17:07 |
| jtv | Phew. I thought I'd gone mad. | 17:07 |
| jtv | rvba: are you making that change or do you want me to? | 17:07 |
| rvba | jtv: fix is coming up | 17:07 |
| jtv | Great | 17:07 |
| jtv | Because I'm almost asleep :) | 17:07 |
| roaksoax | jtv: so you could add something like: http://paste.ubuntu.com/1447968/ | 17:07 |
| roaksoax | or: http://paste.ubuntu.com/1447971/ | 17:08 |
| roaksoax | can't remember what wil work | 17:08 |
| rvba | jtv: https://code.launchpad.net/~rvb/maas/missing-files/+merge/140499 | 17:08 |
| jtv | roaksoax: rvba did something like that in the above MP ^ | 17:14 |
| jtv | Reviewed. | 17:14 |
| roaksoax | jtv: we no longer ship a file etc/maas/commissioning-user-data? | 17:18 |
| jtv | Nope. | 17:18 |
| jtv | It's generated on the fly now. | 17:18 |
| roaksoax | jtv: ack | 17:21 |
| jtv | roaksoax: most of the file is now in src/metadataserver/user_data.template, but some embedded python scripts are now separate files in src/metadataserver/snippets. | 17:24 |
| jtv | This means we can run our lint checkers and import formatters on those, and who knows, maybe even unit- test them. | 17:24 |
| roaksoax | jtv: cool, one thing though, where can I add custom scripts | 17:25 |
| jtv | roaksoax: custom scripts, as provided by the admins, are now stored in the database. Plus MAAS itself can also add in custom scripts that travel through the same mechanism, but aren't editable. | 17:29 |
| jtv | Currently there's only one such script, the tiny lshw one, so it's kept in-line in a name/content dict. I imagine we'll want to replace this with a directory at some point, and the separate ipmi-configs package could install files into that directory. | 17:30 |
| roaksoax | jtv: ack! | 17:33 |
| roaksoax | rvba: if you have the time, could you take a look at: https://code.launchpad.net/~andreserl/maas/lp1073462_fence_cdu_power_type/+merge/140504 | 17:35 |
| roaksoax | please? | 17:35 |
| roaksoax | thanks!! | 17:35 |
| rvba | roaksoax: I've got to step out now but I'll have a look at it tomorrow morning first thing unless jtv grabs it first. | 17:47 |
| jtv | rvba: it's Wednesday today, but not yet working hours. :) | 17:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!