cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cs user <acldstk...@gmail.com>
Subject Re: CoreOS/Docker - a new blog series
Date Mon, 20 Apr 2015 09:07:54 GMT
Ah, I managed to get the sshkeypair working with this template! :)

http://dl.openvm.eu/cloudstack/coreos/x86_64/

Just need to get discovery working now.


On Mon, Apr 20, 2015 at 8:58 AM, cs user <acldstkusr@gmail.com> wrote:

> 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 <Kishan.Kavala@citrix.com>
> 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:runseb@gmail.com]
>> Sent: Tuesday, February 17, 2015 8:50 PM
>> To: users@cloudstack.apache.org
>> Subject: Re: CoreOS/Docker - a new blog series
>>
>>
>> On Feb 17, 2015, at 3:36 PM, Andrei Mikhailovsky <andrei@arhont.com>
>> 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" <runseb@gmail.com>
>> >> To: users@cloudstack.apache.org
>> >> 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 <runseb@gmail.com> wrote:
>> >
>> >>>
>> >>> On Feb 17, 2015, at 1:29 PM, Andrei Mikhailovsky <andrei@arhont.com>
>> >>> 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
>> >>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message