Can we not rely on secondary storage for config drive? I'd much rather see
it generated dynamically into a temp space during VM start, or (less
desirable) even during VM create on primary storage (perhaps in a
configdrive) directory where the root disk resides.  It just seems like a
bad idea to rely on mounting and availability of secondary storage (which
by design is supposed to be out of band from running VMs) to have a healthy
VM. People put a lot of work into their primary storage for VM
availability, not as much for secondary storage.

On Wed, Jul 12, 2017 at 5:01 PM ilya musayev (JIRA) <j...@apache.org> wrote:

>
>     [
> https://issues.apache.org/jira/browse/CLOUDSTACK-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084678#comment-16084678
> ]
>
> ilya musayev commented on CLOUDSTACK-9813:
> ------------------------------------------
>
> Hey [~KrisSterckx] [~waegemae]
>
> The idea of storing config drive on secondary store - is actually bad and
> wont be approved by Information Security teams.
>
> Regards,
> ilya
>
> > Use configdrive for userdata, metadata & password
> > --------------------------------------------------
> >
> >                 Key: CLOUDSTACK-9813
> >                 URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> >             Project: CloudStack
> >          Issue Type: New Feature
> >      Security Level: Public(Anyone can view this level - this is the
> default.)
> >          Components: KVM, Network Controller, Secondary Storage,
> SystemVM, VMware
> >    Affects Versions: Future
> >            Reporter: Eric Waegeman
> >            Assignee: Kris Sterckx
> >
> > To avoid the use of an extra VM for the virtual router we implement
> configdrive for userdata, metadata & password.
> > The configdrive ISO is created on the secondary store and the KVM &
> VMware plugins are adapted to accept the configdrive ISO as second cdrom.
> > Is applicable for isolated, VPC and shared networks.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Reply via email to