Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection question

[Chen CH Ji]

Got it, this is what I am looking for .. thank you
 
- Original message -From: Slawomir Kaplonski To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [nova][neutron] boot server with more than one subnet selection questionDate: Tue, Nov 13, 2018 1:06 AM 
Hi,You can choose which subnet (and even IP address) should be used, see „fixed_ips” field in [1].If You will not provide anything Neutron will choose for You one IPv4 address and one IPv6 address and in both cases it will be chosen randomly from available IPs from all subnets.[1] https://developer.openstack.org/api-ref/network/v2/?expanded=create-port-detail#create-port> Wiadomość napisana przez Chen CH Ji  w dniu 12.11.2018, o godz. 13:44:>> I have a network created like below:>  > 1 network with 3 subnets (1 ipv6 and 2 ipv4) ,when boot, whether I can select subnet to boot from or the subnet will be force selected by the order the subnet created? Any document or code can be  referred? Thanks>  > | fd0e2078-044d-4c5c-b114-3858631e6328 | private   | a8184e4f-5165-4ea8-8ed8-b776d619af6e fd9b:c245:1aaa::/64 |> |                                      |           | b3ee7cad-c672-4172-a183-8e9f069bea31 10.0.0.0/26         |> |                                      |           | 9439abfd-afa2-4264-8422-977d725a7166 10.0.2.0/24         |>  >> __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev—Slawek KaplonskiSenior software engineerRed Hat__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][neutron] boot server with more than one subnet selection question

[Chen CH Ji]

I have a network created like below:
 
1 network with 3 subnets (1 ipv6 and 2 ipv4) ,when boot, whether I can select subnet to boot from or the subnet will be force selected by the order the subnet created? Any document or code can be  referred? Thanks
 
| fd0e2078-044d-4c5c-b114-3858631e6328 | private   | a8184e4f-5165-4ea8-8ed8-b776d619af6e fd9b:c245:1aaa::/64 ||  |   | b3ee7cad-c672-4172-a183-8e9f069bea31 10.0.0.0/26 ||  |   | 9439abfd-afa2-4264-8422-977d725a7166 10.0.2.0/24 |
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] about live-resize the instance

[Chen CH Ji]

Yes, this has been discussed for long time and If I remember this correctly seems S PTG also had some discussion on it (maybe public Cloud WG ? ), Claudiu has been pushing this for several cycles and he actually had some code at [1] but no additional progress there...
 
[1] https://review.openstack.org/#/q/status:abandoned+topic:bp/instance-live-resize
 
- Original message -From: "Rambo" To: "OpenStack Developmen" Cc:Subject: [openstack-dev] [nova] about live-resize the instanceDate: Mon, Nov 5, 2018 10:28 AM 
Hi,all
 
      I find it is important that live-resize the instance in production environment. We have talked it many years and we agreed this in Rocky PTG, then the author remove the spec to Stein, but there is no information about this spec, is there anyone to push the spec and achieve it? Can you tell me more about this ?Thank you very much.
 
[1]https://review.openstack.org/#/c/141219/
 
 
 
 
 
 
 
 
Best Regards
Rambo


__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [zVM] [python3] tox/zuul issues for zVM OpenStack

[Chen CH Ji]

Thank you for your detailed information, we will will on this and add you as reviewer when it's ready, thanks~
 
- Original message -From: William M Edmonds/Raleigh/IBMTo: Chen CH Ji/China/IBM@IBMCN, "OpenStack Development Mailing List \(not for usage questions\)" Cc:Subject: [zVM] [python3] tox/zuul issues for zVM OpenStackDate: Mon, Oct 15, 2018 11:06 PM The current tox.ini for ceilometer-zvm includes this line [1] similar to what ceilometer-powervm was doing up until recently:   -egit+https://github.com/openstack/ceilometer@master#egg=ceilometerWe found that this no longer works since ceilometer was added to upper-constraints [2]. We first got things working again by [3] and are now improving on that by [4]. I expect you will need to make similar changes.I was going to propose this to ceilometer-zvm for you, but then noticed that you don't even have a zuul.yaml file. You're missing changes like [5] adding lower-constraints checking and [6] for the python3-first effort. So that is probably a bigger issue to address first (and for networking-powervm and nova-zvm-virt-driver as well as ceilometer-zvm). When you get to the python3 stuff, I suggest you work with dhellmann on that. He's got scripts to generate at least some of those commits.[1] http://git.openstack.org/cgit/openstack/ceilometer-zvm/tree/tox.ini#n19[2] https://review.openstack.org/#/c/601498[3] https://review.openstack.org/#/c/609058/[4] https://review.openstack.org/#/c/609823/[5] https://review.openstack.org/#/c/555358/[6] https://review.openstack.org/#/c/594984/W. Matthew EdmondsSr. Software Engineer, IBM Power SystemsEmail: edmon...@us.ibm.comPhone: (919) 543-7538 / Tie-Line: 441-7538
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for'T' release

[Chen CH Ji]

>>>(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
>>> "IBM announced that KVM for IBM z will be withdrawn, effective March
>>> 31, 2018 [...] development will not only continue unaffected, but
>>> the options for users grow, especially with the recent addition of
>>> SuSE to the existing support in Ubuntu."

>>> The message seems to be: "use a regular distribution".  So this is
>>> covered, if we a version based on other distributions.

Yes, IBM don't have a product on s390x anymore per [3] indicated,
we are cooperating with distro in enablement

and for openstack, KVM on z has its own 3rd CI maintaining by us per [5]

[5] http://ci-watch.tintri.com/project?project=nova(IBM zKVM CI )

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Kashyap Chamarthy 
To: openstack-operators@lists.openstack.org,
openstack-...@lists.openstack.org
Date:   09/24/2018 09:28 PM
Subject:[Openstack-operators] RFC: Next minimum libvirt / QEMU versions
for 'T' release



Hey folks,

Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
versions for the 'T' (which is still in the naming phase) release, which
will come out in the autumn (Sep-Nov) of 2019.

Proposal


Looking at the DistroSupportMatrix[2], it seems like we can pick the
libvirt and QEMU versions supported by the next LTS release of Ubuntu --
18.04; "Bionic", which are:

libvirt: 4.0.0
QEMU:2.11

Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
above versions.  And it seems reasonable to assume that the enterprise
distribtions will also ship the said versions pretty soon; but let's
double-confirm below.

Considerations and open questions
-

(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
"IBM announced that KVM for IBM z will be withdrawn, effective March
31, 2018 [...] development will not only continue unaffected, but
the options for users grow, especially with the recent addition of
SuSE to the existing support in Ubuntu."

The message seems to be: "use a regular distribution".  So this is
covered, if we a version based on other distributions.

(b) Oracle Linux: Can you please confirm if you'll be able to
release libvirt and QEMU to 4.0.0 and 2.11, respectively?

(c) SLES: Same question as above.

Assuming Oracle Linux and SLES confirm, please let us know if there are
any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
release to be libvirt: 4.0.0 and QEMU: 2.11.

* * *

A refresher on libvirt and QEMU release schedules
-

  - There will be at least 12 libvirt releases (_excluding_ maintenance
releases) by Autumn 2019.  A new libvirt release comes out every
month[4].

  - And there will be about 4 releases of QEMU.  A new QEMU release
comes out once every four months.

[1]
http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b

-- Pick next minimum libvirt / QEMU versions for "Stein"
[2]
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

[3]
http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html

[4]
https://libvirt.org/downloads.html#schedule


--
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for'T' release

[Chen CH Ji]

>>>(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
>>> "IBM announced that KVM for IBM z will be withdrawn, effective March
>>> 31, 2018 [...] development will not only continue unaffected, but
>>> the options for users grow, especially with the recent addition of
>>> SuSE to the existing support in Ubuntu."

>>> The message seems to be: "use a regular distribution".  So this is
>>> covered, if we a version based on other distributions.

Yes, IBM don't have a product on s390x anymore per [3] indicated,
we are cooperating with distro in enablement

and for openstack, KVM on z has its own 3rd CI maintaining by us per [5]

[5] http://ci-watch.tintri.com/project?project=nova(IBM zKVM CI )

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Kashyap Chamarthy 
To: openstack-operat...@lists.openstack.org,
openstack-dev@lists.openstack.org
Date:   09/24/2018 09:28 PM
Subject:[Openstack-operators] RFC: Next minimum libvirt / QEMU versions
for 'T' release



Hey folks,

Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
versions for the 'T' (which is still in the naming phase) release, which
will come out in the autumn (Sep-Nov) of 2019.

Proposal


Looking at the DistroSupportMatrix[2], it seems like we can pick the
libvirt and QEMU versions supported by the next LTS release of Ubuntu --
18.04; "Bionic", which are:

libvirt: 4.0.0
QEMU:2.11

Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
above versions.  And it seems reasonable to assume that the enterprise
distribtions will also ship the said versions pretty soon; but let's
double-confirm below.

Considerations and open questions
-

(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
"IBM announced that KVM for IBM z will be withdrawn, effective March
31, 2018 [...] development will not only continue unaffected, but
the options for users grow, especially with the recent addition of
SuSE to the existing support in Ubuntu."

The message seems to be: "use a regular distribution".  So this is
covered, if we a version based on other distributions.

(b) Oracle Linux: Can you please confirm if you'll be able to
release libvirt and QEMU to 4.0.0 and 2.11, respectively?

(c) SLES: Same question as above.

Assuming Oracle Linux and SLES confirm, please let us know if there are
any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
release to be libvirt: 4.0.0 and QEMU: 2.11.

* * *

A refresher on libvirt and QEMU release schedules
-

  - There will be at least 12 libvirt releases (_excluding_ maintenance
releases) by Autumn 2019.  A new libvirt release comes out every
month[4].

  - And there will be about 4 releases of QEMU.  A new QEMU release
comes out once every four months.

[1]
http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b

-- Pick next minimum libvirt / QEMU versions for "Stein"
[2]
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

[3]
http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html

[4]
https://libvirt.org/downloads.html#schedule


--
/kashyap

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Chen CH Ji]

Thanks for the confirmation, I agree use internal maintain CI whitelist is
a good way, and I confirmed with our CI folks that we already did so and
more can be removed per
Eric's test result below, so we will compare and remove unnecessary cases
to get more bandwidth to run 3rd party CI. thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Ghanshyam Mann 
To: "OpenStack Development Mailing List \\"

Date:   09/07/2018 02:18 PM
Subject:Re: [openstack-dev] [tempest][CI][nova compute] Skipping
non-compute-driver tests






  On Fri, 07 Sep 2018 04:41:32 +0900 Eric Fried 
wrote 
 > Jichen-
 >
 > That patch is not ever intended to merge; hope that was clear from
the
 > start :) It was just a proving ground to demonstrate which tests still
 > pass when there's effectively no compute driver in play.
 >
 > We haven't taken any action on this from our end, though we have
done a
 > little brainstorming about how we would tool our CI to skip those tests
 > most (but not all) of the time. Happy to share our experiences with you
 > if/as we move forward with that.
 >
 > Regarding the tempest-level automation, I certainly had z in mind
when
 > I was thinking about it. If you have the time and inclination to help
 > look into it, that would be most welcome.

Sorry for late response, somehow i missed this thread. As you mentioned and
noticed in your patch that there are ~700 tests which does not touch
compute driver. Most of them are from neutron-tempest-plugins or other
service tests. From Tempest compute tests, many of them are negative tests
or DB layer tests [1].

neutron-tempest-plugin or other service test you can always avoid to run
with regex. And i do not think compute negative or DB test will take much
time to run. But still if you want to avoid to run then, I think it is easy
to maintain a whitelist regex file on CI side which can run only compute
driver tests(61 in this case).

Tagging compute driver on tempest side is little hard to maintain i feel
and it can goes out of date very easily. If you have any other idea on
that, we can surly talk in PTG on this.

[1]
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz


 >
 > Thanks,
 > efried
 >
 > On 09/06/2018 12:33 AM, Chen CH Ji wrote:
 > > I see the patch is still ongoing status and do you have a follow up
 > > plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
 > > so skip non-compute related cases will be a good for 3rd part CI ..
thanks
 > >
 > > Best Regards!
 > >
 > > Kevin (Chen) Ji 纪 晨
 > >
 > > Engineer, zVM Development, CSTL
 > > Notes: 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
 > >
 > > Inactive hide details for Eric Fried ---09/04/2018 09:35:09
PM---Folks-
 > > The other day, I posted an experimental patch [1] withEric Fried
 > > ---09/04/2018 09:35:09 PM---Folks- The other day, I posted an
 > > experimental patch [1] with an effectively
 > >
 > > From: Eric Fried 
 > > To: "OpenStack Development Mailing List (not for usage questions)"
 > > 
 > > Date: 09/04/2018 09:35 PM
 > > Subject: [openstack-dev] [tempest][CI][nova compute] Skipping
 > > non-compute-driver tests
 > >
 > >

 > >
 > >
 > >
 > > Folks-
 > >
 > > The other day, I posted an experimental patch [1] with an effectively
 > > empty ComputeDriver (just enough to make n-cpu actually start) to see
 > > how much of our CI would pass. The theory being that any tests that
 > > still pass are tests that don't touch our compute driver, and are
 > > therefore not useful to run in our CI environment. Because anything
that
 > > doesn't touch our code should already be well covered by generic
 > > dsvm-tempest CIs. The results [2] show that 707 tests still pass.
 > >
 > > So I'm wondering whether there might be a way to mark tests as being
 > > "compute driver-specific" such that we could switch off all the other
 > > ones [3] via a one-line conf setting. Because surely this has
potential
 > > to save a lot of CI resource not just for us but for other driver
 > > vendors, in tree and out.
 > >
 > > Thanks,
 > > efried
 > >
 > > [1]
https://review.openstack.org/#/c/5

Re: [openstack-dev] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Chen CH Ji]

I see the patch is still ongoing status and do you have a follow up
plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
so skip non-compute related cases will be a good for 3rd part CI .. thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Eric Fried 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   09/04/2018 09:35 PM
Subject:[openstack-dev] [tempest][CI][nova compute] Skipping
non-compute-driver tests



Folks-

 The other day, I posted an experimental patch [1] with an
effectively
empty ComputeDriver (just enough to make n-cpu actually start) to see
how much of our CI would pass. The theory being that any tests that
still pass are tests that don't touch our compute driver, and are
therefore not useful to run in our CI environment. Because anything that
doesn't touch our code should already be well covered by generic
dsvm-tempest CIs. The results [2] show that 707 tests still pass.

 So I'm wondering whether there might be a way to mark tests as
being
"compute driver-specific" such that we could switch off all the other
ones [3] via a one-line conf setting. Because surely this has potential
to save a lot of CI resource not just for us but for other driver
vendors, in tree and out.

Thanks,
efried

[1]
https://review.openstack.org/#/c/599066/

[2]
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz

[3] I get that there's still value in running all those tests. But it
could be done like once every 10 or 50 or 100 runs instead of every time.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

[Chen CH Ji]

Thanks all for helping , Saw this patch [1] merged and assume that's the
fix for the issue , we will rebase based on it then try again,

[1] https://review.openstack.org/#/c/575872/4

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Doug Hellmann 
To: openstack-dev 
Date:   06/16/2018 08:14 AM
Subject:Re: [openstack-dev] [requirements][nova] weird error on
'Validating lower constraints of test-requirements.txt'



Excerpts from Eric Fried's message of 2018-06-15 18:09:49 -0500:
> Doug-
>
> > The lower constraints tests only look at files in the same repo.
> > The minimum versions of dependencies set in requirements.txt,
> > test-requirements.txt, etc. need to match the values in
> > lower-constraints.txt.
> >
> > In this case, the more detailed error message is a few lines above the
> > error quoted by Chen CH Ji. The detail say "Requirement for package
> > retrying has no lower bound" which means that there is a line in
> > requirements.txt indicating a dependency on "retrying" but without
> > specifying a minimum version. That is the problem.
>
> The patch didn't change the retrying constraint in requirements.txt [1];
> why isn't this same failure affecting every other patch in nova?
>
> [1]
https://review.openstack.org/#/c/523387/51/requirements.txt@65

>
> -efried
>

Earlier this cycle I updated the requirements check job to verify
that all of the settings are correct any time any changes to the
dependency lists are made. We used to only look at the line being
changed, but that allowed incorrect settings to stay in place for
a long time so we weren't actually testing with good settings. We
still only run that job when the dependency list is modified in
some way.

Earlier this week, Matt Thode updated the job to be more strict and
to require that all dependencies have a minimum version specified
[2]. We did this because some project teams thought that after we
dropped the minimums from the global-requirements.txt list they
were supposed to (or allowed to) drop them from their project
dependency lists, too.

My guess is that this dependency in nova never had a lower bound and
that this is the first patch to touch the dependency list, so now it's
being blocked on the fact that the list has a validation error.

I recommend using a separate patch to fix the minimum version of
retrying and then rebasing 523387 on top of the new patch.

Doug

[2]
https://review.openstack.org/#/c/574367/


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

[Chen CH Ji]

on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to fail on
requirements-check with following error in [2]

Validating lower constraints of test-requirements.txt
*** Incompatible requirement found!
*** See http://docs.openstack.org/developer/requirements

but it doesn't provide enough info to know what's wrong , and because I
didn't make too much change , curious on why
the job failed... can anyone provide any hint on what happened there?
thanks

[1]https://review.openstack.org/#/c/523387
[2]
http://logs.openstack.org/87/523387/51/check/requirements-check/3598ba0/job-output.txt.gz

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][nova] anyway to specify req-id in LOG.xxx

[Chen CH Ji]

Due to bug [1] looks like the req-id of each request will be recorded in
context and then LOG.xxx will use the context if not spcified
per bug reported, the periodic task seems reuse the context of its previous
action and lead to same req-id in the log
quick oslo code check didn't provide too much help along with [2] seems
doesn't work

any hint to specify the id in log instead of using default one? thanks


[1] https://bugs.launchpad.net/nova/+bug/1773102
[2] https://review.openstack.org/#/c/570707/1

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

we are continue to evaluating the ways to remove the restrictions in the
future, one question on following comments:

>>>Why don't you support the metadata service? That's a pretty fundamental
mechanism for nova and openstack. It's the only way you can get a live
copy of metadata, and it's the only way you can get access to device
tags when you hot-attach something. Personally, I think that it's
something that needs to work.

