User1: User2 why would maasserver tests do this?
User1: ImportError: cannot import name oauth
User1: I can't reproduce in bin/py
User2: Isn't that the python-django-piston problem?
User2: Where _on our dev systems_ you got this error if you installed python-django-piston, but on Q/A systems you didn't?
User1: grar
User1: I'll remove the egg and see
User2: We ended up with the hypothesis that it was caused by mixing buildout and packages.
User1: yeah
User1: buildout's copy needs to be junked,we can't use it at all
User2: Still a load of test errors?  Damn.
User1: down to 11 failures, 6 errors
User1: from testresources import FixtureResource
User1: ImportError: cannot import name FixtureResource
User1: hmm
User2: Latest version on pypy is from January; still has FixtureResource in __init__.py as before.
User2: *pypi
User1: python-testresources 0.2.4-1ubuntu1 doesn't have it
User3: Uhm
User1: wtf
User3: so check what that ubuntu1 upload is
User3: someone may have uploaded without sending upstream
User3: trunk is :
User3: revno: 60
User3: tags: 0.2.5
User3: branch nick: trunk
User3: timestamp: Fri 2012-01-27 17:59:50 +1300
User1: yeah it should be in 0.2.5
User1: I have the egg with it in
User1: why is my buildout not picking it up
User1: oh god
User3: 0.2.5 is on pypi
User1: it's not packaged, that's all
User1: but I  thought buildout would pick the egg over the installed package based on version
User1: seems not :(
User3: nope
User3: it trusts you have it all, if you allow it to use system packages at all
User1: something in my quantal upgrade must have pulled it in
User1: Down to: FAILED (SKIP=1, errors=7, failures=2)
User2: User1 need anything reviewed for that?
User1: no, removing the package fixed itg
User2: Well, any of the fixes you came up with?
User1: User2 can you look at the top error here
User1: http://paste.ubuntu.com/1218063/
User1: yeah, starting on fixes now :)
User2: See?  I've been waiting for a chance to get in on this :)
 * bigjools grabs a sandwich, back in 10
