I am working on a proposed approach for this, but the idea would be much like what Faraday does, allow most providers of http client services to be wrapped. This would remove the strong coupling that fog has to exconn (while still supporting it)

I have recently converted fog-core gem to debian's native deb format (to provide a consistent interface to users who need software written in ruby, like diaspora). We install libraries in /usr/lib/ruby/vendor_ruby/. An automatic installation program detected file conflicts between fog and fog-core https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744010 Can each gem have their files in their own directories?

For automatic discovery it would be helpful if Service-attributes could be exposed as required (read/write), optional (read/write) and read-only. Currently the services only expose a list of all attributes (Fog::AWS::Server.attributes) without the type of the individual attributes.

E.g. it would be nice if we had something like Fog::AWS::Server.recognizes, Fog::AWS::Server.requires, Fog::AWS::Server.readonly - akin to Fog::AWS.requires and Fog::AWS.recognizes.

(or, if there's already a way to determine the attribute-types through reflection, I'd appreciate a pointer)

Original issue by @m-o-e at fog/fog#1675

Yesterday's release wasn't tagged so not certain the exact code it went out with!

I'm working on implementing more rigorous tests for fog-google, and I was surprised to see that == isn't reimplemented in Fog::Model to compare identity or something similar. In particular, I would expect that:

> instance = Fog::Compute[:provider].servers.create(params)
...
> Fog::Compute[:provider].servers.all.include? instance

would return true, but because == is still comparing literal Ruby objects, it returns false.