As Matt mentioned in https://review.openstack.org/#/c/562154/ PS#4
As far as I know the metadata service is not a basic feature, it's optional
and some deployments don't run it because of possible security concerns.
so seems it's different suggestion,... and for the following suggestion
It's the only way you can get a live copy of metadata, and it's the only
way you can get access to device tags when you hot-attach something

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?
 and because nova do the hot attach why it's the only way to access the
tags? what exec in the deployed VM will access the device? cloud-init or
something else?

Thanks a lot for your help

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Dan Smith <d...@danplanet.com>
To: "Chen CH Ji" <jiche...@cn.ibm.com>
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" <openstack-dev@lists.openstack.org>
Date:   04/13/2018 09:46 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



> 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_enabled.metadata_service but keep both
> self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
> order to make config drive test validation take effect, our CI will
> handle that

Why don't you support the metadata service? That's a pretty fundamental
mechanism for nova and openstack. It's the only way you can get a live
copy of metadata, and it's the only way you can get access to device
tags when you hot-attach something. Personally, I think that it's
something that needs to work.

> For the tgz/iso9660 question below, this is because we got wrong info
> from low layer component folks back to 2012 and after discuss with
> some experts again, actually we can create iso9660 in the driver layer
> and pass down to the spawned virtual machine and during startup
> process, the VM itself will mount the iso file and consume it, because
> from linux perspective, either tgz or iso9660 doesn't matter , only
> need some files in order to transfer the information from openstack
> compute node to the spawned VM.  so our action is to change the format
> from tgz to iso9660 and keep consistent to other drivers.

The "iso file" will not be inside the guest, but rather passed to the
guest as a block device, right?

> For the config drive working mechanism question, according to [2] z/VM
> is Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2
> hypervisor, there is no file system in z/VM hypervisor (I omit too
> much detail here) , so we can't do something like linux operation
> system to keep a file as qcow2 image in the host operating system,

I'm not sure what the type-1-ness has to do with this. The hypervisor
doesn't need to support any specific filesystem for this to work. Many
drivers we have in the tree are type-1 (xen, vmware, hyperv, powervm)
and you can argue that KVM is type-1-ish. They support configdrive.

> what we do is use a special file pool to store the config drive and
> during VM init process, we read that file from special device and
> attach to VM as iso9660 format then cloud-init will handle the follow
> up, the cloud-init handle process is identical to other platform

This and the previous mention of this sort of behavior has me
concerned. Are you describing some sort of process that runs when the
instance is starting to initialize its environment, or something that
runs  *inside* the instance and thus functionality that has to exist in
the *image* to work?

--Dan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova aggregate and nova placement apiaggregate

[Chen CH Ji]

not sure whether it will helpful , FYI

https://developer.openstack.org/api-ref/placement/

The primary differences between Nova’s host aggregates and placement
aggregates are the following:
  In Nova, a host aggregate associates a nova-compute service with
  other nova-compute services. Placement aggregates are not specific to
  a nova-compute service and are, in fact, not compute-specific at all.
  A resource provider in the Placement API is generic, and placement
  aggregates are simply groups of generic resource providers. This is
  an important difference especially for Ironic, which when used with
  Nova, has many Ironic baremetal nodes attached to a single
  nova-compute service. In the Placement API, each Ironic baremetal
  node is its own resource provider and can therefore be associated to
  other Ironic baremetal nodes via a placement aggregate association.
  In Nova, a host aggregate may have metadata key/value pairs attached
  to it. All nova-compute services associated with a Nova host
  aggregate share the same metadata. Placement aggregates have no such
  metadata because placement aggregates only represent the grouping of
  resource providers. In the Placement API, resource providers are
  individually decorated with traits that provide qualitative
  information about the resource provider.
  In Nova, a host aggregate dictates the availability zone within which
  one or more nova-compute services reside. While placement aggregates
  may be used to model availability zones, they have no inherent
  concept thereof.

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Jeffrey Zhang <zhang.lei@gmail.com>
To: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org>
Date:   05/25/2018 11:34 AM
Subject:[openstack-dev] [nova] nova aggregate and nova placement api
aggregate



Recently, i am trying to implement a function which aggregate nova
hypervisors
rather than nova compute host. But seems nova only aggregate nova-compute
host.

On the other hand, since Ocata, nova depends on placement api which
supports
aggregating resource providers. But nova-scheduler doesn't use this feature
now.

So  is there any better way to solve such issue? and is there any plan
which
make nova legacy aggregate and placement api aggregate cloud work together?


--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [zVMCloudConnector][python-zvm-sdk][requirements] Unblock webob-1.8.1

[Chen CH Ji]

Thanks for the reminder

we updated the code to 1.1.1 , and current info can be found
https://pypi.org/project/zVMCloudConnector/#description

detailed code can be found here , you can see no block for webob anymore
https://github.com/mfcloud/python-zvm-sdk/blob/master/requirements.txt#L7

please share what's additional work need to be done, thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matthew Thode <prometheanf...@gentoo.org>
To: openstack-dev@lists.openstack.org
Date:   05/16/2018 01:01 AM
Subject:[openstack-dev]
[zVMCloudConnector][python-zvm-sdk][requirements]   Unblock
webob-1.8.1



Please unblock webob-1.8.1, you are the only library holding it back at
this point.  I don't see a way to submit code to the project so I cc'd
the project in launchpad.

https://bugs.launchpad.net/openstack-requirements/+bug/1765748

--
Matthew Thode (prometheanfire)
[attachment "signature.asc" deleted by Chen CH Ji/China/IBM]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] review runway status

[Chen CH Ji]

Thanks for the sharing, The z/VM driver spec review marked as END DATE:
2018-05-15
Thanks a couple folks helped a lot on the review and still need more review
activity on the patch sets, can I apply for extend the end date for the run
way? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   05/15/2018 12:33 AM
Subject:[openstack-dev] [nova] review runway status



Howdy everyone,

This is just a brief status about the blueprints currently occupying
review runways [0] and an ask for the nova-core team to give these
reviews priority for their code review focus.

* Add z/VM driver
https://blueprints.launchpad.net/nova/+spec/add-zvm-driver-rocky

(jichen) [END DATE: 2018-05-15] spec amendment
https://review.openstack.org/562154
 and implementation series starting
at
https://review.openstack.org/523387


* Local disk serial numbers
https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers

(mdbooth) [END DATE: 2018-05-16] series starting at
https://review.openstack.org/526346


* PowerVM Driver (esberglu) [END DATE: 2018-05-28]
   * Snapshot
https://blueprints.launchpad.net/nova/+spec/powervm-snapshot:

https://review.openstack.org/#/c/543023/

   * DiskAdapter parent class
https://blueprints.launchpad.net/nova/+spec/powervm-localdisk:

https://review.openstack.org/#/c/549053/

   *Localdisk
https://blueprints.launchpad.net/nova/+spec/powervm-localdisk:

https://review.openstack.org/#/c/549300/


Cheers,
-melanie

[0]
https://etherpad.openstack.org/p/nova-runways-rocky


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks for sharing this info , it make sense to leave a -2 here, I will
keep modifying follow on patches and get more reviews. thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Dan Smith <d...@danplanet.com>
To: "Chen CH Ji" <jiche...@cn.ibm.com>
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" <openstack-dev@lists.openstack.org>
Date:   04/30/2018 10:55 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



> 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 incorrect links of logs etc the newest
> logs sample can be found [3] (take n-cpu as example and those logs are
> with _white.html)
>
> Also, the blueprint [4] requested by previous discussion post here
> again for reference
>
> please let us know whether the procedure -2 can be removed in order to
> proceed . thanks for your help

The CI log format issues look fixed to me and validation is turned on
for the stuff supported, which is what was keeping it out of the
runway.

I still plan to leave the -2 on there until the next few patches have
agreement, just so we don't land an empty shell driver before we are
sure we're going to land spawn/destroy, etc. That's pretty normal
procedure and I'll be around to remove it when appropriate.

--Dan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

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 incorrect links of logs etc
the newest logs sample can be found [3] (take n-cpu as example and those
logs are with _white.html)

Also, the blueprint [4] requested by previous discussion post here again
for reference

please let us know whether the procedure -2 can be removed in order to
proceed . thanks for your help



[1]
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-17455/logs/tempest.log
2018-04-27 08:50:44.852 19582 DEBUG tempest [-] validation.run_validation
= True

http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-17455/console.html
{0}
tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops
 [86.788179s] ... ok

[2]
https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py

[3]
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-17455/logs/n-cpu.log_white.html

[4] https://review.openstack.org/#/c/562154/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
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 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 links to there [3]

Thanks, that is good info.

> You are right, we need image to have our Active Engine, I think
> different arch and platform might have their unique
> requirements and our solution our Active Engine is very like to
> cloud-init so no harm to add it from user's perspective
> I think later we can upload image to some place so anyone is able to
> consume it as test image if they like
> because different arch's image (e.g x86 and s390x) can't be shared
anyway.
>
> For the config drive format you mentioned, actually, as previous
> explanation and discussion witho Michael and Dan,
> We found the iso9660 can be used (previously we made a bad assumption)
> and we already changed the patch in [4],
> so it's exactly same to other virt drivers you mentioned , we don't need
> special format and iso9660 works perfect for our driver

That's good news, I'm glad that got resolved.

> It make sense to me we are temply moved out from runway, I suppose we
> can adjust the CI to enable the run_ssh = true
> with config drive functionalities very soon and we will apply for review
> after that with the test result requested in our CI log.

Okay, sounds good. Since you expect to be up and running with
[validation]run_validation = True soon, I'm going to move the z/VM
driver blueprint back to the front of the queue and put the next
blueprint in line into the runway.

Then, when the next blueprint end date arrives (currently 2018-04-30),
if the z/VM CI is ready with cleaned up, human readable log files and is
running with run_ssh = True with the test_server_basic_ops test to
verify config drive operation, we will add the z/VM driver blueprint
back to a runway for dedicated review.

Let us know when the z/VM CI is ready, in case other runway reviews are
completed early. If other runway reviews complete early, a runway space
might be available earlier than 2018-04-30.

Thanks,
-melanie

> Thanks
>
> [1]
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mfcloud_python-2Dzvm-2Dsdk_blob_master_tools_share_zvmguestconfigure=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=CRsbKwMgE5rCqLl8MTo6ZnKA4QkxK3NRmDont5BYcqw=RpjRNK6wiUJDNTYKBkou6nSDpaUkNOXdmBJ-SyjkPaw=

> [2]
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__cloudlib4zvm.readthedocs.io_en_latest_makeimage.html-23configuration-2Dof-2Dactivation-2Dengine-2Dae-2Din-2Dzlinux=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=CRsbKwMgE5rCqLl8MTo6ZnKA4QkxK3NRmDont5BYcqw=CVvkU6HtWW7GArGIpFT4fichM0fuTXXrmWD9zyRo9h0=

> [3]
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_q_status-3Aopen-2Bproject-3Aopenstack_nova-2Bbranch-3Amaster-2Btopic-3Abp_add-2Dzvm-2Ddriver-2Drocky=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=CRsb

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Yes, fully understand this ,thanks for sharing!

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Jim Rollenhagen <j...@jimrollenhagen.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
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 Ji <jiche...@cn.ibm.com> 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 itself is making by iso by default
  then wrap a zip/base64 format ... thanks



We only gzip and base64 to send it to the ironic API. It is decoded and
unzipped before writing it to disk, so it is a pure iso9660 on the disk.

// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=4L-KwemnBkUdTMyGA_BviipEqJ7MKNGlKFMKH6J6iaM=S52V2lLNK1Mh7rprSl-edF3Q2M4m3qEXcWd3jTW8Y9g=



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

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 itself is making by iso by default
then wrap a zip/base64 format ... thanks

[1]
https://github.com/openstack/nova/blob/324899c621ee02d877122ba3412712ebb92831f2/nova/virt/ironic/driver.py#L977

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Jim Rollenhagen <j...@jimrollenhagen.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   04/19/2018 12:02 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



On Wed, Apr 18, 2018 at 10:56 AM, Matthew Booth <mbo...@redhat.com> 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, I think
  > they're a lot more similar than people think. Ironic is the weirdest
  one
  > we have (IMHO and no offense to the ironic folks) and it can support
  > configdrive properly.

  I was going to ask this. Even if the contents of the disk can't be
  transferred in advance... how does ironic do this? There must be a
  way.

I'm not sure if this is a rhetorical question, so I'll just answer it. :)
We basically build the configdrive in nova-compute, then gzip and base64
it, and send it to ironic with the deploy request. On the ironic side, we
unpack it and write it to the end of the boot disk.

https://github.com/openstack/nova/blob/324899c621ee02d877122ba3412712ebb92831f2/nova/virt/ironic/driver.py#L952-L985


// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=oGbSbjsg1aTX1kg1lAQIkEY8abfQ9632w8YmP3Lrt-U=Q8_XusVUibDx7ee5WguroOVm00Fl4rw2XSNEHIVOGb0=



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

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 disks in the
defintion
of virtual machine and let VM to decide its format.

so we need a way to tell cloud-init where to find ISO file before
cloud-init start but without AE, we can't handle that...some update on the
spec here
for further information https://review.openstack.org/#/c/562154/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Michael Still <mi...@stillhq.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
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 couldn't be provided by cloud-init? I think there's
a lot of cost in deviating from the industry standard, so the reasons to do
so have to be really solid.

I'm also a bit confused by what seems to be support for streaming
configuration. Is there any documentation on the design of AE anywhere?

Thanks,
Michael

On Tue, Apr 17, 2018 at 6:58 PM, Chen CH Ji <jiche...@cn.ibm.com> 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 links to there [3]

  You are right, we need image to have our Active Engine, I think different
  arch and platform might have their unique
  requirements and our solution our Active Engine is very like to
  cloud-init so no harm to add it from user's perspective
  I think later we can upload image to some place so anyone is able to
  consume it as test image if they like
  because different arch's image (e.g x86 and s390x) can't be shared
  anyway.

  For the config drive format you mentioned, actually, as previous
  explanation and discussion witho Michael and Dan,
  We found the iso9660 can be used (previously we made a bad assumption)
  and we already changed the patch in [4],
  so it's exactly same to other virt drivers you mentioned , we don't need
  special format and iso9660 works perfect for our driver

  It make sense to me we are temply moved out from runway, I suppose we can
  adjust the CI to enable the run_ssh = true
  with config drive functionalities very soon and we will apply for review
  after that with the test result requested in our CI log.

  Thanks

  [1]
  
https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure

  [2]
  
http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux

  [3] https://review.openstack.org/#/q/status:open+project:openstack/nova
  +branch:master+topic:bp/add-zvm-driver-rocky
  [4] https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.py
  line 104

  Best Regards!

  Kevin (Chen) Ji 纪 晨

  Engineer, zVM Development, CSTL
  Notes: 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

  Inactive 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 inside the gu

  From: melanie witt <melwi...@gmail.com>
  To: openstack-dev@lists.openstack.org
  Date: 04/17/2018 09:21 AM
  Subject: Re: [openstack-dev] [Nova] z/VM introducing a new config
  driveformat



  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
  > should be able to prepare it,
  > in some hypervisor, you can define something like following to the VM
  > then VM startup is able to consume it
  > 
  > but for z/VM case it allows disk to be created during VM create (define

  > )stage but no disk format set, it's the operating system's
  > responsibility to define the purpose of the
  > disk, so what we do is
  > 1) first when we build image ,we create a small AE like cloud-init but
  >

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Added a update to the spec to the issues that requested
https://review.openstack.org/#/c/562154/ , including:

1) How the config drive (Metadata) defined
2) Special AE reason and why it's needed, also ,some documentation and
source code links
3) neutron agent for z/VM

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
To: Dan Smith <d...@danplanet.com>
Cc: openstack-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 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 back into a runway in the future.
>
> Agreed. I also want to see the CI reporting cleaned up so that it's
> readable and consistent. Yesterday I pointed out some issues with the
> fact that the actual config files being used are not the ones being
> uploaded. There are also duplicate (but not actually identical) logs
> from all services being uploaded, including things like a full compute
> log from starting with the libvirt driver.

Yes, we definitely need to see all of these issues fixed.

> I'm also pretty troubled by the total lack of support for the metadata
> service. I know it's technically optional on our matrix, but it's a
> pretty important feature for a lot of scenarios, and it's also a
> dependency for other features that we'd like to have wider support for
> (like attached device metadata).
>
> Going back to the spec, I see very little detail on some of the things
> raised here, and very (very) little review back when it was first
> approved. I'd also like to see more detail be added to the spec about
> all of these things, especially around required special changes like
> this extra AE agent.

Agreed, can someone from the z/VM team please propose an update to the
driver spec to document these details?

Thanks,
-melanie











__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=CCtWdN4OOlqKzrLg4ctuY1D_fHo8wvps59hVs35J8ys=wHuQV89_dwXLe15VAkg8_UOBPfjD72vB0_47W6BgRVk=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

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 links to there [3]

You are right, we need image to have our Active Engine, I think different
arch and platform might have their unique
requirements and our solution our Active Engine is very like to cloud-init
so no harm to add it from user's perspective
I think later we can upload image to some place so anyone is able to
consume it as test image if they like
because different arch's image (e.g x86 and s390x) can't be shared anyway.

For the config drive format you mentioned, actually, as previous
explanation and discussion witho Michael and Dan,
We found the iso9660 can be used (previously we made a bad assumption) and
we already changed the patch in [4],
so it's exactly same to other virt drivers you mentioned , we don't need
special format and iso9660 works perfect for our driver

It make sense to me we are temply moved out from runway, I suppose we can
adjust the CI to enable the run_ssh = true
with config drive functionalities very soon and we will apply for review
after that with the test result requested in our CI log.

Thanks

[1]
https://github.com/mfcloud/python-zvm-sdk/blob/master/tools/share/zvmguestconfigure
[2]
http://cloudlib4zvm.readthedocs.io/en/latest/makeimage.html#configuration-of-activation-engine-ae-in-zlinux
[3] https://review.openstack.org/#/q/status:open+project:openstack/nova
+branch:master+topic:bp/add-zvm-driver-rocky
[4]  https://review.openstack.org/#/c/527658/33/nova/virt/zvm/utils.py
line 104

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   04/17/2018 09:21 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



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
> should be able to prepare it,
> in some hypervisor, you can define something like following to the VM
> then VM startup is able to consume it
> 
> but for z/VM case it allows disk to be created during VM create (define
> )stage but no disk format set, it's the operating system's
> responsibility to define the purpose of the
> disk, so what we do is
> 1) first when we build image ,we create a small AE like cloud-init but
> only purpose is to get files from z/VM internal pipe and handle config
> drive case