User2: That top error is a Django-specified method in our XMLField getting hit by a signature change.
User2: Looks fixable.
User1: yeah
User1: also means blue squad is not on quantal :)
User2: Review? https://code.launchpad.net/~jtv/maas/quantal-get_db_prep_lookup/+merge/125632
User2: I'm trying to test it on a quantal canonistack instance, but having some trouble getting set up.
User1: ok
User2: Did you get buildout complaining that it can't find lxml 2.3.2?  I'm trying 2.3.5 instead.
User1: nope
User2: (My fix does pass tests on precise)
User2: Could you be unwittingly benefiting from caching or something?
User2: Like lxml 2.3.2 not being available for quantal, but buildout using your existing egg oblivious to the upgrade?
User1: running tests with your branch
User1: I have 2.3.2 in cache
User4: I'm trying to run just 'make test', but it is failing because testscenarios has no attribute WithScenarios.
User1: morning jam
User4: hi bigjools
User1: User4 hehe - see my email to maas-devel
User4: this seems to only be in 'maastesting' vs 'maasserver' so I can skip it
User1: are you on quantal?
User4: User1 this is on precise, though, not Q
User1: ok
User1: do you have python-testresources installed?
User1: if so remove it
User1: User2 approved
User2: thx
User1: passes tests now
User1: well, that one does
User2: Damn, there goes my momentary elation
User1: User2 although, it seems to have made the NoRabbit errors go away too
User1: no idea how!
User2: Urr
User1: 2 failures left
User2: Well don't complain.  :)
User1: both apidoc
User2: Yeah
User2: And suspiciously dependency-no-longer-works-the-way-we're-used-to-like.
User1: whut?
User4: User1 'make' installs testresources
User4: so it is listed as a dependency
User1: ha
User2: Oh joy my canonistack instance is full
User4: I don't have it from 'apt-get install', though.
User4: so I should do 'apt-get install' and try to match that version to the one for buildout?
User1: User4 oh that is fine
User1: no, you need the buildout one
User1: the one we need is not packaged
User4: k
User1: User4 so I have no idea why you get that error then, it works fine here
User1: you could see which actual file it's importing to make sure it's the one you expect
User4: User1 the isolation doesn't seem to be working properly.
User4: it is loading the system testscenarios (which was later than the buildbot one)
User4: I'm surprised it loads from system before loading from buildbot
User4: note that I need testscenarios for other code
User1: apt-get remove python-testresources
User4: so I can uninstall it for now
User4: User1 apt-get remove python-testscenarios
User4: not resources
User4: however,
User1: oh
User4: I will need it to do u1db tests
User1: we set up buildout to prefer system packages
User4: so if bin/test would load from buildout cache before system, my life would be better
User4: User1 isn't the whole point that buildout should override system?
User1: it does, if you tell it to
User4: (use system if it matches, but use the custom defined one if present)
User1: I mean, it doesn;t compare versions
User1: so if you tell it in buildout.cfg you want that package, then it'll use it
User1: unless it's already installed
User1: I think it was done like this to reduce the dependency on pypi, otherwise it downloads a lot of stuff
User4: User1 I have testscenarios 0.3 installed in ~/.buildout/eggs
User4: I also have 0.2? installed in /usr/lib
User4: but when I run 'bin/test' it loads the system one
User4: not the buildout one
User1: yes that's expected
User4: User1 I'm pretty sure the 'reduce dependency on pypi' was that it wouldn't download packages whose versions you already ha
User4: had.
User1: sadly buildout does not compare versions :(
User4: User1 it did for me with ipython-0.12 vs ipython-0.12.1
User4: when versions.cfg said 0.12 and I had 0.12.1 installed globally
User4: it would try to download until I updated
User4: the versions.cfg to point to 0.12.1
User4: now, possibly at *runtime* it doesn't compare versions
User4: but it does seem to at 'make' time
User1: User4 it didn't download because you had a system one installed
User1: it ignores versions completely
User4: User1 it *did* download until I made the version in versions.cfg match the system one
User4: I'm quite sure about that
User1: oh?  lifeless ^ ?
User3: ?
User3: User1 whats up ?
User1: User3 version thing you mentioned earlier
User3: User1 if there is a pth file or egg metadata
User3: User1 if there isn't, I don't think it can tell, and that will depend on the package
User4: so I think what you want is for the 'build' step to say 'if you have the version in sys.path, use it, else download to the egg cach', and then the 'run' step to say 'if it is in the egg cache, use it, else use the system one'
User4: just found out today that there is a 'great firewall of UAE': http://www.du.ae/Documents/Annex%201-IAM%20Regulatory%20Policy%20ver%201%200%2029July2008.pdf
User4: I was a bit surprised that online dating is one of the blocked sites.
User4: "social networking" is listed, but isn't that facebook/twitter/g+ ?
User4: and those certainly aren't blocked
User2: Yeah, blocked in many countries though.
User4: User2 yeah fb was blocked in syria for a while, might even be now with the fighting
User2: Usually all kids and subversives know how to get around it, but âdecentâ people get kept out of the 21st century.
User4: User2 well the first blocked thing is places that let you get around blocking
User4: but there are lots of ways to do that :)
User4: but VOIP is also prohibited
User4: I guess because phone calls are expensive here, and they want to keep their monopoly
User4: (something like $0.40/min to call internationally)
User2: Here too, as are VPNs.  We've had Google's appserver blocked, dropbox, twitter, youtube...  The consequences of blocking aren't usually taken into account because the people who do this are rarely fully aware of what they're damaging.
User2: Didn't the UAE also have Etisalad with its infamous *.com SSL certificates?
User4: User2 the main carrier here is Etisalat (has been for a long time) I hadn't heard about *.com though
User4: that's pretty worrying
User4: my *specific* carrier is the only competitor Du, but that is just because of whatever region I'm in
User2: Yup.  Issued for the purpose of censorship.  Trusted by all clients, at least until a recent surge of awareness.
User2: My understanding is that typically these countries regulate their incumbent carriers' censorship policies onto other carriers as well.
User4: User2 the ultimate MitM attack, carried out by your provider, and government approved.
User2: CA-approved even.
User4: which is why when the government does it, it is so much scarier than when j-random-citizen tries
User1: quantal is doing my head in, no sound at all today
User2: Time to start thinking about dual-boot setups.
User2: So that you can track which of your hardware is really, natively supported in the upgrade before you commit fully.
User2: I got a message saying that I may not have a usable desktop after the upgrade.
User4: User2 there is some way to get raw content out of django, though, as I think we're trying to do that for the xmlfield
User4: (for the file storage discussion)
User2: You mean you support a choice of encodings in the xml, without re-encoding for storage purposes?
User4: User2 https://docs.djangoproject.com/en/dev/howto/custom-model-fields/https://docs.djangoproject.com/en/dev/howto/custom-model-fields/
User4: User2 actually, we are just trying to make it so we can run custom xpath_* queries
User4: which isn't directly supported by django
User4: but it sounds like something that would let you do bytea as well.
User1: User2 what did you think to my packaging suggestion?
User2: It may have been something to do with the dynamicism of field conversions in django.
User2: User1 saw the thread, but didn't look too closely.  Which was your suggestion?
User1: User2 you need to read it
User1: it's a little involved
User2: OK, I'll dig it up
User2: User4 when you write field conversions in django, you get very little information about what the intended conversion is.  Basically you get âa value,â and it's up to you to figure out whether that needs any conversion.  Sometimes the conversion seems to go in unexpected directions, too.
User2: User1 your suggestion sounds good to me â but then I never got around to understanding the distribution of responsibilities between maas-dns and maas-dhcp.  Until recently I thought maas-dhcp was de facto the seedling of the cluster-controller package.
User2: (Small note: the provisioning server may require maas-cli, since it uses apiclient)
User1: gah
User2: Meanwhile, my experiments on quantal suggest that we need: https://code.launchpad.net/~jtv/maas/quantal-updates/+merge/125634
User1: User2 why do we need bzr?
User2: Ohhhh â that's the one Gavin added for now-unclear reasons, innit
User1: commandant
User1: I think it can go, I asked on the list earlier
User2: In any case, 2.5.1 will break the build and 2.6.0b2 doesn't.
User1: 2.5.1 works here
User2: Cached?
User1: well - it gets downloaded
User2: hmmm
User2: On a fresh canonistack instance it said no distribution found.
User1: nfi then
User2: Ahh, I think that was before I ran an upgrade on it.
User1: also, why are we specifying precise versions
User1: why not > <version>
User2: Didn't know you could.
User1: or >=
User2: I guess ideally at this stage, we'd be tracking Quantal's versions.
User1: I'd rather not be specific
User1: we have to QA it either way
User2: Doesn't that carry a risk of accidentally relying on changes that are newer than what quantal has/
User2: ?
User1: no, because we have to QA it
User1: we should only get specific when a particular problem is found
User1: otherwise we'll forever be amending versions in buildout.cfg
User1: versions.cfg even
User2: Soâ¦ want me to slap in a bunch of â>=â then?
User1: we need to review it, but don't do it now.
User2: OK
User1: your point above would equally apply to relying on versions that are less than quantals
User2: I do find I need a newer lxml though.
User2: Yes, absolutely.
User1: ok
User2: What was causing that piston error about _is_string again?  You had a fix for that, right?
User1: yeah remove your local piston egg and cache
User1: we need to remove it from buildout and put it in required-deps
User2: Weird.  This is on a clean system.
User4: User2 I'd be interested in voice chatting with you about: https://code.launchpad.net/~jtv/maas/node-nodegroup-api-ui/+merge/125624
User1: the only use of bzrlib that I can find is src/maascli/__init__.py:from bzrlib import osutils
User4: just to get an understanding of that system, and review your code while I'm there.
User2: User4 OK â but I'll need a few moments to prepare.
User4: User8 you are using osutils.get_unicode_argv(), but it seems to be the only use of bzrlib
User4: Is there a plan to use more? Or can we just split out that code rather than bringing in all of bzr as a dependency?
User1: yes I was wondering the same
User4: right, so it was certainly useful for commandant
User4: but now that we aren't doing that
User4: the dependency is quite small
User1: allenap won't be around for about 2 hours though
User2: User4 ready now â name your medium
User4: User2 whatever is your favorite :)
User2: Face to face over coffee!?
User4: User2 that would be best, I agree
User2: Deal.
User2: Until you get here, I'll set up a hangout.
User2: User4 I've invited you.
User2: User1 removing my piston egg didn't help, and I don't think I have a cache.  Wonder what else could be going on.
User1: User2 clean and rebuild
User1: well just make check will do that
User1: this definitely fixed things for me earlier
User2: Not for me.  :(
User1: User2 have you installed the quantal python-django-piston?
User1: it has the fix in it
User1: for sure
User2: I don't even see it in my available packages.
User1: you need 0.2.3-1ubuntu2
User2: Guess I need some repository that isn't configured.
User1: like quantal? :)
User1: it's right there https://launchpad.net/ubuntu/+source/python-django-piston/0.2.3-1ubuntu2
User2: This is a quantal instance.
User1: apt-get update
User2: I wonder why it doesn't pick up the existence of that package.
User2: Yeah, been doing that.
User1: how are you trying to install?
User2: dselect
User1: ?!
User2: Nothing there with âpistonâ in the name.
User1: apt-get install python-django-piston
User1: if you want to query availability, use "apt-cache search <thing>"
User2: !?  How can that work in apt and not dselect?
User5: User2 I am only a bot, please don't think I'm intelligent :)
User2: Oh shut up.
User1: dpkg -l <package> shows if it's installed
User2: I know about apt-cache search, it's just a hassle compared to interactive pattern searching.
User1: don't use dselect
User2: But why doesn't it see the package?
User2: Oh God it has its own cached package listsâ¦
User1: NFI
User1: I don't even have it installed
User1: friends don't let friends use dselect
User2: I've been used to it for about a decade.
User2: I found it friendlier than aptitude.
User1: don't use aptitide
User1: aptitude even
User1: while it works most of the time, it does have a different dependency resolver to apt, and apt is the reference
User1: User2 https://code.launchpad.net/~julian-edwards/maas/fix-quantal-piston/+merge/125638
User2: Some people swear by aptitude's resolver, apparently.  Again, I'm more used to apt's.
User1: it can offer some interesting resolutions to conflicts, but they are likely to break things even more.
User2: Reviewed.
User1: cheers
User2: Had some weird trouble with the âlxml >= 2.3.2â in Precise, will try in Quantal.
User1: oh?
User2: The error is one of those things that make you go âyes, andâ¦?â
User2: Â«Error: Picked: lxml = 2.3.5Â»
User1: :)
User1: oooooo I know
User2: Let's turn that smile up-side down.
User1: we have explicit versions turned on iirc
User1: bugger
User1: allow-picked-versions = false
User1: bugger
User1: why, I wonder
User1: we really need to start uding system packages more instead of pypi
User1: using*
User1: morning rbasak
User1: argh
User1: morning rvba
User6: Hi bigjools.
User2: Hi rvba
User6: \o jtv.
User2: Yes, rbasak does raise the suspicion of queue-jumping.
User1: I have to reboot, because plugging in new usb device seems to still have a bug that is now about 4 years old which makes the mouse disconnect >:(
User2: It'll get triaged any day now, I'm sure
User1: srsly annoying.
User1: brb
User2: User6 would appreciate your input on the django incantations I applied here â https://code.launchpad.net/~jtv/maas/node-nodegroup-api-ui/+merge/125624
User6: User2 ok, I'll have a look.
User2: Thanks
User1: User6 did you see my packaging suggestion around clusters etc?
User6: User1 not yet.
User1: User6 check out maas-devel
User6: Reading it right now.
User6: User2 I've reviewed your branch.  Looks ok but I've got a few remarks.
User2: Thanks for the additional notes.
User6: User1 I've made some experiments on how to route tasks in celery yesterday btw.
User1: User6 cool, all ok?
User6: User1 yes, queue creation works, routing ok, broadcast messages ok.
User7: User2 thanks for fixing the get_db_prep_lookup thing
User2: np
User1: good - I played around a long time ago and it was ok in my experiments so good to hear you went well too
User2: I'm happy at last to have validation for my habit of âif it's somebody else's signature, accept *args & **kwargs and pass them in the upcall.â  :)
User1: GNARGH
User6: User1 btw, when running the test suite on quantal, I've got only 2 failures, all related to the api doc.
User1: usb disconnection AGAIN
User1: User6 yes that is all that is left now
User6: User1 not so bad after all then :)
User1: User6 that's because we've been fixing them all day ;)
 * bigjools reboots AGAIN
