| jam | bigjools: ping if you are still around | 06:10 |
|---|---|---|
| bigjools | jam: I am here | 06:10 |
| jam | bigjools: /wave. | 06:10 |
| bigjools | surprisingly awake too :) | 06:10 |
| jam | We've been landing our changes into the 1.2 branch | 06:10 |
| jam | but I'm realizing they should also get merged into trunk, right? | 06:10 |
| bigjools | I saw | 06:10 |
| jam | I tried doing the obvious merge, but there are a handful of conflicts. | 06:10 |
| bigjools | ideally they need to start in trunk because I wanted to do a bug-only SRU into quantal :( | 06:10 |
| jam | bigjools: I can revert the changes, but the bug was on the 12.10-stabilization | 06:11 |
| jam | which I thought meant it needed to be in the 1.2 branch. | 06:11 |
| bigjools | It does. I had intended to SRU features later but I realise that the bugtask was a bit misleading :( | 06:12 |
| jam | bigjools: so, if you want I can revert what I've landed so far, retarget them onto trunk. | 06:12 |
| jam | There is still the fact that 1.2 doesn't merge cleanly into trunk, should it? | 06:12 |
| jam | or are they intended to diverge? | 06:12 |
| jam | (So in the *immediate* term, I can put together my teams changes as a single branch, which you can land once you have done the bugfix SRU, and are ready to do a feature SRU) | 06:14 |
| jam | though I imagine any branch will bitrot if not landed soon | 06:14 |
| jam | bigjools: is it worth doing that effort? | 06:16 |
| bigjools | they are diverged | 06:16 |
| bigjools | (sorry had to deal with a large insect) | 06:17 |
| bigjools | you need to cherry pick revisions | 06:17 |
| jam | so, they *have* diverged, but it would be possible to converge them. s there something you don't want in trunk that is in 1.2? | 06:17 |
| bigjools | hmmmm let me think more about the feature branch | 06:17 |
| bigjools | there's stuff in trunk we don't want in 1.2 | 06:18 |
| jam | bigjools: right, I'm talking about the other direction | 06:18 |
| jam | I was thinking to land our code in 1.2 then merge up into trunk | 06:18 |
| bigjools | there *might* be stuff in 1.2 - jtv has been landing there first and forward porting | 06:18 |
| jam | but it isn't possible today because of divergence on both side. | 06:18 |
| jam | mostly simple textual conflicts that are fairly easy to resolve | 06:18 |
| bigjools | you should be able to CP stuff though? | 06:18 |
| jam | bigjools: we can, but it seems a waste to do so unless there is stuff you really don't want in trunk | 06:19 |
| bigjools | if you can work out which revisions are missing we can decide | 06:19 |
| bigjools | but there should be nothing that's not in trunk | 06:19 |
| bigjools | unless there was a separate fix landed just for a bug in 1.2 | 06:19 |
| jam | I'm willing to do the conflict cleanup. The main problem with specific revisions is that cherrypicking makes it hard to see where things specifically come from. | 06:19 |
| bigjools | ok thanks | 06:20 |
| jam | bigjools: so one diff between 1.2 and trunk that I think you worked on. There is a pserv task "import_pxe_files" in 1.2, and "import_boot_images" in trunk. | 06:31 |
| jam | I'm not sure which name you want to use | 06:31 |
| jam | . | 06:31 |
| bigjools | jam: rvba renamed the former to the latter; he needs to backport it | 06:32 |
| jam | k | 06:32 |
| jam | I'll make sure to use boot_images after the merge. | 06:32 |
| bigjools | rightyo | 06:32 |
| bigjools | jam: I think you need to revert the 1.2 features and land them on trunk | 08:27 |
| jam | bigjools: i'm willing to do so, do you know an ETA when 1.2 would be opened again. | 08:47 |
| jam | I guess at this point, we would essentially just hand it off to your team for that, though. | 08:47 |
| === mcclurmc_away is now known as mcclurmc | ||
| jam | /wave mgz, dimitern | 09:10 |
| dimitern | jam: /wave :) | 09:11 |
| jam | I'm sitting in mumble if you guys would care to join. | 09:11 |
| dimitern | ok | 09:12 |
| jam | w7z: poke | 09:14 |
| mgz | hey jam | 09:15 |
| mgz | ...I wonder if I can find an extra network cable | 09:17 |
| jam | mgz: I've got about 10 of them here. | 09:18 |
| jam | If you feel like dropping by :) | 09:18 |
| jam | mgz: care to join us on mumble? | 09:18 |
| jam | bigjools: https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133424 | 09:19 |
| jam | and now https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133425 to properly target 1.2 | 09:20 |
| bigjools | jam: if you make a branch targeted to 1.2, we can land it after the first SRU | 09:27 |
| jam | bigjools: sure | 09:27 |
| jam | the patch is essentially revert this revision :) | 09:27 |
| bigjools | ok :) | 09:27 |
| * bigjools heading off shortly, tired.com | 09:27 | |
| jam | mgz: https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133425 | 09:29 |
| jam | mgz, dimitern: https://code.launchpad.net/~jameinel/maas/merge-1.2/+merge/133418 | 09:49 |
| jam | mgz: DatabaseError: column maasserver_tag.kernel_opts does not exist | 09:59 |
| jam | LINE 1: ...er_tag"."definition", "maasserver_tag"."comment", "maasserve... | 09:59 |
| jam | evilnickveitch: just to let you know, I'm landing a 1.2 merge => trunk which includes your doc fixes | 10:05 |
| evilnickveitch | jam, thanks for the headsup | 10:06 |
| jam | mgz, dimitern: https://code.launchpad.net/~jameinel/maas/land-kernel-opts-in-trunk/+merge/133434 | 10:07 |
| w7z | failure is https://jenkins.qa.ubuntu.com/job/maas-merger-quantal/264/console | 10:11 |
| jam | mgz w7z: Did you see bug #1073090 ? | 10:52 |
| ubot5 | Launchpad bug 1073090 in MAAS "Using MAAS and --constraints "maas-name=$SPECIFIC_HOST" juju will deploy when that host is in commissioning or some other non-ready state" [Critical,Triaged] https://launchpad.net/bugs/1073090 | 10:52 |
| jam | I didn't think this was specific to something we've changed, but I could be wrong. | 10:53 |
| w7z | looking | 10:53 |
| jam | w7z: from what I can see, we already have: 'available_nodes.filter(status=NODE_STATUS.READY)' | 10:54 |
| w7z | hm, we probably inherit the same dodgy logic for other constraints though | 10:54 |
| jam | so get_available_ shouldn't be allowing it if the status isn't actually ready. | 10:54 |
| jam | though maybe juju keeps poking at us for a specific node, and the status goes to READY before some action actually finishes? | 10:55 |
| jam | w7z: is it a possible data race between multiple juju requests to acquire a node, and the backend having a specific node ready? | 10:55 |
| w7z | hm, right, only accepting READY seems fine | 10:55 |
| w7z | I wonder if a symptom is being misdiagnosed and it's actually some other issue with using maas-name | 10:56 |
| w7z | when does READY get changed to something else... | 10:57 |
| jam | w7z: when it is "damn well read | 10:58 |
| jam | ready" | 10:58 |
| jam | :) | 10:58 |
| w7z | in acquire, which is before the api returns | 10:58 |
| jam | w7z: I think you mean in RELEASE | 10:58 |
| w7z | so, no obvious chance for maas to mislead juju here | 10:58 |
| jam | but note, any HTTP level request is inside a transaction that doesn't commit until it returns. | 10:59 |
| w7z | right, READY->ALLOCATED in acquire, ...->READY in release | 10:59 |
| w7z | I think the bug description is just wrong | 11:00 |
| jam | w7z: right, and the API level is "get_available(), node.acquire()" | 11:00 |
| jam | so we shouldn't return a node without it already being marked acquired. | 11:00 |
| w7z | the issue is that if you try to allocate more than one machine with the same maas-name constraint, juju will get no possible options for the second, and be stuck in pending | 11:01 |
| w7z | the fix being, don't use that constraint then | 11:01 |
| dimitern | jam, mgz: my branch is ready for review https://code.launchpad.net/~dimitern/maas/1.2-node-view-shows-kernel-params/+merge/133449 | 11:01 |
| jam | w7z: it sounds more like if you do a deploy before the machine has finished being ready, juju will just stop trying | 11:02 |
| w7z | I don't think he's actually confirmed that, though release does seem optimistic | 11:02 |
| jam | becoming ready | 11:03 |
| w7z | sending reboot then immediately putting in READY may not be good enough | 11:03 |
| w7z | I don't think that's what he's observing though | 11:04 |
| jam | w7z: from what I can pull out of the bug comments, the issue is that you do a 'juju deploy' and it doesn't do anything, because there are no nodes matching the constraint that are READY | 11:04 |
| jam | then juju doesn't wake up and realize once the machine is actually ready. | 11:05 |
| w7z | I think what he's seeing is just the known issue with trying to deploy with a set of constraints that returns no acquirable nodes | 11:05 |
| jam | w7z: is there a specific bug on it? | 11:06 |
| jam | I agree that it doesn't seem specific to maas-name, just easier to trigger because maas-name can have at most 1 machine available. | 11:06 |
| jam | dimitern: I'm curious about the CSS in your patch. | 11:07 |
| w7z | there's a helpful mailing list thread where melmoth was trying to use maas-name... annoyingly it's not the public list >_< | 11:08 |
| dimitern | jam: the css just sets the line input to be longer on the settings page | 11:08 |
| jam | dimitern: sure, it just seems odd to have it be tied to '.size12' | 11:09 |
| jam | .size12 doesn't seem related to 'input' | 11:09 |
| dimitern | jam: well, it's what was used for other form fields, so I thought I should reuse it | 11:09 |
| dimitern | jam: the problem is, that you cannot set easily (at least I could not find an easy way) the css class of a form field in the template, that's why I changed the parent and made the child input take 100% width, because it was constrained otherwise | 11:11 |
| w7z | jam: so, I suspect if the bug reporter checks /var/log/maas/maas.log he will also see "NodesNotAvailable: No matching node is available" | 11:12 |
| w7z | likewise the juju provisioning agent log will have something along those lines | 11:13 |
| jam | w7z: right, so where is the failure that is preventing the *user* from understanding that things aren't going to work? | 11:13 |
| jam | Is juju deploy failing to give the message immediately | 11:13 |
| w7z | that juju doesn't forward errors from the provisioning agent to the client | 11:13 |
| jam | is it not supposed to fail right away | 11:13 |
| jam | but is failing to retry later? | 11:14 |
| w7z | if this happened on bootstrap, the client you're running is talking directly to maas, and you'd see the error | 11:14 |
| w7z | but once the master node is up, all the client does is say "juju please make the state look like this" and the provision agent does all the actions against maas | 11:15 |
| jam | w7z: sure, and what happens if it can't do so immediately? | 11:15 |
| w7z | this means any errors after bootstrap go in the provisioning agent log on the master, and the client never sees them | 11:15 |
| w7z | so, `juju deploy something --constraints=maas-name=bogus` will always succeed... and give you an ever pending machine | 11:16 |
| w7z | whereas `juju bootstrap --constraints=maas-name=bogus` will fail with the nice error the maas api returns | 11:17 |
| jam | w7z: as would `juju deploy something --constraints=maas-tag=no-available-machines | 11:17 |
| jam | where the tag exists, but all machines are busy rightnow. | 11:17 |
| jam | It may be that juju isn't meant to handle it, as it assumes providers that have capacity... | 11:17 |
| w7z | right. anything that doesn't return a machine, or any transient error (though things do get retried in some circumstances that I'm still not completely clear on) | 11:18 |
| Daviey | evilnickveitch: Hey, can you join #ubuntu-server pls? | 11:23 |
| w7z | so, basically bug 984640 | 11:23 |
| ubot5 | Launchpad bug 984640 in juju "Unsatisfied constraints are not reported back to the user" [Medium,Confirmed] https://launchpad.net/bugs/984640 | 11:23 |
| === dimitern is now known as dimitern_lunch | ||
| jam | w7z: so the only bit that makes me think bug #1073090 may not be bug #984640 is that the 'retry forever' doesn't seem to be working. | 12:15 |
| ubot5 | Launchpad bug 984640 in juju "duplicate for #1073090 Unsatisfied constraints are not reported back to the user" [Medium,Confirmed] https://launchpad.net/bugs/984640 | 12:15 |
| ubot5 | Launchpad bug 984640 in juju "Unsatisfied constraints are not reported back to the user" [Medium,Confirmed] https://launchpad.net/bugs/984640 | 12:15 |
| jam | Specifically, after the node *is* ready, it doesn't actually get activated. | 12:15 |
| w7z | right, juju gets the "there are no acquirable nodes" response and takes that as immutable truth | 12:18 |
| jam | w7z: I thought juju was supposed to retry forever, if it isn't retrying again... sigh | 12:22 |
| jam | It feels like they said, no no, you shouldn't care that it isn't ever working because we'll do it again, except we don't do it again. | 12:22 |
| jam | You don't need any actual information about what is going wrong... | 12:22 |
| jam | anyway, bath time for the boy, have a good weekend mgz, maybe I'll see you in dota2? | 12:23 |
| jam | I *think I sent you a friend request, so maybe I'll catch you around there. | 12:23 |
| === dimitern_lunch is now known as dimitern | ||
| dimitern | jam: ping | 13:14 |
| jam | dimitern: pong | 13:17 |
| dimitern | jam: so I see the branch is now merged - now what? | 13:17 |
| dimitern | should I go back to go? | 13:17 |
| jam | 1: work with mgz tomorrow, 2: if you see roaksoak or smoser online, chat with them to see if we can get them to test the kernel opts once it hits the daily ppa. | 13:18 |
| jam | 3: work on Go if you run out of things. | 13:18 |
| dimitern | jam: ok 10x | 13:20 |
| rbasak | roaksoax: around? In maas-import-squashfs, you have "set -o nounset" but etc/maas/import_squashfs doesn't set RELEASES (commented out) so maas-import-pxe-files fails when running out of trunk. What's your intention here? Do you want RELEASES to be set to an empty string in etc/maas/import_squashf? | 14:02 |
| roaksoax | rbasak ill have a look in a bit ( taking care of something else right now) | 14:05 |
| rbasak | OK thanks | 14:06 |
| roaksoax | rbasak: can you pastebin the failure? | 14:13 |
| roaksoax | rbasak: and yes i want it to not be set to a string in etc/maas/import_squashfs | 14:13 |
| rbasak | roaksoax: http://paste.ubuntu.com/1342601/ | 14:14 |
| roaksoax | same as what happens with maas-import-ephemerals | 14:14 |
| w7z | roaksoax: we've landed all the bits we think you need for customising kernel parameters | 14:14 |
| roaksoax | w7z: cool, thanks! how can I customize it? | 14:14 |
| rbasak | roaksoax: I think we need a different test on line 47 then | 14:14 |
| w7z | can you find a way of trying it out on trunk, and telling us if it does what you need? | 14:14 |
| w7z | and also what documentation you want :) | 14:14 |
| roaksoax | rbasak: so my intention there is that if in etc/maas/import_pxe_files quantal has not been set, then maas-import-squashfs should not import anything | 14:15 |
| roaksoax | w7z: documentation on hjow to add/modify kernel parameters for each particular host or group of hosts | 14:16 |
| roaksoax | s/host/nodes | 14:16 |
| roaksoax | rbasak: http://pastebin.ubuntu.com/1342612/ | 14:18 |
| w7z | basically, when creating or modifying a tag, you can supply an optional kernel_opts param (see the for the cli to double check), | 14:19 |
| w7z | which will then be appended to the kernel opts used by the provisioning server on boot | 14:19 |
| roaksoax | w7z: an example would be helpful :) | 14:19 |
| roaksoax | w7z: and you need to let evilnickveitch know too to add that to the documentation on maas.ubuntu.com eventually | 14:20 |
| evilnickveitch | w7z, yes, that would definitely help! | 14:21 |
| w7z | it's essentially as per the auto generated docs | 14:22 |
| w7z | but, specifically | 14:22 |
| w7z | something like `maas-cli tag create --name=00-default-console --definition=true --kernel_opts=console=ttyS0` | 14:23 |
| w7z | will make all nodes (the defintion says effectively match everything) boot with the extra kernel param "console=ttyS0" after all the other ones maas uses | 14:24 |
| w7z | or for a similar thing | 14:24 |
| roaksoax | w7z: cool, thanks | 14:25 |
| w7z | the current highbank special case could be redone as a tag like `maas-cli tag create --name=01-highbank-console --definition="contains(/node/product,'Highbank')" --kernel_opts=console=tty` | 14:27 |
| w7z | or, you can set stuff manually just on one machine | 14:27 |
| rbasak | roaksoax: this scripts fails on a fresh updated quantal machine (with multiverse enabled for python-selenium): http://paste.ubuntu.com/1342651/ | 14:29 |
| w7z | `maas-cli tag create --name=99-special-snowflake --kernel_opts=whatever_magic_param_here` followed by `maas-cli tag update-nodes 99-special-snowflake --add SYSTEM_ID` | 14:29 |
| w7z | plus or minus typos | 14:30 |
| w7z | the naming scheme is something work mentioning in the docs, if multiple tags match, the last in lexi-order will be used, so number prefixing or a similar obvious scheme should be encouraged | 14:30 |
| Lele_ | Hi guys, in 12.10 maas doesnt have the snippets and the maas_proxy file | 14:45 |
| Lele_ | were can i setup http proxy for the image installation | 14:45 |
| Lele_ | oh i found it :) enlist_userdata | 14:46 |
| roaksoax | Lele_: enlist_userdata is for enlistment, not for installation | 14:51 |
| Lele_ | oh ! i see cause didnt work | 14:55 |
| Lele_ | where i can configure proxy por installation ? | 14:55 |
| Lele_ | roaksoax :) | 14:56 |
| rbasak | roaksoax: I've filed bug 1076409 | 14:56 |
| ubot5 | Launchpad bug 1076409 in MAAS "maas-import-pxe-files fails when run from trunk" [Undecided,New] https://launchpad.net/bugs/1076409 | 14:56 |
| roaksoax | rbasak: ack | 15:03 |
| jtv | Code review needed! https://code.launchpad.net/~jtv/maas/import-from-configured-mirror/+merge/133505 | 16:03 |
| rvba | jtv: I'll take it. | 16:09 |
| jtv | Thanks. | 16:09 |
| rvba | jtv: I've got a few branches up for review my self if you fancy doing some reviewing ;) | 16:10 |
| jtv | I can get to that pretty soon! | 16:10 |
| rvba | Cool, ta. | 16:10 |
| === matsubara is now known as matsubara-lunch | ||
| jkordish | so the maas on 12.10 (non clobber version - I'm actually pulling from the daily-builds ppa) - where are the preseed files? can't seem to find it in the docs anywhere :/ | 16:44 |
| roaksoax | jkordish: /usr/share/maas/preseeds | 16:47 |
| jkordish | roaksoax: wow. that simple. | 16:50 |
| roaksoax | :) | 16:50 |
| jkordish | roaksoax: feel like an idoit for missing it. I was doing a dpkg -L on all the maas packages and didn't see it :/ | 16:50 |
| roaksoax | :) | 16:51 |
| roaksoax | jkordish: the maas-region-controller package installs them | 16:51 |
| jkordish | thanks roaksoax | 16:57 |
| roaksoax | jkordish: you're welcome :) | 17:05 |
| === matsubara-lunch is now known as matsubara | ||
| === mcclurmc is now known as mcclurmc_away | ||
| roaksoax | _ | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!