What does AE stand for? So, this means in order to use the z/VM driver,
users must have special images that will ensure the config drive will be
readable by cloud-init. They can't use standard cloud images.

> 2) During spawn we create config drive in nova-compute side then send
> the file to z/VM through z/VM internal pipe (omit detail here)
> 3) During startup of the virtual machine, the small AE is able to mount
> the file as loop device and then in turn cloud-init is able to handle it
>
> because this is our special case, we don't want to upload to cloud-init
> community because of uniqueness and as far as we can tell, no hook in
> cloud-init mechanism allowed as well
> to let us 'mount -o loop' ; also, from openstack point of view except
> this small AE (which is documented well) no special thing and
> inconsistent to other drivers
>
> [1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_number5_cloud-2Dinit_blob_master_cloudinit_sources_DataSourceConfigDrive.py-23L225=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=yV6OJ4IfFSLoHNWAJpBF7j0sK2pgfxSEIigv8vinYw0=3410axnNZ_62U3HOh6i7yivyc7HyTcqwx2xuKRDEeac=


Where is the AE documented? How do users obtain it? What tools are they
supposed to use to build images to use with the z/VM driver?

That aside, from what I can see, the z/VM driver behaves unlike any
other in-tree driver [0-5] in how it handles config drive. Drivers are
expected to create the config drive and present it to the guest in
iso9660 or vfat format without requirement of a custom image and the
existing drivers are doing that.

IMHO, if the z/VM driver can't be fixed to provide proper config drive
support, we won't be able to approve the implementation patches. I would
like to hear other opinions about it.

I propose that we remove the z/VM driver blueprint from the runway at
this time and place it back into the queue whi

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Thanks for the question and comments

>>> metadata service question
Fully agree metadata is something that we need support, and as it need some
network setup on NAT ,as you pointed out, without metadata there are some
functions missing ; so it's already in our support plan , currently we plan
to use config drive and later (with the enhance with our neutron support as
well) to support metadata service

>>>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 should be
able to prepare it,
in some hypervisor, you can define something like following to the VM then
VM startup is able to consume it

but for z/VM case it allows disk to be created during VM create
(define )stage but no disk format set, it's the operating system's
responsibility to define the purpose of the
disk, so what we do is
1) first when we build image ,we create a small AE like cloud-init but only
purpose is to get files from z/VM internal pipe and handle config drive
case
2) During spawn we create config drive in nova-compute side then send the
file to z/VM through z/VM internal pipe (omit detail here)
3) During startup of the virtual machine, the small AE is able to mount the
file as loop device and then in turn cloud-init is able to handle it

because this is our special case, we don't want to upload to cloud-init
community because of uniqueness and as far as we can tell, no hook in
cloud-init mechanism allowed as well
to let us 'mount -o loop' ; also, from openstack point of view except this
small AE (which is documented well) no special thing and inconsistent to
other drivers

[1]
https://github.com/number5/cloud-init/blob/master/cloudinit/sources/DataSourceConfigDrive.py#L225

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Dan Smith <d...@danplanet.com>
To: "Chen CH Ji" <jiche...@cn.ibm.com>
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" <openstack-dev@lists.openstack.org>
Date:   04/13/2018 09:46 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



> 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_enabled.metadata_service but keep both
> self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
> order to make config drive test validation take effect, our CI will
> handle that

Why don't you support the metadata service? That's a pretty fundamental
mechanism for nova and openstack. It's the only way you can get a live
copy of metadata, and it's the only way you can get access to device
tags when you hot-attach something. Personally, I think that it's
something that needs to work.

> For the tgz/iso9660 question below, this is because we got wrong info
> from low layer component folks back to 2012 and after discuss with
> some experts again, actually we can create iso9660 in the driver layer
> and pass down to the spawned virtual machine and during startup
> process, the VM itself will mount the iso file and consume it, because
> from linux perspective, either tgz or iso9660 doesn't matter , only
> need some files in order to transfer the information from openstack
> compute node to the spawned VM.  so our action is to change the format
> from tgz to iso9660 and keep consistent to other drivers.

The "iso file" will not be inside the guest, but rather passed to the
guest as a block device, right?

> For the config drive working mechanism question, according to [2] z/VM
> is Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2
> hypervisor, there is no file system in z/VM hypervisor (I omit too
> much detail here) , so we can't do something like linux operation
> system to keep a file as qcow2 image in the host operating system,

I'm not sure what the type-1-ness has to do with this. The hypervisor
doesn't need to support any specific filesystem for this to work. Many
drivers we have in the tree are type-1 (xen, vmware, hyperv, powervm)
and you can argue that KVM is type-1-ish. They support configdrive.

> what we do is use a special file pool to store the config drive and
> during VM init process, we read that file from special device and
> attach to VM as iso9660 format then cloud-init will handle the follow
> up, the cloud-init handl

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

[Chen CH Ji]

https://blueprints.launchpad.net/nova/+spec/optional-requirements-packages
is the one I created
I agree with you tend to think it's a specless blueprint unless someone
want a spec on it

And I saw there are a set of more discussions in the ML so again agree that
let's  watch and see what's really need to be changed then update blueprint

Thanks for your info and support

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Eric Fried <openst...@fried.cc>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   04/12/2018 08:43 PM
Subject:Re: [openstack-dev] [Nova][Deployers] Optional, platform
specific, dependancies in requirements.txt



+1

This sounds reasonable to me.  I'm glad the issue was raised, but IMO it
shouldn't derail progress on an approved blueprint with ready code.

Jichen, would you please go ahead and file that blueprint template (no
need to write a spec yet) and link it in a review comment on the bottom
zvm patch so we have a paper trail?  I'm thinking something like
"Consistent platform-specific and optional requirements" -- that leaves
us open to decide *how* we're going to "handle" them.

Thanks,
efried

On 04/12/2018 04:13 AM, Chen CH Ji wrote:
> Thanks for Michael for raising this question and detailed information
> from Clark
>
> As indicated in the mail, xen, vmware etc might already have this kind
> of requirements (and I guess might be more than that) ,
> can we accept z/VM requirements first by following other existing ones
> then next I can create a BP later to indicate this kind
> of change request by referring to Clark's comments and submit patches to
> handle it ? Thanks
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: 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
>
> Inactive hide details for Matt Riedemann ---04/12/2018 08:46:25 AM---On
> 4/11/2018 5:09 PM, Michael Still wrote: >Matt Riedemann ---04/12/2018
> 08:46:25 AM---On 4/11/2018 5:09 PM, Michael Still wrote: >
>
> From: Matt Riedemann <mriede...@gmail.com>
> To: openstack-dev@lists.openstack.org
> Date: 04/12/2018 08:46 AM
> Subject: Re: [openstack-dev] [Nova][Deployers] Optional, platform
> specific, dependancies in requirements.txt
>
> 
>
>
>
> On 4/11/2018 5:09 PM, Michael Still wrote:
>>
>>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_523387=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=CNosrTHnAR21zOI52fnDRfTqu2zPiAn2oW9f67Qijo4=
 proposes

> adding a z/VM specific
>> dependancy to nova's requirements.txt. When I objected the counter
>> argument is that we have examples of windows specific dependancies
>> (os-win) and powervm specific dependancies in that file already.
>>
>> I think perhaps all three are a mistake and should be removed.
>>
>> My recollection is that for drivers like ironic which may not be
>> deployed by everyone, we have the dependancy documented, and then loaded
>> at runtime by the driver itself instead of adding it to
>> requirements.txt. This is to stop pip for auto-installing the dependancy
>> for anyone who wants to run nova. I had assumed this was at the request
>> of the deployer community.
>>
>> So what do we do with z/VM? Do we clean this up? Or do we now allow
>> dependancies that are only useful to a very small number of deployments
>> into requirements.txt?
>
> As Eric pointed out in the review, this came up when pypowervm was added:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_438119_5_requirements.txt=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=iyKxF-CcGAFmnQs8B7d5u2zwEiJqq8ivETmrgB77PEg=

>
> And you're asking the same questions I did in there, which was, should
> it go into test-requirements.txt like oslo.vmware and
> python-ironicclient, or should it go under [extras], or go into
> requirements.txt like os-win (we also have the xenapi library now too).
>
> I don't really think all of these optional packages should be in
> requirements.txt, but we should just be consistent with whatever we do,
> be that te

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

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, actually according
to [1] , we should only disable
CONF.compute_feature_enabled.metadata_service but keep
both self.run_ssh and CONF.compute_feature_enabled.config_drive as True in
order to make config drive test validation take effect, our CI will handle
that

For the tgz/iso9660 question below, this is because we got wrong info from
low layer component folks back to 2012 and after discuss with some experts
again, actually we can create
iso9660 in the driver layer and pass down to the spawned virtual machine
and during startup process, the VM itself will mount the iso file and
consume it, because from
linux perspective, either tgz or iso9660 doesn't matter , only need some
files in order to transfer the information from openstack compute node to
the spawned VM.
so our action is to change the format from tgz to iso9660 and keep
consistent to other drivers.

For the config drive working mechanism question, according to [2] z/VM is
Type 1 hypervisor while Qemu/KVM are mostly likely to be Type 2 hypervisor,
there is no file system in z/VM
hypervisor (I omit too much detail here) , so we can't do something like
linux operation system to keep a file as qcow2 image in the host operating
system, what we do is use a
special file pool to store the config drive and during VM init process, we
read that file from special device and attach to VM as iso9660 format then
cloud-init will handle
the follow up, the cloud-init handle process is identical to other platform

Again, The tgz/iso9660 format is only because tgz format being wrongly
thought, we already have some existing customers and a public openstack
cloud [3] running on LinuxONE (system z) [4]
so config drive of z/VM driver does work and we will modify our code to be
consistent to community in our patch set

please let us know any further question, thanks

[1]
https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L68
[2]https://en.wikipedia.org/wiki/Hypervisor
[3]https://linuxone20.cloud.marist.edu/cloud/
[4]https://www.zdnet.com/article/linuxone-ibms-new-linux-mainframes/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   04/13/2018 03:39 AM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config drive
format



On Thu, 12 Apr 2018 09:31:45 +1000, Michael Still wrote:
> The more I think about it, the more I dislike how the proposed driver
> also "lies" about it using iso9660. That's definitely wrong:
>
>          if CONF.config_drive_format in ['iso9660']:
>              # cloud-init only support iso9660 and vfat, but in z/VM
>              # implementation, can't link a disk to VM as iso9660 before
> it's
>              # boot ,so create a tgz file then send to the VM deployed,
and
>              # during startup process, the tgz file will be extracted and
>              # mounted as iso9660 format then cloud-init is able to
> consume it
>              self._make_tgz(path)
>          else:
>              raise exception.ConfigDriveUnknownFormat(
>                  format=CONF.config_drive_format)

I've asked for more information on the review about how this works -- is
it the z/VM library that extracts the tarball and mounts it as iso9660
before the guest boots or is it expected that the guest is running some
special software that will do that before cloud-init runs, or what?

I also noticed that the z/VM CI has disabled ssh validation of guests by
setting '[validation]run_validation=False' in tempest.conf [0]. This
means we're unable to see the running guest successfully consume the
config drive using this approach. This is the tempest test that verifies
functionality when run_validation=True [1].

I think we need to understand more about how this config drive approach
is supposed to work and be able to see running instances successfully
start up using it in the CI runs.

-melanie

[0]
http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-16244/logs/tempest_conf

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tempest_blob_master_tempest_scenario_test-5Fserver-5Fbasic-5Fops.py=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=d9VEfLe0LqlPnfL0F0DwKa5iNpsRfDQKiobInGR02lc=0X5hrQ3zh7vwq7wJJAbox4M_4p0myAC1zehbbxYGNF8=

Re: [openstack-dev] [Nova][Deployers] Optional, platform specific, dependancies in requirements.txt

[Chen CH Ji]

Thanks for Michael for raising this question and detailed information from
Clark

As indicated in the mail, xen, vmware etc might already have this kind of
requirements (and I guess might be more than that) ,
can we accept z/VM requirements first by following other existing ones then
next I can create a BP later to indicate this kind
of change request by referring to Clark's comments and submit patches to
handle it  ? Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   04/12/2018 08:46 AM
Subject:Re: [openstack-dev] [Nova][Deployers] Optional, platform
specific, dependancies in requirements.txt



On 4/11/2018 5:09 PM, Michael Still wrote:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_523387=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=CNosrTHnAR21zOI52fnDRfTqu2zPiAn2oW9f67Qijo4=
 proposes adding a z/VM specific
> dependancy to nova's requirements.txt. When I objected the counter
> argument is that we have examples of windows specific dependancies
> (os-win) and powervm specific dependancies in that file already.
>
> I think perhaps all three are a mistake and should be removed.
>
> My recollection is that for drivers like ironic which may not be
> deployed by everyone, we have the dependancy documented, and then loaded
> at runtime by the driver itself instead of adding it to
> requirements.txt. This is to stop pip for auto-installing the dependancy
> for anyone who wants to run nova. I had assumed this was at the request
> of the deployer community.
>
> So what do we do with z/VM? Do we clean this up? Or do we now allow
> dependancies that are only useful to a very small number of deployments
> into requirements.txt?

As Eric pointed out in the review, this came up when pypowervm was added:

https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_438119_5_requirements.txt=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=iyKxF-CcGAFmnQs8B7d5u2zwEiJqq8ivETmrgB77PEg=


And you're asking the same questions I did in there, which was, should
it go into test-requirements.txt like oslo.vmware and
python-ironicclient, or should it go under [extras], or go into
requirements.txt like os-win (we also have the xenapi library now too).

I don't really think all of these optional packages should be in
requirements.txt, but we should just be consistent with whatever we do,
be that test-requirements.txt or [extras]. I remember caring more about
this back in my rpm packaging days when we actually tracked what was in
requirements.txt to base what needed to go into the rpm spec, unlike
Fedora rpm specs which just zero out requirements.txt and depend on
their own knowledge of what needs to be installed (which is sometimes
lacking or lagging master).

I also seem to remember that [extras] was less than user-friendly for
some reason, but maybe that was just because of how our CI jobs are
setup? Or I'm just making that up. I know it's pretty simple to install
the stuff from extras for tox runs, it's just an extra set of
dependencies to list in the tox.ini.

Having said all this, I don't have the energy to help push for
consistency myself, but will happily watch you from the sidelines.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=212PUwLYOBlJZ3BiZNuJIFkRfqXoBPJDcWYCDk7vCHg=2FioyzCRtztysjjEqCrBTkpQs_wwfs3Mt2wGDkrft-s=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][requirements] uncapping eventlet

[Chen CH Ji]

sorry, I didn't see any solution for following error found in [1]
I just rechecked the patch and is this kind of issue already fixed?

ubuntu-xenial | Requirement for package eventlet : Requirement
(package=u'eventlet', location='',
specifiers='!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2', markers=u'', comment=u'#
MIT', extras=frozenset([])) does not match openstack/requirements value :
set([Requirement(package='eventlet', location='',
specifiers='!=0.18.3,!=0.20.1,>=0.18.2', markers='', comment='# MIT',
extras=frozenset([]))])

[1]
logs.openstack.org/87/523387/32/check/requirements-check/408e28c/job-output.txt.gz

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Doug Hellmann <d...@doughellmann.com>
To: openstack-dev <openstack-dev@lists.openstack.org>
Date:   04/11/2018 08:56 PM
Subject:Re: [openstack-dev] [all][requirements] uncapping eventlet



Excerpts from IWAMOTO Toshihiro's message of 2018-04-11 18:19:02 +0900:
> On Mon, 09 Apr 2018 22:58:28 +0900,
> Doug Hellmann wrote:
> >
> > Excerpts from Tony Breeds's message of 2018-04-09 13:39:30 +1000:
> > > On Fri, Apr 06, 2018 at 09:41:07AM -0700, Clark Boylan wrote:
> > >
> > > > My understanding of our use of upper constraints was that this
should
> > > > (almost) always be the case for (almost) all dependencies.  We
should
> > > > rely on constraints instead of requirements caps. Capping libs like
> > > > pbr or eventlet and any other that is in use globally is incredibly
> > > > difficult to work with when you want to uncap it because you have
to
> > > > coordinate globally. Instead if using constraints you just bump the
> > > > constraint and are done.
> > >
> > > Part of the reason that we have the caps it to prevent the tools that
> > > auto-generate the constraints syncs from considering these versions
and
> > > then depending on the requirements team to strip that from the bot
> > > change before committing (assuming it passes CI).
> > >
> > > Once the work Doug's doing is complete we could consider tweaking the
> > > tools to use a different mechanism, but that's only part of the
reason
> > > for the caps in g-r.
> > >
> > > Yours Tony.
> >
> > Now that projects don't have to match the global requirements list
> > entries exactly we should be able to remove caps from within the
> > projects and keep caps in the global list for cases like this where we
> > know we frequently encounter breaking changes in new releases. The
> > changes to support that were part of
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_555402_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=P99Z7BlpiP8Sg9_5Ku4JMW_tJWXARpd2ldSvFFlFBpU=

>
> As eventlet has been uncapped in g-r, requirements-check is
> complaining on unrelated project-local requirement changes.
> I'm not quite sure but doesn't seem to be a intended behavior.
>
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__logs.openstack.org_57_451257_16_check_requirements-2Dcheck_c32ee69_job-2Doutput.txt.gz=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=6uHgERcFttsqFakjBTrjvKZhk5n-tZO-e0QMd7zj0nc=

>

This error is related to the change in
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_560050_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=1hIA6J9OfM1mhcTDq89NkGmoAQi_fDfhel7q5dgcwIA=
 which applies the matching
rules to all requirements settings any time any requirements-related
file is touched. The change was made because we are less in-sync than we
thought and because we're allowing "bad" settings to stay in place.

To correct the problem in the log you linked to, remove the cap from
eventlet in neutron.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=y9YWvP5nDDQCyw3QGNWGvQS-CVeHBeXA9rfHaLf3JpQ=nEWykx9Cfm6deVwO9Sdge-_Q31mCbdfAmvp_KoPaenc=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Changes toComputeVirtAPI.wait_for_instance_event

[Chen CH Ji]

Thanks for your info ,really helpful

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Andreas Scheuring <scheu...@linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   04/10/2018 10:19 PM
Subject:Re: [openstack-dev] [nova] Changes
toComputeVirtAPI.wait_for_instance_event



Yes, that’s how it works!

---
Andreas Scheuring (andreas_s)



On 10. Apr 2018, at 16:05, Matt Riedemann <mriede...@gmail.com> wrote:

On 4/9/2018 9:57 PM, Chen CH Ji wrote:
  Could you please help to share whether this kind of event is sent by
  neutron-server or neutron agent ? I searched neutron code
  from [1][2] this means the agent itself need tell neutron server the
  device(VIF) is up then neutron server will send notification
  to nova through REST API and in turn consumed by compute node?
  [1]
  
https://github.com/openstack/neutron/tree/master/neutron/notify_port_active_direct

  [2]
  
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/rpc.py#L264

I believe the neutron agent is the one that is getting (or polling) the
information from the underlying network backend when VIFs are plugged or
unplugged from a host, then route that information via RPC to the neutron
server which then sends an os-server-external-events request to the compute
REST API, which then routes the event information down to the nova-compute
host where the instance is currently running.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=tIntFpZ0ffp-_h5CsqN1I9tv64hW2xugxBXaxDn7Z_I=z2jOgMD7B3XFoNsUHTtIO6hWKYXH-Dm4L4P0-u-oSSw=



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] EC2 cleanup ?

