"glance image-create" creates an empty image with no additional args

[Lorin Hochstein]

Running "glance image-create" with no additional arguments creates an empty image.

$ glance image-create
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | None |
| container_format | None |
| created_at | 2013-02-27T15:29:05 |
| deleted | False |
| deleted_at | None |
| disk_format | None |
| id | e83d145a-9bf5-4887-b986-b0b38cb2b8e1 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | None |
| owner | c2d6791a209243c6800c1fe89dbf5ce6 |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2013-02-27T15:29:05 |
+------------------+--------------------------------------+

I found this behavior unexpected. I recommend that instead it should generate something like the following error message:

usage: glance [--version] [-d] [-v] [-k] [--cert-file CERT_FILE]
...
error: <some meaningful error message here>
Try 'glance help image-create' for more information.

Version: 0.8.0 (installed from PyPi).

[Brian Waldon (bcwaldon)]

So the problem is that 'glance image-create' creates a valid image record that can be updated further. None of the values are actually required on creation. Are you suggesting that we require at least one attribute be passed in an image-create call? What about the people who depend on this behavior to create a blank image record to use later?

[Lorin Hochstein (lorinh)]

I'm not sure what the best way to approach this is. Certainly, requiring at least one attribute be passed (e.g., image name) would be one way around the problem.

Is it common for people to create blank nameless images that they use later? I have no sense about how many existing users it would bite if the name becomes required. But I would wager that many more users will accidentally create new images than users will be affected by the change.

Maybe we should take it to the mailing list to get a sense of whether anybody depends on the existing behavior?

[Robert Collins (lifeless)]

I think taking it to the list is a good idea. I'm marking this non-incomplete because the thing is reproducible (to LP, incomplete means 'submitter please answer the triager/developers questions'

[Wlodzimierz Borkowski (borqosky)]

I've checked it whith dashboard create image functionality, and it looks like incosistent in call.
So in dashboard there is at least, image name required.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/127742

[Wlodzimierz Borkowski (borqosky)]

tests failed because glance image-create is invoked with --name param.
There is a function in devstack disk_image_create_upload, which could be cause (line 122) in lib/dip

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/128592

[OpenStack Infra (hudson-openstack)]

Change abandoned by Wlodzimierz Borkowski (<email address hidden>) on branch: master
Review: https://review.openstack.org/127742

[Erno Kuvaja (jokke)]

I do not see anything wrong with the behaviour here. The help text is available via glance help image-create and creating empty image as placeholder is fully legit use case, name not being needed even for the fully functional image.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Wlodzimierz Borkowski (<email address hidden>) on branch: master
Review: https://review.openstack.org/128592

[Ian Cordasco (icordasc)]

> I've checked it whith dashboard create image functionality, and it looks like incosistent in call.
> So in dashboard there is at least, image name required.

So the openstack-dashboard can impose whatever constraints it desires to if they feel it benefits their project and the experience of the user overall. Their design decisions should not affect our design decisions. It's good to know they do this, but I disagree that their behaviour is an indication of a bug in glanceclient.

That said, this is a pattern that's used frequently. I agree with Erno that this is intentional and I'm not sure there's a good way to fix this that won't break existing patterns or expectations. Further, any automation around this will break if we suddenly require a parameter here and they're not passing one (because they shouldn't have to).

[Abel Lopez (al592b)]

Can't we just have the client parse arguments first, and fail out with a usage if it's not complete?