Thanks to everyone that attended today's last minute bonus meeting. I am very glad to see the community getting more and more engaged in the DefCore process. We had some discussions about current tests and current process, and Mark Voelker has done excellent job documenting some of the discussions and decisions on PR bellow.
It was pointed out that 2015.04 covers Havana, Icehouse, and Juno , but the import task code didn't land until Icehouse. Thus, in Havana there's no way to create images without using the create API.However, it was also pointed out that the test's intent is to test listing an image, and creating images happens to be part of the setup for the test. The test could conceivably be set up differently so that it only tests the ability to list images, but it's a tricky proposition. E.g. if you have it list tests first, you also need to tell it exactly what images to expect (e.g. it should fail if it sees images in the list that don't exist or doesn't see images that do exist).It can also be argued that many folks expected the image create API to be "core" and that tests should be able to rely on a "core" API. However, no explicit test of that API exists in DefCore today and I'm not seeing any evidence that this API was ever deliberately meant to be tested. IMHO this seems like an oversight (remember that DefCore is essentially in it's infancy here and there are probably a lot of other things that need to be added yet as well) and I would be inclined to support a patch adding a test for it to DefCore, but none does exist today. Personally, I'd like to hear from the Glance PTL/cores about this since they allowed the (apparently broken? For several releases?) import task workflow in and therefore created an alternative to the create API (the argument was also made that it's difficult to discover that the create image API has been disallowed/disabled/blocked which puts end users in a place where they have to try, fail, and then try the import task route....which is also what Tempest would probably have to do for tests like this).Lastly, several of us discussed this afternoon that while this is very likely something we want to revisit for the next iteration of DefCore (ETA: this fall), we're inclined to be leniant for now given that DefCore is sort of in "catch-up" mode (we've had a couple of approved specs of the past months in order to get several releases covered). Once 2015.05 is done, we'll have Kilo covered and therefore the next iteration of DefCore will have a substantially longer feedback period for discussions like this to happen (refer to  for a timeline of what this will look like). In the interim most of us are inclined to be more inclusive of real-world situations so that we as a community can discuss controversial items like this.
Additionally, Mark has created a hacking HACKING.rst file for the DefCore repository which provides rules for incoming changes in order to make contributor's lives easier. Please review the patch: https://review.openstack.org/#/c/181489/
Etherpad for the bonus meeting: https://etherpad.openstack.org/p/DefCoreScale.15A
Please let us know if you have any questions or feedback!
Defcore-committee mailing list