[Chen CH Ji]

A patch set has been proposed [1] , additional stuffs will be posted once
got further feedback.

[1] https://review.openstack.org/#/c/556778/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Artom Lifshitz <alifs...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   03/27/2018 02:30 AM
Subject:Re: [openstack-dev] [nova] EC2 cleanup ?



> That is easier said than done. There have been a couple of related
attempts
> in the past:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_266425_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=mmdwfYEaSGeM5GvfgBGKf29XfGL9FPgXyPc1BoBkex4=

>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_282872_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=Q9I4L9tbv9-GN91W7rW6wrYpBzC_gbQZtk165On8qwc=

>
> I don't remember exactly where those fell down, but it's worth looking at
> this first before trying to do this again.

Interesting. [1] exists, and I'm pretty sure that we ship it as part
of Red Hat OpenStack (but I'm not a PM and this is not an official Red
Hat stance, just me and my memory), so it works well enough. If we
have things that depend on our in-tree ec2 api, maybe we need to get
them moved over to [1]?

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_ec2-2Dapi=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=c5424HG9UKS4FXVFz3BkIbBYzOGyF9_5F2JyRa9y8i4=


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=7Qqd9VAjMEUMU2lmoHzRFtYMcpBvm9XhPsTVsUd3OoU=rO0wjEa_YYM2oLf0FJcTVJXmbvDB4h93NGieFts62aU=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Changes toComputeVirtAPI.wait_for_instance_event

[Chen CH Ji]

Could you please help to share whether this kind of event is sent by
neutron-server or neutron agent ? I searched neutron code
from [1][2]  this means the agent itself need tell neutron server the
device(VIF) is up then neutron server will send notification
to nova through REST API and in turn consumed by compute node?

[1]
https://github.com/openstack/neutron/tree/master/neutron/notify_port_active_direct
[2]
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/rpc.py#L264


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   04/10/2018 01:56 AM
Subject:[openstack-dev] [nova] Changes to
ComputeVirtAPI.wait_for_instance_event



As part of a bug fix [1], the internal
ComputeVirtAPI.wait_for_instance_event interface is changing to no
longer accept event names that are strings, and will now require the
(name, tag) tuple form which all of the in-tree virt drivers are already
using.

If you have an out of tree driver that uses this interface, heads up
that you'll need to be using the tuple form if you are not already doing
so.

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_558059_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=yyfqhpyjmwq9aUO_EdyVhYZm-8zEDpEYxh2-hPu1kig=S5Asyhxw296d0rp-EOCg1VMsKcwVV39i1pGeqkobE2U=


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=yyfqhpyjmwq9aUO_EdyVhYZm-8zEDpEYxh2-hPu1kig=H3OLArdYuR4ARtKwSqJaI3ctLkqJSAVhldfty7GL9lo=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Eric Fried for nova-core

[Chen CH Ji]

+1, Eric is very active and thorough reviewer  ~

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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 <melwi...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   03/27/2018 10:00 AM
Subject:[openstack-dev] [nova] Proposing Eric Fried for nova-core



Howdy everyone,

I'd like to propose that we add Eric Fried to the nova-core team.

Eric has been instrumental to the placement effort with his work on
nested resource providers and has been actively contributing to many
other areas of openstack [0] like project-config, gerritbot,
keystoneauth, devstack, os-loganalyze, and so on.

He's an active reviewer in nova [1] and elsewhere in openstack and
reviews in-depth, asking questions and catching issues in patches and
working with authors to help get code into merge-ready state. These are
qualities I look for in a potential core reviewer.

In addition to all that, Eric is an active participant in the project in
general, helping people with questions in the #openstack-nova IRC
channel, contributing to design discussions, helping to write up
outcomes of discussions, reporting bugs, fixing bugs, and writing tests.
His contributions help to maintain and increase the health of our project.

To the existing core team members, please respond with your comments,
+1s, or objections within one week.

Cheers,
-melanie

[0]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_q_owner-3Aefried=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=w_QMVh424GtoPTNns-WQXjrX6VTVPNAQBw__J_Sxiiw=

[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_nova_90=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=AE65CYdFeQnyWsUN20WoNI-VujdaNjfn2RiAmFz9BWc=


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=QRzghstztOBBcjk4bouT3z0yudqvu_2Su9Vmmree3SM=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] EC2 cleanup ?

[Chen CH Ji]

seems we have a EC2 implementation in api layer and deprecated since
Mitaka, maybe eligible to be removed this cycle?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][libvirt] question on max cpu and memory

[Chen CH Ji]

In order to work on [1] for prove libvirt is ok to do live-resize, I want
to make following changes on xml file of instance
to make maximum memory as 1G and current memory as 512M , and current CPU
is a while maximum CPU is 2 so that we can hot resize through libvirt
interface

question I have is whether it's ok and whether the current CPU count (1 in
this case) is inconsistent to cpu topology lead to any problem ?
and are there some considerations/limitations ? Not so much experience so
any comments is appreciated

  1048576
  524288
  2

  

  

[1]https://blueprints.launchpad.net/nova/+spec/instance-live-resize

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Chen CH Ji]

Matt, really appreciate for your solid review and patience, learn a lot
from your help :)

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   01/23/2018 07:10 AM
Subject:Re: [openstack-dev] [nova] PTL Election Season



On 1/15/2018 11:04 AM, Kendall Nelson wrote:
> Election details:
https://urldefense.proofpoint.com/v2/url?u=https-3A__governance.openstack.org_election_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=die3e3sesoQt82yq45Rfi5gtzP2xWKhKgCoJZ8ZLIu0=xfpbcenWsmihBXKpCuJ72FnE5x4TQYhNub_PukbF-gA=

>
> Please read the stipulations and timelines for candidates and electorate
> contained in this governance documentation.
>
> Be aware, in the PTL elections if the program only has one candidate,
> that candidate is acclaimed and there will be no poll. There will only
> be a poll if there is more than one candidate stepping forward for a
> program's PTL position.
>
> There will be further announcements posted to the mailing list as action
> is required from the electorate or candidates. This email is for
> information purposes only.
>
> If you have any questions which you feel affect others please reply to
> this email thread.
>

To anyone that cares, I don't plan on running for Nova PTL again for the
Rocky release. Queens was my fourth tour and it's definitely time for
someone else to get the opportunity to lead here. I don't plan on going
anywhere and I'll be here to help with any transition needed assuming
someone else (or a couple of people hopefully) will run in the election.
It's been a great experience and I thank everyone that has had to put up
with me and my obsessive paperwork and process disorder in the meantime.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=die3e3sesoQt82yq45Rfi5gtzP2xWKhKgCoJZ8ZLIu0=1UlkBaPmZzs054ut14Rv9UdruUis5BdYkcOjJ9bd4nc=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] question on , quience use call and unquience use cast

[Chen CH Ji]

During review https://review.openstack.org/#/c/529278/2 ,some question on
the method for quience/unquience

https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L1140
use call for quience
https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L1146
use cast for unquience

just curious ,any special purpose for use different type here?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] IBM z/VM CI asks for reporting permission to Nova changes

[Chen CH Ji]

Hi Andreas
   Exactly, we found the issue yesterday and will fix it
soon,  really appreciate your info and help~

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Andreas Scheuring <scheu...@linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   10/17/2017 08:10 PM
Subject:Re: [openstack-dev] IBM z/VM CI asks for reporting permission
to Nova changes



Hi Laurene,

at the moment the z/VM CI is posting a +1 even though the job failed.
That’s because in zuul layout.yaml the job is probably set to "voting:
false.” You can easily fix this by setting it to “true”.

For example see https://review.openstack.org/#/c/512190/

Regards,

---
Andreas Scheuring (andreas_s)



  On 12. Oct 2017, at 06:42, Xiao Mei GZ Zheng <xmzh...@cn.ibm.com>
  wrote:



  Hello,

  I'm requesting reporting permission (non-voting) to Nova changes for
  the IBM z/VM CI. The wiki is on link [1].

  We designed the CI using nodepool , zuul and Jenkins. The newly
  uploaded patches will receive an initial +/-1 reports from Jenkins
  only for the nova project (just comments on patches but not vote on
  them). Tests completed on the z/VM Driver CI system check-nova
  pipeline. For more information see[2]. To recheck it, you just submit
  a comment with only zvm:recheck in the comment.

  The IBM z/VM CI system has been running for a long time in a stable
  fashion. We present all test artifacts on a public link [3] to make
  debugging failed tests easier. You can see environment details,
  openstack logs and tempest logs.

  * Gerrit Account: zvmosci

  * Gerrit query on patches where the CI commented: [4]

  * Proposal for naming: IBM z/VM CI

  For any questions feel free to reach out to me (Laurene) or to Leon!

  [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI

  [2] https://wiki.openstack.org/wiki/ZVMDriver/zVM-CI


  [3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/


  [4] https://review.openstack.org/#/c/410596/

  Thanks & Best Regards!

  Laurene(Xiao Mei) Zheng
  
  Software developer, CSTL
  IBM China Systems & Technology Lab (CSTL)



  __

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org
  ?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=qBwOmwjtiIbNH88QysyUiSxJT3O4PS0lsayyEqezZSU=fq-TSltLCGGZjat8QSfPpcqiKSaH9GO4VhovL1ElZWQ=



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

[Chen CH Ji]

Thanks for sharing this info, I already keep an eye on this change and
understand the reason,
so if I understand this correctly, out of tree driver only need
'allocations' to be added for spawn and rebuild function and up to the
driver to use it, correct?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Eric Fried <openst...@fried.cc>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   10/18/2017 04:07 AM
Subject:[openstack-dev] [nova][out-of-tree drivers] Breaking change to
ComputeDriver.spawn and friends



Out-of-tree virt driver maintainers, please keep an eye on [1], which
will force you to update the signature of your spawn and rebuild
overrides.  See the commit message for the whys and wherefores, and let
me know if you have any questions.

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_511879=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M=W6Y0oep8w6Gkm_LMDQQb3ISzmAwzMEUej7uIP6wPpGo=


Thanks,
Eric Fried (efried)
.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M=oD7yXwwFk6qjyA_YLNpc_ZCPqChdsni1Q7G08p_TXZI=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] IBM z/VM CI asks for reporting permission to Nova changes

[Chen CH Ji]

Thanks for your help, we have been running the CI for months and star to
report to nova patches after grant the access
could you please help to approve https://review.openstack.org/#/c/464915/
as we already got a +2 and
please let us know anything we need to get the spec approved, thanks~


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   10/13/2017 09:57 PM
Subject:Re: [openstack-dev] [nova] IBM z/VM CI asks for reporting
permission to Nova changes



On 10/11/2017 11:42 PM, Xiao Mei GZ Zheng wrote:
> Hello,
>
> I'm requesting reporting permission (non-voting) to Nova changes for the
> IBM z/VM CI. The wiki is on link [1].
>
> We designed the CI using nodepool , zuul and Jenkins. The newly uploaded
> patches will receive an initial +/-1 reports from Jenkins only for the
> nova project (just comments on patches but not vote on them). Tests
> completed on the z/VM Driver CI system check-nova pipeline. For more
> information see[2]. To recheck it, you just submit a comment with only
> zvm:recheck in the comment.
>
> The IBM z/VM CI system has been running for a long time in a stable
> fashion. We present all test artifacts on a public link [3] to make
> debugging failed tests easier. You can see environment details,
> openstack logs and tempest logs.
>
> * Gerrit Account: zvmosci
>
> * Gerrit query on patches where the CI commented: [4]
>
> * Proposal for naming: IBM z/VM CI
>
> For any questions feel free to reach out to me (Laurene) or to Leon!
>
> [1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_ThirdPartySystems_IBM-5Fz_VM-5FCI=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E=TW3Umekz89KQIa8RANGVjAIS5wwCD0jlTAUCVlPAWOU=

>
> [2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_ZVMDriver_zVM-2DCI=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E=zPstbECoa_-scgebDBtaWIyGOUtli7hU1RmV6T394pQ=

>
>
> [3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/
>
>
> [4]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_410596_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E=CjmX4DjgHSnrRJaJQiJj3EKgXACa8f1MxE84mMhJ7Kw=

>
> Thanks & Best Regards!
>
> Laurene(Xiao Mei) Zheng
> 
> Software developer, CSTL
> IBM China Systems & Technology Lab (CSTL)
>
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E=6cUIH7XMNFR3ov4O7-TvCpka88FwFBFdHOSuVFOK4lY=

>

This is OK for me. The latest CI run I see is here:

http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-7096/


It looks like the CI used to take about 3.5 hours from [4] but now it's
taking a little over an hour, so that's good.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=PMHHg_hTd5A4J7k5WJv0Sxq-IwWnMCSWpu2_il1dv8E=6cUIH7XMNFR3ov4O7-TvCpka88FwFBFdHOSuVFOK4lY=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] About live-resize spec

[Chen CH Ji]

ok, thanks, I will pick up and get Claudiu's help as well, the original
spec is abandoned ,could you please help to restore it?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   09/20/2017 09:11 PM
Subject:Re: [openstack-dev] [nova] About live-resize spec



On 9/20/2017 12:16 AM, Chen CH Ji wrote:
> spec [1] has been there since 2014 and some patches proposed but
> abandoned after that, can someone
> please provide some info/background about why it's postponed or due to
> some limitations that nova hasn't been implemented yet?
>
> some operators suggested that this is a valuable funcationality so
> better to have it in the near feature... thanks
>
>
> [1]:
https://urldefense.proofpoint.com/v2/url?u=https-3A__blueprints.launchpad.net_nova_-2Bspec_instance-2Dlive-2Dresize=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=_CAt9-g8ZEY5LXXo10rhhd-GMWz4B1YBQ28dhuFZnj0=

>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: 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
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw=

>

We talked about this during the newton midcycle and from what I remember
we wanted to make this depend on having the ability for users to know
what they are capable of doing with their server instance in any given
cloud. This has grown into the cross project capabilities API
discussions that happen with the API work group.

At this point, I don't think we have anyone working on doing anything
for a capabilities API in nova, nor do we have cross project agreement
on a perfect solution that will work for all projects. At the PTG in
Denver I think we just said we care less about having a perfect
guideline for all projects to have a consistent API, and more about
actually documenting the APIs that each project does have, which we do a
pretty good job of in Nova.

So I think live resize would be fine to pick up again if you're just
resizing CPU/RAM from the flavor and if we provide a policy rule to
disable it in clouds that don't want to expose that feature.

Cloudbase was originally driving it for Hyper-v so you might want to
talk with Claudiu Belu.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8URBCAs-AokrPQobkaJ801kitvJThbGRR-TJ4o-LcIE=anotHeOxKU8HE2ff2CnYn4rwT48cG1wkINchYamlckw=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

[Chen CH Ji]

yes, I didn't go to that detail and missed the delete flag , that's exactly
what I am looking for, which is a little bit confusing...
Thanks for the info for know this...

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   09/20/2017 09:15 PM
Subject:Re: [openstack-dev] [nova][api] why need
PUT /servers/{server_id}/metadata/{key} ?



On 9/20/2017 12:48 AM, Chen CH Ji wrote:
> in analyzing other code, found seems we don't need PUT
> /servers/{server_id}/metadata/{key} ?
>
> as the id is only used for check whether it's in the body and we will
> honor the whole body (body['meta'] in the code)
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_master_nova_api_openstack_compute_server-5Fmetadata.py-23L80=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE=1S1y1O0K2KOZgQd1wmx5_P8IhzNqf-i6d4IThx0yLrI=

>
> looks like it's identical to
> PUT /servers/{server_id}/metadata
>
> why we need this API or it should be something like
>
> PUT /servers/{server_id}/metadata/{key}but we only accept a value to
> modify the meta given by {key} in the API side?
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: 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
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs=

>

This API is a bit confusing, and the code is too since it all goes down
to some common code, and I think you're missing the 'delete' flag:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_5bf1bb47c7e17c26592a699d07c2faa59d98bfb8_nova_compute_api.py-23L3830=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE=AMY4S8Ux0G78V_Nu2H17kNivICkiKErqDzPj0eFsUgg=


If delete=False, as it is in this case, we only add/update the existing
metadata with the new metadata from the request body. If delete=True,
then we overwrite the instance metadata with whatever is in the request.

Does that answer your question?

This API is problematic and we have bugs against it since it's not
atomic, i.e. two concurrent requests will overwrite one of them. We
should really have a generation ID or etag on this data to be sure it's
atomically updated.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

[Chen CH Ji]

in analyzing other code, found seems we don't need PUT
/servers/{server_id}/metadata/{key} ?

as the id is only used for check whether it's in the body and we will honor
the whole body (body['meta'] in the code)
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80

looks like it's identical to
PUT /servers/{server_id}/metadata

why we need this API or it should be something like

PUT /servers/{server_id}/metadata/{key} but we only accept a value to
modify the meta given by {key} in the API side?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] About live-resize spec

[Chen CH Ji]

spec [1] has been there since 2014 and some patches proposed but abandoned
after that, can someone
please provide some info/background about why it's postponed or due to some
limitations that nova hasn't been implemented yet?

some operators suggested that this is a valuable funcationality so better
to have it in the near feature... thanks


[1]:https://blueprints.launchpad.net/nova/+spec/instance-live-resize

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][keystone] keystoneauth1 and keystonemiddle setting

[Chen CH Ji]

ok, thanks for Morgan and Brant's comments, will rework the patch based on
the comments, thanks!

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Morgan Fainberg <morgan.fainb...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   08/17/2017 07:51 AM
Subject:Re: [openstack-dev] [nova][keystone] keystoneauth1 and
keystonemiddle setting





On Aug 16, 2017 11:31, "Brant Knudson" <b...@acm.org> wrote:


  On Mon, Aug 14, 2017 at 2:48 AM, Chen CH Ji <jiche...@cn.ibm.com> wrote:
   In fixing bug 1704798, there's a proposed patch
   https://review.openstack.org/#/c/485121/7
   but we stuck at http_connection_timeout and timeout value in
   keystoneauth1 and keystonemiddle repo

   basically we want to reuse the keystone_auth section in nova.conf to
   avoid create another section so we can
   use following to create a session

   sess = ks_loading.load_session_from_conf_options(CONF,
   'keystone_authtoken', auth=context.get_auth_plugin())

   any comments or we have to create another section and configure it
   anyway? thanks


   Best Regards!

   Kevin (Chen) Ji 纪 晨

   Engineer, zVM Development, CSTL
   Notes: 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

   __

   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe:
   openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  I think reusing the keystone_authtoken config is a bad idea.
  keystone_authtoken contains the configuration for the auth_token
  middleware so this is what we keystone developers expect it to be used
  for. A deployment may have different security needs for the auth_token
  middleware vs checking quotas in which case they'll need different users
  or project for the auth_token middleware and quota checking. And even if
  we don't need it now we might need it in the future, and it's going to
  create a lot of work going forward to rearchitect.

  If a deployer wants to use the same authentication for both auth_token
  middleware and the proxy, they can create a new section with the config
  and point both keystone_authtoken and quota checking to it (by setting
  the auth_section).

  --
  - Brant

  __

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



What Brant said. Please do not lean on the options from keystone middleware
for anything outside of keystone middleware. We have had to change these
options before and those changes should only ever impact the keystone
middleware code. If you re-use those options for something in Nova, it will
likely break and need to be split into it's own option block in the future.

Please create a new option block (even if a deployers uses the same
user/passord) rather than using the authtoken config section for anything
outside of authtoken.

--Morgan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=tObIBKyCbf77oLwdSwaHb3_FM8au2aTVSaHGYMH8-1Q=vRncIuk0n5yybdLrZA8uRBC3A0UZDhzj5-pX5alqUc0=



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][keystone] keystoneauth1 and keystonemiddle setting

[Chen CH Ji]

In fixing bug 1704798, there's a proposed patch
https://review.openstack.org/#/c/485121/7
but we stuck at http_connection_timeout and timeout value in keystoneauth1
and keystonemiddle repo

basically we want to reuse the keystone_auth section in nova.conf to avoid
create another section so we can
use following to create a session

sess = ks_loading.load_session_from_conf_options(CONF,
'keystone_authtoken', auth=context.get_auth_plugin())

any comments or we have to create another section and configure it anyway?
thanks


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][out-of-tree drivers] InstanceInfo/get_info getting a haircut

