Coverage increased (+0.01%) to 72.258% when pulling 4487beb on dklyle:region-create into e7fa81e on gophercloud:master.

I've come across an implementation question. In python-keystoneclient, an enabled parameter is used which defaults to True. https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/regions.py#L84 This value is important because https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/regions.py#L91 states that the region will not appear in the catalog unless this value is true. This value is not a column in the sql table, but instead is included in the extra column blob. The fun part is there seems to be no way to change the value of enabled or any of the contents of extra once the region is created. I'm think mimicking the default behavior of openstackclient and it's use of python-keystoneclient in setting the value by default. Would some magic of translating a CreateOpt of Enabled to a field in Extra be preferred or automatically populating enabled to true unless the user populates the Extra field Enabled to False?

I'm leaning to the latter and will propose an update to this patch doing that, but any feedback is welcome.

related keystone bug https://bugs.launchpad.net/keystone/+bug/1615076 over a year old.

Ew. This is a tricky one.

So to confirm: if we only look at the API/server-side, the region will be disabled unless enabled is explicitly passed in the body? keystoneclient is doing the user a favor and automatically setting this to true?

If so, I feel like the appropriate thing to do is not mimic keystoneclient. If enabled is not explicitly passed in the Extra field, the region will not be enabled. It sounds a little user-unfriendly but here's my reasoning: Gophercloud aims to adhere to the API, warts and all. Gophercloud is not meant to be a user-facing library, it's meant to be the basis of user-facing applications. Therefore, the application could present the user with an enabled field and then perform the correct building of Extra. Additionally, a function called CreateRegionLikeItShouldBeCreated in the gophercloud/utils repo could be added which has an explicit enabled field/parameter.

Also, just saw your comment re the bug. To consider this behavior a bug makes sense, IMO. I would imagine the correct fix for the bug would be to make enabled and explicit parameter. Once that happens, Gophercloud could add an Enabled field. Until then, I think we should proceed without any added intervention.

Let's just make sure this behavior is documented in doc.go.

I'm open to debate on this, though.

@jtopjian Your reasoning seems sound. Adding magic always seems like a poor idea. I'm currently trying to verify the linked comment in keystoneclient regarding the role of enabled. I can add better documentation in doc.go to instruct the app developer to add enabled: true to Extra.

Well now I feel foolish. I tested creating two regions one with enabled = true and one with enabled = false. Then I added an endpoint to both those regions. The endpoint in both regions is shown in the catalog. So it seems enabled may do nothing at all. Which lines up better with my inability to find the code that would filter out regions with enabled = false.

Given my last finding, I think this can be reviewed as is. But I'm unsure why the CI is failing.

Coverage increased (+0.01%) to 72.258% when pulling 7bcd396 on dklyle:region-create into e7fa81e on gophercloud:master.

@dklyle Travis is failing [at least] due to upstream updates to Go tooling. If you rebase on master after #591 is merged, the unit tests should be able to run.

Coverage increased (+0.01%) to 72.227% when pulling c457069 on dklyle:region-create into 754e57e on gophercloud:master.

thanks @jrperritt much better

Looks good!