User8: jam, User1 Yes, bzrlib's there just for osutils. I considered breaking out that code. It's a big dependency, but I think it's fairly low priority to fix that.
User4: User8 i guess bzr=2.5.1 fails on Q because bzr-2.6b? is there
User7: jam, jelmer: http://pastebin.ubuntu.com/1218325/
User7: when do I need to care about django model identity...
User7: self.assertEqual(xmlbytes, Node.objects.get(id=node.id).hardware_details)
User7: self.assertEqual(xmlbytes, node.hardware_details)
User7: not equivalent
User7: what I want it seems:
User7: self.assertEqual(xmlbytes, Node.objects.get(id=node.id).hardware_details)
User7: self.assertEqual(xmlbytes, node.hardware_details)
User7: bah! cp
User7: node = reload_object(node)
User4: poke mgz for great justice
User4: and jelmer for goodness sake
User7: jam, just about to nip out, but nearly there (despite django) with setting cpu_count/memory
User8: User4 Yeah, I think so. It's not able to arrange for an earlier version of bzrlib because we allow site packages.
User4: User7 just curious where your db patch is at, since I cant evaluate tags until we have the column
User7: ah, I still need to actually propose the branch...
User7: User4 pushed to lp:~gz/maas/temp and I need to run
User9: morning
User9: User6 is the webui only to be meant installed on the region?
User6: User9 yes
User9: cool
User4: I'm running into something strange with django.piston and nested fields
User4: It doesn't seem to restrict the output to just the fields that are specified
User7: User4 sounds like more joy
User4: User7 I'm trying to confirm w/ macaddress_set since that was doing ('mac_address',)
User4: but I can't seem to get it to only return just the 'name' and 'resource_uri' of the tag
User4: of related tags.
User7: User4 I can't get UPDATE to work at all in a raw query...
User4: User6 ^^ Specifically, I'm trying to expose tags, but just saying "NODE_DISPLAYED_FIELDS = (..., 'tags')" means the full tag gets exposed.
User6: User4 can't you apply what we've done with 'macaddress_set' (in DISPLAYED_NODE_FIELDS)?
User6: User4 DISPLAYED_NODE_FIELDS= (â¦, ('macaddress_set', ('mac_address',)),â¦)
User4: User6 that doesn't seem to do what we think it does
User4: I can't confirm mac_address yet, as I haven't found a test that actually tests the values in macaddress_set
User4: however, if I put ('tags', ('name', ))
User4: I still get all the fields
User6: User4 let me have a look at the code.
User4: User6 lp:///~jameinel/maas/tag-list-api
User4: has a failing test
User4: that shows what fields are being exposed.
User6: User4 cool, I'll have look.
User4: User6 and I see tests about 'POST_limited_fields' but none of them seem to test the actual content of the macaddress_set field, just that it exists
User6: User4 indeed.
User4: User6 and I do feel like what we are doing *should* work, from places like http://stackoverflow.com/questions/2215352/django-piston-how-can-i-exclude-nested-fields-from-handler-results-is-it-even
User4: and here: https://bitbucket.org/jespern/django-piston/wiki/FAQ#!why-does-piston-use-fields-from-previous-handlers
User4: but that doesn't seem to actually work
User4: jelmer: any update to where you got to?
User7: okay, I think I have code ready for the tag stuff now jam
User6: User4 I don't understand why it does not work.  I'll have to put my hazmat suit on and debug piston.
User4: User6 so at least I'm not crazy
User7: ...now kapil will wonder why you want to dress up as him...
User6: haha :)
User4: User7 https://code.launchpad.net/~jameinel/maas/tag-list-api/+merge/125697 up for review
User6: User4 I got it.
User6: User4 it's using TagHandler.fields.
User4: User6 which I thought the definition in NodeHandler is supposed to override it for exposing tags on node
User4: if you know a way to do it, I would be fine turning the tags attribute into a simple list of names
User4: rather than a list of objects
User6: User4 let me investigate some moreâ¦
User4: but we are using the default 'get' handler, and I don't know how to easily override it.
User7: User4 I have put up some branches for review
User6: User4 It does not seem to be possible to do that with piston (I even found a fork on github which adds this possibility https://bitbucket.org/liberation/django-piston); the only way is by adding a custom method like this: http://paste.ubuntu.com/1218559/
User4: User6 well, that change looks good to me, so I'll go with that. Thansk
User6: np
User4: User6 which is opposite to what I read https://bitbucket.org/jespern/django-piston/wiki/FAQ#!why-does-piston-use-fields-from-previous-handlers
User4: but hey, tag_names actually works better for my purpose, I think
User6: User4 right, but the code right here overrides the list of fields with the list from a registered emitter: https://bitbucket.org/jespern/django-piston/src/c4b2d21db51a/piston/emitters.py#cl-160
User4: User6 well, update pushed. Your code actually nests the values because 'values_list' returns a list of tuples, but you can unwrap them and get it to work.
User6: User4 ah, right.
User6: User4 values_list('name', flat=True) will solve that for you :)
User2: roaksoax, are you here?
User2: It's about bug 1053295.  I must have missed a step in introducing that upstart file into the maas-dhcp package.
User5: Launchpad bug 1053295 in MAAS "maas-dhcp does not install custom upstart script" [Critical,Triaged] https://launchpad.net/bugs/1053295
User10: User11 https://bugs.launchpad.net/maas/+bug/1054056
User5: Ubuntu bug 1054056 in MAAS "ephemeral images do not support multiple kernel flavours" [Undecided,New]
User11: gracias
User9: User2 yep
User2: Any idea what it might be?
User9: User2 yep :)
User2: What is it?
User2: (You're not getting to me.  vwells@example.net.  :)
User9: User2 missing  dh_installinit --name maas-dhcp-server
User9: User2 i'll fix it
User2: Ahhhh.  Â¡Muchas gracias!
User7: User4 https://code.launchpad.net/~gz/maas/populate_tags/+merge/125720
User7: whoops, forgot to set prereq branch
User12: where can I edit the cloud-init config for maas nodes?
User7: User4 and lp:~gz/maas/_try_migrate_hardware_details is my attempt at doing that migration... which still seems unhappy, but I'll have to look at that later
User7: ...without the leading underscore
User9: User6 https://code.launchpad.net/~andreserl/maas/install_maas_local_celerysettings/+merge/125735
User6: User9 s/etc/contrib/
User9: User6 yeah already pushed another branch
User9: User6 and in the packaging side we need to handle upgrades, not only installations :)
User9: User6 i'll get that done though
User6: User9 cool, thanks a lot.
User9: User6 i'll approve myself the setup.py branch
User6: User9 approved :)
User9: hehe :)
User9: User6 so there's 1 text conflict in debian/changelog, If you want you can fix that and push an updated branch or If you prefer I'll merge it myself against a local branch and resolve the conflict and push it back
User6: User9 I'll fix it, hang on.
User6: User9 I don't see the conflict.
User6: User9 if you're talking about ~rvb/maas/packaging.set-rabbitmq-creds, I've fixed the conflict yesterday.
User9: User6 did you pull the latest packaging branch?
User9: User6 http://pastebin.ubuntu.com/1218767/
User6: User9 hum, let me merge trunk againâ¦
User6: User9 conflict fixed.
User9: User6 thanks! i'll test it one more time and get it merged
User6: User9 ta.  Please review/test it carefully as I'm really no packaging expert.
User9: will do :)
User9: User6 https://code.launchpad.net/~andreserl/maas/maas_local_celeryconfig/+merge/125745
User9: User6 packaging needs to be updated from celerysettings to celeryconfig
User6: User9 you're right.
User12: where can I append some script to the cloud-init running on maas nodes?
User9: User11 ^^
User11: guimaluf, you mean in commissioning?
User9: User12 cloud-init is only used for enlistment and commissioning. Not for deployed maas nodes
User11: roaksoax, thats not true
User11: cloud-init is used on install also.
User11: juju provides cloud-init user-data to the provisioned nodes, it is available through the api
User9: User11 right, but what I mean is in already running nodes
User9: User11 i guess I should have said, not for already deployed maas nodes
User11: roaksoax, well actually i think that is wrong too :)
User11: cloud-init is installed, and active. it will run things as it it does on regular instances
User9: User11 right, but I dind't know that you can tell cloud-init, from maas, to do XYZ after the node was installed/configured
User9: :)
User12: exactly. so if I want to customize some new cloud-init script for new maas nodes, there is a way to do it, right?
User9: User11 so that's what I mean, after I have deployed a node with juju, it installed the service or whatever, does it continue to poll the mAAS meta-data server?
User9: User11 or for example, can i juju deploy something and tell it a cloud-config script to use?
User12: in deed I never get maas nodes to reach metadata server and get the maas-server ssh-key.
User9: User6 i'll do the update if that's ok with you?
User6: User9 have you been able to test the changes to the postinst script?
User9: User6 yeah, it works
User9: obviously changing s/celerysettings/celeryconfig
User9: User6 if you can change that real quick I'll merge your branch
User6: User9 you mean renaming the file in contrib/ right?
User9: User6 the file in contrib is already maas_local_celeryconfig.py
User9: User6 so packaging needs ot be updated accordingly
User6: User9 ah right.
User9: User6 so maas.install maas.links and maas.postinst needs update
User6: User9 ok, I'll update my branch.
User9: User6 cool, other than that it seems to work as expected
User6: User9 fix pushed.
User9: User6 BROKER_URL = 'amqp://maas_workers:T1A3Ksj5wiEfOe1VrDjl@localhost:5672//maas_workers'
User9: so that's what I end up having in maas_local_celeryconfig
User6: That's good.
User9: User8 ping
User8: User9 Yo.
User9: User8 so, what is the cli doing thus far? Can I alreay make changes to a node?
User9: User8 idk if you recall.. but during commissioning we need to be able to modify the node's information
User9: User8 and we were looking at having anonymous access
User9: specifucally to set up the power_parameters for ipmi autodiscovery
User8: User9 It does basic stuff, including setting things. However, not everything works :-/ Bug 1052867 and bug 1052872 are pertinent here.
User5: Launchpad bug 1052867 in MAAS "The metadata API description is not exposed" [Critical,Triaged] https://launchpad.net/bugs/1052867
User5: Launchpad bug 1052872 in MAAS "Anonymous handlers are not treated as subsets of their non-anonymous counterparts in the API" [Critical,Triaged] https://launchpad.net/bugs/1052872
User8: User9 There's probably a view missing from the metadata API too, for the anonymous setting of power parameters.
User8: I don't have a bug number for that.
User9: User8 alright, i guess we can look deeper into that next week
User8: User9 Cool, let's talk on Monday. Have a good weekend!
User9: User8 thanks you do aswell
maas
Ubuntu IRC