[Chen CH Ji]

Thanks for posting this, we do have an out-of-tree driver ,and as you
pointed out in the patch , those parameters seems not used
and this change didn't modify the compute layer functions and params so it
should be no impact

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Eric Fried <openst...@fried.cc>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   06/07/2017 12:35 AM
Subject:[openstack-dev] [nova][out-of-tree drivers]
InstanceInfo/get_info   getting a haircut



If you don't maintain an out-of-tree nova compute driver, you can
probably hit Delete now.

A proposed change [1] gets rid of some unused fields from
nova.virt.hardware.InstanceInfo, which is the thing returned by
ComputeDriver.get_info().

I say "unused" in the context of the nova project.  If you have a
derived project that's affected by this, feel free to respond or reach
out to me (efried) on #openstack-nova to discuss.

This change is planned for Pike only.

[1] https://review.openstack.org/#/c/471146/

Thanks,
Eric
.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] about usage of /consoles

[Chen CH Ji]

Thanks for the info, looks like this is xen only stuff,  not sure whether
this is needed for now or we can remove it
remote_consoles seems related to some general console but not specific to
xvp,

so https://review.openstack.org/459266 just for some info to api reader and
if we are sure xen don't use it any more, we can remove it totally.

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Markus Zoeller <mzoel...@linux.vnet.ibm.com>
To: openstack-dev@lists.openstack.org
Date:   04/21/2017 08:35 PM
Subject:Re: [openstack-dev] [nova] about usage of /consoles



On 21.04.2017 12:12, Chen CH Ji wrote:
>
> Per https://bugs.launchpad.net/nova/+bug/1682303 , POST with return 200
> while GET returns [] is weird
>  what's the purpose of /consoles? looks like
> https://github.com/openstack/nova/blob/master/nova/console/rpcapi.py#L72
> will send a rpc message and which service is the reciever of this message
> and handle it? Thanks
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨

Looks like this API works for the "Xen VNC proxy" service only. The
console manager triggers the console creation here:
https://github.com/openstack/nova/blob/66c661258873e2544e286099c4bc027c26c851c4/nova/console/manager.py#L79


The XVPConsoleProxy implements it here:
https://github.com/openstack/nova/blob/46b3a3ca1ac3a5ffdc7c5420263223f2d3b9a660/nova/console/xvp.py#L56-L58


Looks like that service runs with default Devstack settings as service
"nova-xvpvncproxy":
https://github.com/openstack-dev/devstack/blob/f3b2f4c85307b14f115a020f5eaf6c92026b55b4/lib/nova#L892-L892


The API microversion 2.6 introduced a consolidation of the remote consoles:
https://github.com/openstack/nova/blob/3e032fd45be28c6098235ce336e675d03ebc6619/nova/api/openstack/compute/schemas/remote_consoles.py#L101-L102


Could it be that the "GET /console" API shouldn't be available anymore
since microversion 2.6?

api-ref about the consoles:
https://developer.openstack.org/api-ref/compute/?expanded=get-vnc-console-os-getvncconsole-action-deprecated-detail,create-remote-console-detail


--
Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] about usage of /consoles

[Chen CH Ji]

Per https://bugs.launchpad.net/nova/+bug/1682303 , POST with return 200
while GET returns [] is weird
 what's the purpose of /consoles? looks like
https://github.com/openstack/nova/blob/master/nova/console/rpcapi.py#L72
will send a rpc message and which service is the reciever of this message
and handle it? Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2 setup guide (pike only)

[Chen CH Ji]

Thanks for sharing, our zvm CI had exactly same issue those days , we need
'nova hypervisor-list' to be 'up' in order to do further conf/test
so ,even if nova service-list returns 'up' info but actually the host
mapping is not built and in turn you still can't schedule workload to it
so we build a loop and because the discovery hosts action are idempotent,
we build a loop and keep discover host until
the compute node is created and then in turn create the hostmap

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Matt Riedemann <mriede...@gmail.com>
To: openstack-dev@lists.openstack.org
Date:   04/17/2017 11:46 PM
Subject:Re: [openstack-dev] [nova][deployment] FYI: changes to cells v2
setup guide (pike only)



On 4/16/2017 10:35 PM, Alex Xu wrote:
> Is it strange that the 'nova service-list' and 'nova host-list' return
> the hosts which didn't have host mapping yet?

It's kind of strange yes. We could probably make GET /os-hypervisors
work without requiring the host mappings, but it just doesn't today
because of some targeted calls within each cell to fill the response.

So we could probably decouple things a bit internally in the API if we
wanted to do this differently and not require a host mapping, but for
now I knew we could get the same results by just using os-services and
get Kolla unblocked (this came up Friday morning last week so I was
rushing for a solution).

>
> How the user to know whether a host was added to a cell or not?

A user doesn't need to know, but an operator would care. This actually
came up in IRC last week [1] when Kevin Fox was asking similar
questions, and I have a TODO to write some FAQs for cells v2.

We talked about how the "nova-manage cell_v2 discover_hosts" command is
idempotent and if there are new unmapped hosts you could just run it and
pick them up - the trick is knowing when to run it, unless you configure
the scheduler to use "discover_hosts_in_cells_interval" for auto-discovery.

We also talked about the option of building on the "nova-manage cell_v2
list_cells" command to also optionally dumping hosts per cell, or just
run the "nova-manage host list" command pointed at your cell config.

At some point we might want to consider returning cell uuid out of the
os-services API when listing services or hosts, something like that.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-10.log.html#t2017-04-10T20:25:47


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] About use oslo_service in nova and fix for OSSN-0039

[Chen CH Ji]

Hi
 In https://wiki.openstack.org/wiki/OSSN/OSSN-0039, it's
requested that SSL/TLS library (OpenSSL in this case) is compiled without
SSLv3 ,
 our internal discussion from some security experts suggested
we need add some code to
https://github.com/openstack/nova/blob/master/nova/wsgi.py#L168
 maybe something like:   dup_socket = eventlet.wrap_ssl
(dup_socket, ssl_version=ssl.PROTOCOL_TLSv1_2,
 so that nova client only requests TLSv1_2

 so the question is
1) why nova didn't use oslo service, so we can honor some options like
following while seems nova don't have?
https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py#L108
https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py#L114

2) is there a existing requirement to nova (and maybe other projects) on
OSSN 0039 in addition to recompile ssl library?


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][api] quota-class-show not sync toquota-show

[Chen CH Ji]

ok, thanks for the info,  I will submit the spec and wait for more response
from the spec

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Lance Bragstad <lbrags...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   04/12/2017 03:09 AM
Subject:Re: [openstack-dev] [nova][api] quota-class-show not sync to
quota-show





On Tue, Apr 11, 2017 at 1:21 PM, Matt Riedemann <mriede...@gmail.com>
wrote:
  On 4/11/2017 2:52 AM, Alex Xu wrote:
   We talked about remove the quota-class API for multiple times
   (
   http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html
   )

   I guess we can deprecate the entire quota-class API directly.


  I had a spec proposed to deprecate the os-quota-class-sets API [1] but it
  was abandoned since we discussed it at the Pike PTG and decided we would
  just leave it alone until Nova was getting limits information from
  Keystone [2].

FWIW - in addition to merging the conceptual document [0], Sean recently
proposed the limits interface [1] for the keystone bits.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.htm
[1] https://review.openstack.org/#/c/455709/


  I think the reason we probably missed this API was because of the really
  roundabout way that the information is provided in the response. It calls
  the quota engine driver [3] to get the class quotas. For the DB driver if
  nothing is overridden then nothing comes back here [4]. And the resources
  in the quota driver have a default property which is based on the config
  options [5]. So we'll return quotas on floating_ips and other proxy
  resources simply because of how abstract this all is.

  To fix it, the os-quota-class-sets API would have to maintain a blacklist
  of resources to exclude from the response, like what we do for limits
  [6].

  So yeah, I guess we'd need a new spec and microversion for this.

  [1] https://review.openstack.org/#/c/411035/
  [2] https://review.openstack.org/#/c/440815/
  [3]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/quota_classes.py#L67

  [4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
  [5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
  [6]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/views/limits.py#L20


  --

  Thanks,

  Matt


  __

  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][api] quota-class-show not sync to quota-show

[Chen CH Ji]

Version 2.35 removed most deprecated output like floating ip etc so we
won't have following in quota-show output
| floating_ips| 10|
| fixed_ips   | -1|
| security_groups | 10|
| security_group_rules| 20|

however, quota-class-show still have those output, should we use 2.35 to
fix this bug or add a new microversion or because os-quota-class-sets is
about to deprecate, we can let it be ? Thanks

DEBUG (session:347) REQ: curl -g -i -X GET
http://192.168.123.10:8774/v2.1/os-quota-class-sets/1 -H
"OpenStack-API-Version: compute 2.41" -H "User-Agent: python-novaclient" -H
"Accept: application/json" -H "X-OpenStack-Nova-API-Version: 2.41" -H
"X-Auth-Token: {SHA1}5008bb2787a9548d65b063f4db2525b4e3bf7163"

RESP BODY: {"quota_class_set": {"injected_file_content_bytes": 10240,
"metadata_items": 128, "ram": 51200, "floating_ips": 10, "key_pairs": 100,
"id": "1", "instances": 10, "security_group_rules": 20, "injected_files":
5, "cores": 20, "fixed_ips": -1, "injected_file_path_bytes": 255,
"security_groups": 10}}

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] scaling rabbitmq with cells v2 requires manual database update

[Chen CH Ji]

Should be this one https://bugs.launchpad.net/nova/+bug/1664913 and
https://review.openstack.org/434179 ?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: 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:   Corey Bryant <corey.bry...@canonical.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   02/16/2017 05:37 AM
Subject:Re: [openstack-dev] [nova] scaling rabbitmq with cells v2
requires manual database update





On Wed, Feb 15, 2017 at 4:34 PM, Corey Bryant <corey.bry...@canonical.com>
wrote:

  On Wed, Feb 15, 2017 at 4:26 PM, melanie witt <melwi...@gmail.com> wrote:
   On Wed, 15 Feb 2017 16:12:14 -0500, Corey Bryant wrote:
 This works but you have to specify all of the args (--cell_uuid,
 --name,
 --transport-url and --database_connection).  Otherwise you'll hit
 this: http://paste.ubuntu.com/24003055/

   Corey,

   Thanks for pointing that out.

   It looks like the command intended to have --transport-url and
   --database_connection as optional but missed defaulting them to None in
   the function parameter list.

   -melanie

  I think I figured it out.  I'll submit a patch in a little bit.



You're correct btw :)


--
Regards,
Corey
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] mutate config options on compute service

[Chen CH Ji]

According to http://docs.openstack.org/newton/config-reference/mutable.html
, seems this option is valid to compute service (as it says: Log onto the
compute node. )
but from following test result seems it's not honored by compute service,
is it a bug or wrong usage?

this is a all in one environment, Newton release version
I did change debug options from True to none (default to False) in the node
and tried command 'pkill -HUP nova'

compute logs shows it's still in DEBUG mode (and only service restart will
make the debug logs disappear)

2017-01-05 05:16:46.174 62225 INFO oslo_service.service
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Caught SIGHUP, exiting
2017-01-05 05:16:46.175 62225 DEBUG oslo_concurrency.lockutils
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Acquired semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-01-05 05:16:46.175 62225 DEBUG oslo_concurrency.lockutils
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Releasing semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:225
2017-01-05 05:16:51.287 62225 DEBUG oslo_messaging._drivers.amqpdriver [-]
CALL msg_id: a86b7b1cb66745e485e5ab75a1eb2a83 exchange 'nova' topic
'conductor'
_send /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:448
2017-01-05 05:16:51.295 62225 INFO nova.compute.manager
[req-de8349f2-ceb7-4eef-94ce-7cb09fd289bf - - - - -] Reloading compute RPC
API

api log shows it honored the flag and follow on there is no debug log based
on the 'Option DEFAULT.debug changed from [true] to [None]'

2017-01-05 05:16:46.130 62146 INFO oslo_service.service
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Child caught SIGHUP,
exiting
2017-01-05 05:16:46.130 62146 DEBUG oslo_concurrency.lockutils
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Acquired semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212
2017-01-05 05:16:46.130 62146 DEBUG oslo_concurrency.lockutils
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Releasing semaphore
"singleton_lock"
lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:225
2017-01-05 05:16:46.151 62145 INFO oslo_config.cfg
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Option DEFAULT.debug
changed from [true] to [None]
2017-01-05 05:16:46.151 62145 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Stopping WSGI server.
2017-01-05 05:16:46.151 62145 INFO nova.osapi_compute.wsgi.server
[req-3d3dfc79-4c42-460e-8311-7eab381adff3 - - - - -] (62145) wsgi exited,
is_accepting=True
2017-01-05 05:16:46.152 62145 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] WSGI server has
stopped.
2017-01-05 05:16:46.154 62146 INFO oslo_config.cfg
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Option DEFAULT.debug
changed from [true] to [None]
2017-01-05 05:16:46.155 62146 INFO nova.wsgi
[req-1dc88c01-f1a2-4553-b13d-0a06f8242879 - - - - -] Stopping WSGI server.



2017-01-05 05:16:46.164 62146 INFO nova.osapi_compute.wsgi.server
[req-c0aaa8de-b181-4fb0-a3e1-0e4ed201457b - - - - -] (62146) wsgi starting
up on https://0.0.0.0:8774
Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][cinder][nova] zip for raw Disk Format

[Chen CH Ji]

Thanks for the reply

the question is how can I distinguish the image in 'real' qcow2 format ? I
mean, considering cinder copy from image to volume case,
I need first download that image from glance, then copy contents to
volume ,'real' qcow2 will keep the image while I expect the qcow2
to be converted into raw format within the given command, without a
explicit format, how to decide whether the convent will be made or not?

Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eric Harney <ehar...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   10/05/2016 06:19 PM
Subject:Re: [openstack-dev] [glance][cinder][nova] zip for raw Disk
Format



On 10/05/2016 05:46 AM, Chen CH Ji wrote:
>
> From [1] we support a few common and vendor specific disk format, as use
> raw image sometimes will be very big and do we have existing any method
to
> consider zip the raw disk so the disk space might be saved as an option
to
> offer to end user and admin  ? so something like [2] could be enhanced to
> support zipped format?
> Thanks
>

The qcow2 format supports compression and is one of the most widely
supported image formats that can be used with OpenStack.

You can convert a raw image to qcow2 with:
 $ qemu-img convert -f raw -O qcow2 -c image.raw image.qcow2

And then upload image.qcow2 to Glance.

> [1] http://docs.openstack.org/developer/glance/formats.html
> [2]
>
https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L182

