Bluemix object storage fixes

[gekola]

• Fix 500 due to port presence in Host header for bluemix object storage
• Recognize userid as argument

This is #1 with making port omitting optional.

[seanhandley]

Thanks @gekola. I'm ok with this, though I think you should probably pass that option through to the Keystone v2 method as well.

[gekola]

Thanks for the feedback, @seanhandley. I updated the PR to also apply port omitting option to the Keystone v2 method.

[seanhandley]

Ok great. And what's the motivation for putting the userid attribute into the storage class?

[seanhandley]

I ask because I'm not sure why it isn't present in the compute, image, network etc

[gekola]

@seanhandley while working with Carrierwave and Paperclip there is a warning [fog][WARNING] Unrecognized arguments: openstack_userid on each file uploading/downloading. Adding userid to parameters recognized by storage removes this warning (I figured since domain and username are there it is OK to put userid there also). I am new to fog, so I am not sure why it is not there for compute, image and so on. But I guess it was not added to them when Keystone v3 support was added while it should have been.

[seanhandley]

Ok thanks @gekola - Thumbs up from me 👍

We'll maybe look at re-architecting the gem a little so the parameters aren't duplicated between OpenStack projects.

[Ladas]

indentation nit, we should have rubocop soon, could you indent all = the same? Applies to all below

@seanhandley hm, what are we missing to get rubocop running for each PR?

[Ladas]

@gekola just last comments, then I am ready to merge :-)

[seanhandley]

@Ladas You need to run rubocop from Travis on each build afaik but I've never done it myself (I use a custom integration with RubyCritic and Slack for my commercial projects).

From the looks, you can reference rubocop in the .travis.yml and then pass it arguments to configure how strict you need it to be.

[gekola]

@seanhandley @Ladas you can see an example of using rubocop with travis in rubocop repository. I do not think adding rubocop check to CI it is a good idea at this point as there are too many offenses in the code, so the build would always fail.

[Ladas]

@gekola awesome, thank you :-)

@gekola @seanhandley btw. for ManageIQ the rubocop runs only on the lines changed by the PR, so we can incrementally make it better. I will ask the guys how to setup that.