| jtv | bigjools: complication with the specify-nodegroup-when-creating-node story is that we don't give users a way to identify nodegroups apart from uuids. | 02:26 |
|---|---|---|
| bigjools | morning jtv | 02:27 |
| jtv | And good morning | 02:27 |
| bigjools | yes, we briefly talked about that yesterday | 02:27 |
| bigjools | which is why I said to use subnet | 02:27 |
| jtv | Which didn't work for cases where we don't manage dhcp. | 02:27 |
| bigjools | it can, if the subnet is provided regardless | 02:28 |
| bigjools | where provided means configured on nodegroup | 02:28 |
| jtv | Yes, that'd help. | 02:28 |
| bigjools | did you have any other ideas? | 02:28 |
| jtv | Only things like “identify by uuid but show name and subnet in the UI.” I still haven't found a way to identify objects _in the API call_ based on something other than id though. | 02:29 |
| jtv | The form logic seems to mandate id as the key. | 02:30 |
| jtv | I'm trying to get around that. | 02:30 |
| bigjools | oh smeg | 02:31 |
| jtv | Yeah. The convenience of frameworks is like the beauty of a Potemkin village. | 02:31 |
| jtv | Skin deep. | 02:31 |
| jtv | Also, always specifying the subnet feels like it's going to have widespread consequences. | 02:32 |
| bigjools | it would be worth asking for more opinions on this | 02:33 |
| jtv | I already had a pre-imp with Raphaël. He said it was doable to use a different key for passing a nodegroup to the form, so I'm still searching. | 02:36 |
| bigjools | I need lunch | 02:38 |
| bigjools | back later | 02:38 |
| bigjools | jtv: btw I sorted the package build problem | 04:13 |
| bigjools | branch up for review | 04:13 |
| jtv | bigjools: whoo | 04:14 |
| bigjools | https://code.launchpad.net/~julian-edwards/maas/packaging/+merge/125393 | 04:14 |
| bigjools | not sure I like the tests themselves mind, they seem hard-coded to work in the qa lab | 04:15 |
| jtv | bigjools: reviewed | 04:15 |
| jtv | Yes, they are hardcoded to work in the qa lab. I think I reviewed that bit and said the same thing. But couldn't hold the whole thing up for that, given the circumstances. | 04:16 |
| jtv | afk for a bit. | 04:25 |
| jtv | Back. | 04:53 |
| bigjools | me too | 05:01 |
| jtv | Great, then we're both back. | 05:08 |
| jtv | Wow, a quick round around the block can really clear the head. | 05:08 |
| bigjools | yes | 05:08 |
| jtv | I keep skipping that to get work done, and then when there's finally time, it's dark and raining. | 05:09 |
| jtv | Making progress on select-nodegroup-for-node, thanks to postgres. | 05:30 |
| jtv | But it's like trying to hack your way into a voodoo ritual. | 05:32 |
| jtv | Which, in case you've never tried it, is mostly a matter of just trying things. | 05:33 |
| jtv | bigjools: currently working on getting the django form to do what I want; we'll also need to figure out what needs doing in order to get a subnet for every nodegroup. | 05:53 |
| bigjools | jtv: we'll make it part of cluster registration | 05:54 |
| bigjools | jtv: subnet will return many matches on NodeGroupInterface but fortunately one NodeGroup | 05:55 |
| jtv | Many, even? | 05:55 |
| jtv | BTW since it's easy, I'm making it accept any IP address within the nodegroup's subnet. So you can pass the node's IP, or the cluster manager's IP within the subnet, or the base address, or the broadcast address, or… | 05:56 |
| jtv | Avoids confusion about the bits that just don't matter. | 05:56 |
| bigjools | broadcast address? | 05:57 |
| bigjools | ok might be ok | 05:57 |
| jtv | I notice for example that Raphaël likes to write addresses like 192.168.1.1/24 where I prefer 192.168.1.0/24. The difference shouldn't matter. | 05:58 |
| jtv | \o/ I built a package! Thank you again. | 05:59 |
| bigjools | :) | 05:59 |
| jtv | Now, one issue: how do I represent the nodegroups as labels in the UI, if the label is a subnet and the nodegroup may have multiple subnets? | 06:01 |
| bigjools | labels? | 06:01 |
| jtv | Labels for the selection of a node's nodegroup. | 06:01 |
| jtv | In other words, what is the human-readable identification of a nodegroup? | 06:01 |
| jtv | I was thinking of showing subnet and name, but if there are multiple subnets… | 06:02 |
| bigjools | hmmm | 06:04 |
| bigjools | I'd just show first subnet/name | 06:05 |
| jtv | I could probably just show all, but I don't know how many subnets there might be per nodegroup. | 06:06 |
| jtv | I guess right now it's still just one. | 06:06 |
| jtv | get_managed_interface() is singular. | 06:06 |
| bigjools | yer | 06:06 |
| jtv | I wonder why the lovely nodegroup field I added shows up when editing an existing node (when I don't want it) but not when creating a new one (when I do want it). | 06:09 |
| bigjools | grar | 06:10 |
| bigjools | jtv: I know a man who will know | 06:10 |
| * bigjools wonders why the maas-dhcp package depends on the maas package | 06:10 | |
| jtv | !? | 06:11 |
| jtv | Shouldn't that be the other way around? | 06:11 |
| jtv | And then maas-dhcp can depend on maas-common? | 06:11 |
| bigjools | no, there should be no dependency at all | 06:11 |
| jtv | Ah, right. Not if we want to be able to run appservers without master workers. | 06:12 |
| jam | mgz: ping me when you are back from lunch, I decided to reverse the many-to-many to have node.tags rather than tag.nodes. | 13:02 |
| jam | It felt more natural to say node.tags.add(tag) rather than tag.nodes.add(node) | 13:02 |
| mgz | jam: okay, will update my copy of your branch | 13:03 |
| jam | mgz: I'm happy to review or just preliminary look over (and fix up) a branch that you have | 13:03 |
| mgz | jam: ta, will post things | 13:07 |
| mgz | allenap or rvba: can you take a look at jam's tag-tables mp and see if there's anything that you're not happy with? | 13:12 |
| mgz | this is the main bit of interface we'll actually be sticking with, everything else is more temporary | 13:12 |
| rvba | mgz: ok, I'll have a look. | 13:13 |
| allenap | mgz, jam: It looked good to me a day or two ago. rvba, any Django-expert reservations about tag-tables? | 13:20 |
| smoser | rvba, so did we decide what '--ip=' is supposed to do to mean when given to 'maas config_master_dhcp' | 13:22 |
| rvba | mgz: jam allenap, that change looks good to me. | 13:22 |
| mgz | ace, thanks guys | 13:24 |
| jam | mgz, rvba: thanks, submitted. | 13:25 |
| mgz | hm, for migrations, should they be strictly linear? so, I should base my branch off any existing migration branches so we don't get two 0026-s? | 13:25 |
| jam | mgz: i think allenap is the one to ask, but it does look that way to me | 13:26 |
| rvba | mgz: it's very important that you merge trunk first and regenerate the migration if necessary. | 13:26 |
| mgz | I'll pull and rebase then, thanks. | 13:26 |
| rvba | South puts the complete state of the models in every migration. It uses the last migration to compute diffs when you change a model. | 13:27 |
| rvba | I suppose you can see how wrong this can go :) | 13:27 |
| mgz | yeah, just looking at that, why record all models, even the completely unrelated ones? | 13:28 |
| rvba | Yeah, it's a bit stupid but even if South was smarter that would not solve all the potential problems. | 13:29 |
| rvba | mgz: the rule of thumb is that if you see someone created a migration while you were working on yours, you have to merge and *recreate the migration*. Rebasing won't be enough. | 13:31 |
| jam | mgz: you have to change your needsfixing to approve | 13:31 |
| jam | rvba: isn't it possible to rm *my_migration, 'bzr merge theirs/trunk', bin/... --auto ? | 13:32 |
| rvba | mgz: because if the other migration added a field, your new migration (if you simply rebase) won't have that field and so the state in the latest migration will be wrong (that new field will be missing). | 13:32 |
| rvba | jam: absolutely. | 13:32 |
| rvba | That's what I meant by 'recreate the migration' | 13:32 |
| mgz | jam: didit. | 13:33 |
| jam | allenap, rvba, mgz: I'm looking at adding an API equivalent to Nodes.list() for Tag.list() | 13:50 |
| jam | I'm noticing that nodes have some NODE_PERMISSION.VIEW etc stuff. | 13:50 |
| jam | should we be setting ownership for tags similarly? | 13:50 |
| mgz | hm, I'd say not | 13:51 |
| === cmagina_ is now known as cmagina | ||
| mgz | tags are an adminny thing, but don't really have ownership, whereas nodes may need to be queried by non-admin users | 13:51 |
| rvba | I think this will complicate things for little added benefit. | 13:51 |
| jam | rvba: I definitely agree it will complicate things. I just don't know the Maas users model very well. | 13:54 |
| jam | If it would be a problem that user A created a tag, and user B would have access to change it. | 13:54 |
| rvba | jam: is tag editing something that is accessible to all users? | 13:56 |
| mgz | rvba, I think not. | 13:56 |
| jam | rvba: is tag editing something that should be restricted to specific users? If so, which ones? | 13:56 |
| jam | I can give answers, but I don't have the depth of background to know for sure that they are good ones. :) | 13:57 |
| jam | we can certainly say must be superuser or somehow marked as admin? | 13:57 |
| rvba | That sounds reasonable to me to restrict that to admin users. | 13:57 |
| rvba | But I can't say I have looked at the use case in great detail. | 13:58 |
| jam | rvba: so there seems to be 'User.is_superuser' and 'User.is_staff' | 14:01 |
| rvba | jam: 'is_staff' means 'can access the admin site'. | 14:02 |
| rvba | jam: in MAAS, we only use 'is_superuser'. | 14:02 |
| jam | right, which sounded like an admin to me | 14:02 |
| jam | k | 14:02 |
| rvba | roaksoax: Hi Andres. It turns out we can land the branch we discussed yesterday which creates the rabbitmq user used for celery communications. Right now, both the celery worker and the MAAS server use the same file to get the broker credentials. So the change I'm proposing in https://code.launchpad.net/~rvb/maas/packaging.set-rabbitmq-creds/+merge/125248 can be applied right now. | 14:07 |
| rvba | roaksoax: I've added (upsteam) a file named contrib/maas_local_celeryconfig.py. That file is loaded from celeryconfig and should contain the location-specific BROKER_URL. It's that file that my change in the packaging modifies. | 14:09 |
| roaksoax | rvba: alright, I'll look at it later today | 14:10 |
| rvba | roaksoax: this works exactly as contrib/maas_local_settings.py works but of course I'll need you to help me out with the packaging branch and the testing as I might have missed some things. | 14:10 |
| rvba | roaksoax: cool, thanks a lot. | 14:10 |
| roaksoax | rvba: hold on | 14:12 |
| roaksoax | rvba: we are shipping a celeryconfig.py and now a maas_local_celeryconfig.py? | 14:12 |
| roaksoax | rvba: and that file is symlinked to usr/share/maas/celeryconfig.py | 14:13 |
| rvba | roaksoax: yes, I'm ok to change that it you can think of a better way, but this is exactly the same as what we've done with src/maas/settings.py and contrib/maas_local_config.py. | 14:13 |
| roaksoax | rvba: cant it just be the same file ? celeryconfig.py and maas_local_celeryconfig.py? | 14:13 |
| rvba | roaksoax: well, one is part of the package and the other one is populated at install time. | 14:14 |
| rvba | I thought this was the right way to do it. But I'm happy to do that differently if you think that's better. | 14:14 |
| rvba | roaksoax: maas_local_celeryconfig.py only contains the things that are specific to each installation, right now only the BROKER_URL param. | 14:15 |
| roaksoax | rvba: i'll take a look first, and then will let oytu know | 14:15 |
| rvba | roaksoax: all right. | 14:15 |
| roaksoax | rvba: so celeryconfig.py will be installed in usr/share/maas/ and maas_local_celeryconfig.py installed in /etc/maas and symlinked to usr/share/maas right? | 14:15 |
| rvba | roaksoax: yes. | 14:16 |
| rvba | roaksoax: celeryconfig.py is not meant to be changed by a user. | 14:16 |
| roaksoax | rvba: alright | 14:16 |
| roaksoax | allenap: ping | 14:17 |
| === matsubara-afk is now known as matsubara | ||
| mgz | urk, datamigration hiccough, I need to transfer stuff from metadataserver to maasserver... which are managed seperately by south | 14:28 |
| mgz | is there something magic I need? | 14:28 |
| mgz | ...the south docs seem to cover it at least | 14:32 |
| jam | anyone know a way to get nose to only run the tests associated with one test class? | 14:38 |
| jam | I want to add my tests into test_api, but that is 200+ tests that I don't need to run every time. | 14:38 |
| mgz | the first arg should extend down from modules into test classes as per -s on bzrlib, no? | 14:39 |
| jam | mgz: when I do it (as I think it would look) I get 0 tests run | 14:40 |
| jam | it seems to only match at the Module leve | 14:40 |
| jam | level | 14:40 |
| jam | mgz: bin/test.maas --exclude=Node maasserver.tests.test_api.TestNodesAPI | 14:41 |
| jam | for example | 14:41 |
| jam | well, remove the --exclude, just a sec | 14:41 |
| jam | yeah, still 0 | 14:41 |
| jam | bin/test.maas maasserver.tests.test_api.TestNodesAPI | 14:41 |
| jam | note that if you have a typo | 14:42 |
| jam | such as | 14:42 |
| jam | bin/test.maas maasserver.tests.test_api.TestNodesAPIXXXX | 14:42 |
| jam | then it tells you no-such-attribute | 14:42 |
| mgz | ...that's no fun | 14:42 |
| jam | mgz: http://nose.readthedocs.org/en/latest/usage.html looks like you need to use a : | 14:43 |
| jam | bin/test.maas maasserver.tests.test_api:TestNodesAPI | 14:43 |
| rvba | jam: mgz: you can use ./bin/maas test src/maasserver/tests/test_api.py:TestNodeGroupAPI | 14:49 |
| rvba | or even, to run a particular test: ./bin/maas test src/maasserver/tests/test_api.py:TestNodeGroupAPI.test_method | 14:49 |
| jam | rvba: yeah, you can use the python path, or the filename path, and then a :Class, it just took me a while to find the ':' magic. | 14:49 |
| rvba | jam: there is a note about that in HACKING.txt ;) | 14:50 |
| mgz | rvba: I don't suppose you know the exact form of the filenames in NodeCommissionResult | 14:51 |
| allenap | roaksoax: pong | 14:51 |
| mgz | I'm reading etc/maas/commissioning-user-data but my bash is not good enough to be confident that I understand the exact form | 14:52 |
| mgz | it looks like it should be 01-lshw.out, but will it be absolute including /tmp or does one of the bash magic things make it relative? | 14:52 |
| jam | mgz: fargs="$fargs --file=${file##*/}" | 14:54 |
| jam | I think that means strip all the beginning | 14:54 |
| jam | everything up to a '/' | 14:54 |
| jam | mgz: see man bash, and /## | 14:55 |
| jam | (grep for ##) | 14:55 |
| mgz | thanks, and it's greedy with the double hash | 14:56 |
| jam | mgz: also see the python code, which does files[os.path.basename(fpath)] = ... | 14:56 |
| jam | that leaves a lot of open file handles lying around. | 14:57 |
| jam | mgz: should I expose tag URIs by their tag name? or by their tag.id? | 14:57 |
| jam | (nodes are expose by their system_id | 14:57 |
| jam | which is probably closer to name than DB id) | 14:58 |
| mgz | the name seems preferable | 14:58 |
| rvba | mgz: no, sorry, my bash-fu is not strong enough for me to be really confident with that script ;) | 14:59 |
| rvba | mgz: using the name seems much better to me too. | 14:59 |
| roaksoax | allenap: apiclient needs only python-oauth or httplib2 too? | 15:01 |
| mgz | "The model 'nodecommissionresult' from the app 'metadataserver' is not available in this migration." | 15:07 |
| mgz | that is not encouraging... | 15:07 |
| allenap | roaksoax: I'll check | 15:08 |
| allenap | roaksoax: Only python-oauth right now, but it will soon require python-httplib2. | 15:09 |
| roaksoax | allenap: ok will update the package when that happesn | 15:10 |
| roaksoax | allenap: i separated apiclient from maascli | 15:10 |
| roaksoax | allenap: it *is* required by provisioningserver | 15:10 |
| allenap | roaksoax: Cool. | 15:10 |
| mgz | hopefully --freeze metadataserver is not harmful... | 15:10 |
| jam | mgz: if you are curious: lp:~jameinel/maas/tag-list-api now has exposed a '/tags/' api and a '/tags/<name>/' api. They don't really do much yet, but it is a start. | 15:11 |
| jam | i'll poke at it a bit more later, but it is time for dinner now. | 15:11 |
| mgz | jam: ace, will have a look | 15:12 |
| mgz | the sampledata doesn't include anything from metadataserver though, so I'm not sure how confident I am of this migration code | 15:13 |
| mgz | and migrations don't seem very testable... | 15:13 |
| roaksoax | allenap: cna we already start nodes from your cli? | 15:14 |
| roaksoax | rvba: around? | 15:26 |
| roaksoax | jtv: around | 15:26 |
| roaksoax | ? | 15:26 |
| roaksoax | allenap: around? | 15:26 |
| rvba | roaksoax: yep. | 15:26 |
| mgz | I take it no one minds if I add more sample data | 15:26 |
| roaksoax | rvba: were there any recent changes with the PXE templates? I'm getting AssertionError: No PXE template found in '/usr/lib/python2.7/dist-packages/provisioningserver/pxe'! | 15:27 |
| rvba | roaksoax: not that I know of… let me have a look at the commit history. | 15:28 |
| rvba | roaksoax: looks like this might be a side effect of the changes introduced in revision 1025. allenap, can you help us out here, I see you've reviewed that change…? | 15:30 |
| roaksoax | rvba: ok I figured it out, it seems due to the fact that when you start a node and the node is not allocated to anybody | 15:32 |
| roaksoax | the node still pxeboots | 15:32 |
| roaksoax | and before we had a poweroff thing i think | 15:32 |
| roaksoax | matsubara: the issue that you were seeing when booting and getting stuck, was on commissioning right? | 15:35 |
| matsubara | roaksoax, enlisting | 15:36 |
| matsubara | roaksoax, oh wait, you mean the ipmi thing? or the image issue? | 15:36 |
| roaksoax | matsubara: the image issue. I'm getting a similar issue with quantal images | 15:37 |
| matsubara | roaksoax, the image issue happened during enlisting. It was due to some changes to kernel options passed on that smoser knows more about | 15:40 |
| roaksoax | matsubara: kyeah | 15:41 |
| roaksoax | alright | 15:41 |
| roaksoax | mine seems unrelated after all | 15:41 |
| smoser | roaksoax, what are you seeing ? | 15:42 |
| smoser | i am close to being able to have quantal images produced as 'daily' | 15:42 |
| smoser | all the changes are into archive except for 1 (mountall bug 643289) | 15:43 |
| ubot5 | Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289 | 15:43 |
| roaksoax | smoser: nothing really, my own dumbness i guess | 15:43 |
| roaksoax | smoser: your change to the console output made me think there was an error on quantal installer | 15:43 |
| smoser | ah. yeah. i can see that. | 15:45 |
| smoser | so we need to make that easily configurable. | 15:45 |
| smoser | as your usecase is not unreasonable | 15:45 |
| smoser | but in "hyperscale", i surely dont think anyone is going to be watching video consoles | 15:45 |
| roaksoax | indeed | 15:45 |
| smoser | and serial console is very likely to be loggable | 15:45 |
| roaksoax | smoser: do you know why libvirt might not be be serving DNS anymore? | 15:49 |
| smoser | what do you mean. | 15:50 |
| roaksoax | smoser: for some reason, the machines I deploy on libvirt, i.r. <host mac='00:16:3e:3e:aa:01' name='node01' ip='192.168.123.101' /> | 15:50 |
| roaksoax | no longer resolve | 15:50 |
| roaksoax | to the dns name | 15:50 |
| smoser | oh. you mean in vdenv ? | 15:57 |
| roaksoax | smoser: Yep | 15:57 |
| smoser | i'm not sure. i've not used in a long time. | 15:57 |
| smoser | it*should* work :) | 15:57 |
| roaksoax | yeah it was working | 16:03 |
| roaksoax | for some reason it no longer does | 16:03 |
| roaksoax | oh well | 16:03 |
| roaksoax | smoser: could you please? https://code.launchpad.net/~andreserl/maas/packaging_maas_client_improvements/+merge/125507 | 16:15 |
| smoser | roaksoax, can you clarify for me? | 16:23 |
| smoser | python -c 'import apiclient' | 16:23 |
| smoser | is that how you'd use this "apiclient" ? | 16:23 |
| smoser | because that is a flat out broken name. | 16:23 |
| roaksoax | smoser: that's how upstream has it | 16:24 |
| smoser | ie, 'python -c import maas_apiclient' | 16:24 |
| smoser | yeah, thats broken. | 16:24 |
| roaksoax | smoser: unless, that all gets installed as a private module | 16:25 |
| smoser | what do you mean ? | 16:26 |
| roaksoax | smoser: install it in /usr/share/maas | 16:26 |
| smoser | i'll open a bug on it. | 16:27 |
| smoser | its just bad though. | 16:27 |
| roaksoax | i agree, but that's what private modules in packaging terms are for I guess | 16:28 |
| roaksoax | though that isn't really that private | 16:28 |
| smoser | upstream maas has essentially claimed the names 'provisioningsever', 'metadataserver' 'maasserver' and now 'apiclient' | 16:28 |
| smoser | i'm perfectly fine with | 16:28 |
| smoser | python -c 'import maas.provisioningsever' | 16:28 |
| roaksoax | smoser: right, thought that's why we can change the installation path to be a private module rather than a public one | 16:30 |
| roaksoax | i don't know, however, how things will be affected | 16:30 |
| roaksoax | we'll definitely have things broken | 16:30 |
| smoser | https://bugs.launchpad.net/maas/+bug/1053507 | 16:31 |
| ubot5 | Ubuntu bug 1053507 in MAAS "maas installs python modules with out any namespacing" [Undecided,New] | 16:31 |
| roaksoax | smoser: but I agree with you, it should be maas.XYZ | 16:31 |
| roaksoax | maas.apiclient maas.provisioningserver etc etc | 16:31 |
| * roaksoax lunch | 16:33 | |
| === matsubara is now known as matsubara-lunch | ||
| === matsubara-lunch is now known as matsubara | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!