/home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-core-1.26.0/lib/fog/core/bin/aws.rb:1:in <top (required)>': AWS is not a class (TypeError) 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-core-1.26.0/lib/fog/core/bin.rb:58:inrequire'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-core-1.26.0/lib/fog/core/bin.rb:58:in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-core-1.26.0/lib/fog/core.rb:30:inrequire'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-core-1.26.0/lib/fog/core.rb:30:in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-1.25.0/lib/fog.rb:7:inrequire'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/fog-1.25.0/lib/fog.rb:7:in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/kitchen-ec2-0.8.0/lib/kitchen/driver/ec2.rb:21:inrequire'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/kitchen-ec2-0.8.0/lib/kitchen/driver/ec2.rb:21:in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/driver.rb:40:inrequire'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/driver.rb:40:in for_plugin' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:124:innew_driver'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:130:in new_instance' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:73:inblock in build_instances'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:72:in map' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:72:inwith_index'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:72:in build_instances' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/config.rb:52:ininstances'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:64:in get_filtered_instances' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:85:inparse_subcommand'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/command/action.rb:37:in block in call' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/rubies/ruby-1.9.3-p547/lib/ruby/1.9.1/benchmark.rb:280:inmeasure'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/command/action.rb:36:in call' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/cli.rb:47:inperform'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/cli.rb:118:in block (2 levels) in <class:CLI>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/thor-0.19.1/lib/thor/command.rb:27:inrun'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/thor-0.19.1/lib/thor/invocation.rb:126:in invoke_command' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/cli.rb:233:ininvoke_task'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/thor-0.19.1/lib/thor.rb:359:in dispatch' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/thor-0.19.1/lib/thor/base.rb:440:instart'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/bin/kitchen:13:in block in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/lib/kitchen/errors.rb:81:inwith_friendly_errors'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/gems/test-kitchen-1.2.1/bin/kitchen:13:in <top (required)>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/bin/kitchen:23:inload'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/bin/kitchen:23:in <main>' 02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/bin/ruby_executable_hooks:15:ineval'
02-Dec-2014 15:45:21 from /home/bamboo.agent/.rvm/gems/ruby-1.9.3-p547/bin/ruby_executable_hooks:15:in `

fog-core has a DSL for describing attributes on models and mapping the data responses between API responses and those attributes.

I assume @geemus added this because nothing was around that did this or it seemed a simple problem at the time.

So with the goal of cutting down on code we have to rewrite tests for (as we move away from Shindo) and balancing the new dependencies between less code to maintain I had been thinking about using Virtus to replace the code in https://github.com/fog/fog-core/blob/master/lib/fog/core/attributes.rb (but keep confusing it with ROM).

However the fog DSL also covers mapping so:

attribute :state, :aliases => 'instanceState', :squash => 'name'

So state is set from...

{
  "instanceState" => {
    "name" => "available", ...
  }
}

Example from https://github.com/brightbox/fog/blob/master/lib/fog/aws/models/compute/server.rb#L47

I summoned @solnic on the other issue which was more about dependencies so created this for more of a general discussion.

Basically I'm assuming Virtus can help us if we can work around incompatibilities and/or combine ROM to map between the Hash version of an API response to a model?

I suspect the answer will be "yes, with work" but since I distracted him I thought I'd frame the idea better and see if it's worth me starting a proof of concept.

/cc @elight

Discussion moved from #2

Almost all gems include tests in gem file itself. It makes us take github tarballs for making debian package. It would be nice if if you can ship the tests along with gem.

At a glance I think a lot of the dependencies and dev dependencies are just requirements of providers/services (not of fog-core itself). So we should work to slim down/simplify that.

https://github.com/fog/fog-core/blob/master/lib/fog/core/provider.rb#L22 does not have the latest version of the interface that was just merged.

Changes in fog/fog#1712 mean we need to sync the code again.

Ooooo new repo!

In line with #1 we should remove the two parsing systems into their own gems, allowing fog to be dependent on them.

fog-xml (or similar) would then manage the nokogiri dependency and fog-json the multijson dependency.

From fog user perspective it shouldn't change but when providers break out into modules then they can just include the relevant one.

I think this is already possible, just the requires in lib/fog/core.rb need removing and relevant modules deleting for fog-core to function.

Hi

I'm trying to get my app working on Heroku and I'm recieving this error in the server logs around the credentials

2015-08-13T13:09:43.384364+00:00 heroku[web.1]: Starting process with command `bin/rails server -p 59829 -e production`
2015-08-13T13:09:48.324529+00:00 app[web.1]: => Rails 4.2.1 application starting in production on http://0.0.0.0:59829
2015-08-13T13:09:48.324531+00:00 app[web.1]: => Run `rails server -h` for more startup options
2015-08-13T13:09:48.324502+00:00 app[web.1]: => Booting Puma
2015-08-13T13:09:48.324532+00:00 app[web.1]: => Ctrl-C to shutdown server
2015-08-13T13:09:48.622540+00:00 app[web.1]: Exiting
2015-08-13T13:09:48.622587+00:00 app[web.1]: /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/core/credentials.rb:71:in `[]': no implicit conversion of Symbol into Integer (TypeError)
2015-08-13T13:09:48.622594+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/core/service.rb:122:in `fetch_credentials'
2015-08-13T13:09:48.622591+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/core/credentials.rb:71:in `credentials'
2015-08-13T13:09:48.622596+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-aws-0.1.1/lib/fog/aws/credential_fetcher.rb:29:in `fetch_credentials'
2015-08-13T13:09:48.622607+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/core/service.rb:266:in `handle_settings'
2015-08-13T13:09:48.622610+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/storage.rb:25:in `new'
2015-08-13T13:09:48.622609+00:00 app[web.1]:    from /app/vendor/bundle/ruby/2.2.0/gems/fog-core-1.29.0/lib/fog/core/service.rb:98:in `new'
2015-08-13T13:09:48.622612+00:00 app[web.1]:    from /app/config/initializers/fog.rb:1:in `<top (required)>'

I am setting Fogs credentials in config/intitializers/fog.rb

::FOG = Fog::Storage.new({
  :provider              =>'AWS',
  :aws_access_key_id     =>ENV['AWS_ACCESS_KEY_ID'],
  :aws_secret_access_key =>ENV['AWS_SECRET_ACCESS_KEY']
})

I'm at a bit of a loss was hoping somebody would be able to shed some light on my problem.

Thanks

In the openstack project, there is a folder for requests which has sub-folders for Identity, Compute, etc. Inside these service level folders, requests are stored as individual files. In many services, there are tons of requests, and they can get quite hard to slog thru to find what you need.

It would be nice to be able to organize these under subfolders, based on the operational area. For example:

requests
--> identity
----> tenant
------> get_tenant.rb
------> list_tenants.rb
.....
----> token
------> get_token
------> validate_token
......
----> user
------> get_user_by_id
------> get_user_by_name
.............

In the Openstack Identity service, I found multiple examples where there were 2-3 requests that were exactly the same. Call me anal retentive, but this isn't clean.

Before I suggest a change to address this, what sort of options are there for organizing requests? Given the way that the "request" method/macro works within the context of the service.rb class, I suspect there isn't a clean solution to this without touching fog-core, but wanted to ask.

We're using elastic-mapreduce which sadly declares a module AWS in the global namespace. And I suspect there are other tools that unfortunately do this too. It looks like fog-core 1.26 introduces an AWS class in the global namepace which will cause conflicts. This change caused some issues for us when fog-core 1.26 made it to rubygems.

Can namespace your AWS class instead of leaving at the global level?

@davehatton:

After upgrading from 1.25 to 1.27 the following error

undefined method `redisplay_progressbar' for Fog::Formatador:Class

