jtvbigjools: you up for a quick chat about the way we'll register installed boot images?04:23
jtvBlast.  Test failures in trunk.04:43
jambigjools: I think having some time of a 3-4 person standup, separate from a 8-person standup is reasonable.08:09
bigjoolsjam: exactly what I was thinking :)08:09
bigjoolsjam: do you want to come in in about 10-15 mins then?08:27
Davieythe more the merrier, and distracting !08:27
bigjoolsDaviey: just the man08:27
Davieyoh dear08:28
bigjoolsDaviey: my upgrade to quantal has seriously fucked my installation08:28
Davieyany more detail?08:29
bigjools$ dpkg -l08:29
bigjoolsdpkg-query: error: parsing file '/var/lib/dpkg/status' near line 56897 package 'libao4:i386':08:29
bigjools mixed non-coinstallable and coinstallable package instances present08:29
bigjoolsand a crapload of broken dependencies :/08:30
Davieywow, that is quite spectacular08:30
bigjoolsthanks :)08:30
jambigjools: sounds good08:30
Davieybigjools: fancy raising a bug, and including all this output?08:30
bigjoolsjam: cool08:30
bigjoolsDaviey: yeah08:30
Davieybigjools: just raise it against 'Ubuntu'08:30
bigjoolsDaviey: ok, shall I assign you? :)08:31
Davieybigjools: I suspect it's one that cjwatson will be better suited :)08:31
Davieyi'm just a dumb mangler.08:31
bigjoolsjam, jelmer, mgz: https://plus.google.com/hangouts/_/c667fc896a4dfdbabcd78a47a4018ee6c2cb7341?authuser=0&hl=en-GB08:44
jambigjools: I don't think i have access rights to modify the Maas board, can you add the Story 3 lane?09:09
jamah, there it is, nm09:09
bigjoolsjam: you should have all the rights you need, let me know if you need more09:27
jamDaviey: you were asking about mongo auth. I have a summary of it, would you like it here or on Maas-devel?09:47
Davieyjam: mailing list might be more useful for historic and wider audience09:51
bigjoolso/ roaksoax11:48
roaksoaxo/ bigjools11:54
smoserroaksoax, rvba did you get a chance to read http://pad.daviey.com/server-maas-release-support ?12:47
smoserdo you have som time to talk about it?12:48
roaksoaxsmoser: yeah I skimmed through it12:48
roaksoaxsmoser: i, hoewver, think you should probably post your proposal on the ML12:48
roaksoaxsmoser: i'll drop my patches but I don't think whether there's time to get that into quantal12:49
smoserwell ,we  can do that. but we can surely have people tell me what they think is wrong first.12:49
roaksoaxsmoser: 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 yours12:50
rvbasmoser: I think your proposal makes sense.  Let's post it to the list to see what people think.12:50
rvbaThat problem was briefly mentioned during our standup call this morning.12:51
rvbaPeople 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
rvbaroaksoax: ^12:52
roaksoaxas I said, I give in12:52
roaksoaxi guess that now making sure that smoser's proposal or anhy other fix for the issue gets into quantal is a priority12:53
roaksoaxbut not having quantal support is a blocker for me, so my tasks will be blocked until ya'll have the support implemented12:53
roaksoaxsmoser: ^^12:53
smoserroaksoax, i dont understand "we should be able to select what node should have what release, I think we can support both approaches"12:54
smoserhow does my approach not do that?12:54
roaksoaxsmoser: your approach is telling the api to give you a node with a particular release12:54
smoserwell, no.12:54
smoseri think that is a requirement12:54
rvbaroaksoax: 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
smoserbut that is not related to this actually.12:54
smoserwe dont have an api entry point now for "give me a node"12:55
smoserwe only have "start" on a particular node12:55
smoserso, unaddressed is "just give me a node already!"12:55
roaksoaxsmoser: exactly, so that's what i mean. start a node an install XYZ release on it12:55
smoseri'm confused.12:56
smosermy approach has that.12:56
roaksoaxsmoser: yes12:56
roaksoaxsmoser: that's what I'm saying12:56
roaksoaxi'm talking about your approach12:56
roaksoaxsmoser: 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
roaksoaxsmoser: in your appraoch is not possible to do that because the way you are considering to do this is doing so through the API12:57
roaksoaxsmoser: 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 it12:57
roaksoaxsmoser: and that should be stored somewhere12:57
smoserwell it is stored somewhere.12:58
rvbaroaksoax: the usage of the WebUI to start a node was always considered a very special case primarily meant for testing.12:58
smoseron the node12:58
smoser"default_release" as i said.12:58
rvbaThe API story is the real one.12:58
roaksoaxrvba: right, but the usage is there12:58
roaksoaxrvba: it is out to the wild12:58
roaksoaxrvba: so you need to provide the same functionality in both interfaces12:58
roaksoaxsmoser: yes, defualt_release is very broad...12:58
rvbaI 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
roaksoaxrvba: i think by doing that you are removing functionality12:59
roaksoaxrvba: and another problem is make it place nicely with juju12:59
roaksoaxrvba: for 12.1012:59
rvbaExactly, but Juju uses the API.12:59
roaksoaxrvba: while the WebUI might be a simplified interface to interact with MAAS, I think it is essential to be able to support a release13:00
roaksoaxrvba: so when you start a node, you node that that node will use X release you want13:00
rvbaroaksoax: we can add this in the WebUI as well (dropdown menu next to the start button or something)13:01
rvbaLet's focus on the core functionality first, then the API, and only then the UI.13:01
roaksoaxrvba: ok, well the start button on the UI uses the API right?13:03
rvbaroaksoax: not directly.13:03
rvbaroaksoax: well, sorry, not at all.13:03
roaksoaxrvba: well then we would just simply need to figure out how to pass the release dynamically without relying on having it stored somewhere13:04
rvbaroaksoax: indeed.13:04
roaksoaxrvba: if I find the time I'll look into it, unfortunately i need to concentrate on other stuff atm13:04
rvbaroaksoax: first step would be to add the default I think.13:04
rvbaroaksoax: you've done most of the work for that already I think.13:04
roaksoaxrvba: yeah the default stuff is just a couple lines, i'll separate the patches and see to it13:05
rvbaroaksoax: cool.13:05
=== cheez0r_ is now known as cheez0r
smoseri 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/
bigjoolswhy am I still up13:13
jelmerit's a mystery13:16
smoserroaksoax, ok. so interesting problem here.15:32
smoseri just booted a ephemeral image in a kvm instance.15:32
smoserinstance had (i think 256 M of memory) or some small ish number.15:33
smoserapt-get update runs15:33
smoserapt-get update writes 115M to /var/lib/apt/lists15:33
smoserwhich in ephemeral instance consumes 115M of memory15:33
smoserie, i see some real potential issues here.15:33
smoserDaviey, you  might find that interesting also.15:35
smoseri suspect that 2G memory is the minimum "real server" size15:35
smoserbut for test within vms, thats a bit annoying.15:36
Davieysmoser: hmm.. do you think we might need to back the overlayfs via networking ?15:40
smoseri dont know. we coudl back it via block device exposed over iscsi15:41
Davieynot urgent for 12.10 IMO15:43
Davieybut next cycle, we might need to consider something smarter?15:44
roaksoaxsmoser: interesting16:03
smoserwe can improve that speicifically fairly easily, by removing i386 from and64 arch16:04
roaksoaxsmoser: during commissioning, do we actually need anything from apt?16:04
smoserand removing deb-src lines16:04
roaksoaxsmoser: right, so the only reson why it is being run is for maas-enlist right?16:05
roaksoaxapt* being run16:05
smoserwell..sort of.16:05
smosercommissioning is intended to be a general purpose environment16:06
smoserso you'd expect it to work.16:06
roaksoaxsmoser: right, well we don't really need deb-src16:06
=== hazmat is now known as kapilt
roaksoaxallenap: still around?16:38
allenaproaksoax: Yes :)16:42
roaksoaxallenap: so maybe yoy'll be able to help me16:42
roaksoaxallenap: 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
roaksoaxallenap: or whats the entry point from the node and the generation of the tftp parameters it should use, such as arch, releaes, etc16:43
jamI'm trying to run 'make' but ipython.scypi.org seems to refuse all connections.16:44
jamIs there another option?16:44
allenapjam: 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
roaksoaxallenap: is that api.py?16:45
jamallenap: wasn't that the 'download-cache' discussion?16:45
allenapjam: Yes.16:45
mgzor ignoring it an installing from archive works if the version matches16:45
allenapRight, what mgz said; that's what I was fat-fistedly trying to say with "install ... locally" :)16:46
jammgz: 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
jamallenap: 'apt-get install ipython; make' still fails16:46
jamstill is trying to download ipython16:47
jam(on Precise)16:47
allenapjam: buildout will enforce strict dependencies because allow-picked-version is false, but if they match it'll use it.16:47
allenapOh buildout, how you ***FEFEGEg4%$^$ me.16:47
jamallenap: how do I know what version buildout is wanting?16:48
allenapjam: versions.cfg ought to say.16:48
jamallenap: ah, buildout wants 0.12, and I have 0.12.1 ... :(16:48
jamhacking that makes it get  further at least16:49
allenapjam: http://ubuntuone.com/6HXrvwiGY2qRqKyezMmVYZ for 0.1216:49
jamif only I could easily copy that to another machine :). But I'll make it work16:50
allenapFor the egg. Put it in ~/.buildout/cache/dist16:50
jamit still is getting selenium, and, and16:50
jamallenap: I don't have a ~/.buildout16:50
jamis it reasonably safe to just create it?16:50
allenapjam: Ah, that's worth having. See HACKING.txt about it.16:50
jam(I wasn't following the discussion that closely.)16:51
roaksoaxsmoser: so I still see no easy way to get the release stuff16:57
roaksoaxsmoser: rather tahn continue to do what we were doing16:57
roaksoaxbecause when the preseed is presented or the parameters for tftp boot, the only thing we really send is the Node16:58
allenaproaksoax: So, got distracted.17:00
allenaproaksoax: pxeconfig() in maasserver.api creates  KernelParameters object, which has various boot-related things in it.17:00
allenapIt doesn't generate the preseed though.17:00
roaksoaxallenap: so the problme is this17:00
roaksoaxallenap: hold on (meeting :) )17:01
roaksoaxallenap: 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 node17:03
roaksoaxallenap: but rather we should simply specify the release we want the node to boot into17:03
roaksoaxallenap: and that's it17:04
roaksoaxallenap: so the priblem now becomes, how can we dynamically have that value (the release to use), if we only pass objects ot preseed.py17:04
roaksoaxallenap: we can't pass a globally set value right? since we need it for a particular node17:04
roaksoaxallenap: 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 objects17:05
allenaproaksoax: I think we need to store this on the node, as you've done.17:05
roaksoaxallenap: yeah that's the only solutio I see17:06
roaksoaxallenap: I just needed another opinion17:06
allenaproaksoax: 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
smoserallenap, shouldn't we be able to add a getter to the object?17:09
smoserthat does something more complex than just look at that attribute of the node?17:09
allenapBut 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
smoserit just really isnt an attribute of a node17:09
smoseroperating systems != hardware17:09
smoser(unless you come from apple)17:10
allenapsmoser: 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
smoserboard ?17:12
smoserthe one thing i really care about here.17:12
smoseris the external interface17:12
smoser'start' simply needs to take "release"17:13
allenapsmoser: For reconfigurable hardware... so "future".17:13
smoserand having the user have to change a node attribute in order to do that seems completely broken17:13
roaksoaxsmoser: ok so, the problme is thta basically, in ordfer to create the tftp/pxe stuff we only use the node attributes, right?17:14
allenapsmoser: It probably ought to be an argument to the "acquire" call.17:14
roaksoaxsmoser: 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
roaksoaxsmoser: this means that each node object needs to know what release is related when it gets started17:15
roaksoaxsmoser: 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 instance17:15
roaksoaxsmoser: I don't know if I explained myself clearly :)17:15
smoserallenap, hm..17:15
smoseri thought start becuase i thoguht userdata was attachedk to start17:15
smoserbut i could have been wrong17:16
allenapUser 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
smoserwhat is the link for do con the api?17:16
allenapArgh, you're right, start() does take the user data.17:16
allenapacquire doesn't do the boot; you need to acquire and start in sequence.17:17
roaksoaxwhilke start_nodes() does take the user data, it sets that data as to the node right?17:18
roaksoaxNodeUserData.objects.set_user_data(node, user_data)17:18
roaksoaxbut that's for the metadata server17:19
allenaproaksoax: Yes, essentially. There are only ever zero or one NodeUserData rows for a node.17:19
allenapI have to go now, but I'll be back in about 2h.17:19
roaksoaxallenap: alright17:19
=== matsubara is now known as matsubara-lunch
smoserso. the big thing to me is that whatever takes user-data should take release.17:22
smoserfrom the api perspective.17:22
roaksoaxsmoser: right, but that user-data is for meta-data server, not for the preseed/tftp boot generation stuff17:23
roaksoaxsmoser: the preseed/tftp takes a Node object17:23
smoserbut thats just garbage implementation17:24
smoserjust implementation17:24
smoserthe consumer should not think of those things as separate.17:25
roaksoaxsmoser: 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
smoserwell the user doesn's specify preseed.17:30
smoserso i dont really care17:30
smoserbut user-data and release need to be exposed via api17:30
roaksoaxsmoser: right, but the thing is "how to you match a node object with a piece of data (release)"17:31
roaksoaxsmoser: so that when the preseed/tftp url generation happens, it uses the correct data for  *that* node17:31
roaksoaxsmoser: 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 requesting17:35
smoserbut that is just completely broken from the api perspective.17:35
roaksoaxsmoser: i agree might not be the best approach, but it is a similar approach to what cobbler did17:36
roaksoaxsmoser: in cobbler you simply told it "this system inherits from profile X, and profile X is Y release"17:37
smoseri dont think thats going to win you any fans.17:38
smosersaying "cobbler did it that way" as a response to "thats not the right way"17:38
roaksoaxsmoser: 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 to17:39
roaksoaxsmoser: so, i'm saying can we provide a more appropriate fix with the time constraints that we face?17:39
roaksoaxsmoser: since you said you requested an "instance" type of handling for MAAS, but they were not going to make it happen for 12.1017:39
roaksoaxsmoser: so the release stuff would be part of that "instace" approach within MAAS, right?17:40
roaksoaxsmoser: 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
roaksoaxsmoser: 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 object17:42
smoserthen we could ammend  my suggestion by having an "instance release" that default ed to "node release' that defaulted to "global release"17:43
smoserand instance release would be set to NULL on "return/destroy" (whatever that api call is called)17:44
roaksoaxsmoser: as a node attribute?17:44
smoserwell, my proposal was that those things were node attributes, yes.17:44
smoser(the proposal to the list)17:44
smoseri suggested that we would have a node attribute for "release"17:44
smoserthat would default to the global release.17:45
roaksoaxsmoser: ok hold on, I'm confused now17:45
roaksoaxsmoser: 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 release17:46
roaksoaxsmoser: 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 that17:47
roaksoaxsmoser: and on a release, that could be set back to default17:47
roaksoaxsmoser: is that what you were looking for?17:47
smoserwell, maybe for now that is sufficient.17:49
roaksoaxsmoser: 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 deployment17:51
roaksoaxsmoser: which can obviously be easily changed17:51
smoserwell, i think you need to differenciate between commissioning/enlistment and install17:53
smoserso keep that.17:53
roaksoaxsmoser: right, that's simple to do17:53
roaksoaxsmoser: what I was trying to look a solution for is the attribute (os_release) for the node17:54
roaksoaxsmoser: which I thought you didn't want at all17:54
smoseroutside of another table ("instance"), which i think is the correct long term path, i dont think there is one.17:54
smoserso what i was suggesting is largely what you are doing17:54
smoserexcept for the fact that i do not want specifying "release" in start to change the node.17:54
smoserwhich you're accomplishing by setting it back to 'default' on release.17:55
smoserwhich ... is somewhat lossy17:55
smoserbut not that bad.17:55
smoserie, if it the default "install" for that node had been set to 12.10 for good reason17:55
smoserand i specify 13.04 for one install17:55
smoserand then on release maas puts it back to 12.04 (the global default)17:55
smoserwe've lost data.17:55
smoserthe 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
smoserand unset *that* on release.17:56
roaksoaxsmoser: right17:57
roaksoaxsmoser: 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
roaksoaxsmoser: http://paste.ubuntu.com/1199137/ or similar18:01
roaksoaxsmoser: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
roaksoaxsmoser: i mean, what you refer as treating nodes deployments as intances18:31
roaksoaxsmoser: i mean, just wondering how did you envisoned this?18:31
smoserwell, i basically consider a "install -> release" cycle an "instance"18:35
smoserand an "instance" would have user-data specific to it and a user that owned the instance18:36
smoserand a release that was installed18:36
smoserand a start and end date18:36
roaksoaxsmoser: ok, so how do you start a node thorugh the API?18:41
smoserlook at juju i think.18:42
roaksoaxsmoser: I think I just spotted another issue18:49
roaksoaxsmoser: 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 release18:50
roaksoaxsmoser: unless we specify a release specifically i guess18:51
roaksoaxsmoser: it will indeed require lot of refactoring I believe18:51
roaksoaxi guess we will leave that for upstream :)18:52
smoseryeah, i dont think thats an issue really.18:52
roaksoaxsmoser: ok, so another problme is this19:14
roaksoaxsmoser: when a node makes a PXE request, the request grabs the MAC address of the node making the request19:14
roaksoaxsmoser: and by using the mac address it obtains the node19:15
roaksoaxsmoser: and with that node it generates the kernel command line19:15
roaksoaxsmoser: so the release *has* to be stored somewhere for that particular node19:16
roaksoaxsmoser: because the way this happes is by making a post request19:16
roaksoaxsmoser: unless, we could obtain the relese from that post request somehow19:16
roaksoaxsmoser: oh no way, we can't, cause the request is being made by a node itself after you tell the node to start19:17
smoserroaksoax, you've confused me.19:31
smoserroaksoax, i dont see a problem in the above.19:32
smoserif there were an "instances" table, there would be a way to get the "current" instance htat occupied a node.19:32
smoserso essentially, a node would have a os release but only because of hte instance currently occupying it.19:32
smoserwhich woudl hvae been created on the start19:32
roaksoaxsmoser: right, but look at src/maasserver/api.py:pxeconfig19:33
smoserroaksoax, right. thats fine.19:35
smoseri'm missing something19:35
smoseri'm sorry19:35
roaksoaxsmoser: 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 file19:36
smoserso yes, i agree. that means that given a node you have to be able to come up with the correct kernel/initramdisk/state19:37
smoserbut thats not bad.19:37
roaksoaxsmoser: righjt, so there, there's two options, keep the os_release attribute of a node19:37
roaksoaxsmoser: 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
roaksoaxsmoser: 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 release19:38
smoserthat is fine.19:39
smosergiven a node, there will only ever be one "instance" at a given point in time.19:39
smoserand that instance would have release and user-data19:39
roaksoaxsmoser: right, so the way I was fixing that is: release = node.get_os_release()19:40
smoserso 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 node19:40
roaksoaxsmoser: so, do you think that the Node class should have an attribute (which might be called instance_data, that contains the release)19:41
roaksoaxso 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
smoserroaksoax, for your work i tihnk i'd just hack the way you are19:42
smoserthe longer term fix is another table "instances" where an instance maps N:1 to nodes.19:43
smoserand somehow you can look up "current" instance for a node.19:43
smoserand that instance has "os_release" and such19:43
smoserbut your solution for now is ifne i think.19:43
smoserso dont get more complex than you need.19:43
roaksoaxsmoser: right, that's my question. Where does that "instances" table live?19:43
smoserit seems we are knowingly shortcutting19:43
roaksoaxor should live19:43
smoserwell its a object i think19:44
roaksoaxsmoser: an object that would be instanciated within a node, or separately?19:44
smoserseparately i thikn. but i dont knwo tha ti understand thequestion.19:46
smoserit has to be separate though19:46
roaksoaxsmoser: 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 time19:47
smoserbut over history there are N19:47
smoserand you want to be able to look at historic ones19:47
smoserfor accounting19:47
roaksoaxsmoser: are we looking to make an instance a database entry?19:48
smoseri would think so19:48
smoserbut i'm not sure how such releations are normally modelled.19:48
smoserie, how you would normally indicate "current" on something like that.19:48
roaksoaxsmoser: right. Yeah cause I thought we wouldn't care how many times has that node been deployed in what release or for what purpose19:49
smoserroaksoax, see that bug i opened.19:53
smoseryou'd want to know that for accounting19:53
smoseryou want to know that bob uses 90% of your cpu time19:53
smoseror that only 8% of your cpu used run 10.0419:53
roaksoaxsmoser: right19:54
smoseror that 68% of your total cpu time is unused19:54
smoserand you cant do that without history (or at least keeping the count at the moment of acquire and release)19:54
smoserbut i think you just keep the whole records instead19:54
=== matsubara-lunch is now known as matsubara
=== kapilt is now known as hazmat
roaksoaxsmoser: stil around?22:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!