Postgres DB init fails in Azure

I’m trying to get Boundary set up in Azure using Azure PostgreSQL and an Azure VM. On the controller I am running:

/usr/bin/boundary database init -skip-auth-method-creation -skip-host-resources-creation -skip-scopes-creation -skip-target-creation -config 
/etc/boundary-controller.hcl

And I get the error:

Error running database migrations: schema.(Manager).RollForward: schema.(Manager).runMigrations: postgres.(Postgres).Run: migration failed, on line 0: 
-- This series of expressions fixes the primary key on the server table
alter table session
  drop constraint session_server_id_server_type_fkey;
alter table server
  drop constraint server_pkey;
alter table server
  drop column name;
alter table server
  add primary key (private_id);
alter table server
  add constraint server_id_must_not_be_empty
  check(length(trim(private_id)) > 0);
alter table session
  add constraint session_server_id_fkey
  foreign key (server_id)
  references server(private_id)
  on delete set null
  on update cascade;

create domain wt_bexprfilter as text
check(
  value is null
    or
    (
      length(trim(value)) > 0
        and
      length(trim(value)) <= 2048
    )
);
comment on domain wt_bexprfilter is
  'Text field with constraints for go-bexpr filters';

-- Add the worker filter to the target_tcp table and session table
alter table target_tcp
  add column worker_filter wt_bexprfilter;
alter table session
  add column worker_filter wt_bexprfilter;

-- Replace the immutable columns trigger from 50 to add worker_filter
drop trigger immutable_columns on session;
create trigger immutable_columns
  before update on session
    for each row execute procedure immutable_columns('public_id', 'certificate', 'expiration_time', 'connection_limit', 'create_time', 'endpoint', 'worker_filter');     

-- Replaces the view created in 41 to include worker_filter
drop view target_all_subtypes;
create view target_all_subtypes
as
select
  public_id,
  scope_id,
  name,
  description,
  default_port,
  session_max_seconds,
  session_connection_limit,
  version,
  create_time,
  update_time,
  worker_filter,
  'tcp' as type
from target_tcp;

-- Replaces the view created in 50 to include worker_filter
drop view session_with_state;
create view session_with_state as
  select
    s.public_id,
    s.user_id,
    s.host_id,
    s.server_id,
    s.server_type,
    s.target_id,
    s.host_set_id,
    s.auth_token_id,
    s.scope_id,
    s.certificate,
    s.expiration_time,
    s.connection_limit,
    s.tofu_token,
    s.key_id,
    s.termination_reason,
    s.version,
    s.create_time,
    s.update_time,
    s.endpoint,
    s.worker_filter,
    ss.state,
    ss.previous_end_time,
    ss.start_time,
    ss.end_time
  from
    session s,
    session_state ss
  where
    s.public_id = ss.session_id;

create domain wt_tagpair as text
check(
  value is not null
    and
  length(trim(value)) > 0
    and
  length(trim(value)) <= 512
    and
  lower(trim(value)) = value
);
comment on domain wt_tagpair is
  'Text field with constraints for key/value pairs';

create table server_tag (
  server_id text
    references server(private_id)
    on delete cascade
    on update cascade,
  key wt_tagpair,
  value wt_tagpair,
  primary key(server_id, key, value)
);
: unknown: error #0: pq: constraint "session_server_id_server_type_fkey" of relation "session" does not exist

It looks like Boundary is trying to run a database migration, but this is a clean install with no existing db to migrate. Any ideas on what is going on here?

For reference, I am running Boundary 0.1.5 and Postgres 11.6.

FYI - I tried the same with Boundary 0.1.4 and the database initialized without issue.

The drop there is using Postgres default constraint naming. It’s possible that it’s different in Postgres 11, or different on Azure. We’ll try to figure out the issue here – in the mean time, any chance you can try with Postgres 12?

I just tested – I can confirm this is a Postgres 11 vs 12 issue. We’ll have to discuss internally how to address it, or if we will want to standardize on Postgres 12.

We’re going to spin a 0.1.7 today to fix this issue.

1 Like

Awesome, thanks Jeff! I’ll take it for a spin.