| smoser | here now roaksoax | 00:31 |
|---|---|---|
| jtv | bigjools: I guess my fix for bug 1049407 should go into two branches now? | 02:33 |
| ubot5 | Launchpad bug 1049407 in MAAS "DHCP next-server set incorrectly on multi-homed hosts" [Critical,In progress] https://launchpad.net/bugs/1049407 | 02:33 |
| bigjools | jtv: how's that? | 02:33 |
| bigjools | oh you mean backport | 02:33 |
| bigjools | yes | 02:33 |
| jtv | You couldn't have waited half a lousy day with that branch, could you? :) | 02:33 |
| bigjools | jtv: well the part that lets you set a maas-facing url needs to go in both | 02:34 |
| bigjools | anything to do with dhcp only in the backport branch | 02:34 |
| bigjools | since rvb is doing a generic solution for 12.10 | 02:34 |
| jtv | What solution is that? | 02:34 |
| bigjools | jtv: I *could* have :) | 02:34 |
| jtv | Grrrr | 02:34 |
| bigjools | the cluster enlistment process will detect all interfaces on the cluster host and ask the admin to pick one | 02:35 |
| jtv | Shouldn't that become the setting for the maas-facing URL then? | 02:35 |
| bigjools | no | 02:35 |
| bigjools | cluster vs region here remember | 02:35 |
| jtv | Oh, you mean because the node won't be talking to the region controller anyway? | 02:36 |
| bigjools | these are completely different things we're talking abouty | 02:37 |
| bigjools | the master worker (aka master cluster) can make assumptions that it can use the maas-facing address's interface | 02:37 |
| bigjools | remote clusters need to be explicitly set up | 02:37 |
| jtv | Well either way, I think get_maas_facing_server_address() needs to make use of a different setting — and that should be the whole of the fix to this particular problem. So I don't foresee any changes that would not be suitable for trunk. | 02:40 |
| jtv | Although I do think there are more places where we should explicitly use the maas-facing address. | 02:44 |
| jam | jtv: https://code.launchpad.net/~jtv/maas/bug-1049407/+merge/123891 seems incomplete | 07:37 |
| ubot5 | Ubuntu bug 123891 in firefox (Ubuntu) "No spelling suggestions on right click" [Undecided,Invalid] | 07:37 |
| jam | it only has comment changes | 07:37 |
| jtv | jam: looking | 07:38 |
| jtv | jam: you mean the MP where the commit message says, “There were no changes to make, but I found some comments that could be clearer.” Right? :-) | 07:39 |
| jam | jtv : I skipped to the 'pre implementation with Julian' which made me think there were actual changes. | 07:40 |
| jam | Not sure why you would need a preimpl for comment only. But hey, +1 from me :) | 07:40 |
| jtv | The pre-imp had to establish that no changes were needed! Thanks. | 07:40 |
| jam | jtv: I read it from the email | 07:40 |
| jam | not the Commit message | 07:40 |
| jam | but just the Description | 07:40 |
| jam | apparently Commit Message doesn't get sent via email | 07:40 |
| jam | which is why I didn't see it. | 07:41 |
| jtv | :( | 07:41 |
| jtv | The latest wisdom is that the commit message should be descriptive. | 07:41 |
| jam | I agree it should be descriptive | 07:41 |
| jam | I'm not sure that the LP infrastructure handles it properly | 07:41 |
| jam | I tend to review via email | 07:41 |
| jam | I'll try to be on the lookout for it. | 07:41 |
| bigjools | commit message doesn't get sent if put on at the MP creation time | 07:42 |
| jtv | Sorry about that. Maybe I should just say "see commit message" in the description to avoid these mistakes. Copying the commit message seems wrong. | 07:42 |
| bigjools | :( | 07:42 |
| jam | jtv: that probably would help while we transition, at least. | 07:43 |
| jam | bigjools: I see this is a known issue: https://bugs.launchpad.net/launchpad/+bug/1017293 | 07:49 |
| ubot5 | Ubuntu bug 1017293 in Launchpad itself "Commit message is not shown on the initial merge proposal email" [High,Triaged] | 07:49 |
| bigjools | jam: yeah look who filed it :) | 08:03 |
| jam | yeah, I saw that | 08:10 |
| bigjools | jam, jelmer, mgz https://plus.google.com/hangouts/_/b97be36d9d774b00fb757d4aea1e57f788c80227?hl=en-GB | 08:48 |
| bigjools | back later | 09:08 |
| allenap | bigjools: I have to go out. We did a catch-up yesterday, so can we postpone today's? | 09:16 |
| jam | jtv: i'm happy to continue chatting, I just didn't want to tie up both teams | 09:22 |
| jtv | fair enough! | 09:22 |
| jtv | I was just saying: somebody might have implemented auto-tuning for either data store. | 09:22 |
| bigjools | allenap: yeah find | 09:41 |
| bigjools | fine* | 09:41 |
| mgz | and again today, yeay buildout... | 12:04 |
| mgz | Download error on http://www.liucougar.net/blog/nose-subunit: [Errno -2] Name or service not known -- Some packages may not be found! | 12:04 |
| mgz | jtv: have made the tweaks you suggested in the review | 12:09 |
| roaksoax | jtv: around? | 12:22 |
| roaksoax | rvba: howdy! So while I was talking to smoser yesterday I think we've reached a concensus on how the release should be implmeneted | 12:23 |
| roaksoax | rvba: so, we will have default_commissioning_release and default_install_release. We will keep the os_release attribute until the "instace" approach/table exists. The release will be set on start() and switched back to default on stop() | 12:24 |
| roaksoax | rvba: we will obtain the release with get_install_release and we will set it with set_install_release. That way, once the instances approach smoser was mentioned exists, we can simply replace the get_install_release more easily and ditch the set_install_release | 12:25 |
| roaksoax | rvba: thoughts? | 12:25 |
| roaksoax | smoser: agreed?^^ | 12:25 |
| smoser | its reasonable. although you can just use a getter and setter (rather than get_install_release and set_install_release but do whatever is done in MAAS). | 12:47 |
| roaksoax | smoser: alright, cool then | 13:05 |
| smoser | roaksoax, is maas uninstallable right now ? | 13:33 |
| smoser | http://paste.ubuntu.com/1200553/ | 13:33 |
| roaksoax | smoser: where are you installing from? daily? | 13:34 |
| smoser | http://paste.ubuntu.com/1200556/ | 13:34 |
| roaksoax | smoser: it shouldn't be... | 13:35 |
| roaksoax | smoser: do you have maas already installed? | 13:35 |
| rvba | roaksoax: hey | 13:36 |
| smoser | it says Installed: none | 13:36 |
| rvba | roaksoax: "and switched back to default on stop()" you mean switched back to None don't you? | 13:36 |
| rvba | roaksoax: in the approach you describe, node.os_release will be used to store the current release for a running instance right? | 13:36 |
| roaksoax | rvba: yes. So it will have its default, say precise, but if on start we pass quantal, it should be updated. on stop, it should be rolled back to precise (or the default) | 13:37 |
| roaksoax | rvba: btw... http://pastebin.ubuntu.com/1200559/ | 13:39 |
| rvba | roaksoax: before the instance is even started, what will the os_release field contain? | 13:40 |
| roaksoax | rvba: the one being set as default | 13:40 |
| roaksoax | rvba: the config default | 13:40 |
| rvba | roaksoax: specific to this node? | 13:40 |
| roaksoax | rvba: global one | 13:40 |
| roaksoax | rvba: all nodes iwll be enlisted and set a default release | 13:41 |
| roaksoax | rvba: so if through the api a node is requested and no release is specified,it will use the default. If a release is specified, it will use that specified release | 13:41 |
| roaksoax | rvba: any ideas on the pastebin? | 13:42 |
| rvba | roaksoax: that API behavior seems fine to me but since we don't what to support setting a release to be used at the node level before deploy-time, I suggest having that field None when the node is not yet deployed. | 13:43 |
| rvba | roaksoax: let me have a look. | 13:43 |
| rvba | roaksoax: yes, apparently there is a bug in South and it believes that the nodegroup.uuid field is new and that's not the case. I'll fix that soon but in the meantime: select 2, enter the empty string, then, in the created file, edit out the two lines (one in forward() and one in backward()) which talk about that uuid. | 13:45 |
| roaksoax | rvba: cool thanks | 13:46 |
| roaksoax | smoser: package doesn't seem broken to me btw | 13:52 |
| smoser | hm. | 13:52 |
| roaksoax | rvba: so where is it, or how is it that the WebUI starts a node? | 14:10 |
| roaksoax | if it doens't use the API for that | 14:10 |
| rvba | roaksoax: let me check | 14:11 |
| rvba | roaksoax: have a look at src/maasserver/node_action.py:StartNode | 14:11 |
| roaksoax | rvba: btw.. there's no way to test the start and stop of a node through the api right? | 14:18 |
| roaksoax | as in, actually test it | 14:18 |
| roaksoax | (manually) | 14:18 |
| rvba | roaksoax: src/maasserver/api.py:NodeHandler.start | 14:19 |
| roaksoax | rvba: right, but what I mean, is there a CLI ? | 14:19 |
| roaksoax | rvba: that doesn't involve me hacking around to get it to work | 14:19 |
| rvba | roaksoax: not yet, the CLI is coming up, allenap is working on it atm. | 14:20 |
| roaksoax | ok cool | 14:20 |
| roaksoax | allenap: does your cli already start nodes? | 14:20 |
| rvba | roaksoax: the CLI will expose all the API methods. | 14:20 |
| allenap | roaksoax: It will, but doesn't yet. | 14:20 |
| roaksoax | allenap: ok thanks | 14:21 |
| roaksoax | rvba: so we can handle the selection of release once the cli is in place cause we also need the same for juju | 14:21 |
| roaksoax | rvba: so can can I get the state of a node object? | 14:27 |
| roaksoax | rvba: self.status? | 14:28 |
| roaksoax | err node.status? | 14:28 |
| rvba | roaksoax: yes | 14:28 |
| smoser | roaksoax, it most certainly seems to me that maas in arhcive is uninstallable | 14:48 |
| roaksoax | smoser: why would it be uninstallable if the only change on ubuntu2 against ubuntu1 is simply a change within a file | 14:50 |
| smoser | it seems python-twisted is currently uninstallable | 14:51 |
| roaksoax | smoser: ahh then that's the problem | 14:51 |
| mgz | don't we have archive testing to prevent that kind of thing... :P | 14:51 |
| roaksoax | rvba: so, on the model, we should not set a default for os_release then? | 14:54 |
| roaksoax | rvba: so instead of : | 14:54 |
| roaksoax | os_release = CharField( max_length=10, choices=UBUNTU_RELEASE_CHOICES, null=True, blank=True, default=UBUNTU_RELEASE.default) | 14:54 |
| roaksoax | leave it as : | 14:54 |
| roaksoax | os_release = CharField( max_length=10, choices=UBUNTU_RELEASE_CHOICES, null=True, blank=True) | 14:54 |
| roaksoax | ? | 14:54 |
| rvba | roaksoax: well, I think we should set a default of None. This will indicate that, when a node is created, there is no running ubuntu installation on it. | 14:55 |
| roaksoax | rvba: ok cool | 14:56 |
| roaksoax | rvba: ok so, so far this looks like this: http://paste.ubuntu.com/1200725/ | 15:22 |
| rvba | roaksoax: you got me confused a bit I must say :). Is node.os_release used to : a) store the release which is going to be installed when that node will get deployed or b) store the deployed release when this node will get deployed? | 15:29 |
| roaksoax | rvba: a&b. It will store the release the node will be deployed with if different from the default one | 15:30 |
| roaksoax | rvba: if no release is specified, then it will use the default | 15:30 |
| roaksoax | (still need to change get_install_release) | 15:30 |
| rvba | roaksoax: then consider this: a node has os_release='quantal' and the default is 'precise'. | 15:31 |
| roaksoax | rvba: it will deploy quantal | 15:31 |
| rvba | roaksoax: if someone deploys that node with an APi call and specifies release=precise. | 15:31 |
| roaksoax | rvba: it will install precise | 15:32 |
| rvba | roaksoax: then node.os_release will be changed to precise right? | 15:32 |
| roaksoax | rvba: yes | 15:32 |
| roaksoax | rvba: that part hasn't been coded yet as I'd like to have the CLI in place first | 15:32 |
| rvba | And now, let's say the nodes gets 'released' or undeployed. | 15:32 |
| roaksoax | rvba: os_release will be changed back to None | 15:32 |
| rvba | How do you restore the original setting of 'quantal' ? | 15:32 |
| roaksoax | rvba: initially it will have None, unless you change that on the WebUI | 15:33 |
| rvba | roaksoax: so let's say someone changed that to quantal, you want to restore that when the node is released, even if it was deployed with another release right? | 15:34 |
| roaksoax | rvba: so let me put it some other way | 15:34 |
| roaksoax | rvba: case 1: node.os_release is None default is precise after enlistment/commissioning | 15:35 |
| roaksoax | rvba: on install if quantal is specified, then it will deploy quantal, node.os_release will be set to 'quantal' | 15:35 |
| roaksoax | rvba: on release. node.os_release will be set back to None | 15:35 |
| rvba | That makes perfect sense. | 15:36 |
| roaksoax | so if we deploy that node again and we don't specify the release, then it will deploy the default | 15:36 |
| roaksoax | rvba: now, we have to consider a second case | 15:36 |
| roaksoax | rvba: Case 2: node.os_release is None, default is precise. | 15:36 |
| roaksoax | before we deploy, I go to the WEbUI and I change from "Default Ubuntu Release" to Quantal, and save | 15:36 |
| roaksoax | node.os_release will be 'quantal' | 15:37 |
| roaksoax | rvba: so I go to the cli, and deploy *without* specifying a release | 15:37 |
| roaksoax | it will deploy 'quantal' | 15:37 |
| roaksoax | rvba: now, when I release, it will be set back to None | 15:37 |
| roaksoax | however, if on CLI i deploy specifying 'precise', it will install precise instead of the preivoulsy saved value | 15:38 |
| roaksoax | which was quantal | 15:38 |
| roaksoax | on release, it will be set back to none | 15:38 |
| roaksoax | rvba: doing this gives us the flexibility of being able to temporarily set a particular release for a node | 15:38 |
| rvba | roaksoax: ok, so node.os_release is used to track the release of a running instance. When a node is not deployed, node.os_release is None. | 15:38 |
| roaksoax | rvba: exactly | 15:39 |
| rvba | roaksoax: ok, makes perfect sense to me then. | 15:40 |
| roaksoax | awesome then | 15:44 |
| guimaluf | dam! when I'm installing a new node I'm get this : Configuring 'network-preseed' failed with error code 1; I've not change anything with networks config to stop working! | 15:47 |
| guimaluf | I've restarted squid-deb-proxy but with no success | 15:48 |
| jtv | Any reviewers in the house? I'm EOD, but I still have some reviews up from yesterday that I'm quite eager to get some progress on. | 16:00 |
| jtv | This is the oldest, which the others are based on: https://code.launchpad.net/~jtv/maas/bug-1025582-model/+merge/123679 | 16:01 |
| ubot5 | Ubuntu bug 123679 in gnome-media (Ubuntu) "gnome-volume-control crashed with SIGSEGV" [Medium,Invalid] | 16:01 |
| * roaksoax brb | 16:06 | |
| allenap | rvba: Regarding _API_DOC, I fear one of us is losing their mind. http://pastebin.ubuntu.com/1200807/ is a snippet of what's in trunk. It looks like the docs are cached fine, but never actually used. | 16:21 |
| rvba | allenap: haha, you're right. I misread what you were saying :) | 16:22 |
| allenap | rvba: Phew :) I know it's not important, but it's one of those things that I couldn't let go of. | 16:23 |
| guimaluf | please I need help, my maas server stop working out of nothing! I'm getting the following error in node syslog and in cobbler. maybe they are correlated http://pastebin.ubuntu.com/1200818/ | 16:31 |
| === matsubara is now known as matsubara-lunch | ||
| roaksoax | rvba: rvba still around? | 17:37 |
| roaksoax | allenap: still around? | 18:19 |
| allenap | roaksoax: I'll be back in ~1h. | 18:19 |
| roaksoax | allenap: ok, thanks | 18:19 |
| === matsubara-lunch is now known as matsubara | ||
| allenap | roaksoax: Hi, back sooner than I expected. What's up? | 18:46 |
| roaksoax | allenap: I forgot :) | 18:46 |
| roaksoax | allenap: ah yes, I remember now | 18:47 |
| allenap | guimaluf: Something going into your preseed file has non-ASCII characters in it. Can you think of what that might be? | 18:48 |
| roaksoax | allenap: so, I'm lookat at src/maasserver/api.py:start | 18:48 |
| roaksoax | allenap: nodes = Node.objects.start_nodes | 18:48 |
| roaksoax | allenap: 'nodes' contains only 1 node, or will /can contain several nodes? | 18:49 |
| allenap | roaksoax: Yes, only one node. That start method is part of NodeHandler, so the context is a single node. However, we ought to have a start method on NodesHandler (note the plural) that will let us call start_nodes with more than one node. | 18:50 |
| roaksoax | allenap: right, so I were to pass the release as part of the request to start() | 18:51 |
| allenap | In general, we ought to think of the plural case always before the singular, but iirc the Juju machine provider interface expected to call start on one machine at a time, so that's what ended up getting written. | 18:51 |
| roaksoax | allenap: do you think it should be done in start(), or in start_nodes()? | 18:52 |
| roaksoax | allenap: such as: http://paste.ubuntu.com/1201070/ | 18:52 |
| allenap | roaksoax: I think that start() should be for *only* turning the power on, not for accepting user data. acquire() should accept user data, or there should be a separate way to set user data. I think start() has been wrongly overloaded here. | 18:53 |
| roaksoax | allenap: right, that's a separate issue though :) | 18:54 |
| roaksoax | allenap: anyways, that makes sense? | 18:55 |
| roaksoax | allenap: though, note that for juju, acquire means "give me a system", and start means "start the acquired system with XYZ" | 18:56 |
| roaksoax | allenap: so in the api, the start() servers for that | 18:57 |
| allenap | roaksoax: Yes... your change adds to the things we have to change (it's fine otherwise). The problem is, as we change the API, we will have to change the Juju machine provider too, meaning more coding, reviews, etc. Right now it's more important to get the public face of the API correct than it is to add these features. | 18:57 |
| roaksoax | serves* | 18:57 |
| roaksoax | allenap: agreed | 18:57 |
| allenap | Cool. | 18:57 |
| roaksoax | allenap: ok so, in start() how can I set the a value for that particular node given that it doens't have the node instance | 18:58 |
| allenap | roaksoax: You have the system_id for the Node, so you can get it. | 18:59 |
| allenap | roaksoax: Look in the release method just below. | 18:59 |
| roaksoax | allenap: so siumilar to this then? http://paste.ubuntu.com/1201090/ | 19:02 |
| roaksoax | allenap: or more complete: | 19:03 |
| allenap | roaksoax: Yep. The release arg in the call to start_nodes isn't needed any more though. | 19:03 |
| roaksoax | http://paste.ubuntu.com/1201093/ | 19:03 |
| roaksoax | allenap: http://paste.ubuntu.com/1201100/ | 19:04 |
| roaksoax | allenap: right, but start will reiceive the release to use from juju, and then it should say "the release for the node we are about to start is XYZ" | 19:04 |
| roaksoax | which is what I'm trying to do | 19:04 |
| allenap | roaksoax: I don't understand that. | 19:05 |
| roaksoax | allenap: so juju will pass a request to maas | 19:05 |
| roaksoax | which will contain the release to use for that partcular request | 19:06 |
| roaksoax | then the start() method needs to set the release being passed to the node | 19:06 |
| roaksoax | so that's why I need to get the node, set the correct release for that node | 19:06 |
| allenap | Juju pseudo-does: acquire(some_constraints), start(user_data, os_release) | 19:08 |
| allenap | Isn't that it? | 19:08 |
| roaksoax | allenap: right, but a release won't be a constraint | 19:08 |
| roaksoax | allenap: because a node can be used with X release or Y release | 19:08 |
| roaksoax | allenap: we are treating this as an Instance approach | 19:09 |
| allenap | I still don't understand why we need to set the release on the Node *and* pass it to start_nodes. | 19:09 |
| roaksoax | allenap: we do *not* need to pass it to start_nodes | 19:09 |
| roaksoax | allenap: we only need to set it for the node in question | 19:09 |
| allenap | roaksoax: Ah, okay. Line 17 was passing it to start_nodes, wasn't it? | 19:10 |
| allenap | In the earlier diff. | 19:10 |
| allenap | Yeah. | 19:10 |
| roaksoax | allenap: ah yeah, forgot to strip that out :) | 19:11 |
| roaksoax | sorry :) | 19:11 |
| allenap | No worries, I think we were going round in circles a bit there. | 19:11 |
| allenap | Ah, right, start() accepts *optional* user_data and release. So, it can be used as just power control, but if those parameters are provided then it sets them before issuing a power-on (via start_nodes). | 19:12 |
| allenap | So, the public-face of the API is actually okay. I don't think I have any concerns about that any more. | 19:13 |
| allenap | Fwiw, passing the release in as a constraint isn't a crazy thing to do; some hardware may not be able to run some releases. For now I guess we can leave it as is. | 19:13 |
| roaksoax | cool | 19:31 |
| allenap | roaksoax: By the way, I'm going to start using commandant in trunk soon (so, Quantal only). I'm just bundling it in the source tree, but do you think you'll have time to package it? There is already a package at https://launchpad.net/~jkakar/+archive/commandant which can be used as a basic, and it's a very simple Python package. | 19:32 |
| allenap | s/basic/basis/ | 19:32 |
| roaksoax | allenap: sure, can you remind me tomorrow ? | 19:33 |
| allenap | roaksoax: I think you've already asked me to do that twice :) | 19:35 |
| roaksoax | allenap: hehe yeah :) i added it to my todo | 19:36 |
| allenap | Thanks. | 19:36 |
| Daviey | allenap: do we need to package commandant ? | 19:41 |
| Daviey | hah.. i see you are talking about it already | 19:41 |
| Daviey | roaksoax: once you upload it, can you ping me for a NEW review please? | 19:42 |
| roaksoax | Daviey: sure | 19:42 |
| allenap | Daviey: Heh, nothing gets by you :) Thanks. | 19:44 |
| Daviey | allenap: i just saw the MP :) | 20:10 |
| roaksoax | yay support for ubuntu releaes work with juju tooo | 20:45 |
| roaksoax | yaay | 20:45 |
| Daviey | woot | 21:17 |
| === matsubara is now known as matsubara-afk | ||
| allenap | Does anyone know how to get into the Jenkins machine that runs maas's tests? | 22:44 |
| allenap | Perhaps don't tell me in public though :) | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!