/srv/irclogs.ubuntu.com/2012/09/10/#maas.txt

Davieyjtv: hey, what is omshell?02:28
jtvHi02:28
jtvIt's a way of talking to dhcpd.02:28
jtvYou 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
Davieyyeah, i should have just read the docstring :)02:29
Davieysorry02:29
Davieyi was sort of hoping it was related to the cmd line interface :DDD02:30
bigjoolsDaviey: wtf are you doing up02:32
Davieybigjools: nothing like doing code reviews in the middle of the night eh?02:33
bigjoolsDaviey: fun02:35
lifelessbigjools: do we need to talk today?02:43
bigjoolslifeless: possibly - can we do it in 1.5h or so?02:44
lifelessanytime02:44
bigjoolsthanks02:44
bigjoolsassuming my 12.10 upgrade doesn't completely hose this machine02:46
roaksoaxmornin11:50
roaksoaxrvba: howdy!11:50
rvbaroaksoax: hello12:24
roaksoaxrvba: how's it going12:25
roaksoaxrvba: so, i tested the stuff for the release thing12:25
roaksoaxrvba: and it ended up not having anything12:26
rvbaWhat do you mean?12:26
roaksoaxrvba: on the database, as in, the database didn12:26
roaksoaxrvba: on the database, as in, the database didn't store the default release12:26
rvbaWell, did you create a default for the config value?12:26
rvbaBut the db will store the default only if it's changed.12:27
roaksoaxrvba: right, but doesn't that mean, if for example, the CharField model params are, Choices and defaul12:27
rvbaThe default should be defined in src/maasserver/models/config.py:get_default_config12:27
rvbaAh, *that* default..12:28
rvbaDo you have a branch I could have a look at?12:28
roaksoaxrvba: sure, http://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/97612:29
roaksoaxrvba: that;s what I did at first12:29
roaksoaxnow I'm gonna test this:12:29
roaksoaxhttp://bazaar.launchpad.net/~andreserl/maas/maas_releases_support/revision/97812:29
rvbaroaksoax: 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
roaksoaxrvba: we don't want None as deafult, we want a particular release as default12:31
roaksoaxrvba: so basically s/UBUNTU_RELEASE.precise/UBUNTU_RELEASE.default12:32
rvbaSure, 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
roaksoaxrvba: right, so lets imagine precise is the default, how to make sure it gets stored in the DB?12:32
roaksoaxbecuase the documentation tells me that choices=XYZ default=XYZ.one12:33
roaksoaxstores XYZ.one if none has being given12:33
roaksoaxright?12:33
rvbaWhat 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
rvbaBut I guess we can iterate on that.12:33
roaksoaxrvba: 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 it12:34
roaksoaxrvba: we cannot go without release if the user does not choose a default12:34
rvbaroaksoax: hence the default value in src/maasserver/models/config.py:get_default_config12:34
roaksoaxso UBUNTU_RELEASE.default can be obtained from a config, but if it is not given it should default to the stable release12:35
rvbaroaksoax: so, the default=… is used when a new object is created.12:36
roaksoaxrvba: =right, so when enlisted, the machine should end up with os_release=Precise (the default)12:37
roaksoaxrvba: so this is what happens, with the branch above, we enlist a machine12:38
roaksoaxthe machine enlists successfully12:38
rvbaroaksoax: I thought the os_release field should contain the name of the release used for the next install.  Not the current release.12:38
rvbaMaybe I misunderstood what you were trying to do.12:39
roaksoaxrvba: 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 precise12:39
roaksoaxrvba: that's the only stable release at the moment12:39
rvbaOk, so I got it right.12:39
roaksoaxrvba: for enlistment/commissioning, there's no ephemeral images other than precise12:39
roaksoaxrvba: so this is the problem with the above branch12:41
roaksoaxrvba: 1. the machine enlists. 2. machine gets stored in DB *with* os_release *None*. 3. On commissioning, it fails for not having set release12:41
rvbaroaksoax: do you have a failing test that could illustrate what the problem is?12:41
roaksoaxrvba: 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
rvbaroaksoax: ok, I understand.  Let me see what I can do.12:43
roaksoaxrvba: 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
roaksoaxrvba: the other thing would be in the API verify that if no release has been sent during enlistment, set the value?12:44
rvbaroaksoax: 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
rvbaThat method will use the default if the value of node.os_release is None.12:45
rvbaWhat's the benefit from doing this over storing the default directly you might ask…12:46
rvbaWell, if will let use have a globally defined default under the control of the user.12:46
roaksoaxrvba: could you exemplify12:49
rvbaroaksoax: sure:12:50
rvbaSay you have 100 nodes.12:50
rvbaNone of which need a specific release so you decide to go with the default.12:50
rvbaThen, later, a new release comes out an you want your node to use that release.12:50
rvbaIf, 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
rvbaIf, instead, node.get_os_release() does something like:12:51
rvbaIf node.os_release is None:12:52
rvba    return globally_configured_release12:52
rvbaelse:12:52
rvba    return node.os_release12:52
rvbaThen all you need to do is change the global setting 'globally_configured_release'.12:52
rvbaDoes that make sense?12:52
roaksoaxrvba: right12:59
roaksoaxrvba: so, that would actually be needed on the preseed side of things and nothing to be changed on the forms and model12:59
rvbaroaksoax: that would look like this: http://paste.ubuntu.com/1196615/13:00
rvbaroaksoax: err http://paste.ubuntu.com/1196620/13:00
roaksoaxrvba: is the print(UBUNTU_RELEASE_CHOICES) necessary?13:01
rvbaroaksoax: no, that was for my own benefit :)13:01
roaksoaxrvba: hehe ok cool13:01
roaksoaxrvba: I'll give it a test13:01
roaksoaxthanks for the input and patch13:01
rvbanp13:02
rvbaroaksoax: the default is taken into account correctly btw, http://paste.ubuntu.com/1196624/13:04
rvbaroaksoax: 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
roaksoaxrvba: alright13:07
roaksoaxrvba: i'll run it with you before proposing it, either way, there's gonna be lots of tests that will need to get fixed13:08
rvbaroaksoax: right.13:08
rvbaroaksoax: I'll give you a hand (with tests and stuff) when you'll be satisfied with the behaviour.13:09
mgzthe lshw json output is rather verbose... <http://pastebin.ubuntu.com/1196630/>13:09
roaksoaxrvba: cool thanks13:10
roaksoaxrvba: thoughts? http://paste.ubuntu.com/1196743/14:29
rvbaroaksoax: in api.py, line 1144 and above, I see that node is set to None if macaddress is None…14:32
roaksoaxrvba: yeah just figured it too :)14:32
rvbaroaksoax: 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 blind14:34
roaksoaxrvba: i think it doesn't really make sense to show "Default Release" on the WebUI14:57
roaksoaxso I'll remove that14:57
rvbaroaksoax: what do you want to put instead?14:57
roaksoaxrvba: nothing14:57
rvbaroaksoax: as in… the empty string?14:58
rvbaOr you want to drop that option completely…?14:58
roaksoaxrvba: no, just from the UI14:58
roaksoaxrvba: from the combobox14:58
roaksoaxrvba: it will remain a UBUNTU_RELEASE.default but will not be in UBUNTU_RELEASE_CHOICES14:59
rvbaroaksoax: 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
roaksoaxrvba: yeah, it does use that14:59
roaksoaxrvba: it is just not a choice on the WebUI14:59
roaksoaxrvba: remove this:15:00
roaksoax+    else:15:00
roaksoax+        UBUNTU_RELEASE_CHOICES += ((UBUNTU_RELEASE.default, 'Default release'),)15:00
rvbaroaksoax: so a user won't be able to say that a node should use the globally defined default.15:00
rvbaHe will be forced to specify a particular release.15:00
roaksoaxrvba: nope15:00
roaksoaxrvba: there will always be a default15:01
rvbaThis sort of makes the whole idea of having a globally configurable default pointless.15:01
roaksoaxrvba: it doesn15:01
roaksoaxrvba: using a globally configured one differs from what the WebUI displays15:01
roaksoaxrvba: UBUNTU_RELEASE_CHOICES is only to list what choices are on the WEbUI15:01
roaksoaxrvba: but the default will always be one of the CHOICES15:01
roaksoaxrvba: so UBUNTU_RELEASE.precise, UBUNTU_RELEASE.quantal, UBUNTU_RELEASE.defaul, but the WebUI will only display "(precise,Uuntu Preicse), (quantal,Ubuntu Quantal)"15:02
rvbaI understand the consequences :)15:02
rvbaBut I don't understand the motivation behind that change tbh.15:02
roaksoaxrvba: so in this case, .default = precise, so when it comes to the choice, it will chose .precise15:03
roaksoaxrvba: 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 selected15:03
rvbaIf your concern is that "Default release" is not explicit enough we can fix that properly.15:03
roaksoaxrvba: no it is not about being explicit, it is just simply what you present to the user15:04
rvbaBecause the value 'Default release' is different from 'precise' or 'quantal'15:04
roaksoaxrvba: 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
rvbaIt might mean that it will use 'precise' for now, but later it might be another release if you change the global default.15:05
roaksoaxrvba: exaclt, so if you change the fglobal default, in the WebUI should show the selected default15:05
rvbaroaksoax: yes, there is a need, because using the global default has another meaning than just 'precise'15:05
roaksoaxrvba: exactly, but globally defined means that it will be *one* of the choices15:06
roaksoaxrvba: we should present "default" as a choice, because "default" *is* a choice15:06
rvbaUsing the global default which happens to be precise right now means something else than forcing that node to use precise.15:06
rvbaroaksoax: you lost me now.  I'm arguing to keep 'default' as a choice :) among the explicit names of the releases.15:06
roaksoaxrvba: exaclty, I understand, but we should not *present* in the  WebUI a value "Default Release" when we can simply present *the* selected default release15:06
rvbaroaksoax: that won't work, let me give you an example:15:07
roaksoaxrvba: 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
roaksoaxrvba: so when you enlist a node, the WebUI value sould be "2. Ubuntu Quantal"15:08
rvbaroaksoax: we're talking about the a value that can be modified by the user in the "edit a node" page.15:08
roaksoaxbut if you change the default in the config, let's say you add lucid to the choices, on enlistment,  "3. Ubuntu Lucid" should be selected15:08
roaksoaxinstead of "Default release"15:08
roaksoaxrvba: yes15:09
roaksoaxrvba: we don't need to be able to save a "default" release15:09
roaksoaxrvba: the user should chose a release if he wants to *chage* from the default15:09
rvbaso: yes we do: let me give you an example.15:09
rvbaroaksoax: a user edits a node: the default is selected (precise), he changes that to quantal.15:10
rvbaroaksoax: then he changes his mind and he wants to set it to the default again.15:10
rvbaroaksoax: he clicks on 'precise' but will this see it back to using the default or will this force precise on this node?15:10
rvbas/see/set/15:11
roaksoaxrvba: ahhh I see your point now15:12
roaksoaxrvba: ok but, are we expecting to have commissioning images from every supported release or only for 1 release15:12
roaksoaxsmoser: are we expecting to have commissioning images of every release?15:13
roaksoaxsmoser: every release we support in MAAS?15:13
roaksoaxrvba: but now, if we want that, we would need to add a default release option under Settings on the WebUI15:14
rvbaroaksoax: that's exactly why we have the default stored a Config object.15:14
roaksoaxrvba: 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 release15:15
rvbaroaksoax: a one-line modification to the forms used in the Settings page will get us sorted.15:15
roaksoaxrvba: yes I see your point, and I think it is a fair option. '15:15
rvbaroaksoax: cool15:15
smoserrvba, 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
smoserhm..15:16
smoserjust a15:16
smoseri forgot what b was.15:16
roaksoaxrvba: the other is that default should be distro-info --supported15:16
roaksoaxerr /s/supported/stable15:16
rvbaroaksoax: then we simply need to build the choices for the config option (on the Settings page) with only the stable releases.15:17
roaksoaxsmoser: what's the differece between ubuntu-distro-info and distro-info15:17
smosernothing on ubuntu15:17
smoseron debian distro-info == debian-distro-info15:17
roaksoaxsmoser: ok cool15:17
smoserand here, i think we specifically are asking an ubuntu question15:17
smoser(and --lts is bad usage for debian-distro-info)15:18
smoserrvba, roaksoax so you were discussing up above selection of the to-be-installed OS ?15:18
rvbasmoser: yes15:18
smoseri'd suggest that '--lts' is probably the right default for that also. and let it be user-modifiable.15:19
smoserbut i consider it a requirement that this is an input to the api for deployment.15:19
rvbaOnce 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
smoseri don tthink thats the right way.15:21
smoserjust because i want "quantal" for this installation does not mean I am changing that nodes "default"15:21
smoserthat should not be sticky in any way15: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
rvbaI see, you'd like pre-deployement setting.15:21
smoseri want to say "give me a node with 12.10"15:22
smoseri dont even want to know what node that is.15:22
roaksoaxsmoser: but that assumes that we would randomly chose a node and install 12.04 on it15:22
rvbaroaksoax: that's pretty different from storing the release used by the node on the node itself…15:23
rvbaroaksoax: what smoser said I mean.15:23
roaksoaxyah15:23
smoseri suggest that htere is a list of "supported OS releases to install"15:23
smoserand possibly a "default if unspecified"15:23
roaksoaxsmoser: yes but for each node, you should need to be able to chose a release you want for it15:23
smoseri dont see much use case for "default for a node"15:23
smoseras that is only making it hard to use.15:24
roaksoaxsmoser: you should not just randomly "get a node with 12.10"15:24
roaksoaxsmoser: that would be juju's job IMHO15:24
roaksoaxrvba: inventory will be within maas right?15:24
rvbaroaksoax: as in hardware inventory?  Yes.15:24
smoseri relaly think you want to invision this like a VM.15:24
smoseranyway..15:25
roaksoaxsmoser: right, but that's not the piurpose of inventory15:25
roaksoaxsmoser: 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 release15:25
smoserit seems wrong for me to have to modify an attribute of a node to "deploy with 12.10"15:25
smoserroaksoax, i really dont care about that.15:26
smoseri 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
roaksoaxsmoser: right, but that's why you have juju for15:26
roaksoaxsmoser: becuase if inventory is done within maas, you can treat a machine like a VM in that particular aspect15:27
smoserwell thats fine. so juju specified the release then.15:27
smoserbut from the api perspecitve "give me a node" takes a release.15:27
smoserhaving a default is fine15:27
smoserbut really, thats only going to piss people off15:27
smoserwhen one day the default changes15:27
smoserand all their stuff breaks15:27
smoserso anyone intelligent is going to specify it15:27
smoserthat make sense?15:28
roaksoaxsmoser: 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
smoseryes.15:28
roaksoaxsmoser: or will they say "I want to deploy *this* node, that has precise on it"15:28
smoserif i have 4000 nodes and they're all the same.15:28
smoseri do not want to chose one15:28
rvbasmoser is right.15:29
smoseror look at a list of what is available15:29
rvbaIn the context of having tons of node, deploying to individual nodes is not the priority.15:29
rvbaAnd probably what we should optimize for, even if that should be possible.15:29
roaksoaxit is not, but that doens't change the fact that you know, before hand, what release should a node have15:29
roaksoaxagain I'm not saying smoser's suggestion can't be done15:30
roaksoaxi'm simply saying, we should  think where that lies, if it should lie within juju15:30
roaksoaxor within maas15:30
rvbaBut maybe a global default is all we need.15:30
roaksoaxrvba: right, IMHO, we should keep things the way they are, and add smosers suggetions to the question15:31
rvbaAnd one could override that default when deploying a node.15:31
roaksoaxrvba: right, but we should still be able to have inventory on that, don't we?15:31
smoserheres 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
roaksoaxrvba: that means that after installation, the DB should be updated with the current release of the installed system15:31
smoserbut the user wants 10.04 "by default" except for that node (or class of nodes)15:31
smoserbut this really doesnt matter to me.15:32
smoserand just leads to some more complex "list of supported OSes on this node"15:32
rvbaroaksoax: what's the link between this and the harware inventory?15:32
rvbahardware*15:32
smoserso 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
smoserwhich basically makes the 'global default' a "bad practice" :)15:33
smoserin 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
smoserand we have that to figure out somepoint in the future or just live with.15:34
smoserhardware invententory and "supported hardware db" and things of that sort could make selection magical and know that information outside of maas15:34
roaksoaxrvba: 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
roaksoaxsmoser: 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
roaksoaxsmoser: support is pre deployment, will have is for-deployment/post-deployment15:37
smoserroaksoax, i suggest that it is a requirement to be able to specify a release at deploy time.15:39
smoseri dont know what "chose" means other than that.15:39
smoserand whoever is requesting a node to be deployed is going to want to specify what release they want on it.15:39
roaksoaxsmoser: right but that's a different feature that can lie on top of15:40
smoseron top of?15:40
smoseron top of what.15:40
roaksoaxsmoser: the work that's being done now15:40
smoserwhat work is that ? i'm really sorry for being late to the party.15:40
roaksoaxsmoser: the work on adding support for other ubuntu releases15:41
smoserbut i really dont know what value a "release" field for a node has.15:41
smoserthe only thing i can imagine is with reguard to commissioning and ephemeral environment.15:41
smoserbut then, things get complex quickly.15:41
smoseras i'd only think those things are useful if i can expect behavior out of them.15:41
roaksoaxsmoser: right, but IMHO, you should be able to know what machines deploy what OS version15:42
roaksoaxsmoser: and that should be stored on the DB15:42
smoserroaksoax, they deploy the version that someone asked for15:42
roaksoaxsmoser: selecting a machine and telling what to install on it, is a different feature, but yet, it requires a DB filed15:42
smoserit does not.15:42
smoserits an api call.15:43
roaksoaxsmoser: yes, you can ask that on the WEbUI or you can ask that on the api15:43
smoser"OS version" is not an attribute of a node.15:43
roaksoaxsmoser: it is now15:43
smoserit is an attribute of an instance15:43
roaksoaxsmoser: and it should be15:43
smoserno.15:43
roaksoaxsmoser: we cannot completely treat a machine as an instance15:43
smoserother than the case of "ephemeral" and "commissioning"15:43
smoserwhy not?15:43
roaksoaxsmoser: so then that defeats the purpose of inventory15:44
smoserno.15:44
smoserit does not.15:44
roaksoaxsmoser: when you do inventory you know what machines have what15:44
roaksoaxsmoser: on inventory you *know* what machine has *what* OS on it15:44
roaksoaxsmoser: and that's stored in the DB15:44
roaksoaxsmoser: and after you deploy something, you need to know what15:45
roaksoaxsmoser: and after you deploy something, you need to know what's installed in that machine, and that information is stored in the DB15:45
roaksoaxit is an attribute of a node15:46
smosersee i dont think it is15:46
smoser"default" for that node (which would only really have value in ephemeral / commissioning)15:46
smoseris a derived value based on the hardware you know about in that node15:46
smoserand "currently installed" is a attribute of the "instance" that is currently running on that node.15:47
roaksoaxsmoser: right, where do you store a currently installed value?15:47
smoserthis is the bug i opened for this.15:47
smoserhttps://bugs.launchpad.net/maas/+bug/94432515:47
ubot5Ubuntu bug 944325 in MAAS "no separation of instance id from node id" [Low,Triaged]15:47
roaksoaxsmoser: you have to store that info in the node15:47
smoserwhich is broken.15:47
smoserand your suggestion of inventory is busted anyway.15:48
smoseran OS version can be 'distro-upgraded'15:48
smoserand made invalid15:48
smoseror turned into RH15:48
smoserso you can't *actually* assume much out of that.15:48
smoserso.15:49
smoseri relaize you just want a fix for this now.15:49
smoserand that we're apparently hnot going to get an "instance" table for 12.10.15:49
roaksoaxsmoser: ok so this means we are always going to treat maas as ec2 on physucal machines then15:50
smosernot really.15:51
roaksoaxit is, if you are looking for a provider that gives you X with Y release15:51
smosera specific installation (for user 'bob' rather than user 'fred') is somewhat important to represent.15:51
roaksoaxthen it is the same on ec2 when you ask for X with Y release15:51
roaksoaxsmoser: i personally don't think ew can simply address thjis as whatever machine with X release15:52
roaksoaxwe should be able to select what machines I want to be deployed with X release15:52
smosersure. thats fine.15:52
smoserok.15:52
smoserso.15:52
smoserhere... let me have a few minutes to more clearly write down what i think. and we can put that in a etherpad.15:53
roaksoaxsmoser: 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
roaksoaxsmoser: and not saying that what you are syaing shouldn't be done16:00
roaksoaxsmoser: but what I'm arguing means that I need to be able to select the release for the node I'm wanting to deploy16:00
=== matsubara is now known as matsubara-lunch
* roaksoax needs to run, bbl16:06
smoserroaksoax, rvba http://pad.daviey.com/server-maas-release-support17:01
smoserthats my collected thoughts.17:01
smoserrvba, 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
rvbasmoser: 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!