>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance][cinder][nova] zip for raw Disk Format

[Chen CH Ji]

From [1] we support a few common and vendor specific disk format, as use
raw image sometimes will be very big and do we have existing any method to
consider zip the raw disk so the disk space might be saved as an option to
offer to end user and admin  ? so something like [2] could be enhanced to
support zipped format?
Thanks

[1] http://docs.openstack.org/developer/glance/formats.html
[2]
https://github.com/openstack/cinder/blob/master/cinder/image/image_utils.py#L182

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable][liberty] [cinder] is stable liberty broken?

[Chen CH Ji]

Hi,
  I am backporting https://review.openstack.org/#/c/333749/ 
  to stable/liberty and failed in gating job, then I submitted another doc change https://review.openstack.org/#/c/338699/  to verify and seems failed with same reason and I have no idea what's wrong in test... can someone help to take a look or give some hint?
 
error is :

ft17.1: cinder.tests.unit.api.contrib.test_quotas.QuotaSetsControllerTest.test_delete_StringException: Empty attachments:
  pythonlogging:''
  stderr
  stdout

Traceback (most recent call last):
  File "cinder/tests/unit/api/contrib/test_quotas.py", line 100, in setUp
self.fixture = self.useFixture(config_fixture.Config(auth_token.CONF))
AttributeError: 'module' object has no attribute 'CONF'


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] api-ref sprint today & wed

[Chen CH Ji]

+1 to include .inc in the commit message, I also have to manually search in the open list
 
 
- Original message -From: Augustina Ragwitz To: OpenStack Development Mailing List  (not for usage questions)Cc:Subject: Re: [openstack-dev] [nova] api-ref sprint today & wedDate: Tue, May 10, 2016 12:29 AM 
Currently it's really hard to tell (at least to me) which files havepatches against them and which don't. I've had to manually make aspreadsheet because it's not obvious to me, at a glance, from thecurrent commit messages, and I've accidentally started work on severalfiles that already have owners. Maybe if people could put the .incfilename in their commit message, or maybe we could agree on aconsistent commit message for whichever phase we're on, it would beeasier to tell, at a glance from the list, what's already being workedon. Other suggestions welcome, or if there's another list somewhere Idon't know about, a link to that would be great.This is the list I'm referring to:https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:openThanks!Augustina--Augustina RagwitzSr Systems Software Engineer, HPE CloudHewlett Packard Enterprise---irc: auggy__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient core

[Chen CH Ji]

+1
 
 
- Original message -From: Boris Pavlovic To: "OpenStack Development Mailing List (not for usage questions)" Cc:Subject: Re: [openstack-dev] [nova] Proposing Andrey Kurilin for python-novaclient coreDate: Thu, Apr 14, 2016 8:07 AM 
Great!
 
On Wed, Apr 13, 2016 at 2:56 PM, Sylvain Bauza  wrote:

Le 13/04/2016 19:53, Matt Riedemann a écrit :
I'd like to propose that we make Andrey Kurilin core on python-novaclient.He's been doing a lot of the maintenance the last several months and a lot of times is the first to jump on any major issue, does a lot of themicroversion work, and is also working on cleaning up docs and helping me with planning releases.His work is here [1].Review stats for the last 4 months (although he's been involved in the project longer than that) [2].Unless there is disagreement I plan to make Andrey core by the end of the week.[1] https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient[2] http://stackalytics.com/report/contribution/python-novaclient/120  +1.
__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

[Chen CH Ji]

 agree we can ask people to submit their requirement through backlog spec but not sure it might have too much process sometimes the bug opener is not a developer, it might be some operatoror openstack user, they just want to get it done but they don't know more detailso we can keep the wishlist and cleanup it and mark it invalid as you suggestedlike 6 month or 1 year, but mark the bug which may contains valid request Invalid like [1] right afterwe found it's not current supported seems too rush[1]https://bugs.launchpad.net/bugs/1556756-Matt Riedemann  wrote: -To: openstack-dev@lists.openstack.orgFrom: Matt Riedemann Date: 03/15/2016 02:50PMSubject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?On 3/15/2016 8:37 AM, Chris Dent wrote:> On Tue, 15 Mar 2016, Markus Zoeller wrote:>>> Long story short, I'm in favor of abandoning the use of "wishlist">> as an importance in bug reports to track requests for enhancements.>> While I'm very much in favor of limiting the amount of time issues> (of any sort) linger in launchpad[1] I worry that if we stop making> "wishlist" available as an option then people who are not well> informed about the complex system for achieving features in Nova> will have no medium to get their ideas into the system. We want> users to sometime be able to walk up, drop an idea and move on without> having to be responsible for actually doing that work. If we insist> that such ideas must go through the blueprint process then most> ideas will be left unstated.We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs:https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html>> What I think we need to do instead is fix this problem:>>> * we don't have a process to transform wishlist bugs to blueprints>> such that we do have a process of some kind where a wishlist idea> either gets an owner who starts the blueprint process (because it is> just that cool) or dies from lack of attention.>> It's clear, though, that we already have a huge debt in bug/issue> management so adding yet another task is hard to contemplate.>> I think we can address some of that by more quickly expiring bugs> that have had no recent activity or attention, on the assumption> that:>> * They will come back up again if they are good ideas or real bugs.> * Lack of attention is a truthy signal of either lack of resources or lack>    of importance.>> What needs to happen is that fewer things which are not actionable> or nobody is interested in show up when traversing the bugs looking> for something to work on.>> I'm happy to help some of this become true, in part because of [1]> below.>> [1] I've recently spent a bit of time chasing bugs tagged> "scheduler" and far too many of them are so old that it's impossible> to tell whether they matter any more, and many of them are confused> by patches and people who have gone in and out of existence. It's> challenging to tease out what can be done and the information has> very little archival value. It should go off the radar. Having a> bunch of stuff that looks like it needs to be done but never> actually is is stop energy and depressing. __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that).-- Thanks,Matt Riedemann__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][novaclient]novaclient backward compatible changes

[Chen CH Ji]

 From [1], some questions raised is whether and how we will guarantee the return value of novaclient? e.g some toolssuch as openstackclient utilize novaclient return value , we don't have microversion mechanism (and seems not helpfuland too heavy) to do those kind of changes... so novaclient should make every changes backward compatible?BTW: [1] seems not mandatory(better to have), so the question is related to the patch, just for general idea..[1] https://review.openstack.org/#/c/291915/1


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

[Chen CH Ji]

+1 for no microversion, it's internal implementation and we should be free to remove it since we didn't document it anywhere-GHANSHYAM MANN  wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: GHANSHYAM MANN Date: 02/16/2016 03:49AMSubject: Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?Yes, currently Nova support that for show/update/delete server APIs etc (both v2 and v2.1) and python-novaclient too. But I think that was old behaviour and for ec2 API mainly?I searched on ec2 repo [1] and they get the instance from nova using UUID, i did not find any place they are fetching using id. Hut not sure if external interface directly fetch that on nova by 'id'.But apart from that, may be some users using 'id' instead of 'uuid' but that was not recommended or documented anywhere So in that case can we remove this old behaviour without version bump?[1].. https://github.com/openstack/ec2-apiRegardsGhanshyam MannOn Tue, Feb 16, 2016 at 11:24 AM, Anne Gentle  wrote:On Mon, Feb 15, 2016 at 6:03 PM, 少合冯  wrote:I guess others may ask the same questions. I read the nova API doc: such as this API: http://developer.openstack.org/api-ref-compute-v2.1.html#showServerGET /v2.1/​{tenant_id}​/servers/​{server_id}​Show server detailsRequest parametersParameterStyleTypeDescriptiontenant_idURIcsapi:UUIDThe UUID of the tenant in a multi-tenancy cloud.server_idURIcsapi:UUIDThe UUID of the server.But I can get the server by DB index: curl -s -H X-Auth-Token:6b8968eb38df47c6a09ac9aee81ea0c6 http://192.168.2.103:8774/v2.1/f5a8829cc14c4825a2728b273aa91aa1/servers/2{    "server": {        "OS-DCF:diskConfig": "MANUAL",        "OS-EXT-AZ:availability_zone": "nova",        "OS-EXT-SRV-ATTR:host": "shaohe1",        "OS-EXT-SRV-ATTR:hypervisor_hostname": "shaohe1",        "OS-EXT-SRV-ATTR:instance_name": "instance-0002",        "OS-EXT-STS:power_state": 1,        "OS-EXT-STS:task_state": "migrating",        "OS-EXT-STS:vm_state": "error",        "OS-SRV-USG:launched_at": "2015-12-18T07:41:00.00",        "OS-SRV-USG:terminated_at": null,        ..    }}and the code really allow it use  DB indexhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L1939Nice find. Can you log this as an API bug and we'll triage it -- can even help you fix it on the site if you like. https://bugs.launchpad.net/openstack-api-site/+filebugBasically, click that link, write a short summary, then copy and paste in this email's contents, it has lots of good info.Let me know if you'd also like to fix the bug on the site.And hey nova team, if you think it's actually an API bug, we'll move it over to you.Thanks for reporting it!Anne __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev-- Anne GentleRackspacePrincipal Engineerwww.justwriteclick.com__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][virt] rebuild action not insupport-matrix

[Chen CH Ji]

 ok, thanks, guess even if all virt layer support this 'rebuild' , we can still say it's supported by all hypervisors so others can take it as a reference, will submit a new patch for it, thanks-"Daniel P. Berrange" <berra...@redhat.com> wrote: -To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>From: "Daniel P. Berrange" <berra...@redhat.com>Date: 02/02/2016 10:21AMSubject: Re: [openstack-dev] [nova][virt] rebuild action not insupport-matrixOn Mon, Feb 01, 2016 at 05:04:37PM -0700, Matt Riedemann wrote:> > > On 2/1/2016 12:39 PM, Chen CH Ji wrote:> >Hi> >           We have been trying to enablement of our CI work for our nova> >virt layer code ,so we need to configure the tempest cases based on our> >nova driver capability> >           I found that rebuild action is not listed in [1] (only talk> >about rebuild in evacuate), but code [2] seems support virt layer> >abstraction> >           can someone point the rebuild action in [1] or it's missing> >on purpose ? Thanks> >> >[1]http://docs.openstack.org/developer/nova/support-matrix.html> >[2]https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2920> >> >> >> >__> >OpenStack Development Mailing List (not for usage questions)> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> > Only the Ironic driver overrides the rebuild method, otherwise the compute> manager has a default impl, so it's technically implemented for all virt> drivers. There is also confusion around rebuild vs evacuate since both> operations go through the rebuild_instance method in the compute manager,> they are just separated by the 'recreate' parameter.> > danpb might have reasons for not listing rebuild in the hypervisor support> matrix - it might have just never been on the original wiki matrix. It'd be> worth asking him.The hypervisor matrix just copied the data from the original wiki. It iscertainly not a complete list of all features that are relevant. You couldmake the matrix x10 bigger and it still wouldn't cover all interesting factsacross virt drivers. If anyone has things they want shown they should submitpatches> But at the same time, since there is a default implementation, I'm also not> sure if it's worth listing separately in the support matrix (but is also> confusing I suppose to not list it at all).That there is a default impl is really just an impl detail - if it is aninteresting feature from the user POV it is worth listing IMHORegards,Daniel-- |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :||: http://libvirt.org              -o-             http://virt-manager.org :||: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :||: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][virt] rebuild action not in support-matrix

[Chen CH Ji]

 Hi   We have been trying to enablement of our CI work for our nova virt layer code ,so we need to configure the tempest cases based on our nova driver capability  I found that rebuild action is not listed in [1] (only talk about rebuild in evacuate), but code [2] seems support virt layer abstraction   can someone point the rebuild action in [1] or it's missing on purpose ? Thanks[1]http://docs.openstack.org/developer/nova/support-matrix.html[2]https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2920


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][API]what's the purpose of fping in nova API?

[Chen CH Ji]

ok, a potential work for N release, thanks-Sean Dague <s...@dague.net> wrote: -To: openstack-dev@lists.openstack.orgFrom: Sean Dague <s...@dague.net>Date: 02/01/2016 11:07AMSubject: Re: [openstack-dev] [nova][API]what's the purpose of fping in nova API?On 01/29/2016 09:18 AM, Chen CH Ji wrote:> In doing some API work on> http://developer.openstack.org/api-ref-compute-v2.1.html> noticed that fping was [1] and try to ping the instance to check whether> it's pingable or not..> but this is running on API service host which mostly have no access to> instance with private IP?> Just curious about it ...> > > [1]> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/fping.py#L53fping is probably an API we should deprecate, as you've seen, it'shighly foulable and requires a network topology that people may not have.-Sean-- Sean Daguehttp://dague.net__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev[attachment "signature.asc" removed by Chen CH Ji/China/IBM]


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][API]what's the purpose of fping in nova API?

[Chen CH Ji]

 In doing some API work on http://developer.openstack.org/api-ref-compute-v2.1.htmlnoticed that fping was [1] and try to ping the instance to check whether it's pingable or not..but this is running on API service host which mostly have no access to instance with private IP?Just curious about it ...[1] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/fping.py#L53


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][API] Question about HTTPNotImplementError

[Chen CH Ji]

In reading some API guide line doc [1] seems we should not return 501 to clientbut nova still doing so at API layer [2], any discussion before about this can be referred ? [1]https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#use-of-501---not-implemented[2]https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L536


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] nova cli commands fail with 404. devstack installation from today

[Chen CH Ji]

 Guess it's image-list instead of image list,right?  maybe you can check with nova --debug image-list and see the API which wassend to nova-api server then analyze the nova api log to know what's exactly the error?-"Bob Hansen"  wrote: -To: openstack-dev@lists.openstack.orgFrom: "Bob Hansen" Date: 01/20/2016 10:31PMSubject: [openstack-dev] nova cli commands fail with 404. devstackinstallation from todayInstalled devstack today, this morning actually,  and most everything works except simple nova cli commands, nova image list, list, flavor-list all fail) glance ok, nuetron ok, As an example, nova image list returns:devstack$ nova image listERROR (NotFound): The resource could not be found. (HTTP 404)However the command; openstack image list returns the correct list of cirros images, plus one I have already imported.key.log has:127.0.0.1 - - [20/Jan/2016:21:10:49 +] "POST /tokens HTTP/1.1" 404 93 "-" "keystoneauth1/2.2.0 python-requests/2.9.1 CPython/2.7.6" 2270(us)Clearly an authentication thing. Since other commands work, e.g. neutorn subnet-list, I concluded keystone auth is just fine.I suspect it is something in nova.conf. [keystone_auth] has this in it, which stack.sh built[keystone_authtoken]signing_dir = /var/cache/novacafile = /opt/stack/data/ca-bundle.pemauth_uri = http://127.0.0.1:5000project_domain_id = defaultproject_name = serviceuser_domain_id = defaultpassword = secretserviceusername = novaauth_url = http://127.0.0.1:35357auth_type = passwordAny suggestions on where else to look?Bob Hansenz/VM OpenStack Enablement 
__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [python-novaclient] microversions support

[Chen CH Ji]

+1 , added a doc change just now  https://review.openstack.org/#/c/253644 -"Kevin L. Mitchell"  wrote: -To: From: "Kevin L. Mitchell" Date: 12/04/2015 06:25PMSubject: Re: [openstack-dev] [nova] [python-novaclient] microversions supportOn Fri, 2015-12-04 at 18:58 +0200, Andrey Kurilin wrote:> This week I added 5 patches to enable 2.7-2.11 microversions in> novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone> who are working on new microversions: Please, do not forget to add> support of your microversion to official Nova client.Perhaps this is something we should add to the review guidelines—no APIchange can be merged to nova unless there is a pending change tonovaclient to add support?  We already more or less enforce the criteriathat no addition to novaclient can be added unless the correspondingnova change has been merged…-- Kevin L. Mitchell Rackspace__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] API: Question on 'Retry-After': 0 in HTTPForbidden

[Chen CH Ji]

ok thanks for confirm, I will file a bug and fix it~,

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Alex Xu hejie...@intel.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   08/19/2015 08:14 AM
Subject:Re: [openstack-dev] [nova] API: Question on 'Retry-After': 0 in
HTTPForbidden



+1 for Retry-After is wrong for quota case

  在 2015年8月19日，下午1:32，GHANSHYAM MANN ghanshyamm...@gmail.com
  写道：

  Retry-After
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] API: Question on 'Retry-After': 0 in HTTPForbidden

[Chen CH Ji]

When doing patch[1] Ken'ichi raise a good suggestion on not raise
Retry-After according to [2]

seems nova also when doing create[3] and resize[4] a server nova may raise
those, too
is this a bug or something made on purpose? Thanks

[1]
https://review.openstack.org/#/c/180469/5/nova/api/openstack/compute/tenant_networks.py
[2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
[3]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L591
[4]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L846

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] compute - conductor and version compatibility

[Chen CH Ji]

I remembered I saw somewhere about how to upgrade, (step by step in
updating from J to K or others)
I think it's best and suitable way to use this kind of 'different version'
talking to make compute host alive
during system upgrade.


so I believe controller should be upgrade first the compute node to be
update set by set
that means Kilo conductor should works with Juno compute
but on the contrary I didn't see a value for supporting it

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org
Date:   08/17/2015 05:01 PM
Subject:Re: [openstack-dev] [nova] compute - conductor and version
compatibility



On 08/17/2015 10:41 AM, Markus Zoeller wrote:
 I have the impression that more and more people try to run OpenStack
 in a mixed-releases-mode and face some troubles to understand how
 the capabilities and limitations look like. For example, the reporter
 of [1] runs a nova-conductor (Juno) with a nova-compute (Kilo). I tried
 in comment #3 of [1] to rationalize if this is a valid setup or not
 and I failed...
 If someone with more experience and knowledge could help there and
 clarify it also for other users in the future, that would be awesome.

 [1] https://bugs.launchpad.net/nova/+bug/1483321

No, that's not valid behaviour. You need to upgrade the controller
infrastructure (conductor, API nodes, etc) before any compute nodes.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] How to microversion API code which is not in API layer

[Chen CH Ji]

Hi
 We have [1] in the db layer and it's directly used by API
layer , the filters is directly from client's input
 In this case, when doing [2] or similar changes, do we need to
consider microversion usage when we change options?
 Thanks

