git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ConfigDrive status



On 03/27/2018 08:07 PM, Kris Sterckx wrote:
> Guys if we are talking about the 4.11 implementation, this is documented
> here
> 
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+ConfigDrive+for+Metadata%2C+Userdata+and+Password
> 
> 
> It built further to Jayapal's work, but the support has been significantly
> generalized.
> 
> - generalized to support Isolated networks and VPC's as well .  (note : no
> support *yet* for Basic Zone)
> 

Thanks! It's on my whish-list to test this feature and some other things
like local storage migration.

Could take a while before I get to it, but then we can test this for
Basic Networking as well.

Wido

> - KVM support and ESXI   (lack of lab for testing XEN)
> 
> - it comes with its own User Data provider now ("ConfigDrive") , so any
> network offering can or cannot select Config Drive to be the provider of
> User Data.
>   The use case where VR is not any longer in any of the providers list is
> an interesting use case obviously, but it's fully flexible.
> 
> - OpenStack cloud-init aligned  (~ cfr  Miami CCC conclusion last year)
> 
> - CoreOS ignition support has been provided
> 
> 
> The iso's are stored today at the secondary storage.
> 
> 
> First time i see the higher reported issues . In which context were they
> filed ?
> 
> 
> Kris
> 
> 
> On 27 March 2018 at 16:55, Wido den Hollander <wido@xxxxxxxxx> wrote:
> 
>>
>>
>> On 03/27/2018 10:29 AM, Jayapal Uradi wrote:
>>> Yes.
>>> In case shared network there is only DHCP and DNS and user data. If the
>> DHCP and DNS is external then I don’t want to launch a VR only for user
>> data.
>>> Initially it was started to address only specific requirement.
>>>
>>> We can have a config drive provider and it can be extended to all
>> networks/zones.
>>>
>>
>> Like Lucian/Nux said this can be very helpful in other situations as
>> well. ConfigDrive allows for metadata to reach the Instance without
>> networking function or DHCP.
>>
>> In IPv6-only environments this can also work very well, so yes, it would
>> be great if this works in other offerings.
>>
>> When I have the time I'll dig into this and see if I can get it working.
>>
>> Wido
>>
>>> Thanks,
>>> Jayapal
>>>
>>>> On Mar 27, 2018, at 1:48 PM, Nux! <nux@xxxxxxxxx> wrote:
>>>>
>>>> Hi Jayapal,
>>>>
>>>> This has probably already been discussed and am missing a lot of
>> context, but can you summarise why this is not applied in all zones?
>>>> A network independent userdata provider should seem like the lowest
>> common denominator, right?
>>>>
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>> Nux!
>>>> www.nux.ro
>>>>
>>>> ----- Original Message -----
>>>>> From: "Jayapal Uradi" <jayapal.uradi@xxxxxxxxxxxxxx>
>>>>> To: "dev" <dev@xxxxxxxxxxxxxxxxxxxxx>
>>>>> Sent: Tuesday, 27 March, 2018 05:34:44
>>>>> Subject: Re: ConfigDrive status
>>>>
>>>>> Hi Nux,
>>>>>
>>>>> It is developed only for advanced zone shared network (offering
>> without any
>>>>> services).
>>>>> This feature is developed on xenserver, kvm and vmware hypervisor.
>>>>>
>>>>> It can be extended to other networks.
>>>>>
>>>>> -Jayapal
>>>>>> On Mar 26, 2018, at 9:56 PM, Nux! <nux@xxxxxxxxx> wrote:
>>>>>>
>>>>>> Thanks for all the feedback, I'll do some reading then.
>>>>>>
>>>>>> Lucian
>>>>>>
>>>>>> --
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>>>
>>>>>> Nux!
>>>>>> www.nux.ro
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "ilya musayev" <ilya.mailing.lists@xxxxxxxxx>
>>>>>>> To: "dev" <dev@xxxxxxxxxxxxxxxxxxxxx>
>>>>>>> Sent: Monday, 26 March, 2018 17:03:30
>>>>>>> Subject: Re: ConfigDrive status
>>>>>>
>>>>>>> Lucian
>>>>>>>
>>>>>>> We reported 3-4 issues with config drive. It’s being worked on. It
>> does
>>>>>>> work - but not per agreed upon specifications.
>>>>>>>
>>>>>>> See below
>>>>>>>
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10287
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10288
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10289
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10290
>>>>>>>
>>>>>>> Regards
>>>>>>> Ilya
>>>>>>>
>>>>>>> On Mon, Mar 26, 2018 at 8:58 AM Dag Sonstebo <
>> Dag.Sonstebo@xxxxxxxxxxxxx>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Lucian,
>>>>>>>>
>>>>>>>> I’m maybe not the right person to answer this – but my
>> understanding is it
>>>>>>>> only kicks in when you have a network offering without a VR, at
>> which point
>>>>>>>> the metadata etc. is presented as the config drive. Happy to be
>> corrected
>>>>>>>> on this.
>>>>>>>>
>>>>>>>> We did however have a really major gotcha 18 months ago – when a
>> customer
>>>>>>>> did a CloudStack upgrade and ended up with new unexpected config
>> drives
>>>>>>>> causing changes to all the VMware disk controller addressing –
>> meaning VMs
>>>>>>>> wouldn’t boot, couldn’t see disks, etc. If you use VMware I would
>> test
>>>>>>>> beforehand.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Dag Sonstebo
>>>>>>>> Cloud Architect
>>>>>>>> ShapeBlue
>>>>>>>>
>>>>>>>> On 26/03/2018, 14:50, "Nux!" <nux@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>   Hi,
>>>>>>>>
>>>>>>>>   I am interested in the ConfigDrive feature.
>>>>>>>>   Before I potentially waste time on it, is anyone around here
>> using it
>>>>>>>> or can clarify whether it's usable or not or gotchas etc?
>>>>>>>>
>>>>>>>>   Regards,
>>>>>>>>   Lucian
>>>>>>>>
>>>>>>>>   --
>>>>>>>>   Sent from the Delta quadrant using Borg technology!
>>>>>>>>
>>>>>>>>   Nux!
>>>>>>>>   www.nux.ro
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dag.Sonstebo@xxxxxxxxxxxxx
>>>>>>>> www.shapeblue.com
>>>>>>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>>>>>>> @shapeblue
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> DISCLAIMER
>>>>> ==========
>>>>> This e-mail may contain privileged and confidential information which
>> is the
>>>>> property of Accelerite, a Persistent Systems business. It is intended
>> only for
>>>>> the use of the individual or entity to which it is addressed. If you
>> are not
>>>>> the intended recipient, you are not authorized to read, retain, copy,
>> print,
>>>>> distribute or use this message. If you have received this
>> communication in
>>>>> error, please notify the sender and delete all copies of this message.
>>>>> Accelerite, a Persistent Systems business does not accept any
>> liability for
>>>>> virus infected mails.
>>>
>>> DISCLAIMER
>>> ==========
>>> This e-mail may contain privileged and confidential information which is
>> the property of Accelerite, a Persistent Systems business. It is intended
>> only for the use of the individual or entity to which it is addressed. If
>> you are not the intended recipient, you are not authorized to read, retain,
>> copy, print, distribute or use this message. If you have received this
>> communication in error, please notify the sender and delete all copies of
>> this message. Accelerite, a Persistent Systems business does not accept any
>> liability for virus infected mails.
>>>
>>
>