in: :sequence not working when used with capistrano roles

[neovatar]

Not sure if I am doing this right and if it is capistrano or ssh kit related:

 on (roles :app), in: :sequence do |host|

does execute on all servers in parallel, while

 on %w{appserver-1, appserver-2, appserver-3}, in: :sequence do |host|

does execute sequentially.

Not sure if I am doing something wrong here...

[leehambley]

Can you try:

on roles(:app).to_a, in: :sequence do |host|

See Set#to_a.

I wonder if that could be it?

[neovatar]

Thanks @leehambley, using:

on roles(:app).to_a, in: :sequence do |host|

actually works.

I can use it this way, but its counterintuitive. Do you think this can be changed, so that:

 role :demo, %w{example.com example.org example.net}
 task :uptime do |host|
   on roles(:demo), in: :parallel do
     uptime = capture(:uptime)
     puts "#{host.hostname} reports: #{uptime}"
   end
 end

and

 role :demo, %w{example.com example.org example.net}
 task :uptime do |host|
   on roles(:demo), in: :sequence do
     uptime = capture(:uptime)
     puts "#{host.hostname} reports: #{uptime}"
   end
 end

both work the same way?

[leehambley]

Definitely that's a bug. It must have something to do with how #each is working on a Set vs. an Array here

I'm not sure where best to fix it, actually. I know that Capistrano's roles() and release_roles() etc, use Sets in preference to arrays (precisely because usually their order is unimportant). Perhaps we should revisit that and make the order deterministic.

I know it sucks, but if you can work around it for the time being, please do. I'm leaving to go on vacation tomorrow, and won't have time to fix this for a while.

@seenmyfate I know you're busy mate, but any thoughts on that one way or another. I always liked Sets, and I believe it was my idea originally, but perhaps if people give us an array, we should keep it. Seem to recall wanting to take away the #first crutch that people were relying on rather than specifying a primary: true host property, but I didn't foresee this side effect.

[neovatar]

@leehambley There is no rush in fixing this, I can live with the workaround for now! Thanks for the help!

[kostecky]

Just ran in to this bug with Capistrano 3.2.0. The workaround fixes it, but in: :sequence is essentially useless without it based on the documentation.

[leehambley]

but in: :sequence is essentially useless without it based on the documentation.

Sorry, I'm not understanding what you mean, could you rephrase that?

[leehambley]

Reading up I see that I asked @seenmyfate for some input, he's a busy man and just a day or two ago started a vacation, I don't expect to hear back from him, but perhaps someone else could pick up the baton and find out if Set vs. Array each is the problem?

@seenmyfate I know you're busy mate, but any thoughts on that one way or another. I always liked Sets, and I believe it was my idea originally, but perhaps if people give us an array, we should keep it. Seem to recall wanting to take away the #first crutch that people were relying on rather than specifying a primary: true host property, but I didn't foresee this side effect.

[kostecky]

@leehambley I just meant to say that in: :sequence is documented as a working feature, however, without coming across this issue, it doesn't work out of the box. A pretty run-of-the-mill bug 😄

I consider this a pretty fundamental feature of Capistrano. I think folks may get confused trying to get this to work, so I was thinking that considering the amount of time that's passed since it was noticed, updating the docs may be a quick win?

[mattbrictson]

I can't reproduce this in sshkit@1.7.1, capistrano@3.4.0. Here's my task (tested using 3 servers):

task :test_seq do
  on roles(:all), :in => :sequence do |host|
    uptime = capture(:uptime)
    puts "#{host.hostname} reports: #{uptime}"
  end
end

The three uptime commands were executed in sequence, as expected.

The only thing I can think of is that perhaps you mistyped :in, e.g. as :In or "in", in which case SSHKit would ignore it and default to :parallel.

[leehambley]

The only thing I can think of is that perhaps you mistyped :in, e.g. as :In or "in", in which case SSHKit would ignore it and default to :parallel.

I also wonder if without the parenthesis around roles(…) the Ruby parser is parsing that as roles(:foo, in: :parallel) or something?

[mattbrictson]

I also wonder if without the parenthesis around roles(…) the Ruby parser is parsing that as roles(:foo, in: :parallel) or something?

I thought so too, but I tried many variations of spacing and parentheses and couldn't reproduce. When Ruby parses it as roles(:foo, in: :parallel), it just finds zero hosts and doesn't run the block at all.

[leehambley]

Alright, so I'll re-close the issue, thanks for the investigative work Matt :)

[kostecky]

@leehambley :in => :sequence works! I was originally using the syntax you highlighted in the second comment of this issue (The first response you gave). I originally got it from the sshkit documentation: https://github.com/capistrano/sshkit#how-might-it-work

Thanks for looking in to this!