[00:51] <smoser> blackboxsw, i think that sounds fine.
[00:52] <smoser> anticw, "in ec2 it will easily get a response before" is not really true. the annoying timeouts are there for good reason (although possibly historical)
[00:57] <smoser> anticw, so right now if you take a stock image of 16.04, the behavior you are seeing is what is expected.
[01:45] <anticw> smoser: it would be useful to perhaps put timing detais into the logs so we can get some census on how long it takes in ec2
[01:45] <anticw> but IME of late, vm's from launch (create, api call) to login are often up in 20s (to login)
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
=== rangerpbzzzz is now known as rangerpb
=== tekniq_ is now known as tekniq
=== rangerpb is now known as rangerpbzzzz
[21:45] <blackboxsw> rharper: thanks for the review on the make deb changes. I've copied your comments over into https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/323088 as they are appropriate to that proposal instead. Per your suggestions it sounds like our approach really should be an recommends package for cloud-init on libyaml-0-2 in debian/control
[21:45] <blackboxsw> and our try: import CSafeLoader  except ImportError:  import SafeLoader as a fallback
[21:45] <rharper> blackboxsw: bah, sorry I put it on the wrong one
[21:45] <blackboxsw> then we can have unit tests which exercise both options if available
[21:45] <blackboxsw> yeah it's ok, I got the drift ;)  and thanks
[21:45] <rharper> hehe, sure
[21:46] <rharper> I think a recommends makes sense; but I'll defer to smoser when he's had time here;  I think that manual installation would still pick up the recommands unless users do a --no-install-recommends
[21:46] <rharper> I suppose if it's just that runtime library, that might be ok;
[21:47] <rharper> ideally we'd get the standard image to include it if it's a big win on yaml parsing perf
[22:20] <powersj> rharper: do we care about fedora builds? or just epel for now?
[22:31] <rharper> powersj: both
[22:31] <powersj> rharper: ok trying a build on those right now.
[22:32] <powersj> The build system assumes you have a spec file in your repo, so going to need to figure that one out. Still trying to see if we can generate it on the fly so we have less to change.
[22:32] <rharper> not sure what to do about guessing (testing) which builds should use systemd flag;
[22:32] <powersj> yeah that too...
[22:32] <rharper> so they just read the specfile as is? no "run this cmd" first ?
[22:33] <powersj> correct, I give git repo + branch (optional) + path to spec file
[22:34] <rharper> hrm
[22:34] <powersj> that's the "mock scm"  method.
[22:34] <powersj> there is another method that uses "tito", but our repo obviously is not setup for that
[22:35] <powersj> can also upload a srpm or give a URL to srpm for builds
[22:35] <powersj> then check the release + arches and press go
[22:35] <rharper> yeah, I wonder if we need a cloud-init-spec file repo
[22:35] <rharper> well, maybe srpm uploads would be fine
[22:36] <rharper> we'd do a package/brpm  from master
[22:36] <rharper> and then upload the .src rpm
[22:36] <powersj> yeah doing the git way would be awesome because webhooks ftw
[22:37] <powersj> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init/build/547115/
[22:38] <rharper> fancy sauce
[23:25] <blackboxsw> thanks again for the review rharper  for tomorrow I've addressed your comments on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/323088
[23:25] <blackboxsw> I'm off for today. dinner beckons