| jtv | bigjools: you up for a quick chat about the way we'll register installed boot images? | 04:23 |
|---|---|---|
| jtv | Blast. Test failures in trunk. | 04:43 |
| jam | bigjools: I think having some time of a 3-4 person standup, separate from a 8-person standup is reasonable. | 08:09 |
| bigjools | jam: exactly what I was thinking :) | 08:09 |
| bigjools | jam: do you want to come in in about 10-15 mins then? | 08:27 |
| Daviey | the more the merrier, and distracting ! | 08:27 |
| bigjools | Daviey: just the man | 08:27 |
| Daviey | oh dear | 08:28 |
| bigjools | Daviey: my upgrade to quantal has seriously fucked my installation | 08:28 |
| Daviey | rocking | 08:29 |
| Daviey | any more detail? | 08:29 |
| bigjools | $ dpkg -l | 08:29 |
| bigjools | dpkg-query: error: parsing file '/var/lib/dpkg/status' near line 56897 package 'libao4:i386': | 08:29 |
| bigjools | mixed non-coinstallable and coinstallable package instances present | 08:29 |
| bigjools | and a crapload of broken dependencies :/ | 08:30 |
| Daviey | wow, that is quite spectacular | 08:30 |
| bigjools | thanks :) | 08:30 |
| jam | bigjools: sounds good | 08:30 |
| Daviey | bigjools: fancy raising a bug, and including all this output? | 08:30 |
| bigjools | jam: cool | 08:30 |
| bigjools | Daviey: yeah | 08:30 |
| Daviey | bigjools: just raise it against 'Ubuntu' | 08:30 |
| bigjools | Daviey: ok, shall I assign you? :) | 08:31 |
| Daviey | bigjools: I suspect it's one that cjwatson will be better suited :) | 08:31 |
| bigjools | heh | 08:31 |
| Daviey | i'm just a dumb mangler. | 08:31 |
| bigjools | jam, jelmer, mgz: https://plus.google.com/hangouts/_/c667fc896a4dfdbabcd78a47a4018ee6c2cb7341?authuser=0&hl=en-GB | 08:44 |
| mgz | ta | 08:44 |
| jam | bigjools: I don't think i have access rights to modify the Maas board, can you add the Story 3 lane? | 09:09 |
| jam | ah, there it is, nm | 09:09 |
| bigjools | jam: you should have all the rights you need, let me know if you need more | 09:27 |
| jam | Daviey: you were asking about mongo auth. I have a summary of it, would you like it here or on Maas-devel? | 09:47 |
| Daviey | jam: mailing list might be more useful for historic and wider audience | 09:51 |
| roaksoax | morning | 11:45 |
| bigjools | o/ roaksoax | 11:48 |
| roaksoax | o/ bigjools | 11:54 |
| smoser | roaksoax, rvba did you get a chance to read http://pad.daviey.com/server-maas-release-support ? | 12:47 |
| smoser | do you have som time to talk about it? | 12:48 |
| roaksoax | smoser: yeah I skimmed through it | 12:48 |
| roaksoax | smoser: i, hoewver, think you should probably post your proposal on the ML | 12:48 |
| roaksoax | smoser: i'll drop my patches but I don't think whether there's time to get that into quantal | 12:49 |
| smoser | well ,we can do that. but we can surely have people tell me what they think is wrong first. | 12:49 |
| roaksoax | smoser: well personally I still think we should be able to select what node should have what release, I think we can support both approaches... but if you consider my approach is incorrect i give in in favor to yours | 12:50 |
| rvba | smoser: I think your proposal makes sense. Let's post it to the list to see what people think. | 12:50 |
| rvba | That problem was briefly mentioned during our standup call this morning. | 12:51 |
| rvba | People seen to think that having the ability to tell that a particular node will used a particular release before deploy time is superfluous. | 12:51 |
| rvba | s/seen/seem/ | 12:52 |
| rvba | roaksoax: ^ | 12:52 |
| roaksoax | k | 12:52 |
| roaksoax | as I said, I give in | 12:52 |
| roaksoax | i guess that now making sure that smoser's proposal or anhy other fix for the issue gets into quantal is a priority | 12:53 |
| rvba | yep | 12:53 |
| roaksoax | but not having quantal support is a blocker for me, so my tasks will be blocked until ya'll have the support implemented | 12:53 |
| roaksoax | smoser: ^^ | 12:53 |
| smoser | roaksoax, i dont understand "we should be able to select what node should have what release, I think we can support both approaches" | 12:54 |
| smoser | how does my approach not do that? | 12:54 |
| roaksoax | smoser: your approach is telling the api to give you a node with a particular release | 12:54 |
| smoser | well, no. | 12:54 |
| smoser | i think that is a requirement | 12:54 |
| rvba | roaksoax: you can add the global default stuff, that alone will allow you to test stuff. And it will be one step in the right direction. | 12:54 |
| smoser | but that is not related to this actually. | 12:54 |
| smoser | we dont have an api entry point now for "give me a node" | 12:55 |
| smoser | we only have "start" on a particular node | 12:55 |
| smoser | so, unaddressed is "just give me a node already!" | 12:55 |
| roaksoax | smoser: exactly, so that's what i mean. start a node an install XYZ release on it | 12:55 |
| smoser | i'm confused. | 12:56 |
| smoser | my approach has that. | 12:56 |
| roaksoax | smoser: yes | 12:56 |
| roaksoax | smoser: that's what I'm saying | 12:56 |
| roaksoax | i'm talking about your approach | 12:56 |
| roaksoax | smoser: so on the WebUI, when you do "start node" how can you tell it what release to use if you want a different from the default? | 12:56 |
| roaksoax | smoser: in your appraoch is not possible to do that because the way you are considering to do this is doing so through the API | 12:57 |
| roaksoax | smoser: so in order to do it, you still need to tell the node what release to use, it might not be an attribute of the node, but you still need to tell it | 12:57 |
| roaksoax | smoser: and that should be stored somewhere | 12:57 |
| smoser | well it is stored somewhere. | 12:58 |
| rvba | roaksoax: the usage of the WebUI to start a node was always considered a very special case primarily meant for testing. | 12:58 |
| smoser | on the node | 12:58 |
| smoser | "default_release" as i said. | 12:58 |
| rvba | The API story is the real one. | 12:58 |
| roaksoax | rvba: right, but the usage is there | 12:58 |
| roaksoax | rvba: it is out to the wild | 12:58 |
| roaksoax | rvba: so you need to provide the same functionality in both interfaces | 12:58 |
| roaksoax | smoser: yes, defualt_release is very broad... | 12:58 |
| rvba | I think it is ok to say that using the webUI will use the default for now. And refine later if we need to. | 12:58 |
| roaksoax | rvba: i think by doing that you are removing functionality | 12:59 |
| roaksoax | rvba: and another problem is make it place nicely with juju | 12:59 |
| roaksoax | rvba: for 12.10 | 12:59 |
| rvba | Exactly, but Juju uses the API. | 12:59 |
| roaksoax | rvba: while the WebUI might be a simplified interface to interact with MAAS, I think it is essential to be able to support a release | 13:00 |
| roaksoax | rvba: so when you start a node, you node that that node will use X release you want | 13:00 |
| rvba | roaksoax: we can add this in the WebUI as well (dropdown menu next to the start button or something) | 13:01 |
| rvba | Let's focus on the core functionality first, then the API, and only then the UI. | 13:01 |
| roaksoax | rvba: ok, well the start button on the UI uses the API right? | 13:03 |
| rvba | roaksoax: not directly. | 13:03 |
| rvba | roaksoax: well, sorry, not at all. | 13:03 |
| roaksoax | rvba: well then we would just simply need to figure out how to pass the release dynamically without relying on having it stored somewhere | 13:04 |
| rvba | roaksoax: indeed. | 13:04 |
| roaksoax | rvba: if I find the time I'll look into it, unfortunately i need to concentrate on other stuff atm | 13:04 |
| rvba | roaksoax: first step would be to add the default I think. | 13:04 |
| rvba | roaksoax: you've done most of the work for that already I think. | 13:04 |
| roaksoax | rvba: yeah the default stuff is just a couple lines, i'll separate the patches and see to it | 13:05 |
| rvba | roaksoax: cool. | 13:05 |
| === cheez0r_ is now known as cheez0r | ||
| smoser | i will send proposal to list. | 13:13 |
| === flacoste changed the topic of #maas to: 4 weeks until Final Freeze | Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ | ||
| bigjools | why am I still up | 13:13 |
| jelmer | it's a mystery | 13:16 |
| smoser | roaksoax, ok. so interesting problem here. | 15:32 |
| smoser | i just booted a ephemeral image in a kvm instance. | 15:32 |
| smoser | instance had (i think 256 M of memory) or some small ish number. | 15:33 |
| smoser | apt-get update runs | 15:33 |
| smoser | apt-get update writes 115M to /var/lib/apt/lists | 15:33 |
| smoser | which in ephemeral instance consumes 115M of memory | 15:33 |
| smoser | ie, i see some real potential issues here. | 15:33 |
| smoser | Daviey, you might find that interesting also. | 15:35 |
| smoser | i suspect that 2G memory is the minimum "real server" size | 15:35 |
| smoser | but for test within vms, thats a bit annoying. | 15:36 |
| Daviey | smoser: hmm.. do you think we might need to back the overlayfs via networking ? | 15:40 |
| smoser | i dont know. we coudl back it via block device exposed over iscsi | 15:41 |
| Daviey | yeah | 15:43 |
| Daviey | not urgent for 12.10 IMO | 15:43 |
| Daviey | but next cycle, we might need to consider something smarter? | 15:44 |
| smoser | yeah | 15:45 |
| roaksoax | smoser: interesting | 16:03 |
| smoser | we can improve that speicifically fairly easily, by removing i386 from and64 arch | 16:04 |
| roaksoax | smoser: during commissioning, do we actually need anything from apt? | 16:04 |
| smoser | and removing deb-src lines | 16:04 |
| roaksoax | smoser: right, so the only reson why it is being run is for maas-enlist right? | 16:05 |
| roaksoax | apt* being run | 16:05 |
| smoser | well..sort of. | 16:05 |
| smoser | commissioning is intended to be a general purpose environment | 16:06 |
| smoser | so you'd expect it to work. | 16:06 |
| roaksoax | smoser: right, well we don't really need deb-src | 16:06 |
| === hazmat is now known as kapilt | ||
| roaksoax | allenap: still around? | 16:38 |
| allenap | roaksoax: Yes :) | 16:42 |
| roaksoax | allenap: so maybe yoy'll be able to help me | 16:42 |
| roaksoax | allenap: where is it that when you try to start a node, it sends the data to generate the preseed for a particular node? | 16:43 |
| roaksoax | allenap: or whats the entry point from the node and the generation of the tftp parameters it should use, such as arch, releaes, etc | 16:43 |
| jam | I'm trying to run 'make' but ipython.scypi.org seems to refuse all connections. | 16:44 |
| jam | Is there another option? | 16:44 |
| allenap | jam: Install ipython locally ought to solve it. Failing that, the tarball can be put in your buildout cache (I can send it to you). | 16:44 |
| allenap | (We kind of need a better solution for that.) | 16:45 |
| roaksoax | allenap: is that api.py? | 16:45 |
| jam | allenap: wasn't that the 'download-cache' discussion? | 16:45 |
| allenap | jam: Yes. | 16:45 |
| mgz | or ignoring it an installing from archive works if the version matches | 16:45 |
| allenap | Right, what mgz said; that's what I was fat-fistedly trying to say with "install ... locally" :) | 16:46 |
| jam | mgz: there is a strong debate that you should ignore system packages so that the build environment enforces strict dependencies. | 16:46 |
| mgz | (I had that for nosetests who's blog(?!) buildout was failing to scrape on make)) | 16:46 |
| jam | allenap: 'apt-get install ipython; make' still fails | 16:46 |
| jam | still is trying to download ipython | 16:47 |
| jam | (on Precise) | 16:47 |
| allenap | jam: buildout will enforce strict dependencies because allow-picked-version is false, but if they match it'll use it. | 16:47 |
| allenap | Oh buildout, how you ***FEFEGEg4%$^$ me. | 16:47 |
| jam | allenap: how do I know what version buildout is wanting? | 16:48 |
| allenap | jam: versions.cfg ought to say. | 16:48 |
| jam | allenap: ah, buildout wants 0.12, and I have 0.12.1 ... :( | 16:48 |
| jam | hacking that makes it get further at least | 16:49 |
| allenap | jam: http://ubuntuone.com/6HXrvwiGY2qRqKyezMmVYZ for 0.12 | 16:49 |
| jam | if only I could easily copy that to another machine :). But I'll make it work | 16:50 |
| allenap | For the egg. Put it in ~/.buildout/cache/dist | 16:50 |
| jam | it still is getting selenium, and, and | 16:50 |
| jam | allenap: I don't have a ~/.buildout | 16:50 |
| jam | is it reasonably safe to just create it? | 16:50 |
| allenap | jam: Ah, that's worth having. See HACKING.txt about it. | 16:50 |
| jam | (I wasn't following the discussion that closely.) | 16:51 |
| roaksoax | smoser: so I still see no easy way to get the release stuff | 16:57 |
| roaksoax | smoser: rather tahn continue to do what we were doing | 16:57 |
| roaksoax | because when the preseed is presented or the parameters for tftp boot, the only thing we really send is the Node | 16:58 |
| allenap | roaksoax: So, got distracted. | 17:00 |
| allenap | roaksoax: pxeconfig() in maasserver.api creates KernelParameters object, which has various boot-related things in it. | 17:00 |
| allenap | It doesn't generate the preseed though. | 17:00 |
| roaksoax | allenap: so the problme is this | 17:00 |
| roaksoax | allenap: hold on (meeting :) ) | 17:01 |
| roaksoax | allenap: ok, so the issue is this: In order to add releases support, I added a new attribute to the Node as os_release. However, after discussing it with smoser , he mentioned that we should not have an attribute for the node | 17:03 |
| roaksoax | allenap: but rather we should simply specify the release we want the node to boot into | 17:03 |
| roaksoax | allenap: and that's it | 17:04 |
| roaksoax | allenap: so the priblem now becomes, how can we dynamically have that value (the release to use), if we only pass objects ot preseed.py | 17:04 |
| roaksoax | allenap: we can't pass a globally set value right? since we need it for a particular node | 17:04 |
| roaksoax | allenap: the only easy solution i see is simply saying "the release for X node on deployment will be Y" but I don't see how to pass that Y if we are passing objects | 17:05 |
| allenap | roaksoax: I think we need to store this on the node, as you've done. | 17:05 |
| roaksoax | allenap: yeah that's the only solutio I see | 17:06 |
| roaksoax | allenap: I just needed another opinion | 17:06 |
| allenap | roaksoax: smoser's right in that it's only used during the first boot after a machine has been allocated, and that once the machine has correctly installed and pinged maas to say "stop netbooting me" it's no longer relevant, but we need to keep it somewhere until that ping is done. | 17:08 |
| smoser | allenap, shouldn't we be able to add a getter to the object? | 17:09 |
| smoser | that does something more complex than just look at that attribute of the node? | 17:09 |
| allenap | But there isn't yet a better place to put it. We will at some point model "allocations", at which point I guess we can move it to there. | 17:09 |
| smoser | it just really isnt an attribute of a node | 17:09 |
| smoser | operating systems != hardware | 17:09 |
| smoser | (unless you come from apple) | 17:10 |
| allenap | smoser: Node is overloaded so I'm not sure where else to store the choice of OS right now. We need to remodel. Perhaps something like: board -< node >- allocation, or something like that. | 17:12 |
| smoser | board ? | 17:12 |
| smoser | so. | 17:12 |
| smoser | the one thing i really care about here. | 17:12 |
| smoser | is the external interface | 17:12 |
| smoser | 'start' simply needs to take "release" | 17:13 |
| allenap | smoser: For reconfigurable hardware... so "future". | 17:13 |
| smoser | and having the user have to change a node attribute in order to do that seems completely broken | 17:13 |
| roaksoax | smoser: ok so, the problme is thta basically, in ordfer to create the tftp/pxe stuff we only use the node attributes, right? | 17:14 |
| allenap | smoser: It probably ought to be an argument to the "acquire" call. | 17:14 |
| roaksoax | smoser: so we need a way to tell "NodeXYZ will deploy with ABC release" | 17:14 |
| allenap | "start" and "stop" are just power related; they don't imply OS installation. | 17:14 |
| roaksoax | smoser: this means that each node object needs to know what release is related when it gets started | 17:15 |
| roaksoax | smoser: so it is either have database table/class that matches Node <-> Instance release version, or keep it as an attributed, but treat it as an instance | 17:15 |
| roaksoax | smoser: I don't know if I explained myself clearly :) | 17:15 |
| smoser | allenap, hm.. | 17:15 |
| smoser | i thought start becuase i thoguht userdata was attachedk to start | 17:15 |
| smoser | but i could have been wrong | 17:16 |
| allenap | User will call MAAS and say "I want an amd64 node running Quantal" (== the acquire call), MAAS will store the user and release on the Node record, turn netbooting on, mark it as allocated, and reboot the node. | 17:16 |
| smoser | what is the link for do con the api? | 17:16 |
| allenap | Argh, you're right, start() does take the user data. | 17:16 |
| allenap | acquire doesn't do the boot; you need to acquire and start in sequence. | 17:17 |
| roaksoax | whilke start_nodes() does take the user data, it sets that data as to the node right? | 17:18 |
| roaksoax | NodeUserData.objects.set_user_data(node, user_data) | 17:18 |
| roaksoax | but that's for the metadata server | 17:19 |
| allenap | roaksoax: Yes, essentially. There are only ever zero or one NodeUserData rows for a node. | 17:19 |
| allenap | I have to go now, but I'll be back in about 2h. | 17:19 |
| roaksoax | allenap: alright | 17:19 |
| roaksoax | thanks! | 17:19 |
| === matsubara is now known as matsubara-lunch | ||
| smoser | ugh. | 17:21 |
| smoser | so. the big thing to me is that whatever takes user-data should take release. | 17:22 |
| smoser | from the api perspective. | 17:22 |
| roaksoax | smoser: right, but that user-data is for meta-data server, not for the preseed/tftp boot generation stuff | 17:23 |
| roaksoax | smoser: the preseed/tftp takes a Node object | 17:23 |
| smoser | but thats just garbage implementation | 17:24 |
| smoser | just implementation | 17:24 |
| smoser | the consumer should not think of those things as separate. | 17:25 |
| roaksoax | smoser: right, so the user-data is set as Data for the node right? but that's meta-data server stuff. Unless you want to do the same for the preseed... | 17:26 |
| smoser | well the user doesn's specify preseed. | 17:30 |
| smoser | so i dont really care | 17:30 |
| smoser | but user-data and release need to be exposed via api | 17:30 |
| roaksoax | smoser: right, but the thing is "how to you match a node object with a piece of data (release)" | 17:31 |
| roaksoax | smoser: so that when the preseed/tftp url generation happens, it uses the correct data for *that* node | 17:31 |
| roaksoax | smoser: atm, it seems much easier to keep a node attribute for release and when you do "give me a node and install X on it" then it should just simply get a node and set the os_release attribute to the release you are requesting | 17:35 |
| smoser | but that is just completely broken from the api perspective. | 17:35 |
| roaksoax | smoser: i agree might not be the best approach, but it is a similar approach to what cobbler did | 17:36 |
| roaksoax | smoser: in cobbler you simply told it "this system inherits from profile X, and profile X is Y release" | 17:37 |
| smoser | i dont think thats going to win you any fans. | 17:38 |
| smoser | saying "cobbler did it that way" as a response to "thats not the right way" | 17:38 |
| roaksoax | smoser: I'm not arguing that because cobbler did it, we should do it that way. I'm arguing that we need a way to add handle this fast as upstream is busy with other stuff, I need to get other stuff done, and i'm sure you also need to | 17:39 |
| roaksoax | smoser: so, i'm saying can we provide a more appropriate fix with the time constraints that we face? | 17:39 |
| roaksoax | smoser: since you said you requested an "instance" type of handling for MAAS, but they were not going to make it happen for 12.10 | 17:39 |
| roaksoax | smoser: so the release stuff would be part of that "instace" approach within MAAS, right? | 17:40 |
| roaksoax | smoser: on fwiw, in cobbler you could say "deploy this machine with X release, or deploy this machine with Y release using its api (using koan)" | 17:41 |
| roaksoax | smoser: but anyways, I'm maybe to dumb to see a fix for it (at the moment) that doesn't involve having to store an attribute for a Node object | 17:42 |
| smoser | suck. | 17:43 |
| smoser | then we could ammend my suggestion by having an "instance release" that default ed to "node release' that defaulted to "global release" | 17:43 |
| smoser | and instance release would be set to NULL on "return/destroy" (whatever that api call is called) | 17:44 |
| roaksoax | smoser: as a node attribute? | 17:44 |
| smoser | well, my proposal was that those things were node attributes, yes. | 17:44 |
| smoser | (the proposal to the list) | 17:44 |
| smoser | i suggested that we would have a node attribute for "release" | 17:44 |
| smoser | that would default to the global release. | 17:45 |
| roaksoax | smoser: ok hold on, I'm confused now | 17:45 |
| roaksoax | smoser: the support that was hacked for that was basically this: Have a os_release attribute for a Node (similarly to architecture, power type). Every time we enlist a node, the os_release would be set to a globally default release | 17:46 |
| roaksoax | smoser: so what I was suggesting now was that if we simply specify a release different than default, it would set node.os_release as the new requested release, and deploy with that | 17:47 |
| roaksoax | smoser: and on a release, that could be set back to default | 17:47 |
| roaksoax | smoser: is that what you were looking for? | 17:47 |
| smoser | well, maybe for now that is sufficient. | 17:49 |
| roaksoax | smoser: but if that's what you were proposing, then the support I added does that almost the same. The only difference is that I was setting a default release for both, commissioning/enlistment and deployment | 17:51 |
| roaksoax | smoser: which can obviously be easily changed | 17:51 |
| smoser | well, i think you need to differenciate between commissioning/enlistment and install | 17:53 |
| smoser | so keep that. | 17:53 |
| roaksoax | smoser: right, that's simple to do | 17:53 |
| roaksoax | smoser: what I was trying to look a solution for is the attribute (os_release) for the node | 17:54 |
| roaksoax | smoser: which I thought you didn't want at all | 17:54 |
| smoser | outside of another table ("instance"), which i think is the correct long term path, i dont think there is one. | 17:54 |
| smoser | so what i was suggesting is largely what you are doing | 17:54 |
| smoser | except for the fact that i do not want specifying "release" in start to change the node. | 17:54 |
| smoser | which you're accomplishing by setting it back to 'default' on release. | 17:55 |
| smoser | which ... is somewhat lossy | 17:55 |
| smoser | but not that bad. | 17:55 |
| smoser | ie, if it the default "install" for that node had been set to 12.10 for good reason | 17:55 |
| smoser | and i specify 13.04 for one install | 17:55 |
| smoser | and then on release maas puts it back to 12.04 (the global default) | 17:55 |
| smoser | we've lost data. | 17:55 |
| smoser | the only way i can see to work around that is to not set the default for the node, but on start to set a "install_release" | 17:56 |
| smoser | and unset *that* on release. | 17:56 |
| roaksoax | smoser: right | 17:57 |
| roaksoax | smoser: but that's the thing, on start(), calls start_nodes(), which could take a release and set node.os_release = "whatever release passed" | 17:59 |
| roaksoax | smoser: http://paste.ubuntu.com/1199137/ or similar | 18:01 |
| roaksoax | smoser:so then the "instance" view of a node would be simple a NodeInstace that inherits from Node? which is able to hanlde user-data? | 18:28 |
| smoser | "instance" view? | 18:30 |
| smoser | roaksoax, | 18:30 |
| roaksoax | smoser: i mean, what you refer as treating nodes deployments as intances | 18:31 |
| roaksoax | smoser: i mean, just wondering how did you envisoned this? | 18:31 |
| smoser | well, i basically consider a "install -> release" cycle an "instance" | 18:35 |
| smoser | and an "instance" would have user-data specific to it and a user that owned the instance | 18:36 |
| smoser | and a release that was installed | 18:36 |
| smoser | and a start and end date | 18:36 |
| roaksoax | smoser: ok, so how do you start a node thorugh the API? | 18:41 |
| smoser | look at juju i think. | 18:42 |
| roaksoax | smoser: I think I just spotted another issue | 18:49 |
| roaksoax | smoser: not that it matters much, yet but if the node has not being deployed yet, obtaining the preseed would display the preseed for the default release | 18:50 |
| roaksoax | smoser: unless we specify a release specifically i guess | 18:51 |
| roaksoax | smoser: it will indeed require lot of refactoring I believe | 18:51 |
| roaksoax | i guess we will leave that for upstream :) | 18:52 |
| smoser | yeah, i dont think thats an issue really. | 18:52 |
| roaksoax | smoser: ok, so another problme is this | 19:14 |
| roaksoax | smoser: when a node makes a PXE request, the request grabs the MAC address of the node making the request | 19:14 |
| roaksoax | smoser: and by using the mac address it obtains the node | 19:15 |
| roaksoax | smoser: and with that node it generates the kernel command line | 19:15 |
| roaksoax | smoser: so the release *has* to be stored somewhere for that particular node | 19:16 |
| roaksoax | smoser: because the way this happes is by making a post request | 19:16 |
| roaksoax | smoser: unless, we could obtain the relese from that post request somehow | 19:16 |
| roaksoax | smoser: oh no way, we can't, cause the request is being made by a node itself after you tell the node to start | 19:17 |
| smoser | roaksoax, you've confused me. | 19:31 |
| smoser | roaksoax, i dont see a problem in the above. | 19:32 |
| smoser | if there were an "instances" table, there would be a way to get the "current" instance htat occupied a node. | 19:32 |
| smoser | so essentially, a node would have a os release but only because of hte instance currently occupying it. | 19:32 |
| smoser | which woudl hvae been created on the start | 19:32 |
| roaksoax | smoser: right, but look at src/maasserver/api.py:pxeconfig | 19:33 |
| smoser | roaksoax, right. thats fine. | 19:35 |
| smoser | i'm missing something | 19:35 |
| smoser | i'm sorry | 19:35 |
| roaksoax | smoser: so it gets the MAC address of the machine that has made the request, it searches for a node within MAAS. If found, it uses its attributes to create the params to be granted by the pxe file | 19:36 |
| smoser | right. | 19:36 |
| smoser | so yes, i agree. that means that given a node you have to be able to come up with the correct kernel/initramdisk/state | 19:37 |
| smoser | but thats not bad. | 19:37 |
| roaksoax | smoser: righjt, so there, there's two options, keep the os_release attribute of a node | 19:37 |
| roaksoax | smoser: or, once a node is found based on its mac, then we would need to map the node to somewhere else to obtain the release, right? | 19:38 |
| roaksoax | smoser: so if we have user data for the node, then first we need the node, then we need that node's user-data and then we need the release | 19:38 |
| smoser | right. | 19:39 |
| smoser | that is fine. | 19:39 |
| smoser | given a node, there will only ever be one "instance" at a given point in time. | 19:39 |
| smoser | and that instance would have release and user-data | 19:39 |
| roaksoax | smoser: right, so the way I was fixing that is: release = node.get_os_release() | 19:40 |
| smoser | so assuming mac is unique (which we have assumed), at a given point in time a MAC can map to user-data or os-release thorugh node | 19:40 |
| roaksoax | smoser: so, do you think that the Node class should have an attribute (which might be called instance_data, that contains the release) | 19:41 |
| roaksoax | so when you call: node.get_os_release(), which we can rename to: node.get_install_release(), it will search for the release in that instance_data variable and return it, if not found, simply return the default? | 19:42 |
| smoser | no. | 19:42 |
| smoser | roaksoax, for your work i tihnk i'd just hack the way you are | 19:42 |
| smoser | the longer term fix is another table "instances" where an instance maps N:1 to nodes. | 19:43 |
| smoser | and somehow you can look up "current" instance for a node. | 19:43 |
| smoser | and that instance has "os_release" and such | 19:43 |
| smoser | but your solution for now is ifne i think. | 19:43 |
| smoser | so dont get more complex than you need. | 19:43 |
| roaksoax | smoser: right, that's my question. Where does that "instances" table live? | 19:43 |
| smoser | it seems we are knowingly shortcutting | 19:43 |
| roaksoax | or should live | 19:43 |
| smoser | well its a object i think | 19:44 |
| roaksoax | smoser: an object that would be instanciated within a node, or separately? | 19:44 |
| smoser | separately i thikn. but i dont knwo tha ti understand thequestion. | 19:46 |
| smoser | it has to be separate though | 19:46 |
| roaksoax | smoser: ok, but, there should only be 1 instance for 1 node, hence a 1:1 relation, shouldn't it? BEcause 1 node can only have 1 instance at a time | 19:47 |
| smoser | but over history there are N | 19:47 |
| smoser | and you want to be able to look at historic ones | 19:47 |
| smoser | for accounting | 19:47 |
| roaksoax | smoser: are we looking to make an instance a database entry? | 19:48 |
| smoser | i would think so | 19:48 |
| smoser | but i'm not sure how such releations are normally modelled. | 19:48 |
| smoser | ie, how you would normally indicate "current" on something like that. | 19:48 |
| roaksoax | smoser: right. Yeah cause I thought we wouldn't care how many times has that node been deployed in what release or for what purpose | 19:49 |
| smoser | roaksoax, see that bug i opened. | 19:53 |
| smoser | you'd want to know that for accounting | 19:53 |
| smoser | you want to know that bob uses 90% of your cpu time | 19:53 |
| smoser | or that only 8% of your cpu used run 10.04 | 19:53 |
| roaksoax | smoser: right | 19:54 |
| smoser | or that 68% of your total cpu time is unused | 19:54 |
| smoser | and you cant do that without history (or at least keeping the count at the moment of acquire and release) | 19:54 |
| smoser | but i think you just keep the whole records instead | 19:54 |
| roaksoax | right | 19:55 |
| === matsubara-lunch is now known as matsubara | ||
| === kapilt is now known as hazmat | ||
| roaksoax | smoser: stil around? | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!