[1]
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4440
[2] https://review.openstack.org/#/c/144883

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Chen CH Ji]

no, I only want to confirm whether cinder folks is doing this or there are
already tricks can be used that before submit the change ... thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann mrie...@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Date:   05/07/2015 10:12 PM
Subject:Re: [openstack-dev] [cinder][nova] Question on Cinder client
exception handling





On 5/6/2015 7:02 AM, Chen CH Ji wrote:
 Hi
 In order to work on [1] , nova need to know what kind of
 exception are raised when using cinderclient so that it can handle like
 [2] did?
 In this case, we don't need to distinguish the error
 case based on string compare , it's more accurate and less error leading
 Anyone is doing it or any other methods I can use to
 catch cinder specified  exception in nova? Thanks


 [1] https://bugs.launchpad.net/nova/+bug/1450658
 [2]

https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L64


 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 District, Beijing 100193, PRC



__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Is there anything preventing us from adding a more specific exception to
cinderclient and then once that's in and released, we can pin the
minimum version of cinderclient in global-requirements so nova can
safely use it?

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][nova] Question on Cinder client exception handling

[Chen CH Ji]

Hi
   In order to work on [1] , nova need to know what kind of
exception are raised when using cinderclient so that it can handle like [2]
did?
   In this case, we don't need to distinguish the error case
based on string compare , it's more accurate and less error leading
   Anyone is doing it or any other methods I can use to catch
cinder specified  exception in nova? Thanks


[1] https://bugs.launchpad.net/nova/+bug/1450658
[2]
https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L64

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Which error code should we return when OverQuota

[Chen CH Ji]

In doing patch [1], A suggestion is submitted that we should return 400
(bad Request) instead of 403 (Forbidden)
I take a look at [2], seems 400 is not a good candidate because
'The request could not be understood by the server due to malformed syntax.
The client SHOULD NOT repeat the request without modifications. '

may be a 409 (conflict) error if we really don't think 403 is a good one?
Thanks


[1] https://review.openstack.org/#/c/173985/
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

[Chen CH Ji]

+1

and +1 for not a core :)

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Davanum Srinivas dava...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   04/30/2015 03:14 PM
Subject:Re: [openstack-dev] [nova] Proposal to add Melanie Witt to
nova-core



+1 from me as well! (Ditto as Ed, not a core).

-- dims

On Thu, Apr 30, 2015 at 9:00 AM, Ed Leafe e...@leafe.com wrote:
 On Apr 30, 2015, at 6:30 AM, John Garbutt j...@johngarbutt.com wrote:

 I propose we add Melanie to nova-core.

 I know I'm not core, so my vote doesn't count, but I think that this
would be a great addition.

 +1

 -- Ed Leafe







__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] In loving memory of Chris Yeoh

[Chen CH Ji]

+1
I can't believe we lost him When we met in Hongkong summit his smile
give me very deep impression...
he is very helpful to me from the first day I contribute to community and I
learnt a lot from him

May his soul rest in peace

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Qiao, Liyong liyong.q...@intel.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   04/08/2015 11:30 AM
Subject:Re: [openstack-dev] In loving memory of Chris Yeoh



+1 from me.

Chris is also my leader in IBM some time before, He is a helpful and
talkative man. I learn lots from him, he work so hard that I see he send
out email shortly before even he is ill in bed.

we never forget the contribution for the nova community, nova v3 api, nova
v2.1 api nova 2.1 micro version api.

I hot he will leave in peace and won’t be worry about the review duty in
heaven.
I will never forget his word when ending the scrum, “let talk it tomorrow,
CU”

BR, Eli(Li Yong)Qiao

From: Alex Xu [mailto:sou...@gmail.com]
Sent: Wednesday, April 08, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] In loving memory of Chris Yeoh

Feel very sad. Just few weeks ago, I still saw him active on the community.
Really hard believe this happen such suddenly.

He was my leader in IBM and mentored me on the openstack community also,
offered lots of help without reservation, really
learn a lot from him.  We have phone call meeting every morning before, he
always sounds happy and enthusiastic even after
he got health problem.
May his soul rest in peace.

2015-04-08 12:49 GMT+08:00 Michael Still mi...@stillhq.com:


 It is my sad duty to inform the community that Chris Yeoh passed away this
 morning. Chris leaves behind a daughter Alyssa, aged 6, who I hope will
 remember Chris as the clever and caring person that I will remember him
 as. I haven’t had a chance to confirm with the family if they want flowers
 or a donation to a charity. As soon as I know those details I will reply
 to this email.


 Chris worked on open source for a very long time, with OpenStack being
 just the most recent in a long chain of contributions. He worked
 tirelessly on his contributions to Nova, including mentoring other
 developers. He was dedicated to the cause, with a strong vision of what
 OpenStack could become. He even named his cat after the project.


 Chris might be the only person to have ever sent an email to his coworkers
 explaining what his code review strategy would be after brain surgery. It
 takes phenomenal strength to carry on in the face of that kind of
 adversity, but somehow he did. Frankly, I think I would have just sat on
 the beach.


 Chris was also a contributor to the Linux Standards Base (LSB), where he
 helped improve the consistency and interoperability between Linux
 distributions. He ran the ‘Hackfest’ programming contests for a number of
 years at Australia’s open source conference -- linux.conf.au. He supported
 local Linux user groups in South Australia and Canberra, including
 involvement at installfests and speaking at local meetups. He competed in
 a programming challenge called Loki Hack, and beat out the world to win
 the event[1].


 Alyssa’s memories of her dad need to last her a long time, so we’ve
 decided to try and collect some fond memories of Chris to help her along
 the way. If you feel comfortable doing so, please contribute a memory or
 two at
 
https://docs.google.com/forms/d/1kX-ePqAO7Cuudppwqz1cqgBXAsJx27GkdM-eCZ0c1V8/viewform


 Chris was humble, helpful and honest. The OpenStack and broader Open
 Source communities are poorer for his passing.


 Michael


 [1] http://www.lokigames.com/hack/

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Whether microversion implementation only need to be applied to first layer API?

[Chen CH Ji]

During
http://lists.openstack.org/pipermail/openstack-dev/2015-March/059000.html,
we had some discussions on
whether we need version specific code remaining even we suggest user can
use API version directly in API,  [1][2] aiming to remove that
And if we should keep following stuff , then [3][4]  might be thought
because of some potential issue

can someone give some suggestions ? thanks

[1]https://review.openstack.org/#/c/164229/
[2]https://review.openstack.org/#/c/164234/
[3]https://review.openstack.org/#/c/144998/
[4]https://review.openstack.org/#/c/145240/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?

[Chen CH Ji]

oops, duplication ... I submitted changes to spec after got this info since
it make sense to me ...

https://review.openstack.org/#/c/164229/
https://review.openstack.org/#/c/164234/

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Alex Xu sou...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   03/16/2015 02:53 AM
Subject:Re: [openstack-dev] [nova] is it possible to microversion a
static class method?





2015-03-16 9:48 GMT+08:00 Alex Xu sou...@gmail.com:


  2015-03-13 19:10 GMT+08:00 Sean Dague s...@dague.net:
   On 03/13/2015 02:55 AM, Chris Friesen wrote:
On 03/12/2015 12:13 PM, Sean Dague wrote:
On 03/12/2015 02:03 PM, Chris Friesen wrote:
Hi,
   
I'm having an issue with microversions.
   
The api_version() code has a comment saying This decorator MUST
   appear
first (the outermost decorator) on an API method for it to work
correctly
   
I tried making a microversioned static class method like this:
   
         @wsgi.Controller.api_version(2.4)  # noqa
         @staticmethod
         def _my_func(req, foo):
   
and pycharm highlighted the api_version decorator and complained
   that
This decorator will not receive a callable it may expect; the
   built-in
decorator returns a special object.
   
Is this a spurious warning from pycharm?  The pep8 checks don't
complain.
   
If I don't make it static, then pycharm suggests that the method
   could
be static.
   
*API method*
   
This is not intended for use by methods below the top controller
   level.
If you want conditionals lower down in your call stack pull the
   request
version out yourself and use that.
   
Both the original spec and doc/source/devref/api_microversions.rst
contain text talking about decorating a private method.  The latter
gives this example:
   
        @api_version(2.1, 2.4)
        def _version_specific_func(self, req, arg1):
            pass
   
        @api_version(min_version=2.5) #noqa
        def _version_specific_func(self, req, arg1):
            pass
   
        def show(self, req, id):
             common stuff 
            self._version_specific_func(req, foo)
             common stuff 
   
It's entirely possible that such a private method might not need to
reference self, and could therefore be static, so I think it's a
   valid
question.

   That's a doc bug, we should change it.


  Actually it is not a bug. It's controversial point in the spec, but
  finally that was keep in the spec.
  
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html

  The discussion at line 268
  
https://review.openstack.org/#/c/127127/7/specs/kilo/approved/api-microversions.rst

Submit a patch for devref https://review.openstack.org/164555  Let see
whether we can get agreement



           -Sean

   --
   Sean Dague
   http://dague.net

   __

   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe:
   openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?

[Chen CH Ji]

I posted same question below yesterday, not sure why it's not posted in the
list ...


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Chris Friesen chris.frie...@windriver.com
To: openstack-dev@lists.openstack.org
Date:   03/13/2015 07:57 AM
Subject:Re: [openstack-dev] [nova] is it possible to microversion a
static class method?



On 03/12/2015 12:13 PM, Sean Dague wrote:
 On 03/12/2015 02:03 PM, Chris Friesen wrote:
 Hi,

 I'm having an issue with microversions.

 The api_version() code has a comment saying This decorator MUST appear
 first (the outermost decorator) on an API method for it to work
correctly

 I tried making a microversioned static class method like this:

  @wsgi.Controller.api_version(2.4)  # noqa
  @staticmethod
  def _my_func(req, foo):

 and pycharm highlighted the api_version decorator and complained that
 This decorator will not receive a callable it may expect; the built-in
 decorator returns a special object.

 Is this a spurious warning from pycharm?  The pep8 checks don't
complain.

 If I don't make it static, then pycharm suggests that the method could
 be static.

 *API method*

 This is not intended for use by methods below the top controller level.
 If you want conditionals lower down in your call stack pull the request
 version out yourself and use that.

Both the original spec and doc/source/devref/api_microversions.rst contain
text
talking about decorating a private method.  The latter gives this example:

 @api_version(2.1, 2.4)
 def _version_specific_func(self, req, arg1):
 pass

 @api_version(min_version=2.5) #noqa
 def _version_specific_func(self, req, arg1):
 pass

 def show(self, req, id):
  common stuff 
 self._version_specific_func(req, foo)
  common stuff 

It's entirely possible that such a private method might not need to
reference
self, and could therefore be static, so I think it's a valid question.

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

[Chen CH Ji]

FYI :)
you may take a look at doc/source/devref/api_plugins.rst which was merged
recently
you can take a look at
http://lists.openstack.org/pipermail/openstack-dev/2015-March/058493.html
and its follow up discussion


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Chris Friesen chris.frie...@windriver.com
To: openstack-dev@lists.openstack.org
Date:   03/11/2015 11:44 PM
Subject:Re: [openstack-dev] [nova] need input on possible API change
for bug #1420848




I can see how to do a v2 extension following the example given for
extended_services.py and extended_services_delete.py.  That seems to be
working now.

I'm not at all clear on how to go about doing the equivalent for v2.1.
Does
that use the api/openstack/compute/plugins/v3/ subdirectory?   Is it
possible to
do the equivalent to the v2 extended_services.py (where the code in
api/openstack/compute/plugins/v3/services.py checks to see if the other
extension is enabled) or do I have to write a whole new extension that
builds on
the output of api/openstack/compute/plugins/v3/services.py?

Thanks,
Chris


On 03/11/2015 09:51 AM, Chen CH Ji wrote:
 I would think a on v2 extension is needed
 for v2.1 , mircoversion is a way but not very sure it's needed.

 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
 Beijing 100193, PRC

 Inactive hide details for Chris Friesen ---03/11/2015 04:35:01 PM---Hi,
I'm
 working on bug #1420848 which addresses the issue tChris Friesen
---03/11/2015
 04:35:01 PM---Hi, I'm working on bug #1420848 which addresses the issue
that doing a

 From: Chris Friesen chris.frie...@windriver.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 03/11/2015 04:35 PM
 Subject: [openstack-dev] [nova] need input on possible API change for bug
#1420848








 Hi,

 I'm working on bug #1420848 which addresses the issue that doing a
 service-disable followed by a service-enable against a down compute
node
 will result in the compute node going up for a while, possibly causing
delays
 to operations that try to schedule on that compute node.

 The proposed solution is to add a new reported_at field in the DB
schema to
 track when the service calls _report_state().

 The backend is straightforward, but I'm trying to figure out the best way
to
 represent this via the REST API response.

 Currently we response includes an updated_at property, which maps
directly to
 the auto-updated updated_at field in the database.

 Would it be acceptable to just put the reported_at value (if it exists)
in the
 updated_at property?  Logically the reported_at value is just a
 determination of when the service updated its own state, so an argument
could be
 made that this shouldn't break anything.

 Otherwise, by my reading of
 
https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
 it
 seems like if I wanted to add a new reported_at property I would need
to do it
 via an API extension.

 Anyone have opinions?

 Chris


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?

[Chen CH Ji]

Know it's a little bit tricky but from
doc/source/devref/api_microversions.rst,
can we make _version_specific_func static function thought it's not
required or we can explicitly suggest not to do so...


 91 @api_version(2.1, 2.4)
 92 def _version_specific_func(self, req, arg1):
 93 pass
 94
 95 @api_version(min_version=2.5) #noqa
 96 def _version_specific_func(self, req, arg1):
 97 pass
 98
 99 def show(self, req, id):
100  common stuff 
101 self._version_specific_func(req, foo)
102  common stuff 

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Sean Dague s...@dague.net
To: openstack-dev@lists.openstack.org
Date:   03/12/2015 07:16 PM
Subject:Re: [openstack-dev] [nova] is it possible to microversion a
static class method?



On 03/12/2015 02:03 PM, Chris Friesen wrote:
 Hi,

 I'm having an issue with microversions.

 The api_version() code has a comment saying This decorator MUST appear
 first (the outermost decorator) on an API method for it to work
correctly

 I tried making a microversioned static class method like this:

 @wsgi.Controller.api_version(2.4)  # noqa
 @staticmethod
 def _my_func(req, foo):

 and pycharm highlighted the api_version decorator and complained that
 This decorator will not receive a callable it may expect; the built-in
 decorator returns a special object.

 Is this a spurious warning from pycharm?  The pep8 checks don't complain.

 If I don't make it static, then pycharm suggests that the method could
 be static.

*API method*

This is not intended for use by methods below the top controller level.
If you want conditionals lower down in your call stack pull the request
version out yourself and use that.

 -Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

[Chen CH Ji]

I would think a on v2 extension is needed
for v2.1 , mircoversion is a way but not very sure it's needed.

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Chris Friesen chris.frie...@windriver.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   03/11/2015 04:35 PM
Subject:[openstack-dev] [nova] need input on possible API change for
bug #1420848




Hi,

I'm working on bug #1420848 which addresses the issue that doing a
service-disable followed by a service-enable against a down compute
node
will result in the compute node going up for a while, possibly causing
delays
to operations that try to schedule on that compute node.

The proposed solution is to add a new reported_at field in the DB schema
to
track when the service calls _report_state().

The backend is straightforward, but I'm trying to figure out the best way
to
represent this via the REST API response.

Currently we response includes an updated_at property, which maps
directly to
the auto-updated updated_at field in the database.

Would it be acceptable to just put the reported_at value (if it exists)
in the
updated_at property?  Logically the reported_at value is just a
determination of when the service updated its own state, so an argument
could be
made that this shouldn't break anything.

Otherwise, by my reading of

https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
 it
seems like if I wanted to add a new reported_at property I would need to
do it
via an API extension.

Anyone have opinions?

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] proposal for unwinding database usage from tests

[Chen CH Ji]

Sorry for late reply and thanks for bring this out, I agree the create_db
flag will increase the complexity
so I might do some PoC and write a spec to do it next release

For this sentence, I don't fully understand, are you suggesting to every db
usage remove should be a
patch for a test class? thanks a lot
I'd like to propose instead DB usage should be removed per test Class as
an atomic unit.

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Sean Dague s...@dague.net
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: Chen CH Ji/China/IBM@IBMCN
Date:   01/24/2015 07:13 PM
Subject:[nova] proposal for unwinding database usage from tests



I've been looking at the following patch series -
https://review.openstack.org/#/c/131691/13 for removing database
requirements from some tests.

I whole heartedly support getting DB usage out of tests, but I'd like to
make sure that we don't create new challenges in the process. The
conditional create_db parameter in test functions adds a bit more
internal test complexity than I think we should have.

I'd like to propose instead DB usage should be removed per test Class as
an atomic unit. If that turns into too large a patch that probably means
breaking apart the test class into smaller test classes first.

The other thing to be careful in understanding the results of timing
tests. The way the database fixture works it caches the migration
process -
https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L206

That actually means that the overhead of the db-migration sync is paid
only once per testr worker (it's 1s on my fast workstation, might be 2s
on gate nodes). The subsequence db setups for tests 2 - N in the worker
only take about 0.020s on my workstation (scale appropriately). So
removing all the unneeded db setup code is probably only going to save
~30s over an entire test run.

Which doesn't mean it shouldn't be done, there are other safety reasons
we shouldn't let every test randomly punch data into the db and still
pass. But time savings should not be the primary motivator here, because
it's actually not nearly as much gain as it looks like from running only
a small number of tests.

 -Sean

--
Sean Dague
http://dague.net

(See attached file: signature.asc)

signature.asc
Description: Binary data
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Chen CH Ji]

Is there a way to overwrite the rule in our hacking (not familiar with
it ...)?
if so ,maybe we can do as suggested to avoid 811 for the class which has
Microversion definition? Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Christopher Yeoh cbky...@gmail.com
To: openstack-dev@lists.openstack.org
Date:   01/28/2015 09:37 AM
Subject:Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check
for microversion



