[06:56] <harmw> smoser: I'm to sucky a python programmer to fix the test on my own, so a little help or example would be helpfull yes :)
[12:51] <smoser> JayF, so you're the only one using vendordata on openstack to my knowledge. at least with cloud-init.
[13:10] <smoser> JayF, https://etherpad.openstack.org/p/cloud-init-vendor-data
[13:11] <smoser> harmw, i'll see if i can't help ith that test today.  harlowja wrote the other ones there.  cloud-init suffers badly from having too many test case mechanisms.
[13:55] <siert> smoser: I did an update on #1246485 - not sure if the suggested solution from alexius is perfect, but it works in my situation. also affects latest version...
[13:57] <smoser> siert, just fyi, man page for 'hostname' recommends against using 'hostname -f'
[13:57] <smoser> :)
[14:04] <siert> smoser: hm, ok. but the RHEL install guide is slightly more ambiguous - "either as a fqdn or as a short host name"
[14:10] <smoser> siert,  thank you for loking at this.
[14:11] <smoser> while it seems straight forward, i think its probably as much as you'd hope.
[14:11] <smoser> my experience is that any time i touch 'hostname' or '/etc/hosts', something breaks.
[14:15] <smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1052664
[14:21] <siert> the /etc/hostname should always have the short name only. on rhel, when there is no hostname defined in /etc/sysconfig/network, then /etc/hostname is used as a fallback, to set the systems hostname.
[14:27] <siert> debian/ubuntu have the short name in /etc/hostname and the rest is read from /etc/hosts.
[14:31] <smoser> hm.
[14:37] <smoser> having 'hostname' return a fqdn seems broken to me.
[14:39] <siert> ubuntu 14.04 returns hostname version 3.15. rhel based systems: net-tools 1.60 and hostname 1.100 (2001-04-14)
[14:40] <siert> maybe the difference is in the version of 'hostname', let me see... :s
[14:40] <smoser> well, on ubuntu, it returns whatever you set it to.
[14:41] <smoser>  hostname
[14:41] <smoser> brickies
[14:41] <smoser> er..
[14:41] <smoser> $ hostname
[14:41] <smoser> brickies
[14:41] <smoser> $ sudo hostname brickies.foobar.example.com
[14:41] <smoser> $ sudo hostname
[14:41] <smoser> sudo: unable to resolve host brickies.foobar.example.com
[14:41] <smoser> brickies.foobar.example.com
[14:42] <smoser> $ sudo hostname brickies
[14:42] <smoser> sudo: unable to resolve host brickies.foobar.example.com
[14:42] <smoser> $ hostname
[14:42] <smoser> brickies
[14:42] <smoser> and that initially gets set from the content of /etc/hostname
[14:43] <siert> yeah, by /etc/init/hostname.conf (hostname -b -F)
[14:45] <smoser> right.
[14:45] <smoser> http://manpages.ubuntu.com/manpages/trusty/en/man1/hostname.1.html
[14:45] <smoser> "historically this file was supposed to only contain the hostname and not the full canonical FQDN. ..."
[14:46] <smoser> siert, i know it sounds like i'm paying too much attention here, but i've just been bit many times.
[14:46] <smoser> basically my experience is that anything you do breaks something.
[14:51] <siert> thanks for you time, I gtg. will look into it tomorrow, maybe there's another way of getting rhel to behave the same as ubuntu when it comes to hostnames.
[16:24] <JayF> smoser: Is that a bad thing? Good thing? Heh
[16:24] <JayF> We've used vendor_data.json internally for stuff for a while, just now integrating it with cloud-init
[16:26] <smoser> JayF, well, i would not want to break anyone's usage
[16:26] <smoser> and i was proposing changes in consumpiton of it
[16:26] <smoser> even though that consumption i spretty broken at the moment.
[16:30] <JayF> smoser: not sure I grok what you're trying to suggest in that etherpad
[16:30] <JayF> Have you had feature requests along those lines from other folks using vendor_data?
[16:31] <smoser> that is how vendor data works
[16:31] <smoser> in other datasources
[16:31] <smoser> and actually , if there is 'cloud-init' in the network metadata service on openstack, then it probably works like that now.
[16:32] <smoser> (well, for the 'dict' case)
[16:32] <smoser> ie: 
[16:32] <smoser>  {'cloud-init': 'this-is-processed-same-as-user-data'}
[16:33] <JayF> Hmm. I honestly don't like that format, but you say that's what's already being used for other data sources (including, I presume, metadata service vendor_data?)
[16:37] <smoser> what dont you like about it?
[16:37] <JayF> let me make sure I fully understand
[16:37] <JayF> so I get what you're saying for the dict case
[16:39] <JayF> the cloud-config-archive stuff looks strange, and I'd be curious as to how that fits into a 'list' as far as the json is concerned?
[16:39] <JayF> and for the string case I'm just not sure what source data would lead json.loads() to simply return a string
[16:41] <JayF> you know; here's actually the primary reason I'd want vendor_data treated somewhat differently
[16:41] <JayF> with regards to what we're using it for; network configs; I'd not want that to be something a user could override or influence with user data
[16:42] <JayF> makes me wonder if today a user can inject a /etc/network/interfaces in order to give themselves broken networking in the existing status quo 
[16:44] <smoser> as far as what would give a string:
[16:44] <smoser> $ python -c 'import json, pprint; pprint.pprint(json.dumps("hi mom"))'
[16:44] <smoser> '"hi mom"'
[16:44] <JayF> gotcha
[16:44] <JayF> in Ruby that would throw an exception :)
[16:44] <JayF> ...I think?
[16:45] <JayF> yeah for sure --> JSON::ParserError: 746: unexpected token at 'hello world'
[16:45] <smoser> i thought it would in python earlier this morning
[16:45] <JayF> so that makes a little more sense
[16:45] <smoser> i dotn knwo that it does really.
[16:45] <smoser> why would you not be able to represent a string as json
[16:45] <JayF> I'm saying your etherpad makes more sense :)
[16:45] <JayF> knowing it doesn't bail in python
[16:46] <smoser> ah.
[16:46] <smoser> so anyway.
[16:47] <JayF> So for my use case, I think with what you've proposed
[16:47] <JayF> hmm
[16:47] <JayF> so vd['cloud_init'] could /not/ be a dict?
[16:48] <JayF> if that's the case, it'd 100% not work for what I'd like to do
[16:48] <JayF> well, I say 'like to do' but am-actually-doing in a branch
[16:49] <JayF> I think there are cases for sure where I'd want to send multiple data formats into my vendor_data
[16:49] <JayF> like where we want to, I guess in a sense introduce the network json format proposed for nova into vendor_data
[16:49] <JayF> in the format you lay out I don't think that's doable
[16:50] <smoser> hm..
[16:50] <smoser> no i think it is 
[16:51] <JayF> howso?
[16:51] <smoser> cloud-init is very forgiving on usre-data. it pays attention to a fairly small set of explicit things, and ignores all the others.
[16:51] <smoser> and this would be the same.
[16:51] <JayF> but you said in the etherpad
[16:51] <JayF> vd['cloud_init'] could be a list or a string
[16:51] <JayF> if the goal is to have json encoded network information
[16:51] <JayF> and cloud_init only reads from that key
[16:52] <JayF> then the only way to get json into that key would be to serialize it into a string... which seems obtuse
[16:52] <smoser> ah. i se. so you want to put that into 'network-config' and have cloud-init read it from ther.e
[16:52] <smoser> i am ok with that. 
[16:52] <JayF> or into vd['cloud_init'][network_config]
[16:52] <smoser> wlel, i dont know.
[16:53] <smoser> so 2 ways we could do that
[16:53] <smoser> a.) 'network_config' is not explicitly for cloud-init. so it would be at
[16:53] <smoser>    vendor_data['network-config'
[16:53] <smoser>   as it will eventually (we hope) be a sibling of meta-data.json (or possibly inside meta-data.json)
[16:54] <smoser> ie, its not explicitly cloud-init.
[16:54] <JayF> yes exactly
[16:54] <JayF> that makes sense
[16:54] <JayF> so today have cloud-init look for vd['network-config'] and md['network-config'] and do things with them
[16:54] <smoser> b.) cloud-init handle a part  of type 'network-config'
[16:54] <smoser>  the way it handles cloud-config now.
[16:54] <JayF> probably have some versioning concept so whatever differences come out between our 'prerelease' vendor-data version of it and the final openstack release will be able to be smoothly migrated
[16:54] <smoser>  ie, either explicit mime type, or '#network-config' (startswith)
[16:55] <smoser> yeah. i agree on vendor.
[16:55] <JayF> where would the #network-config or mimetype come from if it's just a json dict?
[16:55] <JayF> I'd say just look for a key, that key may change in the future, and also have it specify a version
[16:55] <smoser> well, in cloud-config-archive, yo ucan supply mimetype
[16:56] <JayF> hell, have the initial vendor_data key be something like rackspace_network_config to completely ensure we don't eat the namespace
[16:56] <smoser> and in just a string, if it startswith('#network-config'), then it gets handled as that.
[16:56] <JayF> I'd strongly prefer not having a metaformat in this case, given it's json data I don't want to have #network-config followed by a json doc
[16:56] <smoser> hm..
[16:57] <JayF> because all we've done is add a magic string at top that breaks all other json parsing tools
[16:57] <smoser> yeah, i think that is fine.
[16:57] <smoser> oh. to address one other thing above.
[16:57] <smoser> yes, the usre can break things.
[16:57] <smoser> rackspace seems very much to want to magically stop users from being able to break things.
[16:57] <smoser> but i dont aare.
[16:57] <smoser> don't care.
[16:58] <smoser> from my perspective, the user is in charge.
[16:59] <JayF> I'd rather software be in charge and prevent the user from doing bad, broken things they probably didn't intend
[17:00] <JayF> but it's fine, I get why you think about it that way :)
[17:00] <smoser> if they say "put this file in /etc/network/interfaces" i'm not going to say "i'm smarter than you".
[17:00] <smoser> same as 'rm -rf /etc'
[17:01] <JayF> I get it, I don't agree but that's a-okay
[17:01] <smoser> i understand why you all want to protect users. but there is only so much you can do.
[17:01] <smoser> fwiw, vendor data is disable-able by user entirely.
[17:01] <JayF> haha
[17:01] <smoser> by design. if they want to feed user-data to turn it off, that is fine.
[17:01] <JayF> if someone does that on an onmetal server
[17:02] <JayF> they're going to be paying a lot of money for a server that doesn't have internet
[17:02] <JayF> hah
[17:02] <JayF> So path forward:
[17:02] <JayF> cloud-init stuff handled the way you specified
[17:03] <JayF> look for a separate key in vd for network configs
[17:03] <smoser> i put a bit more in that pad
[17:03] <smoser> yeah
[17:03] <smoser> interesting.
[17:03] <JayF> right now that key is 'network_info'
[17:03] <JayF> fwiw
[17:04] <smoser> thats fine.
[17:04] <smoser> so i think we should stuff YYYYMMDD in there just right away
[17:05] <smoser> when / if it gets into openstack, it will live at metadata-url/YYYYMMDD/network_info.json
[17:05] <smoser> and that YYYYMMDD would fall out there.
[17:05] <JayF> not injected into meta_data.json?
[17:05] <smoser> i dont have strong feelings there.
[17:05]  * JayF needs to read that spec again
[17:05] <smoser> it certainly could live in meta-data.json
[17:06] <smoser> in which case the YYYYMMDD would certainly fall out (as it would be provided by the openstack version)
[17:06] <smoser> do you think we need to build the version info into network_config
[17:06] <smoser> that was the real question
[17:06] <smoser> when it appears in vendordata
[17:06] <JayF> I think versioning the key is 'fine'
[17:06] <JayF> I dislike all options I can think of
[17:06] <JayF> and that seems the easiest to implement :)
[17:07] <JayF> gimme a sec and I'll give you a good example of a network json format
[17:07] <JayF> fresh off a configdrive
[17:07] <smoser> versioning the key.
[17:07] <smoser> as in network_config_YYYYMMDD ?
[17:07] <JayF> aye
[17:07] <smoser> i don tknow. i tihnk you're optimizing because you dont think it iwll live there long
[17:07] <smoser> :)
[17:08] <JayF> I mean, the reason I'm working with you now is so we don't hold these patches for long
[17:08] <smoser> yeah. 
[17:08] <JayF> would be great if cloud-init support was mostly there when it goes into openstack master
[17:08] <JayF> and as a bonus we don't have to hold a patch
[17:08] <JayF> although the hard part is building custom cloud-inits for a ton of operating systems :)
[17:09] <smoser> so i just think this is cleaner... its more explicit:
[17:09] <smoser> for version in vendor_data_json.get('network_config', {}):
[17:09] <smoser> versus:
[17:10] <smoser> for ver in [k.split("_")[2] for k in vendor_data_json if k.startswith("network_config_"):
[17:11] <JayF> so you'd do
[17:11] <smoser> (like in the pad)
[17:11] <JayF> network-info: { "20140101": {network info here } }
[17:11] <smoser> right.
[17:12] <JayF> smoser: so this is what we're putting down looks like right now --> https://gist.github.com/jayofdoom/b035067523defec7fb53
[17:12] <JayF> smoser: so the patch I posted earlier that pquerna did is currently, on ubuntu, fedora, and centos, already parsing and generating configs against that
[17:12] <JayF> which is pretty nice :)
[17:13] <smoser> ?
[17:13] <JayF> note that I redacted specifics of the server I'm using and knocked out other vendor_data stuff we use
[17:13] <smoser> really? where is that work by pquerna ?
[17:13] <JayF> https://github.com/pquerna/cloud-init/pull/1
[17:13] <JayF> that's what we're running right now, that patch on top of latest release (.7.5 iirc?)
[17:14] <smoser> i'd not seen that. 
[17:15] <JayF> I thought I linked it in here earlier
[17:15] <JayF> my apologies :)
[17:15] <smoser> you probably did. but if i remembered or correctly processed every thing people say to me
[17:15] <smoser> then i'd be pretty awesome
[17:15] <smoser> :)
[17:15] <JayF> heh, that's what logs and git/bzr are for, right?
[17:16] <smoser> so this supports bonds
[17:16] <smoser> and vlans
[17:16] <smoser> and mtu
[17:16] <JayF> Which is why we had to do that :)
[17:16] <JayF> the interfaces file parsing didn't handle it
[17:16] <JayF> and we wanted to use the network json instead
[17:16] <smoser> this is awesome.
[17:17] <JayF> if you spin up a rackspace onmetal server, you get network like that (10gbit bonded, vlans handed down over that bond)
[17:17] <smoser> i was disapointed by onmental minimum $500/month
[17:17] <JayF> I actually think there's a bug, because ubuntu trusty and debian anything can't both use the same /etc/network/interfaces file to achieve that setup
[17:17] <smoser> kind of turns me off from trying it :)
[17:17] <JayF> we charge by the hour
[17:17] <smoser> but monthly minimum.
[17:17] <pquerna> by the minute
[17:18] <smoser> no?
[17:18] <pquerna> there is a $50 minimum for support fee
[17:18] <pquerna> (unforunately)
[17:19] <smoser> dwonder why i thought it was $500.
[17:19] <pquerna> well
[17:19] <smoser> maybe that was something else.
[17:19] <pquerna> there is a $500 option
[17:19] <harlowja> JayF so we can get free onmetal
[17:19] <harlowja> thx much, lol
[17:20] <harlowja> then i don't need to request it here @ yahoo, lol
[17:20]  * harlowja getting vms is easier than getting hardware :-P
[17:20] <pquerna> managed infrastructure -> $50, managed operations -> $500
[17:20] <pquerna> managed ops = rackers will configure / operate software, etc, etc.
[17:20] <pquerna> managed infra is what most... of 'us' types want.
[17:21] <harlowja> def
[17:21] <harlowja> none of that stuff that makes people do things
[17:21] <pquerna> heh
[17:21] <smoser> well http://www.rackspace.com/cloud/servers/onmetal/
[17:21] <smoser> still confuses me
[17:21] <smoser> so i dont think i simply mis-remembered.
[17:22]  * JayF brb shortly
[17:22] <smoser> raw infrastructure: $500/server/mo.
[17:22] <smoser> but i guess you're saying really that is :
[17:22] <pquerna> so, thats billed per-minute
[17:22] <pquerna> those are just monthly prices to be 'nice'
[17:22] <pquerna> (le sigh)
[17:22] <smoser>  $50 + minutes * (500/30/24/60)
[17:22] <pquerna> right
[17:23] <pquerna> $0.68493/hr or $0.0114155/min
[17:23] <smoser> pquerna, ipv6 support in that patch ?
[17:24] <pquerna> no :(
[17:24] <smoser> ok. so see, you're not perfect
[17:24] <smoser> :)
[17:24] <smoser> this is really neat though.
[17:24] <pquerna> we don't do ipv6 right now for.... sigh. switches.
[17:24] <pquerna> one day i'll be able to run ubuntu on my switches. it'll be great :)
[17:25] <pquerna> JoshNang: actually, i guess we should make the nova/neutron changes to support v6
[17:25] <smoser> ok. so i'm out for thursday -> tuesday.
[17:25] <pquerna> JoshNang: even if our networks don't support it right now
[17:25] <smoser> yeah, there is work to do on that front too
[17:25] <pquerna> JoshNang: and do the cloud-init work
[17:25] <smoser> dreamhost has it 
[17:25] <smoser> but your network config format *has* to support it
[17:26] <JoshNang> pquerna: oh definitely.
[17:26] <pquerna> +1
[17:26] <smoser> and cloud-init should generically be able to support it too.
[17:26] <pquerna> JoshNang: then at least we can write test cases on both sides
[17:26] <JoshNang> when we originally drew up the json format, we had ipv6 in there. i just don't think it made it into the spec explicitly
[17:26] <smoser> on dreamcompute you only get a public ipv6 by default.
[17:26] <pquerna> nice
[17:26] <pquerna> the future
[17:26] <JoshNang> awesome
[17:26] <smoser> yeah, but i had to find somewhere to ssh hop through to get to my instances there :)
[17:27] <smoser> ok.
[17:27] <harlowja> JayF u see my comment on https://code.launchpad.net/~jason-oldos/cloud-init/upgrade-configdrive/+merge/232312 ?
[17:27] <harlowja> i can't quite remember if the new inline comment feature sends emails or not, lol
[17:27] <smoser> i'm out the rest of the week. after US EOD. and out monday too. 
[17:27] <smoser> but i really would lik to get this stuff in quick
[17:27] <smoser> harlowja, you able to patch harmw's test case for him ?
[17:28] <smoser> https://code.launchpad.net/~harmw/cloud-init/freebsd/+merge/231024
[17:28] <harlowja> hmmm, lets see
[17:28] <smoser> pquerna, or JayF can you get me as much data as possible on what you have for network config ?
[17:28] <pquerna> (i'm also out starting Friday until... September 24th, wedding/honeymoon, so JayF/Josh will be on this)
[17:28] <harlowja> wtf, why u guys going on vacation
[17:28] <harlowja> no good, lol
[17:29] <smoser> pquerna, well congratulations on that. sir.
[17:29] <harlowja> u found a female, impassible
[17:29] <harlowja> lol
[17:29] <harmw> harlowja al rescate!
[17:31] <harlowja> smoser do u have someone looking into https://bugs.launchpad.net/nova/+bug/1361357 or tbd?
[17:32] <smoser> i've got someone trying to verify if it regressed between 2014.1.1 and 2014.1.2
[17:32] <smoser> but thats been slow going.
[17:32] <smoser> i *think* it is neutron related.
[17:32] <harlowja> kk
[17:32] <harlowja> hmmm
[17:32] <smoser> i as happy to see the ML post
[17:32] <smoser> that seemingly its not just us
[17:32] <harlowja> ya, not just u 
[17:32] <harlowja> thats always good
[17:33] <smoser> we really need to do something there.
[17:33] <smoser> even the 3 seconds that it took before it regressed is laughable
[17:34] <smoser> on amazon, the ~ 20 requests it takes to crawl their MD service takes ~ 0.07 seconds 
[17:35] <harlowja> :-/
[17:35] <harlowja> ya, it makes no sense
[17:36] <harlowja> the time it takes for such a simple service should be like < 0.01 seconds
[17:36] <harlowja> no reason for it not to me
[17:36] <harlowja> *not to be
[17:39] <pquerna> weird. i thought the MD service put it all in memcache anyways. hrm.
[17:39] <JayF> harlowja: it didn't email me
[17:39] <smoser> pquerna, yeah, its definitely supposed to be.
[17:40] <pquerna> we don't yet deploy MD service, but its on the short list of things i want.
[17:40] <pquerna> its just silly that we don't
[17:40] <pquerna> so... lets stop doing silly things.
[17:42] <harlowja> less silly is good
[17:42] <harlowja> but u don't want to remove all the silly
[17:42] <harlowja> thats no fun
[17:42] <harmw> smoser: whre should I run that script of yours, inside cirros? (regarding the nova bug)
[17:43] <harmw> or would just any vm suffice
[17:43] <harmw> since I'm running openstack-nova-api-2014.1.1-2.el6.noarch
[17:44] <harmw> old comparison code:  0.103947877884
[17:44] <harmw> new comparision code:  4.36138916016
[17:45] <harlowja> :-/
[17:45] <smoser> harmw, what script did you run ? 
[17:45] <smoser> the wget ?
[17:45] <smoser> i dont recal.
[17:45] <harlowja> how is 4.2 more seconds even possible
[17:45] <harlowja> thats insane
[17:45] <smoser> ec2metadata is a command on ubuntu or cirros
[17:46] <smoser> harmw, so what are your bencharms there ?
[17:46] <harmw> hhe
[17:46] <smoser> bencharms.
[17:46] <harmw> this is from a centos7 instance in my cloud :P
[17:46] <smoser> bench marks
[17:46] <smoser> but "old" and "new"
[17:46] <harmw> I took the script at https://bugs.launchpad.net/nova/+bug/1361357
[17:47] <harmw> and it printed that
[17:47] <smoser> oh. nah. 
[17:47] <smoser> that was red-herring.
[17:47] <smoser> i should just change the description of that bug.
[17:47] <smoser> i'll do that now
[17:47] <harmw> hhehe
[17:48] <harmw> well, if you have some benchmark I could run
[17:48] <smoser> the string comparison code is massively slower than it was 
[17:48] <harmw> just let me know
[17:48] <smoser> but that is actually by design
[17:48] <smoser> harmw, 
[17:48] <smoser> time ec2metadata
[17:48] <smoser> just run that. 
[17:49] <harmw> ah, and in which package should I find that binary?
[17:49] <harlowja> smoser i don't get how even crappy string comparison can slow down by that much
[17:50] <harlowja> its not like massive strings are being compared right
[17:50] <harlowja> where massive is in the MB range
[17:50] <harlowja> its gotta be something else than that
[17:52] <smoser> right.
[17:52] <smoser> it was redherring
[17:53] <harlowja> ya, does the metadata server now use the conductor and object model
[17:54] <harlowja> https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L130 
[17:54] <harlowja> that thing adds on alot of new RPC requests and such
[17:54] <JayF> harlowja: https://code.launchpad.net/~jason-oldos/cloud-init/upgrade-configdrive/+merge/232312 I don't see any comments on this at all
[17:55] <harlowja> JayF ah, it saves unsaved comment
[17:55] <harlowja> thats not cool
[17:55] <harlowja> odd
[17:55] <harlowja> oh, u have to press the save comment button
[17:55] <harlowja> weird
[17:55] <harlowja> JayF ok try now
[17:56] <JayF> totally got an email this time
[17:58] <JayF> harlowja: I guess I don't see how that's cleaner in this case; it's more lines of code to do the same thing?
[17:58] <JayF> harlowja: if there's a difference in functionality help me understand please 
[17:58] <harmw> smoser: you've got a direct link on ec2metadata binary?
[17:58] <harmw> or is it included with c-i?
[17:58] <harlowja> JayF version can be passed in as a function argument, so the code i was doing was just ensuring that u aren't going to rescan the same version twice
[17:58] <harlowja> aka someone passes in openstack.OS_GRIZZLY 
[17:59] <JayF> see I almost was tempted
[17:59] <JayF> to not even want to use that kwarg anymore
[17:59] <JayF> because I didn't see any instances where it was being used
[17:59] <harlowja> JayF kk, then lets drop it?
[18:00] <harlowja> seems fair to me 
[18:01] <JayF> harlowja: is there a better way to get the merge req to update other than deleting and making a new one (in lp?)
[18:01] <harlowja> afaik u can just do bzr ci, and push and it the merge request will update
[18:01] <JayF> bzr ci?
[18:01] <harlowja> bzr commit i guess
[18:02] <harlowja> guess thats my shorthand
[18:02] <smoser> harmw, sorry. not in cloud-init. sorry behind on reading.
[18:02] <smoser> here....
[18:02] <JayF> I've been doing bzr commit -> bzr push lp:~jason-oldos/cloud-init/upgrade-configdrive
[18:02] <smoser> this will work if you have sane cloud-init
[18:02] <smoser> http://paste.ubuntu.com/8151758/
[18:02] <JayF> and either I'm not patient enough to see the merge req update or it never does
[18:02] <harlowja> JayF ya, that should be fine
[18:02] <JayF> me being impatient very likely
[18:02] <harlowja> JayF it should show 'commit updating' or somethign usually
[18:02] <harlowja> http://paste.ubuntu.com/8161416/ is what i sent to a co-worker who i think will get involved with cloud-init
[18:03] <harlowja> the basics
[18:03] <smoser> harlowja, well, the string comparison is really by design. like explicitly complex to avoid magic optimizaiton that would give informatin away.
[18:03] <JayF> s/ci/commit/
[18:03] <JayF> and that matches what Iw as doing
[18:03] <harlowja> smoser ya, i've put something similar in another part of code that uses hmac stuff
[18:04] <harmw> smoser: I think my cloud sux :P
[18:04] <harmw> crawl of openstack took 17.666 seconds
[18:04] <harmw> crawl of ec2 took 14.452 seconds
[18:04] <harlowja> harmw lol
[18:04] <harlowja> super-speed
[18:05] <harlowja> https://github.com/stackforge/osprofiler/commit/034987f083cfa1aff2347a4f (for the other place i've used that hmac comparison func)
[18:06] <harlowja> * https://docs.python.org/2/library/hmac.html#hmac.compare_digest
[18:06] <harlowja> anyways
[18:13] <harmw> hehe, neutron-server taking 40% cpu :p I should realy upgrade this Atom server
[18:14] <harlowja> :(
[18:41] <smoser> harlowja, so something is odd in your 'smart-read' branch
[18:41] <harlowja> could be
[18:41] <harlowja> lol
[18:41] <smoser> time nosetests tests/unittests/test_datasource/test_openstack.py
[18:41] <smoser> not good. it takes like ... (still going)
[18:41] <harlowja> hmmm
[18:41] <harlowja> kk, let me see what i can find out
[18:41] <smoser> 65 seconds
[18:41] <smoser> but returns success (which is worse)
[18:42] <harlowja> probably retrying i think
[18:42] <smoser> harlowja, i was going to do this:
[18:42] <smoser>  http://paste.ubuntu.com/8161712/
[18:42] <smoser> to remove the duplication in find_working_version... put the differencein _avialable_versions
[18:43] <harlowja> kk
[18:43] <harlowja> that seems ok
[19:00] <smoser> harlowja, wrt the openstakc metadata service and conductor...
[19:01] <smoser> hopefully we cache the InstanceMetaData()
[19:01] <smoser> and reuse it.
[19:01] <smoser> so yeah, you'd hit that once, and that would suck, but it is supposed to be good for 15 seconds after tat.
[19:02] <harlowja> sure, even without caching  there is no way it should take that long :-P
[19:02] <harlowja> i mean i can render most of yahoo in +10 seconds
[19:04] <smoser> https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py#L38
[19:06] <harlowja> ya, i'd almost want to disable that cache for figuring out the root cause
[19:07] <smoser> https://review.openstack.org/#/c/102212/
[19:07] <smoser> hm.. wonder if that is in 2014.1.2
[19:34] <harlowja> smoser alright, https://code.launchpad.net/~harlowja/cloud-init/smart-read/+merge/232316 updated
[21:08] <smoser> harlowja, hey. ok. i just merged that.
[21:08] <smoser> harlowja, if you could fix (or help harm) fix his bsd bug
[21:08] <smoser> that'd be good
[21:08] <smoser> one of his tests fails on linux
[21:08] <smoser> and then you are welcome to push that to trunk
[21:09]  * smoser feels really bad for always taking so long to do things for harm.
[21:21] <harlowja> smoser checking
[21:21] <harlowja> will help boss
[21:21] <harlowja> lol
[21:27] <harlowja> harmw alright, let me see if i can get your thingy adjusted, will get u a patch i guess
[22:25] <harlowja_> harmw if u get a chance, http://paste.ubuntu.com/8163345/
[22:25] <harlowja_> applying that to your freebsd makes it work for me
[22:26] <harlowja_> hopefully fine with u, should just be apply to apply it and resubmit your branch