is generated by fog-1.27.0/lib/fog/vcloud_director/models/compute/task.rb

The problem occurs when calling fog from the vcloud-tools gem when creating a new VM in a vcloud_director/Skyscape environment.

Downgrading to 1.25 resolves the issue.

Opened at fog/fog#3398

I am working on building a middleman static site to aws S3, and encountering the following error:
gems/fog-core-1.35.0/lib/fog/storage.rb:68:in get_content_type': uninitialized constant Fog::Storage::MIME (NameError)`

I've done a bit of tracing, and it looks to me like what's going on is:

mime/types is inaccessible in lib/fog/storage.rb:68 at least when called from fog-aws requests/storage/put_object.rb:43 (where Fog::Storage#parse_data is called), presumably because Fog::Storage#new does not actually run in this instance.

Perhaps the recent commit that moved requirement of mime/types or mime/types/columnar inside self#new is what created this bug.

Would love feedback as to the accuracy of this diagnosis, and what preferable fix is. Happy to submit a PR with preferred fix if needed. Thanks!

See fog/fog#2368 for further details

This seems to cause an issue when attempting to run tests with Fog.mock! set. When Time.now is evaluated, it is only ever evaluated in full second intervals. Take this code block for example

Fog::Mock.delay = 0

server.wait_for { ready? }
.....
class Mock
  def list_servers_detail(filters = {})
    response = Excon::Response.new
    servers = self.data[:servers].values
    for server in servers
      case server['status']
        when 'BUILD'
          if Time.now - self.data[:last_modified][:servers][server['id']] > Fog::Mock.delay * 2 [#1]
            server['status'] = 'ACTIVE'
          end
        end
      end

    response.status = [200, 203][rand(1)]
    response.body = { 'servers' => servers }
    response
  end
end

def list_servers_detail is invoked as part of the ready call in the server.wait_for block. Even with Fog::Mock.delay = 0 server.wait_for { ready? } will take a full second to finish. This is because Time.now - self.data[:last_modified][:servers][server['id']] will equal 0.0 until a full second has passed. We locally patched our tests to use Time instead of Fog::Time and our tests no longer took a performance hit on this line. Can Time.now be a float instead of an integer?

Regards,
Derek, @wschaefer, @ryantang

Can we get a new release of fog-core at v1.22.0 out please?

I'm bottlenecked by it and I believe @elight & co wanted a new fog release to address fog/fog#2835

It's been about a month since the last release anyway.

We currently have Travis notifications pointing to IRC:

notifications:
  email: false
  irc:
    channels:
      - "irc.freenode.org#ruby-fog"
    template:
    - "[#%{build_number}] %{message} %{build_url}"
    - "[#%{build_number}] %{commit} on %{branch} by %{author}"
    - "[#%{build_number}] %{compare_url}"
    on_success: always
    on_failure: always
    use_notice: false

With people now working in slack, it may make sense to push build notifications there as well.
It should be relatively simple to add:
http://docs.travis-ci.com/user/notifications/#Slack-notifications

/CC @plribeiro3000 as the slack org and fog-core owner, since I don't think I have access to generate API tokens.

@geemus We have fixed some issues and introduced all the features that i need to improve fog-xenserver code and tests (simple code, simple tests 😄).

When do you plan to make a new release? Is there something missing that i can help?

BTW, Thank you for all the support and time spent to help me out making this possible.

mime-types gem is required here https://github.com/fog/fog-core/blob/master/lib/fog/storage.rb#L11, but it's not added in the gemspec dependencies.
This is causing Travis failure for the gems which are using fog.

https://github.com/fog/fog/blob/master/.rubocop.yml was the style guide we agreed on for the main repo (based on the Github style guide).

That same version should be used for both and copied here.

So changing double quotes to single quotes are in fact going the wrong direction leaving inconsistent style between the two projects.

Fog::Core::Service#setup_requirements requires files using require [@model_path, collection].join('/')

It should be using File.join to use the system based path separator not assuming "/".

At least 3 cases there. Maybe others.

This issue was spurred by fog/fog#2939.

This is certainly not the first time, I have seen downstream developers expect to use string and symbols interchangeably. Doing a quick search through issues shows 33 issues have been submitted about this and something tells me there are a lot more that aren't being reported.

Should address this and if so how?

/cc: @geemus @tokengeek

I noticed fog-google builds started failing as I have just made a no-op change before release:
https://travis-ci.org/fog/fog-google

Builds failing on fog-core on:
Ruby - 1.8.7
Ruby - 1.9.2
Ruby - 1.9.3
ree
jruby

Looking at the dep graph, it's fog-core's dependency net-ssh, which just updated a couple of hours ago:
https://rubygems.org/gems/net-ssh/
3.0.1 - September 25, 2015 (177 KB)

I created a #161 to try and kick off the travis build and check if locking the version works adequately.

However, please, note that I'm not that familiar with core code, so please, check this first.

/CC @geemus @plribeiro3000

It's time!

Just an idea, but I'd love if we settled on a style guide for fog-core (and the other modules as we break them off). One that works: https://github.com/styleguide/ruby

Then we could set up something like https://github.com/markstory/lint-review to try and enforce some sort of style standard. Considering the size of the repo, this could be nice.

https://github.com/fog/fog-core/blob/master/lib/fog/core/logger.rb#L38

Some small percentage of s3 operations would fail because a call to Fog:Logger would raise Errno::EBADF. (I am pretty sure the call to log is because of the path_style warning.) Note that most operations would still be fine even if they did invoke the warning; the exception wouldn't be raised and I could see the log entry. I have no way to reproduce. It's very possible it has to do with us capturing stdout and the log file getting rotated?

To handle it I simply added:

[:debug, :warning, :deprecation].each { |level| ::Fog::Logger[level] = nil }

to our initialization code. However, I feel an exception from logging shouldn't fail a real operation like uploading an object.

If you are against rescuing Errno::EBADF here then I can understand. Just trying to help others down the road.

@geemus Can you assign this to me please?

Brightbox's CloudIp object can no longer be inspected because #map
is already defined to "port" them between servers.

>> service.cloud_ips
ArgumentError: wrong number of arguments (0 for 1)
        from /home/paul/.gem/ruby/2.2.1/gems/fog-brightbox-0.7.1/lib/fog/brightbox/models/compute/cloud_ip.rb:32:in `map'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:87:in `inspect_object'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:74:in `block in nested_objects_string'
        from /home/paul/.gem/ruby/2.2.1/gems/formatador-0.2.5/lib/formatador.rb:92:in `indent'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:43:in `indent'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:74:in `nested_objects_string'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:56:in `object_string'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:14:in `block in format'
        from /home/paul/.gem/ruby/2.2.1/gems/formatador-0.2.5/lib/formatador.rb:92:in `indent'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:43:in `indent'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:14:in `format'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/core/model.rb:24:in `inspect'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/formatador.rb:87:in `block in inspect_object'
        from /home/paul/.gem/ruby/2.2.1/gems/fog-core-1.29.0/lib/fog/core/collection.rb:19:in `map'

It seems when the code that is now Fog::Formatador was extracted from
CollectionString it became more general rather than just for collections.

So when trying to enumerate the collection of Cloud IPs, because map is assumed rather than each (which appears to be an implementation detail here https://github.com/fog/fog-core/blob/master/lib/fog/formatador.rb#L87) an error occurs due to the arity difference.

I plan to deprecate map in fog-brightbox however this is still a bug in Formatador.

• We should be using each to confirm if an Object is Enumerable

I'll try to fix it Monday unless anyone else wants to try.

Original report: fog/fog-brightbox#17

Hello,
Currently it seems this chunk of code isn't really tested, and I'm looking for pointers on how to go about testing it. For example, if I put raise "Foo!" in the Fog::Collection.inspect, all tests still pass. I started refactoring some of code collection.rb, but don't want to commit it without ensuring that it's all being tested.

@plribeiro3000 here's the issue I ran into that caused the back-and-forth in fog/fog-softlayer@454cfd21.

A picture being worth 1,000 words, let's do it like this:

Here's a short screencast where you can see what I ran into that made me track it down this far.
http://screencast.com/t/jZOY4K5l

I tracked it down a little bit on the table method as below pictures show. Specifically look at the difference in output of the call to Formatador.ancestors at the bottom of both.
Here's 1.25.0 http://cl.ly/image/3v3s2v0k1t3j (#table not broken)
Here's 1.27.3 http://cl.ly/image/0U1j2o3O3J1w (#table is broken)

Let me know if I can help.

/cc @geemus @tokengeek @michaeljb @fernandes

Seems to be related with this plugin.

$ vagrant up 

Bringing machine 'default' up with 'libvirt' provider...
/home/pablogc/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/formatador.rb:6:in `initialize': wrong number of arguments (0 for 1) (ArgumentError)
    from /home/pablogc/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `new'
    from /home/pablogc/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `inspect'
    from /home/pablogc/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `inspect'
    from /home/pablogc/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `to_s'
    from /home/pablogc/.vagrant.d/gems/gems/vagrant-libvirt-0.0.24/lib/vagrant-libvirt/action/set_name_of_domain.rb:17:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `block in run'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in `busy'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `run'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/call.rb:53:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /home/pablogc/.vagrant.d/gems/gems/vagrant-libvirt-0.0.24/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `block in run'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in `busy'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `run'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:214:in `action_raw'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:191:in `block in action'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/environment.rb:516:in `lock'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in `call'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in `action'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Hey, all.

I have an issue with ssh to my server with fog. I can ssh in terminal using password, but when I try to do it in script I get invitation to enter a password interactively ([email protected]'s password:):

server.username = "ubuntu"
server.password = "password"
server.ssh("pwd")
ubuntu@x.x.x.x's password:
=> [#<Fog::SSH::Result:0x007ff9bc943d98 @command="pwd", @status=0, @stderr="", @stdout="/home/ubuntu\r\n">]

Everything works after I enter password manually. I also got this text before:

Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress echoed text.

I tried to run it both with highline and ruby-termios, but it didn't help.

Some lines about my environment:

ruby 2.1.5p273
fog-core (1.30.0, 1.29.0)
ruby-termios (0.9.6)
net-ssh (2.9.2, 2.9.1)

Could you tell how can I run ssh commands without entering password?

Thank you,
Alex L.

I use the vagrant-libvirt plugin, which uses the Fog library. I get this error when I'm trying to launch a vm.

/home/kaushal/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/formatador.rb:6:in `initialize': wrong number of arguments (0 for 1) (ArgumentError)
        from /home/kaushal/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `new'
        from /home/kaushal/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `inspect'
        from /home/kaushal/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `inspect'
        from /home/kaushal/.vagrant.d/gems/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `to_s'
        from /home/kaushal/.vagrant.d/gems/gems/vagrant-libvirt-0.0.24/lib/vagrant-libvirt/action/set_name_of_domain.rb:17:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/builder.rb:116:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/runner.rb:66:in `block in run'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/util/busy.rb:19:in `busy'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/runner.rb:66:in `run'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/builtin/call.rb:53:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /home/kaushal/.vagrant.d/gems/gems/vagrant-libvirt-0.0.24/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/warden.rb:34:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/builder.rb:116:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/runner.rb:66:in `block in run'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/util/busy.rb:19:in `busy'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/action/runner.rb:66:in `run'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:212:in `action_raw'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:189:in `block in action'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/environment.rb:516:in `lock'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:176:in `call'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/machine.rb:176:in `action'
        from /opt/vagrant/embedded/gems/gems/vagrant-1.7.1/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

My environment:
ruby 2.2.0p0
vagrant 1.7.2
vagrant-libvirt 0.0.24
fog 1.27.0

I reported this as issue vagrant-libvirt/vagrant-libvirt#292 on vagrant-libvirt, but I was asked to open a new issue here.

I can reproduce the same with the following snippet of code,

require "fog"
lv = Fog::Compute.new({:provider => 'Libvirt'})
lv.servers.all.to_s

this leads to the same error,

/home/kaushal/.gem/ruby/2.2.0/gems/fog-core-1.27.3/lib/fog/formatador.rb:6:in `initialize': wrong number of arguments (0 for 1) (ArgumentError)
        from /home/kaushal/.gem/ruby/2.2.0/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `new'
        from /home/kaushal/.gem/ruby/2.2.0/gems/fog-core-1.27.3/lib/fog/core/model.rb:24:in `inspect'
        from /home/kaushal/.gem/ruby/2.2.0/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `inspect'
        from /home/kaushal/.gem/ruby/2.2.0/gems/fog-core-1.27.3/lib/fog/core/collection.rb:19:in `to_s'
        from test.rb:4:in `<main>'

I receive the following warnings when require Fog with Ruby 2.2.1:

vendor/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/fog-core-1.29.0/lib/fog/core/service.rb:166: warning: Comparable#== will no more rescue exceptions of #<=> in the next release.
vendor/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/fog-core-1.29.0/lib/fog/core/service.rb:166: warning: Return nil in #<=> if the comparison is inappropriate or avoid such comparison.

I am on Fog master, commit f16fae7b0b40af3212facbf317a76628e353fcc5

We need the compute.rb file in fog to properly require and Instantiate the Compute service based on a namespace of Fog::OpenStackCommon::Compute.

See fog/fog#1973 for more info.

I'm not sure how to describe this in technical terms, but somewhere between fog-core 1.27.2 and 1.27.3, output in the command line tool (and Pry and IRB) that used to look like this:

>> Fog::Compute::AWS.new.servers
  <Fog::Compute::AWS::Servers
    filters={}
    [
      <Fog::Compute::AWS::Server
        id="i-01234567",
        ami_launch_index=0,
        associate_public_ip=nil,
        availability_zone="us-east-1d",
...etc..

Started looking like this instead:

>> Fog::Compute::AWS.new.servers
  <Fog::Compute::AWS::Servers
  >
>> 

As far as I can tell nothing else about the functionality of the library seems to be affected.

When net-scp is not found, fog-core prompts to install net-ssh. This is misleading, and occurs even if net-ssh is in fact installed.

This is work in progress specification for adding core functionality to register a provider and its services within Fog::Core making the register available to third party applications.

This is an expansion of #16

Goals:

• fog references no providers in code only dependencies. For any provider that is required, they register themselves and are available through the current API.
• fog-provider can contain all the code for a provider.
• Applications can require fog and "new experimental provider" and NEP is available via current API
• To avoid clashes with existing code and modules, they will exist in Fog::Core
• Configuration/Credentials will vary per provider/service but their passing should be standardised in the registration calls.
• Configuration/Credentials should not depend on .fog since it should be usable programmatically from third party applications.
• Providers may offer different versions of a service that we either need to support or remove. Registering 2 compute versions verses a specific version for a provider.

This is arising from fog/fog-rackspace#10 where the need for this functionality meant quite a disruptive change of code occurred.

/cc @geemus @plribeiro3000 @mdarby

Hey guys,

I've seen fog-core has a Billing Module but none of the providers have support for billing stuff yet. Do you have any example how to implement?

I'm adding support on fog softlayer, but API is a little bit complex to add support like Compute or DNS, my ideia is add support for Account stuff under Account module and Billing stuff under Billing module trying to keep Fog standards.

Suggestions?

// cc @cphrmky

Hi

I think the latest upgrade of mime-types has broken all old versions of fog. I am still very new to ruby and gems but as far as I can tell this line pulls the latest version off mime-types which just got updated to require Ruby 2

spec.add_dependency("mime-types")

I have tried installing a specific version mime-types before installing fog but it seems still to install the latest mime-types.

Any idea how I can get around this?

Thanks

  Fog::Compute[:or2] | Collections | servers (or2)
    success
      #new({"image"=>"image-94d5", "shape"=>"XL", "keyName"=>"keypair-dc10"}) + succeeds
      #create({"image"=>"image-94d5", "shape"=>"XL", "keyName"=>"keypair-dc10"}) + succeeds
      #all + succeeds
      #get(instance-302a) + succeeds
      Enumerable
        #all - succeeds
          expected => true
          returned => false

1. Method collection.all testing twice.
2. collection_tests tries to pass block to method all which actually doesn't accept blocks.

How it designed? Should I implement possibility to pass block to method "all" or this is really bug?

The factories for services appear to have the same problem based on a case statement around some providers.

So when Fog::Compute[:provider] or Fog::Compute.new(:provider => "provider") is called in almost all cases we require fog/provider/service then return a new instance of Fog::Provider::Service

I'm pretty sure that we can scrap most of this stuff.

• Some providers are just there but have no special behaviour.
• new_servers is just a wrapper around bare_metal_cloud and can probably go.
• Rackspace and HP use the factory to switch on version. I think this can probably be pushed down to a factory for each provider. Fog::Compute[:hp] => Fog::HP::Compute.new(:version => "v1") => Fog::HP::ComputeV1.new
• Anyone missing from Fog.providers can be added.
• Might be some cases where symbol and class name are awkward to constantize vclouddirector => VcloudDirector

The behaviour is so similar / copy pasted that I think we can eliminate most of this.

We could even add something and enumerate over all providers asking if they recognise the symbol and use that.

Fog::Brightbox.recognise_provider?(:new_servers) # => false
Fog::BareMetalCloud.recognise_provider?(:new_servers) # => true
Fog::VcloudDirector.recognise_provider?(:vclouddirector) # => true

module Fog
  def self.new(options)
    provider_key = get_provider_from(options)
    provider_server = Fog.providers.detect { |prov| prov.recognise_provider?(provider_key)
   require "fog/{provider_service.name}/service"
   Fog::{Provider}.new(remaining_options...)
  end
end

Basically we don't want anything in core that doesn't need to be there or needs updating when a new provider is added.

Examples:

https://github.com/fog/fog-core/blob/master/lib/fog/compute.rb#L13-L62
https://github.com/fog/fog-core/blob/master/lib/fog/storage.rb#L10-L27

This issue was moved from fog/fog#2910.

Take a look at the original issue for further details.

cc/ @geemus Feel free to add more context here if you think we need. I'm not totally into it yet.

We need the storage.rb file in fog to properly require and Instantiate the Storage service based on a namespace of Fog::OpenStackCommon::Storage.

I did some refactor at fog-xenserver and i think that some of the methods i created can be migrated to here to improve another providers. One piece of code which maked some extra methods possible is this one:

module Fog
  class Model
    def self.provider_class(provider_class = nil)
      return @provider_class if provider_class.nil?
      @provider_class = provider_class.to_s
    end

    def provider_class
      self.class.provider_class
    end
  end
end

I dont know in other providers but in XenServer, each request is mapped to a class in its core as represented in citrix.com. To make a request using fog is necessary to inform this class in the request as a param. With the code above i can inform this param based on the class instantiated and implement methods like:

module Fog
  class Model
    def set_attribute(name, *val)
      service.set_attribute(provider_class, identity, name, *val)
    end
  end
end

Also, The Fog::Collection has a method model to identify which model it represents, but the model doesn't have something similar, so i think we can implement this another piece of code:

module Fog
  class Model
    def self.collection_name(collection_name = nil)
      return @collection_name if collection_name.nil?
      @collection_name = collection_name
    end

    def collection
      service.send(self.class.collection_name)
    end
  end
end

With this methods it would be easier to create methods that depend on methods inplemented in collections.

What do you think of this @geemus . Does it help? Need some changes? Of it can break some provider?