On Tue, 06 Jan 2015 07:31:19 -0500
Jay Pipes jaypi...@gmail.com wrote:

 On 01/06/2015 06:25 AM, Chen CH Ji wrote:
  Based on nova-specs api-microversions.rst
  we support following function definition format, but it violate the
  hacking rule pep8 F811 because duplicate function definition
  we should use #noqa for them , but considering microversion may
  live for long time ,
  keep adding #noqa may be a little bit ugly, can anyone suggest a
  good solution for it ? thanks
 
  @api_version(min_version='2.1')
  def _version_specific_func(self, req, arg1):
 pass
   
  @api_version(min_version='2.5')
  def _version_specific_func(self, req, arg1):
 pass

 Hey Kevin,

 This was actually one of my reservations about the proposed
 microversioning implementation -- i.e. having functions that are
 named exactly the same, only decorated with the microversioning
 notation. It kinda reminds me of the hell of debugging C++ code that
 uses STL: how does one easily know which method one is in when inside
 a debugger?

 That said, the only other technique we could try to use would be to
 not use a decorator and instead have a top-level dispatch function
 that would inspect the API microversion (only when the API version
 makes a difference to the output or input of that function) and then
 dispatch the call to a helper method that had the version in its name.

 So, for instance, let's say you are calling the controller's GET
 /$tenant/os-hosts method, which happens to get routed to the
 nova.api.openstack.compute.contrib.hosts.HostController.index()
 method. If you wanted to modify the result of that method and the API
 microversion is at 2.5, you might do something like:

   def index(self, req):
   req_api_ver = utils.get_max_requested_api_version(req)
   if req_api_ver == (2, 5):
   return self.index_2_5(req)
   return self.index_2_1(req)

   def index_2_5(self, req):
   results = self.index_2_1(req)
   # Replaces 'host' with 'host_name'
   for result in results:
   result['host_name'] = result['host']
   del result['host']
   return results

   def index_2_1(self, req):
   # Would be a rename of the existing index() method on
   # the controller


So having to manually add switching code everything we have an API
patch I think is not only longer and more complicated but more error
prone when updating. If we change something at the core in the future it
means changing all the microversioned code rather than just the
switching architecture at the core of wsgi.


 Another option would be to use something like JSON-patch to determine
 the difference between two output schemas and automatically translate
 one to another... but that would be a huge effort.

 That's the only other way I can think of besides disabling F811,
 which I really would not recommend, since it's a valuable safeguard
 against duplicate function names (especially duplicated test methods).

So I don't think we need to disable F811 in general - why not just
disable it for any method with the api_version decorator? On those ones
we can do checks on what is passed to api_version which will help
verify that there hasn't been a typo to an api_version decorator.

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] proposal for unwinding database usage from tests

[Chen CH Ji]

ok, I understand the purpose and way to go now, thanks for the sharing
and I will refactory the patches I have ,thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann mrie...@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Date:   01/28/2015 06:17 PM
Subject:Re: [openstack-dev] [nova] proposal for unwinding database
usage from tests





On 1/28/2015 10:59 AM, Chen CH Ji wrote:
 Sorry for late reply and thanks for bring this out, I agree the
 create_db flag will increase the complexity
 so I might do some PoC and write a spec to do it next release

 For this sentence, I don't fully understand, are you suggesting to every
 db usage remove should be a
 patch for a test class? thanks a lot
 /I'd like to propose instead DB usage should be removed per test Class as
 an atomic unit./

 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 District, Beijing 100193, PRC

 Inactive hide details for Sean Dague ---01/24/2015 07:13:45 PM---I've
 been looking at the following patch series - https://reviSean Dague
 ---01/24/2015 07:13:45 PM---I've been looking at the following patch
 series - https://review.openstack.org/#/c/131691/13 for rem

 From: Sean Dague s...@dague.net
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Chen CH Ji/China/IBM@IBMCN
 Date: 01/24/2015 07:13 PM
 Subject: [nova] proposal for unwinding database usage from tests

 



 I've been looking at the following patch series -
 https://review.openstack.org/#/c/131691/13 for removing database
 requirements from some tests.

 I whole heartedly support getting DB usage out of tests, but I'd like to
 make sure that we don't create new challenges in the process. The
 conditional create_db parameter in test functions adds a bit more
 internal test complexity than I think we should have.

 I'd like to propose instead DB usage should be removed per test Class as
 an atomic unit. If that turns into too large a patch that probably means
 breaking apart the test class into smaller test classes first.

 The other thing to be careful in understanding the results of timing
 tests. The way the database fixture works it caches the migration
 process -
 https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L206

 That actually means that the overhead of the db-migration sync is paid
 only once per testr worker (it's 1s on my fast workstation, might be 2s
 on gate nodes). The subsequence db setups for tests 2 - N in the worker
 only take about 0.020s on my workstation (scale appropriately). So
 removing all the unneeded db setup code is probably only going to save
 ~30s over an entire test run.

 Which doesn't mean it shouldn't be done, there are other safety reasons
 we shouldn't let every test randomly punch data into the db and still
 pass. But time savings should not be the primary motivator here, because
 it's actually not nearly as much gain as it looks like from running only
 a small number of tests.

 -Sean

 --
 Sean Dague
 http://dague.net

 /(See attached file: signature.asc)/



__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


I take that to mean doing something like this:

https://review.openstack.org/#/c/142655/

But I don't want to speak for Sean.  But that would be a lot of work for
some test classes, so I'd think it'd have to be phased, which is
happening in some places, e.g. danpb was doing some of that with the
libvirt unit test refactoring, and we've done some of that with the
compute manager tests.  test_compute_mgr is huge though so refactoring
and moving tests to NoDB will take time (test_neutronv2 also has some of
this similar issue, i.e. we want to get away from the DB and mega-mox in
setUp and move to using mock, so there is a separate test class in that
module which uses Mock and NoDB and new tests should live there unless
we can just update small parts of old tests).

So this is kind of like the mox-mock conversion, it's OK to update
existing test cases for bug fixes, but if you have new unit tests (new
test cases/classes), do them in mock (and do them w/o the DB).

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

Re: [openstack-dev] [nova] novaclient support for V2.1 micro versions

[Chen CH Ji]

No, AFAICT it's not supported because the v2.1 microversion and related bp
are still under implementation ,there is no change on novaclient now ...

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Day, Phil philip@hp.com
To: OpenStack Development Mailing List
(openstack-dev@lists.openstack.org)
openstack-dev@lists.openstack.org
Date:   01/23/2015 05:56 PM
Subject:[openstack-dev] [nova] novaclient support for V2.1 micro
versions



Hi Folks,

Is there any support yet in novaclient for requesting a specific
microversion ?   (looking at the final leg of extending clean-shutdown to
the API, and wondering how to test this in devstack via the novaclient)

Phil

 __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] local and gate pep8 check comparsion

[Chen CH Ji]

Thanks, I did the 'tox -r -e pep8' in my local env and it seems the problem
is gone ... thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann mrie...@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Date:   01/06/2015 05:29 PM
Subject:Re: [openstack-dev] [nova] local and gate pep8 check comparsion





On 1/6/2015 10:21 AM, Chen CH Ji wrote:
 I got following error in patch
 https://review.openstack.org/#/c/137009/ from Jenkins

 _2015-01-06 12:24:20.445_
 
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445
 |
 ./nova/compute/manager.py:5325:13: N331  Use LOG.warning due to
 compatibility with py3
 _2015-01-06 12:24:20.445_
 
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445
 |
 ./nova/compute/manager.py:5726:13: N331  Use LOG.warning due to
 compatibility with py3
 _2015-01-06 12:24:20.916_
 
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_916
 |
 ERROR: InvocationError:
 '/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

 but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my
 local test env, I am pretty sure I have the latest nova code so I think
 I should get same result ?

 Thanks a lot

 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 District, Beijing 100193, PRC


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Stale venv?  Try tox -r -e pep8.

--

Thanks,

Matt Riedemann


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] microversion and backward incompatible changes on v2.1

[Chen CH Ji]

Hi
https://review.openstack.org/#/c/144995/ introduced a
backward incompatible change with mirco version support
and I think it's the microversion's purpose to enable v2.1
(v3) API to make those changes

The question is whether we should make bp for each change
for the API change? should we make a simple bp or go through the nova-spec
process? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

[Chen CH Ji]

Based on nova-specs api-microversions.rst
we support following function definition format, but it violate the hacking
rule pep8 F811 because duplicate function definition
we should use #noqa for them , but considering microversion may live for
long time ,
keep adding #noqa may be a little bit ugly, can anyone suggest a good
solution for it ? thanks

   @api_version(min_version='2.1')
   def _version_specific_func(self, req, arg1):
  pass

   @api_version(min_version='2.5')
   def _version_specific_func(self, req, arg1):
  pass



Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] local and gate pep8 check comparsion

[Chen CH Ji]

I got following error in patch https://review.openstack.org/#/c/137009/
from Jenkins

2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5325:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5726:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.916 | ERROR: InvocationError:
'/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my local
test env, I am pretty sure I have the latest nova code so I think I should
get same result ?

Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Chen CH Ji]

Hi
  Sorry If I didn't understand clearly about it , looks to me
the hypervisor itself hosts the instances and it should have a IP with it
(like Linux host KVM instances, Linux is the hypervisor, the PC is the
host)
  while the host is physical node and only to be used by
'hypervisor' concept ,so I think maybe we don't need ip for the 'host' ?
thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Lingxian Kong anlin.k...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   12/31/2014 07:22 AM
Subject:Re: [openstack-dev] [Nova] should 'ip address' be retrived when
decribe host?



Thanks Kevin for your clarification, which further affirms my belief
that ip address should be included in the host info.

I will contact Jay Pipes on IRC, to see what can I help towards this
effort, soon after the New Year's Day in China. :)

2014-12-31 0:34 GMT+08:00 Kevin L. Mitchell kevin.mitch...@rackspace.com:
 On Tue, 2014-12-30 at 14:52 +0800, Lingxian Kong wrote:
 Just as what Jay Lau said, 'nova hypervisor-show hypervisor_id'
 indeed returns host ip address, and there are more other information
 included than 'nova host-describe hostname'. I feel a little
 confused about the 'host' and 'hypervisor', what's the difference
 between them? For cloud operator, maybe 'host' is more usefull and
 intuitive for management than 'hypervisor'. From the implementation
 perspective, both 'compute_nodes' and 'services' database tables are
 used for them. Should them be combined for more common use cases?

 Well, the host and the hypervisor are conceptually distinct objects.
 The hypervisor is, obviously, the thing on which all the VMs run.  The
 host, though, is the node running the corresponding nova-compute
 service, which may be separate from the hypervisor.  For instance, on
 Xen-based setups, the host runs in a VM on the hypervisor.  There has
 also been discussion of allowing one host to be responsible for multiple
 hypervisors, which would be useful for providers with large numbers of
 hypervisors.
 --
 Kevin L. Mitchell kevin.mitch...@rackspace.com
 Rackspace


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards!
---
Lingxian Kong

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Chen CH Ji]

ok, that make sense to me , thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Kevin L. Mitchell kevin.mitch...@rackspace.com
To: openstack-dev@lists.openstack.org
Date:   12/31/2014 09:37 PM
Subject:Re: [openstack-dev] [Nova] should 'ip address' be retrived when
decribe host?



On Wed, 2014-12-31 at 20:56 +0100, Chen CH Ji wrote:
   Sorry If I didn't understand clearly about it , looks to
 me the hypervisor itself hosts the instances and it should have a IP
 with it (like Linux host KVM instances, Linux is the hypervisor, the
 PC is the host)
   while the host is physical node and only to be used by
 'hypervisor' concept ,so I think maybe we don't need ip for the
 'host' ?  thanks a lot

The hypervisor hosts the VMs, yes, but the component that sits between
the hypervisor and the rest of nova―that is, nova-compute―does not
necessarily reside on the hypervisor.  It is the nova-compute node
(which may be either a VM or a physical host) that is referred to by the
nova term host.  For KVM, I believe the host is often the same as the
hypervisor, meaning that nova-compute runs directly on the hypervisor…
but this is not necessarily the case for all virt drivers.  For example,
the host for Xen-based installations is often a separate VM on the same
hypervisor, which would have its own distinct IP address.
--
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][resend with correct subject prefix] ask for usage of quota reserve

[Chen CH Ji]

I used to submit a patch and retrieve the reservation of quota, got a -2
because it can expire :)

so, I guess expire do no harm unless the uncommitted / unrollbacked
reservation may occupy the quota
and lead to side effect on upcoming actions...

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eli Qiao ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   12/22/2014 11:37 AM
Subject:Re: [openstack-dev] [nova][resend with correct subject prefix]
ask for usage of quota reserve




在 2014年12月18日 17:33, Chen CH Ji 写道:


  AFAIK, quota will expire in 24 hours

  cfg.IntOpt('reservation_expire',
                 default=86400,
                 help='Number of seconds until a reservation expires'),

  Best Regards!


hi Kevin,
but that is not reliable,  user/op can change the default value.
shall we just leave as the quota reservation there can do not
commit/rollback ?
I don't think there will be much more we can do.



  Kevin (Chen) Ji 纪 晨

  Engineer, zVM Development, CSTL
  Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
  Phone: +86-10-82454158
  Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
  District, Beijing 100193, PRC

  Inactive hide details for Eli Qiao(Li Yong
  Qiao)
  ---12/18/2014 04:34:32 PM---hi all, can anyone
  tell if we
  call quotas.reservEli Qiao(Li Yong Qiao) ---12/18/2014 04:34:32
  PM---hi all, can anyone tell if we call quotas.reserve() but never
  call

  From: Eli Qiao(Li Yong Qiao) ta...@linux.vnet.ibm.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Date: 12/18/2014 04:34 PM
  Subject: [openstack-dev] [nova][resend with correct subject prefix]
  ask for usage of quota reserve





  hi all,
  can anyone tell if we call quotas.reserve() but never call
  quotas.commit() or quotas.rollback().
  what will happen?

  for example:
1. when doing resize, we call quotas.reserve() to reservea a
delta quota.(new_flavor - old_flavor)
2. for some reasons, nova-compute crashed, and not chance to
call quotas.commit() or quotas.rollback() (called by
finish_resize in nova/compute/manager.py)
3. next time restart nova-compute server, is the delta quota
still reserved , or do we need any other operation on quotas?

  Thanks in advance
  -Eli.


  ps: this is related to patch : Handle RESIZE_PREP status when nova
  compute do init_instance(https://review.openstack.org/#/c/132827/)


  --
  Thanks Eli Qiao(qia...@cn.ibm.com)
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Thanks,
Eli (Li Yong) Qiao___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][resend with correct subject prefix] ask for usage of quota reserve

[Chen CH Ji]

AFAIK, quota will expire in 24 hours

cfg.IntOpt('reservation_expire',
   default=86400,
   help='Number of seconds until a reservation expires'),

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eli Qiao(Li Yong Qiao) ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   12/18/2014 04:34 PM
Subject:[openstack-dev] [nova][resend with correct subject prefix] ask
for usage of quota reserve



hi all,
can anyone tell if we call quotas.reserve() but never call quotas.commit()
or quotas.rollback().
what will happen?

for example:

   1.   when doing resize, we call quotas.reserve() to reservea a delta
  quota.(new_flavor - old_flavor)
   2.   for some reasons, nova-compute crashed, and not chance to call
  quotas.commit() or quotas.rollback() (called by finish_resize in
  nova/compute/manager.py)
   3.   next time restart nova-compute server, is the delta quota still
  reserved , or do we need any other operation on quotas?


Thanks in advance
-Eli.


ps: this is related to patch : Handle RESIZE_PREP status when nova compute
do init_instance(https://review.openstack.org/#/c/132827/)


--
Thanks Eli Qiao(qia...@cn.ibm.com)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] anyway to pep8 check on a specified file

[Chen CH Ji]

tox -e pep8 usually takes several minutes on my test server, actually I
only changes one file and I knew something might wrong there
anyway to only check that file? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] Using query string or request body to pass parameter

[Chen CH Ji]

Found something might be helpful for you
http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request



Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eli Qiao ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   12/08/2014 02:10 PM
Subject:Re: [openstack-dev] [api] Using query string or request body to
pass parameter




在 2014年12月08日 13:13, Alex Xu 写道:
  Hi,

  I have question about using query string or request body for REST
  API.
I wonder if we can use body in delete, currently , there isn't any case
used in v2/v3 api.

  This question found when I review this spec:
  
https://review.openstack.org/#/c/131633/6..7/specs/kilo/approved/judge-service-state-when-deleting.rst

  Think about use request body will have more benefit:
  1. Request body can be validated by json-schema
  2. json-schema can doc what can be accepted by the parameter

  Should we have guideline for this?


  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Thanks,
Eli (Li Yong) Qiao___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gerrit] Gerrit review problem

[Chen CH Ji]

+1, I also found this inconvenient point before ,thanks Jay for bring up :)

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Jay Lau jay.lau@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date:   12/01/2014 01:56 PM
Subject:[openstack-dev] [gerrit] Gerrit review problem




When I review a patch for OpenStack, after review finished, I want to check
more patches for this project and then after click the Project content
for this patch, it will **not** jump to all patches but project
description. I think it is not convenient for a reviewer if s/he wants to
review more patches for this project.

内嵌图片 1

内嵌图片 2

--
Thanks,

Jay___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova host-update gives error 'Virt driver does not implement host disabled status'

[Chen CH Ji]

are you using libvirt ? it's not implemented
,guess your bug are talking about other hypervisors?

the message was printed here:
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/contrib/hosts.py#n236

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Vineet Menon mvineetme...@gmail.com
To: openstack-dev openstack-dev@lists.openstack.org
Date:   11/26/2014 12:10 AM
Subject:[openstack-dev] [nova] nova host-update gives error 'Virt
driver does not implement host disabled status'



Hi,

I'm trying to reproduce the bug
https://bugs.launchpad.net/nova/+bug/1259535.
While trying to issue the command, nova host-update --status disable
machine1, an error is thrown saying,

  ERROR (HTTPNotImplemented): Virt driver does not implement host disabled
  status. (HTTP 501) (Request-ID: req-1f58feda-93af-42e0-b7b6-bcdd095f7d8c)


What is this error about?

Regards,
Vineet Menon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Do we need to add xml support for new API extensions on v2 API ?

[Chen CH Ji]

Hi
 I saw we are removing v2 XML support proposed several days
before

 For new api extensions, do we need to add it now and
remove it later or only support JSON ? Thanks

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev