Calendar synchronisation

[rmascarenhas]

This introduces the changes that we have been talking about and started as a discussion on #100

Summary

• This introduces a new event that implementations might decide to implement or not: "calendar.SupplierName". The skeleton should be similar to the previous Workers::Synchronisation (now Workers::PropertySynchronisation)

module Workers::Suppliers
  class WayToStay::Calendar
    def initialize(host)
      @host = host
      @sync = Workers::CalendarSynchronisation.new(host)
    end

    def perform
      sync.start("id1") do
        calendar = Roomorama::Calendar.new("id1")
        entry = Roomorama::Calendar::Entry.new(
          date: "2016-02-12"
          available: true,
          nightly_rate: 100
        )
        calendar.add(entry)
      end
    end
  end
end

Concierge::Announcer.on("calendar.WayToStay") do |host|
  Workers::Suppliers::WayToStay::Calendar.new(host).perform
end

Dynamic sections above were ommited for simplicity.

• Introduction of the BackgroundWorker entity, which can be of type metadata (existing workers) or calendar (new workers). The schema for workers is defined per supplier on config/suppliers.yml, but the association happens on the host level. This means that for now we can stick all hosts to the same frequency for property metadata/availabilities synchronising, but in the future, we should be able to have customised frenquencies for different hosts of the same supplier.

Here's how AtLeisure is currently defined:

AtLeisure:
  workers:
    metadata:
      every: "1d"
    availabilities:
      every: "5h"

This means that all hosts from AtLeisure will be triggered:

• every day for the metadata worker
• every 5h for the calendar worker

For WayToStay, since it operates on a diff API that includes availabilities, we might want to skip the availabilities section and have only metadata (so the process would use both Workers::PropertySynchronisation and Workers::CalendarSynchronisation.) But that is to be decided on a per supplier basis.

• The update_calendar was removed. The publish API call on Roomorama does not accept availabilities on that endpoint anymore, and instead, availabilities are uploaded in bulk via the update_calendar API call, used by CalendarSynchronisation. That is the current way to synchronise calendars

Misc

• Highly experimental work, untested. We will see how it goes and fix rough edges as implementations are tested
• @Traf333 please review the AtLeisure entry on config/suppliers.yml and see if the random defaults I assumed there make sense
• @keang let me know what you think.
• @sharipov-ru this will also change your implementation. If anything, event names changed and update_calendar is no longer available
• @kkolotyuk the above also applies to you I guess!
• @ralavay I will need you to change Concierge's deployment recipe. bundle exec rake hosts:update_worker_definitions will have to be run on every deployment after the existing suppliers:load rake task.

👀

[ralavay]

@rmascarenhas updated the new task on staging

[keang]

Looks good 👍

[keang]

So this works on top of a new bulk availability endpoint from Roomorama right? is there a corresponding PR for that project?

[rmascarenhas]

Yes @keang. https://github.com/roomorama/roomorama/pull/3595

[keang]

I think you forgot a
calendar.add(entry)

[rmascarenhas]

Also, for @Traf333: I think you were working on something to automate host creation on concierge/roomorama? I created a Concierge::Flows::HostCreation class that could be invoked in the future in some UI on concierge-web. If we are to automate anything, we could add as steps of that flow too. Just to let you know! 👍

[kkolotyuk]

Got it! Looks good!

[Traf333]

👀

[Traf333]

It's a good PR. Additional thanks for HostCreation flow, it will be useful for future automatisation.

Just to clarify. As I understood now instead of Host#next_run_at we are going to use BackgroundWorker, is it correct?

Let's merge it. 👍

[rmascarenhas]

@Traf333 yes, you are right. Host#next_run_at was removed in favour of the columns on BackgroundWorker. Reasons:

• next_run_at is a column that doesn't feel right at a hosts table to begin with. It's not data about the host itself, but internal data on concierge worker's bookkeeping
• We can then have different kinds of workers without clustering the hosts table with one timestamp for each. Instead, we have different records on background_workers for that host, with independent execution frequencies.

Thanks everyone!