| Daviey | jtv: hey, what is omshell? | 02:28 |
|---|---|---|
| jtv | Hi | 02:28 |
| jtv | It's a way of talking to dhcpd. | 02:28 |
| jtv | You can run it as an interactive shell to issue commands like "create a new host mapping." | 02:29 |
| jtv | (Which is the kind of thing we use if for, in fact) | 02:29 |
| Daviey | yeah, i should have just read the docstring :) | 02:29 |
| Daviey | sorry | 02:29 |
| Daviey | i was sort of hoping it was related to the cmd line interface :DDD | 02:30 |
| bigjools | Daviey: wtf are you doing up | 02:32 |
| Daviey | bigjools: nothing like doing code reviews in the middle of the night eh? | 02:33 |
| bigjools | Daviey: fun | 02:35 |
| lifeless | bigjools: do we need to talk today? | 02:43 |
| bigjools | lifeless: possibly - can we do it in 1.5h or so? | 02:44 |
| lifeless | anytime | 02:44 |
| bigjools | thanks | 02:44 |
| bigjools | assuming my 12.10 upgrade doesn't completely hose this machine | 02:46 |
| roaksoax | mornin | 11:50 |
| roaksoax | rvba: howdy! | 11:50 |
| rvba | roaksoax: hello | 12:24 |
| roaksoax | rvba: how's it going | 12:25 |
| roaksoax | rvba: so, i tested the stuff for the release thing | 12:25 |
| roaksoax | rvba: and it ended up not having anything | 12:26 |
| rvba | What do you mean? | 12:26 |
| roaksoax | rvba: on the database, as in, the database didn | 12:26 |
| roaksoax | rvba: on the database, as in, the database didn't store the default release | 12:26 |
| rvba | Well, did you create a default for the config value? | 12:26 |
| rvba | But the db will store the default only if it's changed. | 12:27 |
| roaksoax | rvba: right, but doesn't that mean, if for example, the CharField model params are, Choices and defaul | 12:27 |
| rvba | The default should be defined in src/maasserver/models/config.py:get_default_config | 12:27 |
| rvba | Ah, *that* default.. | 12:28 |
| rvba | Do you have a branch I could have a look at? | 12:28 |
| roaksoax | rvba: sure, http://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/976 | 12:29 |
| roaksoax | rvba: that;s what I did at first | 12:29 |
| roaksoax | now I'm gonna test this: | 12:29 |
| roaksoax | http://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/978 | 12:29 |
| rvba | roaksoax: I thought we wanted a None default. So that one could be able to change the default release used globally. | 12:31 |
| rvba | ? | 12:31 |
| roaksoax | rvba: we don't want None as deafult, we want a particular release as default | 12:31 |
| roaksoax | rvba: so basically s/UBUNTU_RELEASE.precise/UBUNTU_RELEASE.default | 12:32 |
| rvba | Sure, but in the db, this will mean that the value of os_release will be None when this should be left to the global default. | 12:32 |
| roaksoax | rvba: right, so lets imagine precise is the default, how to make sure it gets stored in the DB? | 12:32 |
| roaksoax | becuase the documentation tells me that choices=XYZ default=XYZ.one | 12:33 |
| roaksoax | stores XYZ.one if none has being given | 12:33 |
| roaksoax | right? | 12:33 |
| rvba | What you propose will mean that the default is something decided by the value of UBUNTU_RELEASE.default. My idea was that the default should be something that a user could change. | 12:33 |
| rvba | But I guess we can iterate on that. | 12:33 |
| roaksoax | rvba: right, UBUNTU_RELEASE.default will be ultimately be chosen by the user, but we still need a default regardless of the fact that the user can chose it | 12:34 |
| roaksoax | rvba: we cannot go without release if the user does not choose a default | 12:34 |
| rvba | roaksoax: hence the default value in src/maasserver/models/config.py:get_default_config | 12:34 |
| roaksoax | so UBUNTU_RELEASE.default can be obtained from a config, but if it is not given it should default to the stable release | 12:35 |
| rvba | roaksoax: so, the default=… is used when a new object is created. | 12:36 |
| roaksoax | rvba: =right, so when enlisted, the machine should end up with os_release=Precise (the default) | 12:37 |
| roaksoax | rvba: so this is what happens, with the branch above, we enlist a machine | 12:38 |
| roaksoax | the machine enlists successfully | 12:38 |
| rvba | roaksoax: I thought the os_release field should contain the name of the release used for the next install. Not the current release. | 12:38 |
| rvba | Maybe I misunderstood what you were trying to do. | 12:39 |
| roaksoax | rvba: os_release should contain the release it will use for the install, but if none is given it should default. In this case, it defaults to precise | 12:39 |
| roaksoax | rvba: that's the only stable release at the moment | 12:39 |
| rvba | Ok, so I got it right. | 12:39 |
| roaksoax | rvba: for enlistment/commissioning, there's no ephemeral images other than precise | 12:39 |
| roaksoax | rvba: so this is the problem with the above branch | 12:41 |
| roaksoax | rvba: 1. the machine enlists. 2. machine gets stored in DB *with* os_release *None*. 3. On commissioning, it fails for not having set release | 12:41 |
| rvba | roaksoax: do you have a failing test that could illustrate what the problem is? | 12:41 |
| roaksoax | rvba: a software test, no not really. Basically the problme is that with the branch above the os_release value in the DB is None instead of the default (precise) | 12:43 |
| rvba | roaksoax: ok, I understand. Let me see what I can do. | 12:43 |
| roaksoax | rvba: because as far as I understand, the DB should have stored the default value if it has not been specied due to the fact that if no value is specified, then "we store the defualt" | 12:44 |
| roaksoax | rvba: the other thing would be in the API verify that if no release has been sent during enlistment, set the value? | 12:44 |
| rvba | roaksoax: indeed, there is something wrong here. But like I said, I think we should keep the behaviour of storing None if no specific release has been set, and then not use node.os_release directly but a small method get_os_release. | 12:45 |
| rvba | That method will use the default if the value of node.os_release is None. | 12:45 |
| rvba | What's the benefit from doing this over storing the default directly you might ask… | 12:46 |
| rvba | Well, if will let use have a globally defined default under the control of the user. | 12:46 |
| roaksoax | rvba: could you exemplify | 12:49 |
| rvba | roaksoax: sure: | 12:50 |
| rvba | Say you have 100 nodes. | 12:50 |
| rvba | None of which need a specific release so you decide to go with the default. | 12:50 |
| rvba | Then, later, a new release comes out an you want your node to use that release. | 12:50 |
| rvba | If, during the first registration of the node, each of them had the release stored onto them, you'll need to change each and everyone of them to 'upgrade' to a new release. | 12:51 |
| rvba | If, instead, node.get_os_release() does something like: | 12:51 |
| rvba | If node.os_release is None: | 12:52 |
| rvba | return globally_configured_release | 12:52 |
| rvba | else: | 12:52 |
| rvba | return node.os_release | 12:52 |
| rvba | Then all you need to do is change the global setting 'globally_configured_release'. | 12:52 |
| rvba | Does that make sense? | 12:52 |
| roaksoax | rvba: right | 12:59 |
| roaksoax | rvba: so, that would actually be needed on the preseed side of things and nothing to be changed on the forms and model | 12:59 |
| rvba | roaksoax: that would look like this: http://paste.ubuntu.com/1196615/ | 13:00 |
| rvba | roaksoax: err http://paste.ubuntu.com/1196620/ | 13:00 |
| roaksoax | rvba: is the print(UBUNTU_RELEASE_CHOICES) necessary? | 13:01 |
| rvba | roaksoax: no, that was for my own benefit :) | 13:01 |
| roaksoax | rvba: hehe ok cool | 13:01 |
| roaksoax | rvba: I'll give it a test | 13:01 |
| roaksoax | thanks for the input and patch | 13:01 |
| rvba | np | 13:02 |
| rvba | roaksoax: the default is taken into account correctly btw, http://paste.ubuntu.com/1196624/ | 13:04 |
| rvba | roaksoax: also, I understand you're not there yet but please put the code used to initialize the release names into methods. This way it will be much more easy to test. | 13:07 |
| roaksoax | rvba: alright | 13:07 |
| roaksoax | rvba: i'll run it with you before proposing it, either way, there's gonna be lots of tests that will need to get fixed | 13:08 |
| rvba | roaksoax: right. | 13:08 |
| rvba | roaksoax: I'll give you a hand (with tests and stuff) when you'll be satisfied with the behaviour. | 13:09 |
| mgz | the lshw json output is rather verbose... <http://pastebin.ubuntu.com/1196630/> | 13:09 |
| roaksoax | rvba: cool thanks | 13:10 |
| roaksoax | rvba: thoughts? http://paste.ubuntu.com/1196743/ | 14:29 |
| rvba | roaksoax: in api.py, line 1144 and above, I see that node is set to None if macaddress is None… | 14:32 |
| roaksoax | rvba: yeah just figured it too :) | 14:32 |
| rvba | roaksoax: looks like you need to provide a default for the os_release in that case as it cannot be derived from the node. | 14:33 |
| * roaksoax going blind | 14:34 | |
| roaksoax | rvba: i think it doesn't really make sense to show "Default Release" on the WebUI | 14:57 |
| roaksoax | so I'll remove that | 14:57 |
| rvba | roaksoax: what do you want to put instead? | 14:57 |
| roaksoax | rvba: nothing | 14:57 |
| rvba | roaksoax: as in… the empty string? | 14:58 |
| rvba | Or you want to drop that option completely…? | 14:58 |
| roaksoax | rvba: no, just from the UI | 14:58 |
| roaksoax | rvba: from the combobox | 14:58 |
| roaksoax | rvba: it will remain a UBUNTU_RELEASE.default but will not be in UBUNTU_RELEASE_CHOICES | 14:59 |
| rvba | roaksoax: I don't really understand… we want the user be able to say that the node should use the globally configured release don't you think? | 14:59 |
| roaksoax | rvba: yeah, it does use that | 14:59 |
| roaksoax | rvba: it is just not a choice on the WebUI | 14:59 |
| roaksoax | rvba: remove this: | 15:00 |
| roaksoax | + else: | 15:00 |
| roaksoax | + UBUNTU_RELEASE_CHOICES += ((UBUNTU_RELEASE.default, 'Default release'),) | 15:00 |
| rvba | roaksoax: so a user won't be able to say that a node should use the globally defined default. | 15:00 |
| rvba | He will be forced to specify a particular release. | 15:00 |
| roaksoax | rvba: nope | 15:00 |
| roaksoax | rvba: there will always be a default | 15:01 |
| rvba | This sort of makes the whole idea of having a globally configurable default pointless. | 15:01 |
| roaksoax | rvba: it doesn | 15:01 |
| roaksoax | rvba: using a globally configured one differs from what the WebUI displays | 15:01 |
| roaksoax | rvba: UBUNTU_RELEASE_CHOICES is only to list what choices are on the WEbUI | 15:01 |
| roaksoax | rvba: but the default will always be one of the CHOICES | 15:01 |
| roaksoax | rvba: so UBUNTU_RELEASE.precise, UBUNTU_RELEASE.quantal, UBUNTU_RELEASE.defaul, but the WebUI will only display "(precise,Uuntu Preicse), (quantal,Ubuntu Quantal)" | 15:02 |
| rvba | I understand the consequences :) | 15:02 |
| rvba | But I don't understand the motivation behind that change tbh. | 15:02 |
| roaksoax | rvba: so in this case, .default = precise, so when it comes to the choice, it will chose .precise | 15:03 |
| roaksoax | rvba: the reason to the change is that the release should be selected by default, but that, instead of showing "Default Release", it should show the actual default that has been selected | 15:03 |
| rvba | If your concern is that "Default release" is not explicit enough we can fix that properly. | 15:03 |
| roaksoax | rvba: no it is not about being explicit, it is just simply what you present to the user | 15:04 |
| rvba | Because the value 'Default release' is different from 'precise' or 'quantal' | 15:04 |
| roaksoax | rvba: there's no need to present "Default Release" when you already know that the default relase is either "Ubuntu PRecise" or "Ubuntu Quantal" | 15:04 |
| rvba | It might mean that it will use 'precise' for now, but later it might be another release if you change the global default. | 15:05 |
| roaksoax | rvba: exaclt, so if you change the fglobal default, in the WebUI should show the selected default | 15:05 |
| rvba | roaksoax: yes, there is a need, because using the global default has another meaning than just 'precise' | 15:05 |
| roaksoax | rvba: exactly, but globally defined means that it will be *one* of the choices | 15:06 |
| roaksoax | rvba: we should present "default" as a choice, because "default" *is* a choice | 15:06 |
| rvba | Using the global default which happens to be precise right now means something else than forcing that node to use precise. | 15:06 |
| rvba | roaksoax: you lost me now. I'm arguing to keep 'default' as a choice :) among the explicit names of the releases. | 15:06 |
| roaksoax | rvba: exaclty, I understand, but we should not *present* in the WebUI a value "Default Release" when we can simply present *the* selected default release | 15:06 |
| rvba | roaksoax: that won't work, let me give you an example: | 15:07 |
| roaksoax | rvba: ok so WebUI will show "1. Ubuntu Precise", "2. Ubuntu Quantal", so you set the config option to be "quantal", so that becomes default right? | 15:08 |
| roaksoax | rvba: so when you enlist a node, the WebUI value sould be "2. Ubuntu Quantal" | 15:08 |
| rvba | roaksoax: we're talking about the a value that can be modified by the user in the "edit a node" page. | 15:08 |
| roaksoax | but if you change the default in the config, let's say you add lucid to the choices, on enlistment, "3. Ubuntu Lucid" should be selected | 15:08 |
| roaksoax | instead of "Default release" | 15:08 |
| roaksoax | rvba: yes | 15:09 |
| roaksoax | rvba: we don't need to be able to save a "default" release | 15:09 |
| roaksoax | rvba: the user should chose a release if he wants to *chage* from the default | 15:09 |
| rvba | so: yes we do: let me give you an example. | 15:09 |
| rvba | roaksoax: a user edits a node: the default is selected (precise), he changes that to quantal. | 15:10 |
| rvba | roaksoax: then he changes his mind and he wants to set it to the default again. | 15:10 |
| rvba | roaksoax: he clicks on 'precise' but will this see it back to using the default or will this force precise on this node? | 15:10 |
| rvba | s/see/set/ | 15:11 |
| roaksoax | rvba: ahhh I see your point now | 15:12 |
| roaksoax | rvba: ok but, are we expecting to have commissioning images from every supported release or only for 1 release | 15:12 |
| roaksoax | smoser: are we expecting to have commissioning images of every release? | 15:13 |
| roaksoax | smoser: every release we support in MAAS? | 15:13 |
| roaksoax | rvba: but now, if we want that, we would need to add a default release option under Settings on the WebUI | 15:14 |
| rvba | roaksoax: that's exactly why we have the default stored a Config object. | 15:14 |
| roaksoax | rvba: because yes, if we have default, moved to quantal, and then I decide to move back to the default, then I'd need to select the particular release | 15:15 |
| rvba | roaksoax: a one-line modification to the forms used in the Settings page will get us sorted. | 15:15 |
| roaksoax | rvba: yes I see your point, and I think it is a fair option. ' | 15:15 |
| rvba | roaksoax: cool | 15:15 |
| smoser | rvba, right now i think i'm leaning towards having commissioning images of each release. but probably defaulting in maas to a.) only import '$(ubuntu-distro-info --lts)' | 15:16 |
| smoser | hm.. | 15:16 |
| smoser | just a | 15:16 |
| smoser | i forgot what b was. | 15:16 |
| roaksoax | rvba: the other is that default should be distro-info --supported | 15:16 |
| roaksoax | err /s/supported/stable | 15:16 |
| rvba | roaksoax: then we simply need to build the choices for the config option (on the Settings page) with only the stable releases. | 15:17 |
| roaksoax | smoser: what's the differece between ubuntu-distro-info and distro-info | 15:17 |
| smoser | nothing on ubuntu | 15:17 |
| smoser | on debian distro-info == debian-distro-info | 15:17 |
| roaksoax | smoser: ok cool | 15:17 |
| smoser | and here, i think we specifically are asking an ubuntu question | 15:17 |
| smoser | (and --lts is bad usage for debian-distro-info) | 15:18 |
| smoser | rvba, roaksoax so you were discussing up above selection of the to-be-installed OS ? | 15:18 |
| rvba | smoser: yes | 15:18 |
| smoser | i'd suggest that '--lts' is probably the right default for that also. and let it be user-modifiable. | 15:19 |
| smoser | but i consider it a requirement that this is an input to the api for deployment. | 15:19 |
| rvba | Once os_release will be added to the node object, one will be able to use the API to modify that value for each node. | 15:20 |
| smoser | i don tthink thats the right way. | 15:21 |
| smoser | just because i want "quantal" for this installation does not mean I am changing that nodes "default" | 15:21 |
| smoser | that should not be sticky in any way | 15:21 |
| smoser | (ie, i think you're suggesting that my client would then have to change the nodes data, and then request deploy) | 15:21 |
| rvba | I see, you'd like pre-deployement setting. | 15:21 |
| smoser | i want to say "give me a node with 12.10" | 15:22 |
| smoser | i dont even want to know what node that is. | 15:22 |
| roaksoax | smoser: but that assumes that we would randomly chose a node and install 12.04 on it | 15:22 |
| rvba | roaksoax: that's pretty different from storing the release used by the node on the node itself… | 15:23 |
| rvba | roaksoax: what smoser said I mean. | 15:23 |
| roaksoax | yah | 15:23 |
| smoser | i suggest that htere is a list of "supported OS releases to install" | 15:23 |
| smoser | and possibly a "default if unspecified" | 15:23 |
| roaksoax | smoser: yes but for each node, you should need to be able to chose a release you want for it | 15:23 |
| smoser | i dont see much use case for "default for a node" | 15:23 |
| smoser | as that is only making it hard to use. | 15:24 |
| roaksoax | smoser: you should not just randomly "get a node with 12.10" | 15:24 |
| roaksoax | smoser: that would be juju's job IMHO | 15:24 |
| roaksoax | rvba: inventory will be within maas right? | 15:24 |
| rvba | roaksoax: as in hardware inventory? Yes. | 15:24 |
| smoser | i relaly think you want to invision this like a VM. | 15:24 |
| smoser | anyway.. | 15:25 |
| roaksoax | smoser: right, but that's not the piurpose of inventory | 15:25 |
| roaksoax | smoser: i don't say we can't do that, but I'm just saying we should still have the ability to choose what node should have what release | 15:25 |
| smoser | it seems wrong for me to have to modify an attribute of a node to "deploy with 12.10" | 15:25 |
| smoser | roaksoax, i really dont care about that. | 15:26 |
| smoser | i honestly cannot see any reason that anyone ever would say "give me a node" without a care as to what OS was on it. | 15:26 |
| smoser | (which you'd essentially be doing if you relied on the 'default') | 15:26 |
| roaksoax | smoser: right, but that's why you have juju for | 15:26 |
| roaksoax | smoser: becuase if inventory is done within maas, you can treat a machine like a VM in that particular aspect | 15:27 |
| smoser | well thats fine. so juju specified the release then. | 15:27 |
| smoser | but from the api perspecitve "give me a node" takes a release. | 15:27 |
| smoser | having a default is fine | 15:27 |
| smoser | but really, thats only going to piss people off | 15:27 |
| smoser | when one day the default changes | 15:27 |
| smoser | and all their stuff breaks | 15:27 |
| smoser | so anyone intelligent is going to specify it | 15:27 |
| smoser | that make sense? | 15:28 |
| roaksoax | smoser: right, but do you really think an admin wil simply say "give me *a* node, whatever it is and install precise on it?" | 15:28 |
| smoser | yes. | 15:28 |
| roaksoax | smoser: or will they say "I want to deploy *this* node, that has precise on it" | 15:28 |
| smoser | if i have 4000 nodes and they're all the same. | 15:28 |
| smoser | i do not want to chose one | 15:28 |
| rvba | smoser is right. | 15:29 |
| smoser | or look at a list of what is available | 15:29 |
| rvba | In the context of having tons of node, deploying to individual nodes is not the priority. | 15:29 |
| rvba | And probably what we should optimize for, even if that should be possible. | 15:29 |
| roaksoax | it is not, but that doens't change the fact that you know, before hand, what release should a node have | 15:29 |
| roaksoax | again I'm not saying smoser's suggestion can't be done | 15:30 |
| roaksoax | i'm simply saying, we should think where that lies, if it should lie within juju | 15:30 |
| roaksoax | or within maas | 15:30 |
| rvba | But maybe a global default is all we need. | 15:30 |
| roaksoax | rvba: right, IMHO, we should keep things the way they are, and add smosers suggetions to the question | 15:31 |
| rvba | And one could override that default when deploying a node. | 15:31 |
| roaksoax | rvba: right, but we should still be able to have inventory on that, don't we? | 15:31 |
| smoser | heres why global default doesn't really work: 10.04 wont install on system X because system X has sandybridge. so having a global default of 10.04 clearly cannot work. | 15:31 |
| roaksoax | rvba: that means that after installation, the DB should be updated with the current release of the installed system | 15:31 |
| smoser | but the user wants 10.04 "by default" except for that node (or class of nodes) | 15:31 |
| smoser | but this really doesnt matter to me. | 15:32 |
| smoser | and just leads to some more complex "list of supported OSes on this node" | 15:32 |
| rvba | roaksoax: what's the link between this and the harware inventory? | 15:32 |
| rvba | hardware* | 15:32 |
| smoser | so my feeling right now is a global default, but i would suggest that it is a best practice to always specify it in the api when you request a node. | 15:33 |
| smoser | which basically makes the 'global default' a "bad practice" :) | 15:33 |
| smoser | in short, i suggest using global default for now. realizing that it is insufficient when a given set of hardware cannot be supported by a release. | 15:34 |
| smoser | and we have that to figure out somepoint in the future or just live with. | 15:34 |
| smoser | hardware invententory and "supported hardware db" and things of that sort could make selection magical and know that information outside of maas | 15:34 |
| roaksoax | rvba: hardware inventory means that you will know "these set of nodes will have precise" "these set of nodes will have quantal" | 15:36 |
| smoser | "will have" ? | 15:36 |
| smoser | "support" ? | 15:36 |
| roaksoax | smoser: so you suggest not being able to chose a particular release for a particular node, or set of nodes and pre-define that? | 15:37 |
| roaksoax | smoser: support is pre deployment, will have is for-deployment/post-deployment | 15:37 |
| smoser | roaksoax, i suggest that it is a requirement to be able to specify a release at deploy time. | 15:39 |
| smoser | i dont know what "chose" means other than that. | 15:39 |
| smoser | and whoever is requesting a node to be deployed is going to want to specify what release they want on it. | 15:39 |
| roaksoax | smoser: right but that's a different feature that can lie on top of | 15:40 |
| smoser | on top of? | 15:40 |
| smoser | on top of what. | 15:40 |
| roaksoax | smoser: the work that's being done now | 15:40 |
| smoser | what work is that ? i'm really sorry for being late to the party. | 15:40 |
| roaksoax | smoser: the work on adding support for other ubuntu releases | 15:41 |
| smoser | but i really dont know what value a "release" field for a node has. | 15:41 |
| smoser | the only thing i can imagine is with reguard to commissioning and ephemeral environment. | 15:41 |
| smoser | but then, things get complex quickly. | 15:41 |
| smoser | as i'd only think those things are useful if i can expect behavior out of them. | 15:41 |
| roaksoax | smoser: right, but IMHO, you should be able to know what machines deploy what OS version | 15:42 |
| roaksoax | smoser: and that should be stored on the DB | 15:42 |
| smoser | roaksoax, they deploy the version that someone asked for | 15:42 |
| roaksoax | smoser: selecting a machine and telling what to install on it, is a different feature, but yet, it requires a DB filed | 15:42 |
| smoser | it does not. | 15:42 |
| smoser | its an api call. | 15:43 |
| roaksoax | smoser: yes, you can ask that on the WEbUI or you can ask that on the api | 15:43 |
| smoser | "OS version" is not an attribute of a node. | 15:43 |
| roaksoax | smoser: it is now | 15:43 |
| smoser | it is an attribute of an instance | 15:43 |
| roaksoax | smoser: and it should be | 15:43 |
| smoser | no. | 15:43 |
| roaksoax | smoser: we cannot completely treat a machine as an instance | 15:43 |
| smoser | other than the case of "ephemeral" and "commissioning" | 15:43 |
| smoser | why not? | 15:43 |
| roaksoax | smoser: so then that defeats the purpose of inventory | 15:44 |
| smoser | no. | 15:44 |
| smoser | it does not. | 15:44 |
| roaksoax | smoser: when you do inventory you know what machines have what | 15:44 |
| roaksoax | smoser: on inventory you *know* what machine has *what* OS on it | 15:44 |
| roaksoax | smoser: and that's stored in the DB | 15:44 |
| roaksoax | smoser: and after you deploy something, you need to know what | 15:45 |
| roaksoax | smoser: and after you deploy something, you need to know what's installed in that machine, and that information is stored in the DB | 15:45 |
| roaksoax | it is an attribute of a node | 15:46 |
| smoser | see i dont think it is | 15:46 |
| smoser | "default" for that node (which would only really have value in ephemeral / commissioning) | 15:46 |
| smoser | is a derived value based on the hardware you know about in that node | 15:46 |
| smoser | and "currently installed" is a attribute of the "instance" that is currently running on that node. | 15:47 |
| roaksoax | smoser: right, where do you store a currently installed value? | 15:47 |
| smoser | this is the bug i opened for this. | 15:47 |
| smoser | https://bugs.launchpad.net/maas/+bug/944325 | 15:47 |
| ubot5 | Ubuntu bug 944325 in MAAS "no separation of instance id from node id" [Low,Triaged] | 15:47 |
| roaksoax | smoser: you have to store that info in the node | 15:47 |
| smoser | which is broken. | 15:47 |
| smoser | and your suggestion of inventory is busted anyway. | 15:48 |
| smoser | an OS version can be 'distro-upgraded' | 15:48 |
| smoser | and made invalid | 15:48 |
| smoser | or turned into RH | 15:48 |
| smoser | so you can't *actually* assume much out of that. | 15:48 |
| smoser | so. | 15:49 |
| smoser | i relaize you just want a fix for this now. | 15:49 |
| smoser | and that we're apparently hnot going to get an "instance" table for 12.10. | 15:49 |
| roaksoax | smoser: ok so this means we are always going to treat maas as ec2 on physucal machines then | 15:50 |
| smoser | not really. | 15:51 |
| roaksoax | it is, if you are looking for a provider that gives you X with Y release | 15:51 |
| smoser | a specific installation (for user 'bob' rather than user 'fred') is somewhat important to represent. | 15:51 |
| roaksoax | then it is the same on ec2 when you ask for X with Y release | 15:51 |
| roaksoax | smoser: i personally don't think ew can simply address thjis as whatever machine with X release | 15:52 |
| roaksoax | we should be able to select what machines I want to be deployed with X release | 15:52 |
| smoser | sure. thats fine. | 15:52 |
| smoser | ok. | 15:52 |
| smoser | so. | 15:52 |
| smoser | here... let me have a few minutes to more clearly write down what i think. and we can put that in a etherpad. | 15:53 |
| roaksoax | smoser: so simply enough , forget about API and Juju "If I want node-XYZ to be deployed with Precise, I should be able to do so fro the WebIU, which is what I'm aruguing" | 16:00 |
| roaksoax | smoser: and not saying that what you are syaing shouldn't be done | 16:00 |
| roaksoax | smoser: but what I'm arguing means that I need to be able to select the release for the node I'm wanting to deploy | 16:00 |
| === matsubara is now known as matsubara-lunch | ||
| * roaksoax needs to run, bbl | 16:06 | |
| smoser | roaksoax, rvba http://pad.daviey.com/server-maas-release-support | 17:01 |
| smoser | thats my collected thoughts. | 17:01 |
| smoser | rvba, but i'd be more than delighted if you said "oh, we really need to have the notion of 'instance'" and just implemented that. | 17:02 |
| rvba | smoser: thanks for that. I need to step out right now but I'll have a look at your summary. | 17:25 |
| === matsubara-lunch is now known as matsubara | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!