<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 25, 2015 at 9:33 PM, Curtis Hovey-Canonical <span dir="ltr"><<a href="mailto:curtis@canonical.com" target="_blank">curtis@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Mar 25, 2015 at 3:04 AM, Andrew Wilkins<br>
<<a href="mailto:andrew.wilkins@canonical.com">andrew.wilkins@canonical.com</a>> wrote:<br>
> Hey folks,<br>
><br>
> I just signed up for a GCE trial, and tested out the provider on master.<br>
> Found a couple of issues.<br>
><br>
> I've filed <a href="https://bugs.launchpad.net/juju-core/+bug/1436191" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1436191</a>. I suspect the<br>
> same issue would exist on 1.23, but haven't tested. I haven't set the<br>
> status/importance, because I don't know what the importance is (there's no<br>
> CI or docs?), and I'd like for someone to confirm the bug.<br>
<br>
</span>I just got CI credentials yesterday evening. As CI is using a project<br>
shared by several Canonical staff, it isn't clear to me if I should be<br>
creating new client ids or how to generate keys and not interfere with<br>
other people.<br>
<br>
Contrary to text generated by init, 'region' is required.</blockquote><div><br></div><div>Indeed, I forgot that one. The boilerplate we generate should</div><div>not comment out "region".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Second, a UX thing. It was mostly clear how to generate keys, but it wasn't<br>
> super clear what format to put them into environments.yaml. Obviously<br>
> this'll be documented, but I think it'd be nice if in environments.yaml we<br>
> could just specify the location of the JSON file that GCE spits out, and<br>
> have Juju extract the info it needs, like we do with certs and SSH keys.<br>
<br>
</span>I assumed I could use authorized-keys.</blockquote><div><br></div><div>authorized-keys is fine. That was a bad example.</div><div><br></div><div>In the Azure provider, credentials take the form of a certificate and key.</div><div>You *can* enter the cert/key inline in your environments.yaml, but you</div><div>can also specify management-certificate-path and the provider will read</div><div>that file and add the contents into the management-certificate attribute.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Curtis Hovey<br>
Canonical Cloud Development and Operations<br>
<a href="http://launchpad.net/~sinzui" target="_blank">http://launchpad.net/~sinzui</a><br>
</font></span></blockquote></div><br></div></div>