| smoser | bigjools, roaksoax were you discussing the api creds for commissioning environment? | 00:36 |
|---|---|---|
| smoser | or how we should make ipmi calls home | 00:36 |
| smoser | ? | 00:36 |
| bigjools | smoser: we didn't, just talked about packaging | 00:37 |
| bigjools | AFAIK commissioning already posts back to the metadata service, so is there any reason we can't extend that api to handle power details? | 00:37 |
| smoser | it just seems like a patch to me | 00:38 |
| smoser | but, no. other than that no reason. | 00:38 |
| smoser | ie, a simple fix for "here, you can update *this* token of information" | 00:39 |
| smoser | which will later be extended with "and *this* token too"... | 00:39 |
| smoser | but i do agree that it is the simplist "right now" fix | 00:39 |
| bigjools | indeed | 00:53 |
| === matsubara is now known as matsubara-afk | ||
| smoser | bigjools, is htat something you can have soon ish ? | 01:11 |
| smoser | ie, like so that roaksoax and i can bang on fleshing it out tomrrow? | 01:11 |
| bigjools | smoser: sure, I'll get it done in a few hours | 01:12 |
| smoser | thank you. you rock. | 01:12 |
| bigjools | smoser: any special requirements? | 01:12 |
| bigjools | other than "I want to set power parameters" | 01:12 |
| smoser | nah. we just need to be able to call home with that info from the commissioning envrionment. | 01:12 |
| smoser | i'll probably just extend the hackish client tha tis sent down in user-data right now. | 01:12 |
| bigjools | smoser: is it ok to do it in the existing "signal" call? or do you want a separate one? | 01:13 |
| smoser | well, signal is easier | 01:13 |
| smoser | but just seems more hackish :) | 01:13 |
| bigjools | yeah :) | 01:13 |
| bigjools | also, what's the plan for powering up enlisted nodes? | 01:13 |
| smoser | well, dont know. | 01:14 |
| smoser | Davieys' idea was reasonable. | 01:14 |
| smoser | in enlistment you'd (at least in an otion) sit and wait for "ready" | 01:14 |
| smoser | ie, poll on the server "am i ready for commission?" | 01:14 |
| smoser | ... | 01:14 |
| smoser | and then when you are, reboot | 01:14 |
| bigjools | it was, but it wasn't liked by a certain person | 01:14 |
| smoser | oh. | 01:15 |
| smoser | hm.. | 01:15 |
| smoser | well, then. | 01:15 |
| bigjools | yeah | 01:15 |
| smoser | th eonloyy other hting is to call home in enlistment | 01:15 |
| smoser | only other thing | 01:15 |
| smoser | what other options do we have? | 01:15 |
| smoser | either a.) not power off | 01:15 |
| bigjools | can existing power params be discovered without changing anything in enlistment? | 01:15 |
| smoser | maybe | 01:15 |
| smoser | roaksoax, would know more | 01:15 |
| smoser | we can poke | 01:15 |
| smoser | i really have to run | 01:15 |
| bigjools | that's what I always assumed would happen | 01:15 |
| bigjools | ok, cya | 01:15 |
| roaksoax | bigjools: during enlistment we can't | 01:56 |
| bigjools | roaksoax: :( | 01:56 |
| roaksoax | bigjools: unless you give that unauth access :) | 01:56 |
| bigjools | roaksoax: why doesn't the enlistment env have the creds? | 01:57 |
| roaksoax | bigjools: the power settings are under a NodeAdminForm validation, | 01:57 |
| bigjools | it's the same env as commissioning AFAIK? | 01:57 |
| roaksoax | bigjools: I don't think it would make sense to send admin creds during enlistment | 01:57 |
| bigjools | true | 01:57 |
| bigjools | so two things: | 01:57 |
| bigjools | 1. you *can* detect existing power params in enlistment? | 01:58 |
| bigjools | 2. we can change the enlistment api to take power params | 01:58 |
| roaksoax | bigjools: i can do that and I always wanted that | 01:58 |
| bigjools | so, let's do it :) | 01:58 |
| roaksoax | that's my personal preference | 01:58 |
| roaksoax | bigjools: however, Daviey and smoser saw better usage of those in commissioning rather than enlistment | 01:59 |
| roaksoax | smoser: ^^ | 01:59 |
| bigjools | that will complicated the existing setup | 01:59 |
| bigjools | complicate* | 01:59 |
| roaksoax | ah he is gone | 01:59 |
| bigjools | Daviey wanted to leave the node powered up and poll | 02:00 |
| roaksoax | bigjools: you'll have to talk to Daviey on that regards | 02:00 |
| bigjools | but that was disliked... | 02:00 |
| roaksoax | yeah well | 02:00 |
| roaksoax | bigjools: the idea behind doing it during commissioning is that commissioning is the step were all the configuration is being made | 02:00 |
| roaksoax | enlistment is all about discovery | 02:00 |
| roaksoax | so while auto-detecting IPMI is also discovery, we also might need to do setup | 02:01 |
| roaksoax | so that's why it was preferred to be in commissioning rather than enlistment | 02:01 |
| bigjools | sure | 02:01 |
| bigjools | so does this mean that we can't reliably auto detect power params in enlistment? | 02:02 |
| roaksoax | needless to say, my personal preference has always been in enlistment due to the fact that once we click on "Accept&Commission" the nodewill be turned on automatically | 02:02 |
| roaksoax | bigjools: *personally* I'd love it to have it done during enlistment | 02:02 |
| bigjools | well if it can be done, I don't see why we don;t just do it | 02:03 |
| roaksoax | bigjools: that's why I explained the reasons above | 02:03 |
| roaksoax | bigjools: you should really discuss this with Daviey :) | 02:03 |
| bigjools | it will be the minority use case because most people will use some sort of discovery module to poke in new nodes on the api | 02:03 |
| bigjools | roaksoax: I will! | 02:03 |
| bigjools | I did already in fact but I'll revisit | 02:03 |
| bigjools | so roaksoax, do you have more time to talk packaging? | 02:04 |
| roaksoax | bigjools: so if we are going to have unauth access for enlistment, we might aswell have an aunauth mehotd for power settings on an update | 02:04 |
| roaksoax | so we can do it in commissioning | 02:04 |
| roaksoax | (at least that's what could be argued) | 02:04 |
| roaksoax | bigjools: and yes... I'm taking a break from homework :) | 02:04 |
| bigjools | heh, ok | 02:05 |
| * bigjools back in 2 mins | 02:05 | |
| roaksoax | k | 02:05 |
| bigjools | back | 02:08 |
| roaksoax | bigjools: ok, shoot :) | 02:09 |
| bigjools | roaksoax: so the upgrade scenario | 02:10 |
| bigjools | I moved the massive postinst from maas to maas-region-controller | 02:10 |
| bigjools | that will probably break it | 02:11 |
| roaksoax | bigjools: ok, that needs to be cleaned up, and i think some stuff should be passed to maas-cluster-controller | 02:11 |
| roaksoax | yeah | 02:11 |
| bigjools | well I imagine post if it heads back to maas? | 02:11 |
| bigjools | most of* | 02:12 |
| roaksoax | well there's upgrade stuff that i think it is not longer needed | 02:13 |
| bigjools | ok | 02:13 |
| roaksoax | i need to evaluate that though | 02:13 |
| roaksoax | bigjools: btw: I think this is missing, though I don;t like having to symlink that config in maas-common http://paste.ubuntu.com/1227767/ | 02:13 |
| bigjools | all the stuff comparing versions will fail | 02:13 |
| roaksoax | bigjools: not really | 02:14 |
| bigjools | well maas-region-controller won't have ancestry | 02:14 |
| bigjools | how can it compare? | 02:14 |
| roaksoax | bigjools: it won't be run | 02:15 |
| roaksoax | bigjools: becuase it is a first install of that binary package | 02:15 |
| roaksoax | so it enters as a new install | 02:15 |
| roaksoax | not an upgrade | 02:15 |
| bigjools | exactly my point :)( | 02:15 |
| roaksoax | bigjools: so when we install, it will run this: if [ "$1" = "configure" ] && [ -z "$2" ]; then | 02:16 |
| roaksoax | right? | 02:16 |
| roaksoax | so it will do initial configuration of everything | 02:16 |
| bigjools | yep | 02:16 |
| roaksoax | bigjools: when we upgra maas-region-controller, it will run this: elif [ "$1" = "configure" ] && dpkg --compare-versions "$2" gt 0.1+bzr266+dfsg-0ubuntu1; then | 02:16 |
| roaksoax | bigjools: which is where the comparing version stands | 02:17 |
| roaksoax | so big part of that I think might no longer be needed | 02:17 |
| roaksoax | i just need to make sure it's not before I drop it completely | 02:17 |
| roaksoax | i had in mind dropping most of it anyway | 02:17 |
| bigjools | will this break: | 02:20 |
| bigjools | elif [ "$1" = "configure" ] && dpkg --compare-versions "$2" gt 0.1+bzr266+dfsg-0ubuntu1; then | 02:20 |
| bigjools | ah should be ok | 02:21 |
| bigjools | however | 02:21 |
| roaksoax | it will be ok | 02:22 |
| bigjools | I still think upgrading from 12.04 will break since it'll think it's installing from scratch | 02:22 |
| bigjools | (pushed up your last diff) | 02:22 |
| roaksoax | bigjools: no wont break, it will simply install everything as if it was new | 02:22 |
| bigjools | so why are there postinst sections comparing versions then? | 02:23 |
| bigjools | ie a special upgrade case | 02:23 |
| bigjools | or are you saying that install from scratch will work even if there's an existing DB etc? | 02:24 |
| roaksoax | bigjools: cause for example, we were upgrading from package XYZ to ABC, and ABC needed W to be configured, but since XYC didn't have it, we need to configure it in upgrade | 02:24 |
| roaksoax | but we don't need it if we are upgrading from ABC | 02:24 |
| roaksoax | bigjools: yeah it won't install a new DB, i think it will just change the password | 02:25 |
| bigjools | that's not useful :( | 02:25 |
| roaksoax | bigjools: it will change the psasword and update the config files | 02:25 |
| roaksoax | bigjools: so it should be good | 02:25 |
| roaksoax | bigjools: i'll have to test it TBH | 02:26 |
| roaksoax | bigjools: if you wnat, do this. Push a package to a PPA< fire up a cnaonistack instance. install maas and upgrade from that PPA | 02:26 |
| roaksoax | and see what happens :) | 02:26 |
| bigjools | roaksoax: ok :) | 02:26 |
| bigjools | I'll build something in the testing PPA | 02:27 |
| bigjools | could do with a cow image with maas installed on 12.04, would speed things up | 02:27 |
| roaksoax | bigjools: not maas-maintainers/testing please :) | 02:27 |
| bigjools | roaksoax: bah spoilsport :) | 02:27 |
| bigjools | maas-maintainers/experimental then | 02:28 |
| roaksoax | bigjools: i have sabdlf's lab using MAAS from maas-maintainers/testing | 02:28 |
| bigjools | ! | 02:28 |
| bigjools | /o\ | 02:28 |
| bigjools | roaksoax: I'd be tempted to make a ppa called sabdfl-garage! | 02:28 |
| roaksoax | he wnaqted to test the quantal stuff I think | 02:28 |
| roaksoax | lol | 02:29 |
| bigjools | deadly serious | 02:29 |
| roaksoax | hehe but that's simplyt latest trunk | 02:30 |
| roaksoax | pre-package split | 02:30 |
| roaksoax | alright i'm off for the night | 02:38 |
| roaksoax | nigth | 02:38 |
| bigjools | roaksoax: ok thanks for the help | 02:39 |
| bigjools | I'll test and let you know results | 02:39 |
| bigjools | roaksoax: oh if you are still there ... | 02:39 |
| bigjools | is there an easy hack to make get-orig-source automatically use my local trunk instead of lp:maas ? | 02:40 |
| roaksoax | bigjools: uhmmm you could simply package your local branch | 02:41 |
| bigjools | I just hacked rules for now but it'd be nice if you could set an override | 02:41 |
| roaksoax | bigjools: I don't know TBH how to override it easily | 02:42 |
| bigjools | no worries | 02:42 |
| bigjools | go to bed :) | 02:42 |
| roaksoax | bigjools: i wish I could go to bed | 02:42 |
| * roaksoax doing homework | 02:42 | |
| bigjools | ah those days ... | 02:43 |
| roaksoax | yeah!! can't wait them to be over :) | 02:43 |
| jam | _rvba, allenap: (when you wake up) I'd like to add a test that if you update a tag with invalid data, the transaction is properly aborted, and the data stays consistent. | 07:25 |
| jam | I was able to manually do transactions in a test by inheriting TransactionTestCase | 07:26 |
| jam | however, for an API test, the transactions are done by the middleware | 07:26 |
| jam | (which seems to handle everything is committed or nothing on a single API request.) | 07:26 |
| jam | is it reasonable to just skip that test and assume the transaction works properly? | 07:26 |
| jam | maybe jtv ^^ | 07:26 |
| jtv | hi jam | 07:27 |
| jtv | By "invalid data" here you mean malformed data? | 07:27 |
| jam | jtv: the Tag definition field needs to be a proper XPATH string. | 07:28 |
| jam | we currently validate that at the point where we go around updating the nodes that match the tag | 07:28 |
| jtv | By the way, the regular test case turns commit() into a no-op and probably abort() as well. I guess there are probably other ways to establish that changes have been aborted. | 07:28 |
| jam | and I want to make sure that we don't mutate any nodes => tag associations. | 07:28 |
| jtv | You're keeping the tags as a field on the node? | 07:29 |
| jam | jtv: in test_api.py if I do a POST with invalid data, I either: get an uncaught DatabaseError, or I catch that in my TagHandler, and raise ValidationError. If I raise VE, then I can't 'reload_object()' because the DB is in 'I want you to rollback' state. | 07:29 |
| jam | jtv: we have a node_tags table | 07:29 |
| jam | (many to many) | 07:29 |
| jtv | Ah good | 07:30 |
| jtv | jam: by "invalid data" here, you mean malformed data? | 07:30 |
| jam | jtv: right, the user tries to update a tag to a definition that is improperly formed. | 07:30 |
| jam | syntactically invalid, I guess. | 07:30 |
| jtv | Yeah, malformed. | 07:30 |
| jam | '/node/foo' is valid XPATH, 'node@id=bar' is not. | 07:30 |
| jam | node[@id=bar] is the proper syntax, etc. | 07:31 |
| jtv | I'm asking just because I'm not too familiar with the details, so there might conceivably be other notions of validity. | 07:31 |
| jam | So I *could* do LBYL and do a check that the syntax is valid before I do any further work. | 07:31 |
| jam | But it feels YAGNI, vs just doing the work and assuming if there is a problem it will get rolled back. | 07:31 |
| jtv | LBYL? | 07:31 |
| jtv | Ah | 07:31 |
| jtv | nm | 07:31 |
| jam | Look Before You Leap | 07:31 |
| jtv | Agreed -- the database does exactly what you want here, might as well build on that. | 07:32 |
| jam | (Right now to update the node <=> tag association on new definition, I delete all the old values, and then repopulate with new values) | 07:32 |
| jam | jtv: so the question is, the testing infrastructure doesn't have TransactionMiddleware running (that I can tell) | 07:32 |
| jam | which is where the real API is getting transaction + rollback. | 07:32 |
| jam | (AFAICT) | 07:33 |
| jtv | Nasty idea for a test: store some malformed data, attempt trivial database access, verify that it fails. | 07:33 |
| jam | jtv: self.assertRaises(DatabaseError, reload_object, tag) ? | 07:33 |
| jtv | For example! Just as long as there is no doubt whatsoever that the test won't have affected the object. | 07:33 |
| jtv | You could also assert that Node.objects.all().count() fails. | 07:34 |
| jam | jtv: well, I have *another* test which goes directly to the Tag attributes, and does the transaction logic itself. | 07:34 |
| jam | the real key is if somone removes TransactionMiddleware, I don't have a failing test. | 07:34 |
| jam | and potentially get inconsistent data in the DB on posting invalid definitions. | 07:34 |
| jtv | And the test does remove the middleware, because it stubs out commit/abort and runs its own transaction. Gotcha. | 07:35 |
| jtv | Hmm. | 07:35 |
| jam | I don't know if we have any tests at a higher level (Selenium-ish) that runs the real server and we can poke at. | 07:36 |
| jam | Like maybe something for diogo? | 07:36 |
| jtv | Actually, isn't it enough to test that malformed data raises a database error? | 07:36 |
| jtv | Of course if somebody makes database changes prior to the insertion _and_ someone takes away the transaction management, YASEF. | 07:37 |
| jam | jtv: well, we already mutate the db before we find the error | 07:38 |
| jtv | :( | 07:38 |
| jam | tag.node_set.clear() | 07:38 |
| jam | for node in raw("""xpath_query""): tag.node_set.add(node) | 07:38 |
| jam | jtv: hence the 'I could LBYL' and issue a semi-bogus query | 07:39 |
| jam | like 'raw("""xpath_query(%s, <dummy />)""")' | 07:39 |
| jtv | Or document in big letters that nobody should take away transaction management. It seems a silly thing to do at any rate. | 07:39 |
| jam | jtv: I agree it would be silly to switch to autocommit. | 07:40 |
| jtv | So testing for this does feel a bit like checking your car for seatbelts: it's sort of a static shared assumption. | 07:41 |
| jam | jtv: well, it is a bit of "I'm definitely assuming X, can I test that X is still present"? | 07:46 |
| jam | jtv: and as for seatbelts, there are lots of places I've been that don't have them (taxis tend to tuck them under the seat in many countries I've visited) | 07:46 |
| jtv | The way django is designed, I see neither a good way of setting it in stone nor a good way of testing it. | 07:46 |
| jtv | I deliberately spoke of "your" car, not a taxi -- some drivers here cut them off. :) | 07:47 |
| jtv | (And yes, I'm making some guesses there) | 07:47 |
| jam | :) | 07:47 |
| jam | jtv: I imagine pull it down so the bell doesn't ring, and then cut it off? | 07:48 |
| jtv | Don't know. It's not something you ask about, or try for yourself. | 07:48 |
| jtv | They may point out that you don't need them, since they have all the proper talismans and statuettes. | 07:48 |
| jtv | Leading cause of blindness resulting from vehicle accidents, apparently. | 07:49 |
| jtv | If you do get one of those in your eye, people will probably tell you how lucky you are -- without the Ganesh statue you'd probably have been killed in the accident. | 07:49 |
| jam | Interestingly, this last year in the US, suicide overcame car accidents as the leading cause of accidental death (not counting health issues, etc) | 07:50 |
| jtv | Suicide is counted as accidental death? I had no idea the country's problems ran _that_ deep. | 07:51 |
| jtv | I mean, no wonder the financial system collapses with that kind of accounting. | 07:52 |
| jam | jtv: 'injury related death' | 07:52 |
| jam | http://vitals.nbcnews.com/_news/2012/09/25/14101794-suicide-now-kills-more-americans-than-car-crashes?lite | 07:52 |
| jtv | Jokes aside, it's shocking. | 07:52 |
| jam | not 'accidental' | 07:52 |
| jam | sure, though car accidents killed something like 40,000 people, but heart disease kills about 600,000 | 07:54 |
| jtv | I guess nobody there worries much about terrorism any more then, if more Americans get killed by themselves than by terrorism? | 07:54 |
| jam | jtv: I've read a lot of Schneier, and worrying about terrorism is stupid (but publicly funded) in the US. | 07:54 |
| jam | I think more people die to pigs than to terrorism. | 07:55 |
| jtv | Is that the little table at the beginning of the book? | 07:55 |
| jam | jtv: something like that I think. I know more people die to pigs than to sharks, which was in that table. | 07:55 |
| jam | The bit I read was that the US has an official policy that if a death rate is more than 1:1Million, then it is worth doing something about it. And even in 2001 it didn't reach 1:1M death rates due to terrorism. | 07:56 |
| jam | but we sure spent a lot of money on it. | 07:57 |
| jam | morning mgz | 08:05 |
| jam | mgz: I'm guessing you missed the cat with myself and j-t-v about testing the transaction logic. Want to do a quick standup on Mumble before we join red squad? | 08:08 |
| melmoth | stoopid question of the day: when i pxe boot a node, what is the difference between the "enlist" and the "local" choice ? | 08:15 |
| dannf | enlist will register it into maas' database - local will tell it to boot from the local disk | 08:26 |
| dannf | melmoth: ^ | 08:26 |
| melmoth | ok. thanks. | 08:27 |
| melmoth | i felt it was this, but was surprise to see my node enlisted when choosing local (but this is because there was nothing on the drive, so it pxe boot anyway) | 08:27 |
| mgz | jam: sorry, missed the poke, will read log later | 08:34 |
| jam | np | 08:35 |
| jam | we can chat after the standup, too | 08:35 |
| jam | mgz: I'm back on mumble when you get back to your machine :) | 08:43 |
| mgz | migration complete :) | 08:45 |
| mgz | 's one way of getting exercise in the morning... | 08:45 |
| melmoth | grumble.. hitting one problem i had lots of time.. once a node has booted, its name is note resolbable | 08:49 |
| melmoth | and the entry in /var/lib/misc/dnsmasq.leases for its mac mention "ubuntu" instead of its name | 08:50 |
| melmoth | any idea what to do when one is experiencing this ? | 08:50 |
| melmoth | ohh, this time, restarting dnsmasq and rebooting the node seems to have "fixed it". | 08:52 |
| jam | mgz: so what did you think about the tests I put up? (I imagine you are currently away at lunch?) | 11:54 |
| mgz | nearly but not quite | 11:57 |
| jam | mgz: https://code.launchpad.net/~jameinel/maas/tags-exposing-nodes/+merge/126438 | 12:11 |
| rbasak | Daviey, roaksoax: ping. I've just realised that maas-enlist is going to need to send MAAS the subarchitecture for ARM support, eg. armhf/highbank instead of armhf. This will need an SRU to 12.04. Currently it uses architecture=armhf, but changing this would break old MAAS installs. So I think I need to add architecture=armhf&subarchitecture=generic, which should work. MAAS doesn't seem to complain about extra fields. Thoughts? | 12:18 |
| rbasak | er, architecture=armhf&subarchitecture=highbank, or architecture=amd64&subarchitecture=generic | 12:18 |
| rbasak | For backwards compatibility new MAAS can just assume subarchitecture=generic if it is not specified | 12:18 |
| Daviey | rbasak: I actually thought we were sending the subarch! | 12:19 |
| Daviey | rbasak: so i agree with that direction, and thought it was done | 12:19 |
| rbasak | Oddly, no. archdetect returns the exact string we need ("$arch/$subarch") | 12:19 |
| rbasak | It's a shame maas-enlist filters out the second component! | 12:19 |
| Daviey | yeah | 12:20 |
| rbasak | It currently does arch=`archdetect | cut -d'/' -f1` | 12:20 |
| rbasak | And I can't cut that out, since then older MAAS installs will use a more recent SRU'd maas-enlist and then break | 12:20 |
| rbasak | I'll just have to add a whole other field | 12:20 |
| rbasak | Daviey: will the SRU be OK? | 12:21 |
| Daviey | rbasak: ideally... we do this IMO.. If it doesn't post the subarch, server-side assumes generic | 12:22 |
| Daviey | and SRU in conjunction. | 12:22 |
| rbasak | Daviey: and to confirm, you mean subarch in a separate field? | 12:22 |
| Daviey | rbasak: I don't know. | 12:23 |
| rbasak | ok | 12:23 |
| * rbasak has filed https://bugs.launchpad.net/ubuntu/+source/maas-enlist/+bug/1056816 | 12:26 | |
| ubot5 | Ubuntu bug 1056816 in maas-enlist (Ubuntu) "maas-enlist does not post subarch" [Undecided,In progress] | 12:26 |
| === matsubara-afk is now known as matsubara | ||
| smoser | rbasak, dailies should show up in the next hour or so | 12:57 |
| rbasak | smoser: awesome. Thank you! | 12:57 |
| smoser | both quantal and precise. | 12:57 |
| smoser | qemu-arm-static is freaking slow. | 12:59 |
| smoser | amazing. | 12:59 |
| smoser | but slow | 13:00 |
| smoser | https://maas.ubuntu.com/images/ephemeral/daily/precise/20120924/ | 13:21 |
| rbasak | rvba: having some piston trouble with the subarch stuff. I'm trying to add a subarchitecture= field to the api that maas-enlist calls. Except that it doesn't seem to work because it's tied a model so ignores any extra fields. http://paste.ubuntu.com/1228451/ | 13:28 |
| rbasak | (or at least I think it's why) | 13:28 |
| rbasak | any ideas? | 13:29 |
| mgz | rbasak: is your subarch branch up anywhere yet? just want to see what you've changed for the constraint | 13:32 |
| rbasak | mgz: I haven't touched the constraint yet | 13:34 |
| rbasak | still figuring out how the whole thing will work | 13:35 |
| rbasak | I think I've got most of the pieces except this problem with maas-enlist | 13:35 |
| mgz | rbasak: I can do that then if you tell me what the architecture field will contain | 13:35 |
| rbasak | mgz: it'll be armhf/highbank, armhf/armadaxp, i386/generic or amd64/generic | 13:35 |
| rbasak | and these strings shoudl be available as ARCHITECTURE.i386, ARCHITECTURE.amd64, ARCHITECTURE.armhf_highbank, etc | 13:36 |
| rbasak | (from maasserver.enum) | 13:36 |
| mgz | rbasak: thanks, I'll put sometime like that up for consideration | 13:36 |
| rbasak | but maas-enlist is usingi an API that is heavily tied to the node model | 13:36 |
| rbasak | And since I'm not adding a subarchitecture field to node, this is being a massive pain for me | 13:37 |
| rbasak | piston doesn't seem to support additional fields that aren't in the model, unless I'm missing something | 13:37 |
| rbasak | (I hope I am) | 13:37 |
| _rvba | rbasak: Looks like you're manually changing query_data['architecture'] so it should be ok… what's the error exactly? | 13:53 |
| rbasak | Piston/0.2.3rc1 (Django 1.4.1) crash report: Method signature does not match. Resource does not expect any parameters. | 13:54 |
| rbasak | (across multiple lines) | 13:54 |
| rbasak | create_node never gets called | 13:54 |
| rbasak | But only if I have a subarchitecture key in the POST data | 13:54 |
| rbasak | WIthout it, everything works normally | 13:54 |
| rbasak | THe only place that seems to define allowed fields is the fields tuple, and I've added subarchitecture to that | 13:54 |
| _rvba | Looks like the request does not get properly routed if subarchitecture is there. Which is weird. | 13:54 |
| rbasak | So the only other thing I can think of is that it's tied to the Node model, and that doesn't define subarchitecture | 13:54 |
| _rvba | create_node should be called even if the form has a problem with what's in request.data. | 13:55 |
| rbasak | I don't think it's the form with the problem | 13:55 |
| rbasak | I think it's piston | 13:55 |
| _rvba | Piston does not do much. I don't see how it can get in the way. I think it's simply hiding the error. | 13:56 |
| rbasak | I raised a ValidationError in create_node to check | 13:57 |
| rbasak | It gets raised and I get its output over HTTP if I don't use subarchitecture | 13:57 |
| rbasak | WHen I use subarchitecture I get this other error instead | 13:57 |
| rbasak | So I'm certain that create_node never gets called if subarchitecture is set | 13:57 |
| rbasak | THe problem has to be in the new method or in piston | 13:57 |
| _rvba | Can you paste the result of 'bzr diff'? I'll have a look. | 13:58 |
| rbasak | I'm working on top of my highbank patchset | 13:58 |
| rbasak | _rvba: https://pastebin.canonical.com/75335/ should bring you up to where I am, but it does include other patches | 14:02 |
| rbasak | _rvba: they shouldn't affect this issue though | 14:02 |
| _rvba | rbasak: sorry to be thick but how can I apply that kind of patch to my tree? | 14:07 |
| rbasak | rvba: sorry. Use patch -p1 | 14:07 |
| * rbasak finds it a bit bizarre that bzr uses -p0 | 14:07 | |
| _rvba | Thanks. | 14:08 |
| _rvba | rbasak: what's the failing test? | 14:08 |
| rbasak | _rvba: I don't have one / haven't tried tests | 14:08 |
| rbasak | _rvba: the problem occurs when I actually fire MAAS up and try and enlist with a patched maas-enlist | 14:09 |
| rbasak | _rvba: I'll see if I can add an appropriate test. Looks like it shouldn't be too ahrd | 14:10 |
| _rvba | rbasak: ok, let's see if I can recreate your problem by modifying an existing test. | 14:11 |
| smoser | jtv, around ? | 14:13 |
| jtv | hi smoser | 14:13 |
| smoser | maas daily ppa yesterday successfully wrote a dhcpd.cofn file. | 14:13 |
| smoser | but that seems broken now. | 14:13 |
| jtv | Yeah, Julian and I went over some problems earlier | 14:14 |
| smoser | so it was knowingly broken? | 14:15 |
| smoser | it worked yesterday | 14:15 |
| jtv | Not knowingly, but we saw breakage and fixed it. | 14:15 |
| jtv | Although... | 14:15 |
| _rvba | rbasak: '/'.join('b','a') is not correct. '/'.join(['b','a']) | 14:15 |
| jtv | Ah yes, smoser: I remember now -- the dhcpd.conf wasn't being written for a very different reason than the other problems. | 14:15 |
| smoser | but it was being written yesterday. | 14:16 |
| smoser | i'm almost certain. | 14:16 |
| jtv | The task to do so never arrived at the cluster controller, because of changes in routing. | 14:16 |
| jtv | Those routing changes are very recent. | 14:16 |
| jtv | And difficult to get entirely right without some trial and error. | 14:16 |
| _rvba | rbasak: that's in http://paste.ubuntu.com/1228526/. Also, if '/' in given_subarch blows up if given_subarch is None. | 14:16 |
| rbasak | _rvba: ok, I'll fix that and retest | 14:17 |
| rbasak | _rvba: but I don't think it's getting that far anyway. Let me see... | 14:17 |
| rbasak | _rvba: urgh. Looks like it is | 14:18 |
| rbasak | _rvba: sorry | 14:18 |
| mgz | my new api test case if failing with a 400 response and this text: | 14:26 |
| mgz | Piston/0.2.3rc1 (Django 1.4.1) crash report: | 14:26 |
| mgz | Method signature does not match. | 14:26 |
| mgz | Resource does not expect any parameters. | 14:26 |
| mgz | what is it really trying to tell me? | 14:26 |
| mgz | allenap: ^ any ideas? | 14:26 |
| allenap | mgz: diff? | 14:28 |
| allenap | mgz: I'll be back in ~10 minutes. | 14:29 |
| mgz | allenap: <http://pastebin.ubuntu.com/1228548/> | 14:30 |
| mgz | the other tests are fine, just writing this at the api level weirded up | 14:30 |
| mgz | gah, nose I hate you. | 14:37 |
| allenap | mgz: How very odd. | 14:49 |
| mgz | so, it's an error from inside acquire.. just not a useful one | 14:50 |
| mgz | is there some way to make tests show the traceback in that case? | 14:50 |
| allenap | Gah! 2FA just to download the plain text. I hate you Ubuntu pastebin. | 14:50 |
| mgz | ...and how do I run *just one* test with nose... ;_; | 14:50 |
| allenap | mgz: bin/test.maas <path-or-module>:TestClass.test_method | 14:51 |
| allenap | mgz: nose is stupid enough to output test IDs that can't be used as input. | 14:51 |
| mgz | ah, the colon is the magic I forgot | 14:52 |
| mgz | okay, this will make tdd on this much less painful | 14:52 |
| mgz | (well, where the last d is 'debugging' not 'development', was bad and wrote all the code first) | 14:53 |
| allenap | mgz: Do you want me to hack at it too? | 14:59 |
| mgz | okay, seems I can do filter(a_manytomany_field=obj), using filter(a_manytomany_field__contains=obj) was wrong | 14:59 |
| mgz | I shall now continue writing tests.... | 15:00 |
| _rvba | smoser: the recent problem with dhcp is due to the change we made to how tasks are routed. I image it's frustrating for you but here is the explanation: we are working towards having the tasks routed correctly when multiple cluster controllers are connected but this will obviously require some changes to the packaging. And splitting up the existing package into 2 (one for the region controller and one for the | 15:43 |
| _rvba | cluster controller) is still WIP. Hence the routing problem. | 15:43 |
| smoser | when you break something like that you cost lots of people time. | 15:44 |
| _rvba | smoser: not sure if you're interested in that kind of solution but this: http://paste.ubuntu.com/1228681/ should fix the problem. | 15:44 |
| _rvba | And I could say that not having the proper package structure is costing us a lot of time too. | 15:45 |
| smoser | really? | 15:45 |
| smoser | so you're complaining that you broke somethign that worked (in the packaging) | 15:45 |
| smoser | and it no longer works | 15:46 |
| smoser | ok | 15:46 |
| _rvba | I'm not complaining. I'm trying to explain to you why that mistake was made. | 15:46 |
| _rvba | smoser: I did not touch the packaging precisely because the whole structure is being changed (from one package to two packages). That's exactly why there is friction. | 15:49 |
| smoser | _rvba, sorry for ranting. its just frustrating when i'm trying to test something and the daily ppa regresses. | 15:53 |
| _rvba | smoser: I understand… and I think I'm used to you being grumpy now. Well, sort of :). | 15:54 |
| === matsubara is now known as matsubara-lunch | ||
| smoser | well, i wanted to find a link for grumpy old man | 15:57 |
| smoser | but the best i could find was http://www.hulu.com/watch/271896 | 15:57 |
| smoser | and you probably can't see that. | 15:57 |
| _rvba | Indeed, I can't. | 15:57 |
| _rvba | roaksoax: may I ask how it the packaging work going? I'm asking because I'm making changes upstream that will require some packaging changes but I can't do that while you're refactoring the whole structure (at least I think I can't). | 15:58 |
| _rvba | s/how it/how is/ | 15:58 |
| roaksoax | _rvba: we are working on it with bigjools | 15:59 |
| roaksoax | what type of changes are you making? | 15:59 |
| _rvba | Tasks are now routed to the queue named after nodegroup.uuid. So the invocation of celeryd needs to be done with "-Q name-of-the-queue". | 16:00 |
| _rvba | But this means that the script Jeroen has done needs to be started in an upstart job, that a proper UUID needs to be generated, etc. | 16:01 |
| _rvba | smoser: http://craigmcn.ca/wp-content/uploads/2012/09/old-man.jpg maybe? | 16:02 |
| smoser | https://www.google.com/search?q=dana+carvey+grumpy+old+man&hl=en&safe=off&tbm=isch&prmd=imvnso&source=lnms&sa=X&ei=LCdjUIffM_K70QGRooDADw&ved=0CAcQ_AUoAQ&biw=1259&bih=799 | 16:03 |
| _rvba | roaksoax: do you have an ETA for a first version? I'm trying to figure out if I need to do something to cope with the current package (something I would have to undo when the new structure will be in place) or not. | 16:05 |
| roaksoax | _rvba: hoping that this friday we have sometihng | 16:06 |
| _rvba | roaksoax: all right, thanks. | 16:06 |
| roaksoax | allenap: ping | 16:07 |
| roaksoax | allenap: https://pastebin.canonical.com/75364/ | 16:07 |
| roaksoax | allenap: let me know when you see it, it's kinda critical to resolve :) | 16:09 |
| roaksoax | _rvba: how does the templating work for if statements? | 16:14 |
| roaksoax | _rvba: such as {{ if node.distro_series >= {'quantal' }} | 16:15 |
| roaksoax | can i use variables? | 16:16 |
| _rvba | Yes you can :). I'll see if I can find an example but the doc is here: http://pythonpaste.org/tempita/. | 16:16 |
| roaksoax | thanks ) | 16:18 |
| roaksoax | :) | 16:18 |
| _rvba | roaksoax: here is a completely stupid example I just wrote: http://paste.ubuntu.com/1228724/ | 16:19 |
| _rvba | roaksoax: that template language is very permissive, any python syntax variable.field, dict['element'] should work all right. | 16:20 |
| roaksoax | _rvba: cool thanks | 16:20 |
| roaksoax | _rvba: http://paste.ubuntu.com/1228732/ | 16:22 |
| _rvba | roaksoax: I think you want to use {{server_url}} instead of http://{{server_host}}. | 16:24 |
| _rvba | The server_url should contain http or https. | 16:24 |
| _rvba | We don't want to hardcode 'http' anywhere. | 16:25 |
| roaksoax | _rvba: ok cool, though if the error above gets fixed we will use tftp instead | 16:25 |
| _rvba | right | 16:26 |
| _rvba | roaksoax: that's not valid : {{if node.distro_series in {'quantal'} }} | 16:27 |
| _rvba | roaksoax: hold on, I'll find the correct syntax. | 16:28 |
| roaksoax | _rvba: it is, just tested it | 16:28 |
| _rvba | roaksoax: ah indeed, you're right, my mistake. | 16:29 |
| mgz | so, these get_blah_or_404 methods seem like a bad idea to me | 16:53 |
| mgz | at least using the django helper does, because the user just gets, as the response body "Not Found"... with no indicaton of *what* wasn't found or why | 16:54 |
| mgz | shouldn't there be at least an ObjectNotFound exception class with code httplib.NOT_FOUND but takes (type, field=None, value=None) so we can give errors like "Tag with name 'foo' is not found" instead? | 16:56 |
| smoser | rbasak, the images tested ok for me on intel and daily ppa | 17:09 |
| smoser | wait. for quantal they did. | 17:10 |
| smoser | i just uploaded the precise fix. | 17:10 |
| rbasak | smoser: \o/ | 17:25 |
| rbasak | smoser: thank you! | 17:25 |
| smoser | i'll rebuild precise | 17:25 |
| smoser | but you should test also | 17:25 |
| smoser | roaksoax, do you know how i could convince maas to boot quantal ephemeral images? | 17:25 |
| roaksoax | smoser: yes | 17:26 |
| roaksoax | smoser: src/maasserver/models/config.py set it there | 17:26 |
| roaksoax | smoser: i need to add an option to modify that in "Settings" view | 17:27 |
| rbasak | smoser: I'll test tomorrow morning | 17:29 |
| rbasak | smoser: so where do I need to test from? maas.ubuntu.com daily? | 17:30 |
| rbasak | smoser: and for precise? or would you like the result of a quantal test first? | 17:30 |
| smoser | precise will fail | 17:31 |
| smoser | well, actually might pass. i'm not sure how it worked. | 17:31 |
| smoser | but resolvconf didn't get written | 17:31 |
| smoser | i'll start a new precise build right now | 17:32 |
| roaksoax | smoser: ok so for ipmi, we want to create a new user and a random pass right? | 17:32 |
| smoser | hm.. | 17:34 |
| smoser | well i would suggest that is oen path. | 17:34 |
| smoser | and that collecting is another | 17:34 |
| roaksoax | huh? | 17:35 |
| smoser | roaksoax, so in the "let maas do it all" case, you would then assume access to the ipmi and you'd want to set up a user, pass, and then tell maas about that. | 17:36 |
| smoser | but there is also the case where you would just want that collected and reported to maas. | 17:36 |
| smoser | but not changed. | 17:36 |
| smoser | (i think) | 17:36 |
| roaksoax | smoser: right, so I had that in mind at first, though Daviey mentioned that we should simply assume that every time we commission, we should configure it as if it was unconfiguraed | 17:38 |
| smoser | i guess that is not unreasonable. | 17:39 |
| roaksoax | smoser: what could be done is simple "If maas use already exists, then collect info" | 17:40 |
| smoser | warning: grave ignorance about to be exposed | 17:41 |
| smoser | so.. if we boot, collect/set ipmi password and user and IP and such | 17:41 |
| smoser | then we give the system to a potentially malicous user | 17:42 |
| smoser | why would that not be granting them access to the same credentials | 17:42 |
| smoser | and thus the ability to not be nice | 17:42 |
| roaksoax | right but we are with the assumption that the credentials are set by the administrator and is a random password that should be hidden on the WebUI | 17:43 |
| smoser | roaksoax, i'm confused. | 17:44 |
| smoser | i'm saying the occupant of the system | 17:44 |
| smoser | can then just read them from the system | 17:44 |
| smoser | or create new ones | 17:44 |
| roaksoax | smoser: right, but that's the same case when an admin manually creates ipmi credentials | 17:45 |
| smoser | well, yes. | 17:45 |
| smoser | except for i would suspect that after doing so the admin would then disallow access | 17:46 |
| roaksoax | or when no other than the defalt ones have been created | 17:46 |
| smoser | but if we disallow access, then your "redeploy" scenario requires some sort of manual intervention. | 17:46 |
| roaksoax | smoser: right, so this is tricky to resolve | 17:47 |
| smoser | would this work ? | 17:47 |
| smoser | for our deployment/re-deployment systems. | 17:48 |
| smoser | we create one se of credeitians with 'ubuntu:ubuntu' that is admin | 17:48 |
| smoser | with those credentials, you can open up access from the system itself | 17:48 |
| smoser | then enlist/commission with maas (which will disallow access from the system) | 17:48 |
| === matsubara-lunch is now known as matsubara | ||
| smoser | then you can reset to "ready" with the 'ubuntu:ubuntu' creds | 17:49 |
| smoser | (from the network interface, rather than from the system itself) | 17:49 |
| roaksoax | smoser: right, but that means that we would have to pre-configure ipmi | 17:49 |
| smoser | right. but in our test labs we would have to do that. | 17:50 |
| roaksoax | and i thought, or so I was told, that the idea here is to simply plug in a server, detect ipmi, configure it and that's it | 17:50 |
| smoser | hm.. | 17:50 |
| roaksoax | so we cannot rely on having someone pre-configuring IPMI | 17:51 |
| roaksoax | smoser: but either way, IPMI cards have a default user/password | 17:51 |
| roaksoax | which is supposed to be enabled | 17:51 |
| roaksoax | by default always | 17:51 |
| roaksoax | so the idea is to create a user/pass for maas:XYZ | 17:51 |
| roaksoax | and tell that to MAAS so it can start/stop machines | 17:52 |
| roaksoax | smoser: btw.. I can't see an option to disable BMC access of a machine itself | 17:54 |
| roaksoax | there's only lan channel | 17:54 |
| smoser | doesn't that seem broken? | 17:56 |
| roaksoax | smoser: well, that's IPMI settings themselves | 17:56 |
| roaksoax | there's no option ot disable local BMC access | 17:56 |
| smoser | doesn't that seem broken? | 17:57 |
| smoser | and our entire system based on the fact that we could do that? | 17:57 |
| roaksoax | yeah | 17:57 |
| roaksoax | well, we can maybe restrict access to such tools on sudoers to the ubuntu user? | 17:58 |
| roaksoax | smoser: but to me... the root user is the one who has access to every piece of hardware | 17:59 |
| roaksoax | smoser: and it is the same case with the BMC | 17:59 |
| roaksoax | smoser: so in reality, if we argue that it is broken, we can argue the same thing with every piece of hardware attached to the system | 18:00 |
| roaksoax | restricting local bmc access would be as restricting access to a HD for a root admin | 18:00 |
| roaksoax | s/admin/user | 18:00 |
| smoser | well, thats not really true. | 18:01 |
| smoser | generally you can disbale access to the bios from the OS | 18:02 |
| smoser | which would stop the OS from changing boot-order or such things | 18:02 |
| smoser | which is essentially what we want to do here. | 18:02 |
| smoser | if my OS is compromised, i'd still like to be able to use my hardware. | 18:02 |
| roaksoax | smoser: right, but an ipmi card is a piece of hardware | 18:04 |
| roaksoax | not a BIOS | 18:04 |
| roaksoax | smoser: so if your OS is compromised, i'd still like to be able to use IPMI | 18:04 |
| roaksoax | or access the BMC | 18:05 |
| roaksoax | smoser: lp:~andreserl/+junk/autodetect-ipmi | 18:33 |
| roaksoax | smoser: ok so instead of doing most of the --commit stuff by commands, a template can be used and written as a file, so we just do 1 commit | 18:34 |
| smoser | rbasak, precise image daily image should be good now. | 18:38 |
| rbasak | smoser: thank you! | 18:38 |
| smoser | roaksoax, bug 1: /bin/python | 18:41 |
| ubot5 | Launchpad bug 1 in Ubuntu "Microsoft has a majority desktop market share" [Critical,In progress] https://launchpad.net/bugs/1 | 18:41 |
| smoser | roaksoax, | 18:57 |
| smoser | you said /usr/share/pyshared/maasserver/models/config.py and change DISTRO_SERIES.precise to DISTRO_SERIES.quantal, right? | 18:58 |
| smoser | and then i sudo restart maas.pserv | 18:58 |
| smoser | but it still gives me precise | 18:58 |
| roaksoax | smoser: restart apache2 | 18:58 |
| smoser | roaksoax, https://code.launchpad.net/~smoser/maas/trunk.import-ephem-fix/+merge/126543 | 20:34 |
| roaksoax | smoser: done | 20:37 |
| smoser | thanks | 20:45 |
| smoser | verified that i can boot quantal ephenmeral | 20:45 |
| roaksoax | smoser: awesome! | 20:45 |
| smoser | bigjools, 'https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1055935' works for you? | 23:59 |
| ubot5 | Ubuntu bug 1055935 in MAAS "dhcpd.conf is not updated after package install" [Critical,Fix released] | 23:59 |
| smoser | i have failed on several attempts | 23:59 |
| bigjools | smoser: yes I had it working yesterday after I fixed the upstart file | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
