[all][interop] Please suggest capabilities to deprecate-remove and add to the OpenStack Powered Programs

Sean Mooney smooney at redhat.com
Mon May 25 16:43:19 UTC 2020


On Mon, 2020-05-25 at 10:27 -0500, Ghanshyam Mann wrote:
>  ---- On Sat, 23 May 2020 10:36:08 -0500 prakash RAMCHANDRAN <pramchan at yahoo.com> wrote ----
>  > Already,
>  > Please note Ghanshtam Maan had submitted a patch for Cinder v2 deprication  and removal and  we have merged it for
> Cinder under 
>  > https://review.opendev.org/#/c/728564/2/next.json
>  > 
>  > PTLs or core reviewers or anyone with API expertise  can review that for reference like above for compute & storage
> based on test failures available in refstack for 2020.06
>  > However this message is for community to work on main trunk as required by governance.
>  > 
> https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=2020.06.json;h=7bc62929e5576519196dc4a2ea2de0627ab319ca;hb=HEAD
> 
> Hi Prakash,
> 
> For, compute guidelines, most of the new capabilities are done with API change( or new API) with microversion. As you
> know, interop does not
> have the API version based capabilities yet so I will say to continue with the current compute guidelines. and
> continue the discussion on adding
> the microversion capabilities. We have most of the microversion test covered in Tempest but I am sure it's not 100% as
> per the scope of Tempest.
> But adding the interop required tests will not take much time.

one thing that does feel odd to me regarding the current defintion is that the current compute gudieline require some
optional compute features. specificly i think it requires resize and some other ops which prohibits ironic and some
contaner driver from being considers acceptable for openstack powered compute.

granted there are like 3 mandatory features
https://docs.openstack.org/nova/latest/user/support-matrix.html

so i think we shoudl actully reconsider this in nova internally too
for example i think reboot probably could be made mandatory at this point since all
in tree driver support it and we require both stop and start instance which when done back to back is a reboot.
https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_reboot

there are no other feature on the support matrix that is actually supported by everything but is not mandatory
but rebuild is close https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_rebuild
rebuild is basically a delete followed by spawnign a new instnace using the same port and volumes but a new
root disk image so so it should be genericly supportable.


looking at the list specfically i think the following should be remvoed from required and moved to advisory

compute-servers-resize (not required to be a vlaid virt driver) (prevent ironic form qualifying)
https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_resize

compute-servers-rebuild (not required to be a vlaid virt driver) (should be trivial to add but prevent powervm and zvm
form qualifiing)
https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_rebuild

compute-volume-attach (not requried to be a valid virt driver) (prevents ironic zvm and some container driver form
qulifying)
https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_attach_volume
this is currently being verifed wtih test_attach_detach_volume
so the name is also missleading.

strictly speaking all of the volume capablites 

  "volumes-list-api-versions",
 152           "volumes-v3-create-delete",
 153           "volumes-v3-snapshot-create-delete",
 154           "volumes-v3-get",
 155           "volumes-v3-list",
 156           "volumes-v3-update",
 157           "volumes-v3-copy-image-to-volume",
 158           "volumes-v3-clone",
 159           "volumes-v3-availability-zones",
 160           "volumes-v3-extensions",
 161           "volumes-v3-metadata",
 162           "volumes-v3-readonly",
 163           "volumes-v3-upload"

should proably also be advisory as cinder is not really require to have a minimal compute cloud.
for example a ci cloud.

a minimal compute cloud is nova, placement, neutron, keystone and glance.
tenant provisiond volume storage then object storage are certainly the next most important feature to add after a basic
compute cloud to round out its capablites but neither shoudl be required for the minium defintion of os_powered_compute.


compute-quotas-get is not deprecated yet but assuming os-limtes is addtopted in Victoria it likely will be this cycle.

compute-servers-invalid 
having a test to validate invalid request makes sense but im not sure we should be useing invalid ipv6 to assert that
behavior. e.g. we shoudl not fail this on a ipv4 only cloud. so perhapse the test shoudl be chagned for this
requirement. also the description is incorrect it is not a basic ops its a negitive test.
   "description": "Basic server operations in the Compute API",


by the way i might not be using advisor correctly as its not really defiend in that git page but i am using it to mean
recommended but not mandatory in the context above. so each advisory item would be "you should provide X" not you "must
provide X" were as required it the later.


> 
> -gmann
> 
>  > We will have patches coming week.
>  > ThanksPrakash
>  > 
>  > Sent from Yahoo Mail on Android 
>  >    On Fri, May 22, 2020 at 11:38 AM, Arkady.Kanevsky at dell.com<Arkady.Kanevsky at dell.com> wrote:   
>  > Prakash,
>  >  Why not submit a patch for of guidelines for compute, storage, and openstack for review?
>  >  It will show the diffs against previous version.
>  >  Thanks,
>  >    
>  >  From: prakash RAMCHANDRAN <pramchan at yahoo.com> 
>  > Sent: Friday, May 22, 2020 12:56 PM
>  > To: openstack-discuss at lists.openstack.org
>  > Subject: [all][interop] Please suggest capabilities to deprecate-remove and add to the OpenStack Powered Programs
>  >    
>  >  [EXTERNAL EMAIL] 
>  >  Hi all,
>  >    
>  >  Please help the Interop WG to review and finalize the draft version for the next interop guidelines.
>  >    
>  >  
> https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=2020.06.json;h=7bc62929e5576519196dc4a2ea2de0627ab319ca;hb=HEAD
>  >    
>  >  Link for the DNS add-on: 
> https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=add-ons/dns.2020.06.json;h=848e6d800f75e1f3aed8ba19263c3d1f86f4dde6;hb=HEAD
>  
>  >    
>  >    
>  >  Link for the Heat add-on: 
> https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=add-ons/orchestration.2020.06.json;h=6362abbac5756aaec24e25e5a0803f31497360f3;hb=HEAD
>  
>  >    
>  >    
>  >    
>  >  This guidelines is intended to cover "Stein" , "Train", "Ussuri" and "Victoria" releases of OpenStack.
>  >    
>  >  We request that PTLs or Core team members please confirm any updates you may want to include or exclude in link
> above.
>  >    
>  >  The Projects currently covered under OpenStack  Powered Programs include "Keystone", "Glance", "Nova", "Neutron",
> "Cinder", "Swift" and add-on programs "Designate", "Heat".
>  >    
>  >    
>  >  A more human-readable view of the capabilities can be found in RefStack: 
> https://refstack.openstack.org/#/guidelines
>  >    
>  >    
>  >  We would like have feedback by next Interop call on Friday. - Can attend 10 AM PDT  call refer etherpad - 
> https://etherpad.opendev.org/p/interop
>  >    
>  >    
>  >  If you have any additional topics to discuss at PTG please add them to 
> https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020
>  >    
>  >  The conference Bridge will be assigned once we know the number of participants. Please add your names/topics to
> ether pad interop ptg planning. 
>  >    
>  >    
>  >  Optionally reply to this  email with your inputs/patches.
>  >    
>  >   Please  Register to  attend the Interop WG slot scheduled for Virtual PTG on June 1 6-8 AM PDT /  9-11 AM EST /
> 14-16 UTC / 9-11 PM BJT
>  >  https://www.openstack.org/ptg/
>  >    
>  >    
>  >  Thanks
>  >  for Interop WG
>  >  Chair - Prakash Ramchandran
>  >  Vice Chair - Mark Voelker
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
>  >    
> 




More information about the openstack-discuss mailing list