=== harlowja is now known as harlowja_away | ||
=== praneshp_ is now known as praneshp | ||
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 :) | 06:56 |
---|---|---|
=== praneshp_ is now known as praneshp | ||
=== smoser` is now known as smoser | ||
smoser | JayF, so you're the only one using vendordata on openstack to my knowledge. at least with cloud-init. | 12:51 |
smoser | JayF, https://etherpad.openstack.org/p/cloud-init-vendor-data | 13:10 |
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:11 |
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:55 |
smoser | siert, just fyi, man page for 'hostname' recommends against using 'hostname -f' | 13:57 |
smoser | :) | 13:57 |
siert | smoser: hm, ok. but the RHEL install guide is slightly more ambiguous - "either as a fqdn or as a short host name" | 14:04 |
smoser | siert, thank you for loking at this. | 14:10 |
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:11 |
smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1052664 | 14:15 |
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:21 |
siert | debian/ubuntu have the short name in /etc/hostname and the rest is read from /etc/hosts. | 14:27 |
smoser | hm. | 14:31 |
smoser | having 'hostname' return a fqdn seems broken to me. | 14:37 |
siert | ubuntu 14.04 returns hostname version 3.15. rhel based systems: net-tools 1.60 and hostname 1.100 (2001-04-14) | 14:39 |
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:40 |
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:41 |
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:42 |
siert | yeah, by /etc/init/hostname.conf (hostname -b -F) | 14:43 |
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:45 |
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:46 |
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. | 14:51 |
=== zz_gondoi is now known as gondoi | ||
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:24 |
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:26 |
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:30 |
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:31 |
smoser | (well, for the 'dict' case) | 16:32 |
smoser | ie: | 16:32 |
smoser | {'cloud-init': 'this-is-processed-same-as-user-data'} | 16:32 |
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:33 |
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:37 |
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:39 |
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:41 |
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:42 |
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:44 |
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:45 |
smoser | ah. | 16:46 |
smoser | so anyway. | 16:46 |
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:47 |
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:48 |
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:49 |
smoser | hm.. | 16:50 |
smoser | no i think it is | 16:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
smoser | from my perspective, the user is in charge. | 16:58 |
JayF | I'd rather software be in charge and prevent the user from doing bad, broken things they probably didn't intend | 16:59 |
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:00 |
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:01 |
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:02 |
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:03 |
smoser | thats fine. | 17:04 |
smoser | so i think we should stuff YYYYMMDD in there just right away | 17:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
smoser | for ver in [k.split("_")[2] for k in vendor_data_json if k.startswith("network_config_"): | 17:10 |
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:11 |
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:12 |
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:13 |
smoser | i'd not seen that. | 17:14 |
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:15 |
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:16 |
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:17 |
smoser | no? | 17:18 |
pquerna | there is a $50 minimum for support fee | 17:18 |
pquerna | (unforunately) | 17:18 |
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:19 |
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:20 |
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:21 |
* 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:22 |
pquerna | $0.68493/hr or $0.0114155/min | 17:23 |
smoser | pquerna, ipv6 support in that patch ? | 17:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
harlowja | smoser do u have someone looking into https://bugs.launchpad.net/nova/+bug/1361357 or tbd? | 17:31 |
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:32 |
smoser | we really need to do something there. | 17:33 |
smoser | even the 3 seconds that it took before it regressed is laughable | 17:33 |
smoser | on amazon, the ~ 20 requests it takes to crawl their MD service takes ~ 0.07 seconds | 17:34 |
harlowja | :-/ | 17:35 |
harlowja | ya, it makes no sense | 17:35 |
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:36 |
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:39 |
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:40 |
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:42 |
harmw | or would just any vm suffice | 17:43 |
harmw | since I'm running openstack-nova-api-2014.1.1-2.el6.noarch | 17:43 |
harmw | old comparison code: 0.103947877884 | 17:44 |
harmw | new comparision code: 4.36138916016 | 17:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
smoser | right. | 17:52 |
smoser | it was redherring | 17:52 |
harlowja | ya, does the metadata server now use the conductor and object model | 17:53 |
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:54 |
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:55 |
JayF | totally got an email this time | 17:56 |
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:58 |
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? | 17:59 |
harlowja | seems fair to me | 18:00 |
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:01 |
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:02 |
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:03 |
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:04 |
harlowja | https://github.com/stackforge/osprofiler/commit/034987f083cfa1aff2347a4f (for the other place i've used that hmac comparison func) | 18:05 |
harlowja | * https://docs.python.org/2/library/hmac.html#hmac.compare_digest | 18:06 |
harlowja | anyways | 18:06 |
harmw | hehe, neutron-server taking 40% cpu :p I should realy upgrade this Atom server | 18:13 |
harlowja | :( | 18:14 |
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:41 |
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:42 |
harlowja | kk | 18:43 |
harlowja | that seems ok | 18:43 |
smoser | harlowja, wrt the openstakc metadata service and conductor... | 19:00 |
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:01 |
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:02 |
smoser | https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py#L38 | 19:04 |
harlowja | ya, i'd almost want to disable that cache for figuring out the root cause | 19:06 |
smoser | https://review.openstack.org/#/c/102212/ | 19:07 |
smoser | hm.. wonder if that is in 2014.1.2 | 19:07 |
harlowja | smoser alright, https://code.launchpad.net/~harlowja/cloud-init/smart-read/+merge/232316 updated | 19:34 |
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:08 |
* smoser feels really bad for always taking so long to do things for harm. | 21:09 | |
harlowja | smoser checking | 21:21 |
harlowja | will help boss | 21:21 |
harlowja | lol | 21:21 |
harlowja | harmw alright, let me see if i can get your thingy adjusted, will get u a patch i guess | 21:27 |
=== gondoi is now known as zz_gondoi | ||
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:25 |
harlowja_ | hopefully fine with u, should just be apply to apply it and resubmit your branch | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!