this is not a bug. this is the defined behavior. I think you are misinterpreting something you might have read.
When you "sync to all" it is propagated to ALL farms that had the role you synchronized. The way to achieve what you describe is to create a role from an instance (from the main menu - there is such an option). This will create a role based on the state of an existing instance and will not restart any other servers based on that. On Wed, Apr 15, 2009 at 8:09 PM, kevbaker <[email protected]> wrote: > > Hello Scalr support, > > We experienced some very strange behavior last night when using the > sync to all feature. > > This is what happened: > - We have two farms 925 and 1606 > - We have two custom roles app1, www1 > - Both farms use these roles > - We made some configuration changes to app1/www1 in farm 1606 > - We "synced to all" app1 and www1 roles from farm 1606 to app2 and > www2 in farm 1606, they were renamed > - Based on the fact that they were renamed we expected them to only be > updated in the 1606 farm > - instead the following happened: > - everything worked as expected in farm 1606 > - app2 and www2 were both deployed to the other farm 925? > - app1 and www1 were both still in farm 925, not terminated? > - farm 925 front end was switched to www2? > - www2 was updated with all app1 and app2 application servers > > Because of the above, all incoming traffic to www2 role was round > robining to both kinds of app servers. Some worked properly since they > were routed to app1 others failed since the updates to the role for > app2 were not valid for the 925 farm. > > The expected behavior based on scalr documentation is that if I rename > a role before syncing to all, that only the roles in that farm would > be updated. Instead all the farms with that role were updated and the > previous roles in other farms were not terminated. > > For more detail here are the actual names of the roles: > app1 = app-beachfront > app2 = smi-beachfront-app-stress > www1 = www-juice > www2 = smi-beachfront-www-stress > > This is a pretty big deal. We were able to back out of it okay, with > some fixes and DNS changes... but in a production environment this > would have cause a couple hours of down time ;( > > Can someone at scalr please investigate, explain what happened and > hopefully fix the bug? Let me know if you have any questions, I'd be > happy to help out in any way. > > > Thanks > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
