Thanks for raising this question, really helpful to the enhancement of our
driver
for the run_validation=False issue, you are right, because z/VM driver only
support config drive and don't support metadata service ,we made bad
assumption
and took wrong action to disabled the whole ssh check, actua
> for the run_validation=False issue, you are right, because z/VM driver
> only support config drive and don't support metadata service ,we made
> bad assumption and took wrong action to disabled the whole ssh check,
> actually according to [1] , we should only disable
> CONF.compute_feature_enable
ing Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Dan Smith
To: "Chen CH Ji"
Cc: "OpenStack Development Mailing List \(not for usage questions
\)"
Date: 04/13/2018 09:46 PM
Subject:Re: [openstack-dev] [Nova] z/V
On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote:
>>>The "iso file" will not be inside the guest, but rather passed to
the guest as a block device, right?
Cloud init expects to find a config drive with following requirements
[1], in order to make cloud init able to consume config drive , we
es: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: melanie witt
To: openstack-dev@lists.openstack.org
Date: 04/17/2018 09:21 AM
Subject: Re: [openstack-
On 04/16/2018 09:20 PM, melanie witt wrote:
I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = True in tempest.conf be
> I propose that we remove the z/VM driver blueprint from the runway at
> this time and place it back into the queue while work on the driver
> continues. At a minimum, we need to see z/VM CI running with
> [validation]run_validation = True in tempest.conf before we add the
> z/VM driver blueprint
On Tue, 17 Apr 2018 16:58:22 +0800, Chen Ch Ji wrote:
For the question on AE documentation, it's open source in [1] and the
documentation for how to build and use is [2]
once our code is upstream, there are a set of documentation change which
will cover this image build process by
adding some l
On Tue, 17 Apr 2018 06:40:35 -0700, Dan Smith wrote:
I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue while work on the driver
continues. At a minimum, we need to see z/VM CI running with
[validation]run_validation = True in tempest.
ctive hide details for melanie witt ---04/17/2018 09:21:03
> AM---On Mon, 16 Apr 2018 14:56:06 +0800, Chen Ch Ji wrote: > >>>]melanie
> witt ---04/17/2018 09:21:03 AM---On Mon, 16 Apr 2018 14:56:06 +0800, Chen
> Ch Ji wrote: > >>>The "iso file" will not be in
k-dev@lists.openstack.org
Date: 04/18/2018 01:47 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat
On Tue, 17 Apr 2018 06:40:35 -0700, Dan Smith wrote:
>> I propose that we remove the z/VM driver blueprint from the runway at
>> this time and p
lopment Mailing List (not for usage questions)"
Date: 04/18/2018 05:08 PM
Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat
I'm confused about the design of AE to be honest. Is there a good reason
that this functionality coul
> Thanks for the concern and fully under it , the major reason is
> cloud-init doesn't have a hook or plugin before it start to read
> config drive (ISO disk) z/VM is an old hypervisor and no way to do
> something like libvirt to define a ISO format disk in xml definition,
> instead, it can define
On 18 April 2018 at 15:10, Dan Smith wrote:
>> Thanks for the concern and fully under it , the major reason is
>> cloud-init doesn't have a hook or plugin before it start to read
>> config drive (ISO disk) z/VM is an old hypervisor and no way to do
>> something like libvirt to define a ISO format
On Wed, Apr 18, 2018 at 10:56 AM, Matthew Booth wrote:
>
> > I agree with Mikal that needing more agent behavior than cloud-init does
> > a disservice to the users.
> >
> > I feel like we get a lot of "but no, my hypervisor is special!"
> > reasoning when people go to add a driver to nova. So far
> Having briefly read the cloud-init snippet which was linked earlier in
> this thread, the requirement seems to be that the guest exposes the
> device as /dev/srX or /dev/cdX. So I guess in order to make this work:
>
> * You need to tell z/VM to expose the virtual disk as an optical disk
> * The z
dress: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Jim Rollenhagen
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 04/19/2018 12:02 AM
Subject: Re: [openstack-dev] [Nova] z/VM intr
On Fri, Apr 20, 2018 at 4:02 AM, Chen CH Ji wrote:
> Thanks a lot for your sharing, that's good info, just curious why [1] need
> zip and base64 encode if my understand is correct
> I was told nova need format should be pure vfat or iso9660, I assume it's
> because actually the config drive itsel
, PRC
From: Jim Rollenhagen
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 04/20/2018 10:13 PM
Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat
On Fri, Apr 20, 2018 at 4:02 AM, Chen CH
District,
Beijing 100193, PRC
From: melanie witt
To: openstack-dev@lists.openstack.org
Date: 04/18/2018 01:41 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat
On Tue, 17 Apr 2018 16:58:22 +0800, Chen Ch Ji wrote:
> For the question
> According to requirements and comments, now we opened the CI runs with
> run_validation = True And according to [1] below, for example, [2]
> need the ssh validation passed the test
>
> And there are a couple of comments need some enhancement on the logs
> of CI such as format and legacy incorrec
On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:
According to requirements and comments, now we opened the CI runs with
run_validation = True
And according to [1] below, for example, [2] need the ssh validation
passed the test
And there are a couple of comments need some enhancement on th
On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote:
> On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:
> > According to requirements and comments, now we opened the CI runs with
> > run_validation = True
> > And according to [1] below, for example, [2] need the ssh validation
> > pas
On Mon, 30 Apr 2018 12:42:40 -0400, Matthew Treinish wrote:
On Mon, Apr 30, 2018 at 09:21:22AM -0700, melanie witt wrote:
On Fri, 27 Apr 2018 17:40:20 +0800, Chen Ch Ji wrote:
According to requirements and comments, now we opened the CI runs with
run_validation = True
And according to [1] below
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Dan Smith
To: "Chen CH Ji"
Cc: "OpenStack Development Mailing List \(not for usage questions
\)"
Date: 04/30/2018 10:55 PM
Subject: Re: [openst
a/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Dan Smith
To: "Chen CH Ji"
Cc: "OpenStack Development Mailing List \(not for usage questions
> can I know a use case for this 'live copy metadata or ' the 'only way
> to access device tags when hot-attach? my thought is this is one time
> thing in cloud-init side either through metatdata service or config
> drive and won't be used later? then why I need a live copy?
If I do something lik
27 matches
Mail list logo
