Hi All, Thanks for the blog post Phillip, very impressive! :)
I've had a play with coreos/cloudstack myself, but it's been pretty manual and the SSH public key has been baked into the template. I guess I'm missing something very simple here, but how is everyone managing to set the following via the dhcp router metadata? ssh_authorized_keys: - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0g+ZTxC7weoIJLUafOgrm+h. Are you creating a script on the coreos template which curls against the router the first time it boots? Cheers! On Thu, Feb 19, 2015 at 12:32 PM, Kishan Kavala <[email protected]> wrote: > cloud-config is supported via config drive in CoreOS [1]. Are there any > usecases for cloudstack if config drive is supported as an alternative to > VR providing userdata/metadata? It could be a generic implementation not > specific to CoreOS. > > [1] > https://coreos.com/docs/cluster-management/setup/cloudinit-config-drive/ > > -----Original Message----- > From: sebgoa [mailto:[email protected]] > Sent: Tuesday, February 17, 2015 8:50 PM > To: [email protected] > Subject: Re: CoreOS/Docker - a new blog series > > > On Feb 17, 2015, at 3:36 PM, Andrei Mikhailovsky <[email protected]> > wrote: > > > Seb, > > > > It is strange, but $public_ipv4 seem to work now. I've not really > changed anything and I have attempted to use it several times in the past. > Very strange indeed. > > > > yeah, public_ipv4 should work. Sometimes I have seen failure, but these > were due to etcd bootstrapping. I don't know how you do it, but if you use > token from the cores discovery service, you will need to regenerate a new > one when you start a new cluster...and make sure that this token is > properly set in your cloud-config files.... > > > > > Andrei > > ----- Original Message ----- > > > >> From: "sebgoa" <[email protected]> > >> To: [email protected] > >> Sent: Tuesday, 17 February, 2015 2:04:10 PM > >> Subject: Re: CoreOS/Docker - a new blog series > > > >> On Feb 17, 2015, at 1:58 PM, sebgoa <[email protected]> wrote: > > > >>> > >>> On Feb 17, 2015, at 1:29 PM, Andrei Mikhailovsky <[email protected]> > >>> wrote: > >>> > >>>>>> etcd: > >>>>>> name: <server-name> > >>>>>> discovery: https://discovery.etcd.io/<token> > >>>>>> addr: <private_ip>:4001 > >>>>>> peer-addr: <private_ip>:7001 > >>>>>> > >>>>>> You need to change the values between <> to suite your > >>>>>> environment. > >>>>>> > >>>>>> I've read that there should be variable $private_ipv4 to > >>>>>> automatically inject your private IP, however, it doesn't seem to > >>>>>> work for some reason. Will need to investigate further > >>>>>> > >>>> > >>>>> try with $public_ipv4 > >>>> > >>>>>> Andrei > >>>>>> > >>>> > >>>> Seb, > >>>> > >>>> I've tried to use the $public_ipv4 and it seems to have made the > >>>> sabstitube to the public ip. At least I can see the messages in > >>>> journal: > >>>> > >>>> Feb 17 12:15:10 coreos-04022015-6 etcd[614]: [etcd] Feb 17 > >>>> 12:15:10.537 INFO | coreos-04022015-6 joined the cluster via peer > >>>> 10.0.1.45:7001 > >>>> Feb 17 12:15:10 coreos-04022015-6 etcd[614]: [etcd] Feb 17 > >>>> 12:15:10.539 INFO | etcd server [name coreos-04022015-6, listen on > >>>> :4001, advertised url http://178.248.xxx.xxx:4001] Feb 17 12:15:10 > >>>> coreos-04022015-6 etcd[614]: [etcd] Feb 17 > >>>> 12:15:10.540 INFO | peer server [name coreos-04022015-6, listen on > >>>> :7001, advertised url http://178.248.xxx.xxx:7001] > >>>> > >>>> However, I would like to use the private ip range for that. The > >>>> substitution did not work when i've tried the $private_ipv4. Is it > >>>> working you you? > >>>> > >>> > >>> I haven't looked deep into it, my guess is there might be a problem > >>> with the cloudstack metadata. > >>> Can you check if private_ipv4 exists and is what you expect it to > >>> be: > >>> > >>> curl your virtual router to get the metadata: > >>> > >>> http://docs.cloudstack.apache.org/projects/cloudstack-administration > >>> /en/4.4/api.html?highlight=metadata#user-data-and-meta-data > >>> > >>> I have a hunch it's not defined and thus coreOS does not work with > >>> it. I could be wrong but could be a cloudstack bug. > > > >> Did a bit of digging and things should work. > > > >> The metadata url for cloudstack instances is fetched via : > > > >> https://github.com/coreos/coreos-overlay/blob/master/coreos-base/oem- > >> cloudstack/files/cloudstack-dhcp > > > >> cloudstack serves: > > > >> service-offering > >> availability-zone > >> local-ipv4 > >> local-hostname > >> public-ipv4 > >> public-hostname > >> instance-id > >> vm-id > >> public-keys > >> cloud-identifier > > > >> Now I am just not sure how coreOS does the substitution: > > > >> https://github.com/coreos/coreos-cloudinit/tree/4eaaa5c9273a0ce557d42 > >> 4f5da676777bef53e8e/datasource/metadata > > > >> Since there is no cloudstack metadata source defined yet. > > > >> I will ask around and keep digging > > > >>> > >>>> Thanks > >>>> > >>>> Andrei > >>> > >
