[01:23] <kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
[03:20] <kurt_> Can anyone tell me what the mechanism is in maas that copies ssh keys from ~/.ssh/id_rsa.pub to the boot image?
[03:21] <bigjools> kurt_: yes, 2 ways
[03:21] <bigjools> 1. juju does it for you if you use juju
[03:21] <bigjools> 2. you need to register them in maas against your maas user
[03:21] <bigjools> if you start a node manually use #2
[03:22] <kurt_> is this mostly done by maas, or juju?
[03:22] <kurt_> so, create your key, configure it in the settings, right?
[03:22] <bigjools> kurt_: is what done?
[03:23] <bigjools> if you are using juju you don't need to worry about it
[03:23] <kurt_> I guess I wondering what mechanism/script does a chroot and copies the key in your home directory to the image that gets booted?
[03:24] <bigjools> it gets passed via preseed data
[03:24] <kurt_> because, even though my clocks are all relatively up to date, I am having trouble with one or two servers booting
[03:24] <kurt_> (these are VMs again, remember)
[03:25] <bigjools> watch the console log when the VM boots
[03:25] <bigjools> it should give some info
[03:25] <kurt_> maas.log or the VM's console? (ie. dmesg or syslog/messages)?
[03:25] <bigjools> VM console
[03:27] <kurt_> kk - how does server/VM force a reseed of the pre seeded software? is there some way to force this?
[03:27] <kurt_> presided data rathere
[03:27] <kurt_> preseeded data rather
[03:28] <bigjools> kurt_: http://pastebin.ubuntu.com/1040179/
[03:29] <kurt_> thnx Julian
[03:29] <bigjools> np
[03:29] <kurt_> can you tell me when the next full release is scheduled vs git releases?
[03:30] <bigjools> you mean bzr? we don't use git
[03:30] <kurt_> apt-get update maas :)
[03:30] <bigjools> there's a point release scheduled with 12.04.01
[03:31] <bigjools> and it'll run without cobbler
[03:31] <kurt_> kk - are you guys looking at forcing delete even when node is in state "commissioning" or will that always be left to the shell?
[03:32] <bigjools> that's fixed in trunk already
[03:32] <kurt_> cool, nice to have
[03:32] <kurt_> will shell features be more completely documented? :)
[03:32] <bigjools> unlikely
[03:32] <kurt_> I've been learning what I know via newsgroups
[03:33] <kurt_> or postings
[03:33] <bigjools> they are for developer and debug usage
[03:33] <bigjools> we'll document supported stuff for sure
[03:33] <bigjools> but people are free to document unsupported stuff themselves :)
[03:34] <kurt_> If I can figure it out, I'm happy to ;)
[03:35] <kurt_> Like the section on the non-dhcp set up of maas :)
[03:35] <bigjools> that's not supported yet
[03:35] <kurt_> that will be really nice to have
[03:35] <bigjools> presuming you mean external dhcp
[03:35] <kurt_> I do
[03:36] <bigjools> it's not really something that we're concentrating on because it makes things much harder to use
[03:36] <kurt_> understood - get things working first
[03:36] <kurt_> get it solid
[03:36] <bigjools> well, the dhcp actions are integral to how maas operates
[03:36] <kurt_> yes!
[03:37] <bigjools> we're moving all this out of cobbler and into maas at the moment
[03:37] <bigjools> so when maas does it itself it should be  more obvious how to set it up manually
[03:37] <kurt_> because of the pxe stuff, this very much reminds me of clonezilla too
[03:38] <kurt_> a question about the documented system requirements - are those pretty strict?
[03:38] <kurt_> ie. 16 GB for the master node?
[03:39] <bigjools> I'm not sure, but it largely depends on the size of your cloud
[03:39] <bigjools> I am debugging locally on a 4GB box
[03:39] <kurt_> for testing and demo purposes, I'm just trying to put together a minimal functional installation
[03:39] <bigjools> which has a master and a few VMs running on it.  Admittedly it gets sluggish :)
[03:39] <kurt_> I don't care about performance at this point
[03:40] <kurt_> but what about the requirement of 9 nodes for openstack?
[03:40] <kurt_> is that strict, or just a "suggested" number?
[03:40] <bigjools> I don't know much about that
[03:40] <kurt_> my end goal is to get a functional openstack installation working
[03:40] <bigjools> ok
[03:40] <bigjools> we'd love to help
[03:40] <kurt_> ie. on top of maas
[03:41] <kurt_> and juju
[03:41] <bigjools> when are you normally around on IRC?
[03:41] <kurt_> I'm GMT -8 (PST)
[03:41] <kurt_> I'm on all day mostly
[03:42] <bigjools> ok - there are people who know more intricaces of the server stuff than me who are in -5
[03:42] <kurt_> and I am happy to contribute to the documentation and such
[03:42] <bigjools> cool
[03:42] <kurt_> this is great stuff you guys are doing btw
[03:42] <bigjools> I'm in GMT+10 so barely overlap with anyone
[03:42] <bigjools> glad you like it
[03:43] <bigjools> it's still a little raw but there's some cool stuff coming
[03:45] <kurt_> so you are a core developer, how many others?  Are you employees of canonical?
[03:48] <bigjools> yeah, there's me and 3 others working on the core web app
[03:48] <bigjools> and a few others doing packaging and server stuff
[03:48] <kurt_> are you dedicated, ie. full time on this?
[03:48] <bigjools> yup
[03:49] <kurt_> nice.
[03:49] <kurt_> I take it you are in austrailia or asia?
[03:49] <bigjools> yeah Brisbane
[03:49] <kurt_> excellent
[03:50] <kurt_> I almost went to work for a contract with Telstra a few years back
[03:51] <kurt_> my wife put the brakes on that :(
[03:52] <kurt_> did I see above you guys are trying to get rid of cobbler out of the equation?
[03:52] <bigjools> we are
[03:52] <kurt_> I think the more you can streamline this, the better
[03:52] <bigjools> cobbler is pretty horrible; the security team dislikes it and we don't think it will scale
[03:53] <kurt_> are you beginning to think of how things can scale in much larger deployments?
[03:53] <bigjools> not just beginning, it was a core goal
[03:54] <kurt_> what processes are the best candidates for scaling?
[03:54] <bigjools> not sure I understand
[03:54] <kurt_> scaling = spreading the love
[03:55] <bigjools> what do you mean by processes?
[03:56] <kurt_> for example maas-dhcp, which configures...
[03:56] <kurt_> trying to think of the dhcpd process used
[03:56] <bigjools> there are two :)
[03:56] <bigjools> dnsmasq or isc-dhcpd
[03:57] <kurt_> dnsmasq is what I was thinking of...
[03:57] <bigjools> we're not supporting dnsmasq when cobbler has gone
[03:57] <kurt_> what will take that function over/
[03:57] <kurt_> ?
[03:57] <bigjools> the other one :)
[03:57] <bigjools> it's more proven in large environments
[03:57] <kurt_> will it be capable of perhaps supporting VLANs?
[03:58] <kurt_> multiple large scale VLANs?
[03:58] <bigjools> vlans are orthogonal really
[03:58] <bigjools> network admins are free to set any topology
[03:58] <bigjools> we're just providing a worker on a per-subnet basis
[03:58] <kurt_> what kind of api's are you guys thinkng of?
[03:59] <bigjools> the existing API won't change much
[04:01] <kurt_> ok, I've bothered you enough tonight :)
[04:01] <kurt_> lol
[04:01] <bigjools> heh np
[04:01] <kurt_> thanks for fielding my questions...
[04:01] <bigjools> my pleasure
[04:01] <kurt_> I'll look forward to your releases
[04:01] <kurt_> bfn
[04:01] <bigjools> we look forward to you trying them out
[04:02] <kurt_> I'll be happy to give input
[04:06] <kurt_> what is your suggestion when clock is in sync, and VM gets stuck in "init: cloud-init-nonet main process (307) killed by TERM signal"?
[04:06] <kurt_> this has been killing me with only one of my VMs
[04:07] <kurt_> I've tried recreating the mac address, destroying and recreating the VM numerous times
[04:07] <kurt_> I have to manually delete the name via the maas sheel
[04:07] <kurt_> shell rather
[04:08] <kurt_> but always gets stuck in commissioning with that above problem
[04:11] <bigjools> that's rather odd
[04:11] <bigjools> is there no other clue as to why the SIGTERM happens?
[04:12] <kurt_> since I can't get access to the VM until its booted, I'm limited in what I can see
[04:12] <kurt_> I usually hard power the VM down
[04:13] <kurt_> is there some mapping associated with the naming?
[04:13] <kurt_> ie. my hosts name is maas02
[04:13] <bigjools> smoser or roaksoax, are you guys around? Any idea with the above?
[04:14] <kurt_> so is some key in the db maybe not being deleted and some artifact in the db remains that's being recycled?
[04:14] <kurt_> or some cobbler files that the maas shell doesn't delete that need to be manually deleted?
[04:14] <bigjools> what does cobbler think about the node's power details?
[04:15] <kurt_> can you tell me how to look?
[04:15] <kurt_> sorry…not cobbler saavy
[04:15] <bigjools> well it's turning it on so it's probably ok
[04:15] <kurt_> its not
[04:15] <kurt_> I have to manually boot
[04:15] <bigjools> aha
[04:16] <kurt_> vmware doesn't really support WOL
[04:16] <bigjools> well you can manually set the virsh parameters in cobbler
[04:16] <bigjools> it's not really supported but it'll work
[04:16] <kurt_> virsh = kvm, not vmware, right?
[04:17] <bigjools> vmware should work too
[04:17] <bigjools> not tried it personally
[04:17] <kurt_> is there some rtfm I can do around this?
[04:18] <bigjools> browse to localhost/cobbler_web
[04:18] <kurt_> Not Found
[04:18] <kurt_> The requested URL /cobbler_web was not found on this server.
[04:18] <kurt_> must it be on the local node?
[04:19] <bigjools> no it's on the maas server
[04:20] <bigjools> ummm different port
[04:20]  * bigjools tries to remember
[04:20] <bigjools> 8080?
[04:20] <kurt_> nope :)
[04:20] <kurt_> you have 64943 more tries ;)
[04:20] <bigjools> heh
[04:21] <bigjools> hmmmm it's possible that the web part is not installed
[04:21] <bigjools> you'd have to dink about in the command line
[04:21] <bigjools> there's an exe called "cobbler"
[04:22] <bigjools> it sounds like the cobbler DB is out of whack with maas anyway
[04:22] <kurt_> that sounds logical
[04:22] <kurt_> is there a sync process?
[04:22] <bigjools> the only way I know of fixing it is to delete the nodes on both sides
[04:23] <kurt_> how do I fully delete the node on the cobbler side? I think I know how to on the maas side
[04:23] <bigjools> you can sync manually but it's error prone
[04:23] <bigjools> via the cobbler web or command liner
[04:24] <kurt_> do I need to install the cobbler web application?
[04:24] <kurt_> and why do you guy want to get rid of cobbler?  Its so easy and painless?
[04:24] <kurt_> LOL!
[04:24] <bigjools> heh
[04:25] <kurt_> what are your timelines for getting rid of cobbler?
[04:26] <bigjools> ASAP
[04:26] <bigjools> couple of weeks
[04:27] <kurt_> so, if I begin to install cobbler-common, etc - is that going to overwrite some of the maas related configuration?
[04:27] <bigjools> yes
[04:27] <kurt_> ugh
[04:27] <bigjools> the packages conflict
[04:27] <kurt_> :)
[04:28] <kurt_> looks like I'm not going to be able to install cobbler-web
[04:28] <bigjools> fraid not
[04:29] <bigjools> the way I get around it is to install cobbler on a separate VM
[04:29] <bigjools> and point maas at it
[04:30] <kurt_> otherwise, I need to figure out the command line stuff, right?
[04:31] <kurt_> do any of your comrades have a better understanding of this part?
[04:32] <kurt_> I do see the problematic node is listed 3x:
[04:32] <kurt_> ituser@maas01:~$ sudo cobbler system list
[04:32] <kurt_>    default
[04:32] <kurt_>    node-2e11a386-b5c1-11e1-8715-000c29de71df
[04:32] <kurt_>    node-dc7aa15e-b5ce-11e1-8715-000c29de71df
[04:32] <kurt_>    node-ff6a0be4-b5d5-11e1-8b34-000c29de71df
[04:33] <bigjools> ah nice
[04:33] <bigjools> delete everything and re-add it
[04:34] <kurt_> I think I've tried that…but I'll try again
[04:34] <bigjools> make sure it's deleted in cobbler
[04:34] <kurt_> so, just do cobbler system remove --name=xxx for all, then relist the systems as shown above?
[04:35] <kurt_> or is there some other sync too?
[04:35] <kurt_> or other place in cobbler it needs to be deleted?
[04:35] <bigjools> remove in maas and cobbler
[04:35] <bigjools> make sure you do a cobbler sync
[04:35] <bigjools> as in the command "cobbler sync"
[04:35] <kurt_> ah, ok
[04:46] <kurt_> what is the difference between "cobbler sync" and "maas-import-isos" ?
[04:46] <bigjools> the former tells cobbler to sync its internal database
[04:47] <bigjools> the latter is the script that pulls the images from maas.ubuntu.com
[04:48] <kurt_> they look very similar in their functions
[04:48] <kurt_> i.e.,after images are downloaded
[04:49] <kurt_> maybe maas-import-isos does a cobbler sync as a part of its functions?
[04:50] <bigjools> it does
[04:51] <kurt_> k, I've managed to screw something up now.  web process is stuck.
[04:52] <kurt_> I removed all of those extra cobbler systems, but it somehow had an association with the newer mac adds associated with maas02
[04:52] <kurt_> so when I went to try to remove that via the web interface, things went south
[04:55] <kurt_> ah, like windows.  rebooting fixed everything :)
[04:58] <kurt_>   File "/usr/lib/python2.7/dist-packages/maasserver/provisioning.py", line 254, in __call__
[04:58] <kurt_>     raise friendly_fault
[04:58] <kurt_> ExternalComponentException: Unable to reach provisioning server.
[04:58] <kurt_> looks like there is artifact in maas db
[04:58] <kurt_> will try to reprovision to see if that fixes...
[05:52] <kurt_> ok, discovered issue… note to self - ensure you have a complete os and system writable disk before proceeding with netboot
[05:56] <bigjools> heh
[05:56] <kurt_> configuration couldn't write to vm's disk
[06:02] <kurt_> so process when creating maas VMs is to build your VM first with complete install, then switch VM to PXE boot.
[06:02] <bigjools> glad it works
[06:03] <kurt_> me too. so far so good
[06:03] <bigjools> I just got powering on with virsh working without cobbler too, so it's all going well today
[06:03] <kurt_> nice
[06:03] <kurt_> is that some that works in the current build?
[06:03] <bigjools> no
[06:03] <kurt_> ok, something to look forward too :)
[06:04] <kurt_> ah - ok, I see - cobbler is a lot of the reason you need to do that...
[06:04] <kurt_> it has the PXE functionality you need
[07:20] <jtv> bigjools: here
[07:20] <bigjools> o/
[07:20] <bigjools> ok
[07:20] <jtv> Doesn't something in there block until at least the files have been gathered?
[07:20] <bigjools> no idea
[07:21] <bigjools> I'll find out shortly
[07:21] <jtv> I hope it's not the code that (AFAICT) decides to deal with umount failure by doing the umount again.
[07:22] <bigjools> grepping for "import" doesn't help ....
[07:23] <jtv> Oh, I'm sure the right answer will be in the output.
[07:23] <jtv> Somewhere.
[07:23]  * bigjools stabs a pin in
[07:24] <kurt_> qq:  can the hostname be changed in the maas interface without repercussion after the hostname has already been created like "node-000c25abcc"?
[07:25] <jtv> kurt_: the code for maas itself doesn't care, but something else that maas relies on might.
[07:25] <jtv> Not very helpful, I know.
[07:25] <kurt_> :)
[07:26] <kurt_> ok, best to leave it alone
[07:26] <jtv> Specifically, if it's okay with juju and with cobbler, it should be okay.
[07:27] <jtv> MAAS in its current incarnation (which still uses cobbler) propagates such changes to cobbler immediately.  But we're on the cusp of radical change.
[07:27] <kurt_> that's a wee bit of a frustrating part of that interface is having to maintain my own mac adds to human friendly name mapping, esp where VMs are concerned
[07:29] <jtv> You can leave the hostname blank.
[07:29] <jtv> I'd assign it only in cases where the hostname has a special meaning to what you're doing.
[07:30] <kurt_> and yes, je was talking about the whole rework of the cobbler stuff
[07:30] <kurt_> that's great work
[07:30] <jtv> Where “easy work” would be preferred, of course.  :)
[07:31] <kurt_> go for the low hanging fruit of course...
[07:32] <jtv> bigjools: looks to me like cobbler's import_tree rsyncs the whole given directory into its own storage.
[07:32] <bigjools> jtv: yeah just looking at it
[07:33] <jtv> Not too surprising, really, given how tiny the two files we want are compared to the whole image we download
[07:33] <bigjools> nice of it to say "importing from a network location" regardless
[07:35] <bigjools> bare excepts.... yegads
[07:36] <jtv> More detail in modules/manage_import_debian_ubuntu.py — with just a hint of suspicion that we've got several layers of scripts and code duplicating similar support functionality.
[07:36] <bigjools> yup
[07:38] <jtv> This is going to drive me to drink.
[07:38] <bigjools> at least you'll be sober in the morning
[07:38] <bigjools> the code will still be shit
[07:39] <kurt_> ok, last question of the night…then off to bed...
[07:39] <kurt_> trying to delete a node from maas, seeing "Unable to reach provisioning server."
[07:39] <kurt_> restarted pserv
[07:39] <kurt_> no joy
[07:39] <kurt_> any ideas?
[07:39] <bigjools> what's in the pserv log?
[07:40] <kurt_> here's little excerpt from maas.log, will get pserv
[07:40]  * jtv braves the 30—40kg dog in a desperate dash to the bathroom
[07:40] <kurt_>   File "/usr/lib/python2.7/dist-packages/maasserver/provisioning.py", line 254, in __call__
[07:40] <kurt_>     raise friendly_fault
[07:40] <kurt_> ExternalComponentException: Unable to reach provisioning server.
[07:41] <kurt_> not really much..
[07:41] <kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] 127.0.0.1 - - [14/Jun/2012:07:38:35 +0000] "POST /api HTTP/1.1" 200 1265 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[07:41] <kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] 127.0.0.1 - - [14/Jun/2012:07:38:35 +0000] "POST /api HTTP/1.1" 200 1265 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[07:41] <kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] Stopping factory <twisted.web.xmlrpc._QueryFactory instance at 0x2ad9320>
[07:41] <kurt_> 2012-06-14 00:38:35-0700 [QueryProtocol,client] Stopping factory <twisted.web.xmlrpc._QueryFactory instance at 0x2ad9320>
[07:42] <kurt_> ok, completely knackered
[07:42] <kurt_> see you guys tomorrow
[07:42] <jtv> kurt_: that's the maas log
[07:42] <bigjools> not much to go on
[07:43] <jtv> as distinct from the pserv log
[07:43] <kurt_> last bit is pserv.log
[07:43] <kurt_> guess I need to turn up debug
[07:43] <jtv> Sounds as if the maasserver really can't reach the pserver then
[07:43] <jtv> Try a ps -ef | grep pserv?
[07:44] <jtv> See if it's really running or not
[07:44] <kurt_> ituser@maas01:~$ ps -ef | grep pserv
[07:44] <kurt_> maas     15396     1  0 00:35 ?        00:00:00 /usr/bin/python /usr/bin/twistd -n --uid=maas --gid=maas --pidfile=/run/maas-pserv.pid --logfile=/dev/null maas-pserv --config-file=/etc/maas/pserv.yaml
[07:44] <jtv> Love that --logfile option
[07:45] <kurt_> interesting...
[07:45] <kurt_> default - is that set in pserv.yaml?
[07:45] <jtv> No idea tbh
[07:45] <bigjools> jtv: so import looking for repos, kickstarts and bootloaders
[07:45] <kurt_> ok, good night
[07:45] <jtv> nn kurt_
[07:45] <bigjools> nn
[07:45] <kurt_> can't focus any more
[07:46] <jtv> then don't overdo it :)
[07:46] <kurt_> thnx guys
[07:48] <bigjools> jtv: I think we need more help from server guys
[07:48] <bigjools> and get their take on what needs doing
[07:48] <jtv> Can't disagree with you.
[07:49] <bigjools> yay, late night for me
[07:50] <jtv> So sorry about that.  :(  I've been trying to throw extra hours at this, but haven't had the energy lately.
[07:51] <jtv> It does look as if the core of the Cobbler import code looks for initrds and kernels.
[07:52] <jtv> But it's all much more OS-agnostic, of course.
[07:53] <bigjools> yeah
[07:53] <bigjools> but there's then these layers of bash
[07:55] <jtv> Suddenly the name makes sense to me.
[07:55] <jtv> bigjools: I've updated the Questions section of the google doc.
[07:56] <bigjools> ok
[07:59] <jtv> bigjools: we'll also want to deal with updates that happen concurrently to net-boots.
[07:59] <jtv> In other words, we can't just replace an initrd/kernel pair while nodes are using it.
[08:00] <bigjools> depends if tftp keeps a file handle open? :)
[08:00] <jtv> So we may need to number versions.  The server guys suggested something like this, but I cut it short since it wasn't part of the immediate problem.
[08:00] <jtv> Bear in mind that it's stateless, UDP.
[08:01] <jtv> There's no such thing as an ongoing session or even an ongoing download.  A request for a chunk of file comes in and gets serviced, and total amnesia follows.
[08:01] <jtv> At least conceptually — optimization may be a different issue.
[08:04] <bigjools> I've no idea how it works internally
[08:04] <bigjools> anyway
[08:05] <bigjools> dinner, back later
[08:05] <jtv> bon appétit
[08:13] <jtv> hi there mrevell
[08:13] <mrevell> Hello jtv
[13:32] <cheez0r> hey maas gurus, is there a command line way of adding/deleting nodes from a maas?
[13:33] <cheez0r> the command 'maas' on the command line gives me a number of options but not many seem specific to maas
[13:35] <rvba> cheez0r: http://paste.ubuntu.com/1040776/
[13:36] <cheez0r> right, that does the delete
[13:37] <rvba> To create a node manually: Node(hostname='sss', status=3)  note that you will need to know the internals a bit to provide the right parameters to the node creation method.
[13:37] <rvba> node = Node(...)
[13:37] <rvba> node.save()
[13:39] <cheez0r> can I do node = Node.objects.get(hostname='myhostname')
[13:39] <cheez0r> node.show()
[13:39] <cheez0r> ?
[13:39] <cheez0r> node.print()?
[13:39] <cheez0r> trying to figure out how to get an existing node out to use as template
[13:41] <rvba> node.__dict__
[13:41] <cheez0r> danke
[13:42] <rvba> I don't know your constraints but note that you would probably be better off using the API.
[13:43] <cheez0r> just trying to come up with a way to create a file that has mac,arch,hostname and can reproduce what I'm doing in the web gui
[13:43] <cheez0r> kind of slow to add eleven nodes via the GUI when I'm adding/removing them a lot
[13:44] <cheez0r> plus for auto-commissioning of a maas cluster that'd be useful
[13:46] <cheez0r> if I was more of a programmer Id just write a command-line front end to the API, but I'm not much of one :p
[13:47] <rvba> That's something that's on our TODO list.
[13:47] <cheez0r> I'm sure, now that I think about it.
[13:57] <rvba> roaksoax: The fix to support fetching YUI's file from the package has landed.  Please ping me if you update YUI's packaging as Francis suggested yesterday.  I'll need to change one line in contrib/maas_local_settings_sample.py if you change the place where the files are located.
[13:58] <rvba> roaksoax: you'll see a new config option in contrib/maas_local_settings_sample.py: YUI_LOCATION.
[13:58] <roaksoax> rvba: awesome! thanks. I'm emailing the java script team in Debian to talk about that
[13:58] <rvba> roaksoax: cool.
[13:59] <roaksoax> rvba: I cannot follow Francis suggestion libjs-yui35 because that'd mean introducing a new source and I'm not sure whether we wanna do that or not yet
[13:59] <roaksoax> ^^
[13:59] <roaksoax> smoser: ^^
[14:08] <roaksoax> rvba: was the directory suggested 'yui/<version>/build/*.js'?
[14:09] <rvba> roaksoax: it's not really suggested, but that's what the JS side requests by default.
[14:10] <roaksoax> rvba: the JS side in *maas*? or generally?
[14:11] <rvba> roaksoax: sorry for being vague, the JS side in YUi.  YUI3 has this mechanism where you load a small initial file and then this tiny bit of code requests the needed additional modules all in one request.
[14:13] <rvba> roaksoax: does that make sense?
[14:15] <roaksoax> rvba: kindof, is there any documentation that you could point me at?
[14:16] <rvba> roaksoax: http://yuilibrary.com/yui/docs/yui/loader.html
[14:17] <rvba> roaksoax: you'll see that the default 'root' option is '{version}/build'. Because the idea is to be able to have multiple versions of YUI3.
[14:28] <roaksoax> rvba: right, but even so, we can only have 1 version of YUI 3.5.X
[14:28] <roaksoax> ah nevermind :)
[14:30] <roaksoax> rvba: does this make sense to you? http://pastebin.ubuntu.com/1040864/
[14:31] <rvba> Looking.
[14:34] <rvba> roaksoax: Look good.  One remark: I'd drop the part about having 'build' in the path.  I think this is the default because of the way the code is structured in the yui tarball (src/ docs/ build/ etc.).  But when it comes to having that packaged, it really makes sense to have only the files in build/ and drop everything else.  The main question is the about having the version in the path and the package name.
[14:36] <roaksoax> rvba: right, ah I thgouht you wanted everything to be installed under ./build/
[14:37] <rvba> No, YUI 'likes' it by default.  but I think it's just a convenience.  In a package I think it makes sense to drop that.
[14:37] <roaksoax> rvba: ok
[14:39] <roaksoax> rvba: ok cool. email sent!
[14:53] <roaksoax> paultag: could you pelase repeat this for rvba to give his opinion
[14:53] <roaksoax> rvba: ^^
[14:54] <paultag> I was wondering how you suggested dealing with node.js policy, since it's a slightly different subset of javascript policy it's self - adding a version path will cause some pretty gnarly behavior (as much as I would kill to have scripted languages major-versioned)
[14:55] <paultag> so I was wondering if you had an idea for how to keep javascript and node.js normalized, or if this was just to solve the problem at hand
[14:55] <paultag> also, using update-alternatives for a "current" version of the lib would be nice to add, IMHO anyway
[14:56] <paultag> (also wrt package naming, since node.js folk have some jacked up version schemes)
[14:56] <roaksoax> so, TBH i'm not a JS expert, but was just given the task to upgrade the mpackages, and obviously by doing so, some concerns arised
[14:56] <paultag> major version doens't always mean API stability :(
[14:56] <paultag> roaksoax: of course, I totally ACK that there is a problem
[14:56] <paultag> not that I do much javascript work, I was just here, saw @ubuntu and figured I'd see what you thought
[14:56] <paultag> I'm just a casual member of that team
[14:57] <paultag> javascript policy was written by dapal on the wiki, and it's very short -- getting it changed will not be so much of an issue, there are two active folks on that team ATM
[14:57] <roaksoax> paultag: so I do not have an idea of keeping js and node.js normalized but would definitely make sense doing so, as well as using update-alternatives
[14:58] <paultag> OK, I was just wondering :)
[14:58] <paultag> node.js isn't in testing, so it's not so much an issue
[14:58] <paultag> (whereas plain js libs are)
[15:00] <roaksoax> right.
[15:00] <roaksoax> let's see what rvba things :)
[15:00] <roaksoax> rvba: ^^
[15:01] <paultag> roaksoax: so, I'm guessing Jonas Smedegaard will be the first to reply
[15:01] <paultag> anyway, just wanted to say hi and ask. Thanks, guys.
[15:02] <roaksoax> looking forward to it
[15:02] <roaksoax> paultag: thanks to you too though! as concerns like yours also made be hold on the upgrade and/or make changes that differ from Debian
[15:03]  * rvba reads scrollback.
[15:03] <paultag> roaksoax: reducing the delta is good for everyone :)
[15:03] <roaksoax> indeed
[15:06] <rvba> roaksoax: I confess I don't know anything about node.js but clearly it would make sense to treat YUI as a library and use the major version in the package.
[15:08] <paultag> rvba: my main point is -- not all js libs treat the major-version as api stability (as well as the same policy covering both, for the most part)
[15:08] <paultag> rvba: I agree that's a good way of doing it, though.
[15:10] <paultag> (node.js would have to be treated as a  lib if it is (which is a good thing(tm)) - but node folks are really really (REALLY) bad about API stability)
[15:10] <rvba> paultag: you're right so I guess it would be good to have two policies then.
[15:10] <paultag> some of them don't even include license information, the situation is really gnarly.
[15:10] <paultag> rvba: so that might be good to include in the proposal :)
[15:11] <rvba> Right.
[15:11] <paultag> (propose a branch) - as well as perhaps considering a update-alternatives pointer to the current version or something.
[15:12] <paultag> again, I'm not a javascript authority. Just a lurking member who is also @ubuntu, and took the time to make sure I gave it some thought and a friendly hi
[15:13] <rvba> And I'm definitely not a packaging authority. But I agree that the current policy seems to be very… minimal, to say the least. Your idea sounds good to me.  What do you think roaksoax.
[15:13] <rvba> ?
[15:13] <paultag> (so, we're agreed, the current state sucks ;) )
[15:14] <paultag> rvba: the "policy" was written by dapal to keep sanity -- if you check out his DDPO, you'll understand why it's so small
[15:14] <paultag> 163 maintained packages :)
[15:14] <paultag> a lot are node / js
[15:14] <rvba> I see.
[15:15] <roaksoax> well i guess he definitely has the last word on this then
[15:15] <roaksoax> as he's the one who maintains all of those packages
[15:15] <paultag> roaksoax: oh, no. The other one (Jonas) maintains 308
[15:15] <roaksoax> but yes, I think a node.js policy would be a good idea
[15:16] <paultag> also a few node packages (and nodejs it's self)
[15:23] <roaksoax> oh wow
[15:23] <roaksoax> those are quite a few packages
[15:25] <paultag> alright, well, I've said my piece
[15:25] <paultag> thanks, y'all.
[15:26] <rvba> Thanks paultag!
[15:26] <paultag> rvba: thank *you* for caring about this stuff :)
[15:26] <paultag> (and wanting to upstream the delta)
[15:26]  * paultag waves
[15:26] <cheez0r> thank both of you ;)
[16:18] <roaksoax> rvba: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-June/003709.html
[16:23] <rvba> roaksoax: we're only interested in YUI packaging right now.  And 2.8.2 is largely incompatible with 3.5.
[18:45] <kurt_> how do I map the cobbler system list names to the maas system list names?
[19:35] <cheez0r> kurt_: in cobbler system dumpvars --name "NAME" there will be a dnsname field.
[19:35] <cheez0r> you can correlate them using that field.
[19:35] <cheez0r> dnsname == maas name.
[19:35] <kurt_> thank you
[19:35] <cheez0r> np
[19:36] <cheez0r> it is kind of odd that nodename in cobbler is different than nodename in maas.
[19:36] <cheez0r> but cobbler is being phased out of maas so it's a moot point.
[19:36] <kurt_> I'm glad cobbler will be gone soon
[19:36] <cheez0r> roaksoax: what is the pxe system that's replacing cobbler in maas?
[19:36] <kurt_> ;)
[19:37] <roaksoax> cheez0r: one developed in house
[19:38] <cheez0r> cool.
[19:38] <cheez0r> does it have a name, or will it just be maas-pxe?
[19:45] <Daviey> no name, just a core part of maas
[19:45] <cheez0r> cool
[19:53] <roaksoax> indeed
[21:06] <czajkowski> Daviey: ping
[23:20] <czajkowski> bigjools: thank you
[23:20] <bigjools> czajkowski: nae worries
[23:21] <bigjools> czajkowski: those two I answered a FAQs BTW
[23:21] <bigjools> are*
[23:22] <czajkowski> bigjools: cool once I figure out how to create a FAQ on AU I'll do that tomorrow it was complaingin I didnt add a body to the text
[23:23] <bigjools> heh
[23:23] <bigjools> czajkowski: I added FAQs to LP as well
[23:24] <czajkowski> ah yes but I've to add them to AU now
[23:25] <kurt_> I'm playing around a bit with trying to provision via kvm controlled VM, and it appears the bridged connection is slow in reaching the maas server.  Only after the VM boots to hard disk does it get a dhcp address from the maas server.  Has this been observed?
[23:26] <kurt_> its two bridged connections…so maybe that matters?
[23:26] <bigjools> I don't get that
[23:26] <bigjools> have a look at the vdenv/ dir in the source tree, it sets a load of VMs up
[23:26] <kurt_> maas server runs on VMWARE <--> kvm server with VM
[23:27] <kurt_> both on same network, in my case 172.16.100.x
[23:28] <kurt_> my kvm VM boots, looks for the dhcp server, doesn't find it, so boots to HD, then once it comes up on HD it finds the DHCP server and gets an IP address!
[23:28] <kurt_> ie. tries to do a PXE boot is what I mean
[23:29] <bigjools> I am not pxe booting on VMs
[23:29] <kurt_> eh?
[23:30] <kurt_> the vmware vms pxe boot
[23:30] <bigjools> s/not// sorry
[23:30] <kurt_> ?
[23:30] <bigjools> I am pxe booting on VMs
[23:30] <czajkowski> bigjools: for future reference do you want to be mailed or should I spread it around on the red team?
[23:31] <kurt_> ok, back to trying to figure it out
[23:31] <bigjools> czajkowski: send to the list
[23:31] <bigjools> czajkowski: in a pleading tone :)
[23:31] <czajkowski> list?
[23:31] <bigjools> maas-devel
[23:31] <czajkowski> maas devl?
[23:31] <czajkowski> grand will do
[23:31] <bigjools> ta
[23:32] <czajkowski> not sure it'll be a pleading tone mind you
[23:32] <czajkowski> ;)
[23:32] <bigjools> domineering? :)
[23:33] <czajkowski> forceful, or they wont get answered and it'll fall back to one person again :)
[23:33] <czajkowski> anways I should in fact log off and attempt sleep
[23:34] <bigjools> yes, you should indeed
[23:37] <kurt_> yeah I get "connection timed out" from kvm VM each time - can you tell me what network driver you are using?  I was using virtio
[23:40] <bigjools> ummm
[23:40] <kurt_> sent you screenshot
[23:40] <kurt_> or tried to anyways
[23:40] <bigjools> just doing a virsh net-start here
[23:40] <bigjools> seriously, look in the vdenv tree in the source
[23:41] <kurt_> sorry.  I don't know what you mean.
[23:45] <bigjools> http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/files/head:/vdenv/