FYI Katello CI is broken

Petr_Chalupa · February 19, 2014, 3:05pm

Commit
https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43
introduced collision on field 'label' in table 'taxonomies' which is
being added later in katello migration
https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb.
Katello rake db:migrate is now broken. See
http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console.

Mike_McCune · February 19, 2014, 4:35pm

Can we get this change backed out of Foreman until Katello can do work
to be compatible with this change?

Until we get better automation and process (being discussed) for
handling changes in Foreman that effect plugins could we at least
informally agree that if things in mainline Foreman break plugins they
should be backed out until those plugins get updated such that things
remain functional?

We are very much blocked at this point with this change existing as-is.
We are definitely willing to do work to make Katello compatible with
the change but can't function in a 'deal with it' model where mainline
Foreman changes land on us without any testing against the plugins.

Mike

···

On 02/19/2014 07:05 AM, Petr Chalupa wrote: > Commit > https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 > introduced collision on field 'label' in table 'taxonomies' which is > being added later in katello migration > https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. > Katello rake db:migrate is now broken. See > http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. > >

–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

Mike_McCune · February 19, 2014, 5:04pm

> Mike,
>
> Is the issue that the most recent migration of foreman wont run due to this migration?
>
> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
>
> or is it this line in the Katello migration from 2013-11-20?
>
> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5

I believe it is this one that is failing.

>
> Is it on a fresh install or existing environment that already has katello plugin installed and database migrated? If the above run in katello is deleted, then the migration should run on a fresh install.
>

fresh install, our CI is new environment for each test run.

> I could rename the db field in taxonomies from 'label' to 'fullname' or something similar? Does Katello allow editing on 'label', because with Foreman, it's generated automatically.
>

katello does allow editing of the label, our UI generates it but allows
for an override if they see fit. If you type:

"Some object name"

you get a label of:

"Some_object_name"

but the user is able to edit it to something else if they want.

Mike

···

On 02/19/2014 08:42 AM, Joseph Magen wrote:

Joseph_Magen · February 19, 2014, 4:42pm

Mike,

Is the issue that the most recent migration of foreman wont run due to this migration?

github.com

theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb

class AddAncestryToTaxonomies < ActiveRecord::Migration[4.2]
  def up
    add_column :taxonomies, :ancestry, :string, :limit => 255
    add_index :taxonomies, :ancestry
    # migration 20131120225132 is run by the katello plugin that adds 'label' to taxonomies
    add_column(:taxonomies, :label, :string, :limit => 255) unless ActiveRecord::Migrator.get_all_versions.include?(20131120225132)
  end

  def down
    remove_column :taxonomies, :ancestry
    remove_column(:taxonomies, :label) unless ActiveRecord::Migrator.get_all_versions.include?(20131120225132)
  end
end

or is it this line in the Katello migration from 2013-11-20?

github.com

Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5


class AddOrganizationFields < ActiveRecord::Migration[4.2]
def change
  add_column :taxonomies, :description, :text unless column_exists?(:taxonomies, :description)
  add_column :taxonomies, :label, :string, :limit => 255
  add_column :taxonomies, :deletion_task_id, :integer
  add_column :taxonomies, :default_info, :text
  add_column :taxonomies, :apply_info_task_id, :integer
  add_column :taxonomies, :owner_auto_attach_all_systems_task_id, :integer


  add_index :taxonomies, [:deletion_task_id], :name => "index_organizations_on_task_id"
  add_index :taxonomies, [:label], :name => "index_organizations_on_cp_key", :unique => true
end
end

Is it on a fresh install or existing environment that already has katello plugin installed and database migrated? If the above run in katello is deleted, then the migration should run on a fresh install.

I could rename the db field in taxonomies from 'label' to 'fullname' or something similar? Does Katello allow editing on 'label', because with Foreman, it's generated automatically.

Joseph

···

----- Original Message ----- > From: "Mike McCune" > To: foreman-dev@googlegroups.com > Cc: "Petr Chalupa" , "Joseph Magen" , "Dominic Cleal" > Sent: Wednesday, February 19, 2014 6:35:41 PM > Subject: Re: [foreman-dev] FYI Katello CI is broken > > On 02/19/2014 07:05 AM, Petr Chalupa wrote: > > Commit > > https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 > > introduced collision on field 'label' in table 'taxonomies' which is > > being added later in katello migration > > https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. > > Katello rake db:migrate is now broken. See > > http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. > > > > > > Can we get this change backed out of Foreman until Katello can do work > to be compatible with this change? > > Until we get better automation and process (being discussed) for > handling changes in Foreman that effect plugins could we at least > informally agree that if things in mainline Foreman break plugins they > should be backed out until those plugins get updated such that things > remain functional? > > We are very much blocked at this point with this change existing as-is. > We are definitely willing to do work to make Katello compatible with > the change but can't function in a 'deal with it' model where mainline > Foreman changes land on us without any testing against the plugins. > > Mike > -- > Mike McCune > mmccune AT redhat.com > Red Hat Engineering | Portland, OR > Systems Management | 650-254-4248 > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Justin_Sherrill · February 19, 2014, 5:06pm

>> Mike,
>>
>> Is the issue that the most recent migration of foreman wont run due
>> to this migration?
>>
>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
>>
>>
>> or is it this line in the Katello migration from 2013-11-20?
>>
>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5
>>
>
> I believe it is this one that is failing.
>
>>
>> Is it on a fresh install or existing environment that already has
>> katello plugin installed and database migrated? If the above run in
>> katello is deleted, then the migration should run on a fresh install.
>>
>
> fresh install, our CI is new environment for each test run.
>
>> I could rename the db field in taxonomies from 'label' to 'fullname'
>> or something similar? Does Katello allow editing on 'label', because
>> with Foreman, it's generated automatically.
>>
>
>
> katello does allow editing of the label, our UI generates it but
> allows for an override if they see fit. If you type:
>
> "Some object name"
>
> you get a label of:
>
> "Some_object_name"
>
> but the user is able to edit it to something else if they want.
>

To clarify the label cannot be changed once the object is created, but
can be set by the user.

-Justin

···

On 02/19/2014 12:04 PM, Mike McCune wrote: > On 02/19/2014 08:42 AM, Joseph Magen wrote:

Mike

Mike_McCune · February 19, 2014, 8:08pm

I'd vote change Foreman's Location label to be something named
differently. In Katello labels are pervasive throughout the system and
we add them to a bunch of our objects as well as add-on attributes to
Foreman core objects like Org.

Adding a field to another core concept like Locations called 'label'
that behaves different from what our users are going to expect from the
existing label concept is going to cause lots of confusion.

FYI, some background on the requirements and need for the label field:

https://fedorahosted.org/katello/wiki/ObjectLabelDesign

Mike

···

On 02/19/2014 09:59 AM, Justin Sherrill wrote: > On 02/19/2014 12:50 PM, Joseph Magen wrote: >> >> ----- Original Message ----- >>> From: "Justin Sherrill" >>> To: foreman-dev@googlegroups.com >>> Cc: "Joseph Magen" , "Petr Chalupa" >>> , "Dominic Cleal" >>> Sent: Wednesday, February 19, 2014 7:06:13 PM >>> Subject: Re: [foreman-dev] FYI Katello CI is broken >>> >>> On 02/19/2014 12:04 PM, Mike McCune wrote: >>>> On 02/19/2014 08:42 AM, Joseph Magen wrote: >>>>> Mike, >>>>> >>>>> Is the issue that the most recent migration of foreman wont run due >>>>> to this migration? >>>>> >>>>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb >>>>> >>>>> >>>>> >>>>> or is it this line in the Katello migration from 2013-11-20? >>>>> >>>>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5 >>>>> >>>>> >>>> I believe it is this one that is failing. >>>> >>>>> Is it on a fresh install or existing environment that already has >>>>> katello plugin installed and database migrated? If the above run in >>>>> katello is deleted, then the migration should run on a fresh install. >>>>> >>>> fresh install, our CI is new environment for each test run. >>>> >>>>> I could rename the db field in taxonomies from 'label' to 'fullname' >>>>> or something similar? Does Katello allow editing on 'label', because >>>>> with Foreman, it's generated automatically. >>>>> >>>> >>>> katello does allow editing of the label, our UI generates it but >>>> allows for an override if they see fit. If you type: >>>> >>>> "Some object name" >>>> >>>> you get a label of: >>>> >>>> "Some_object_name" >>>> >>>> but the user is able to edit it to something else if they want. >>>> >>> To clarify the label cannot be *changed* once the object is created, but >>> can be set by the user. >> The foreman label may change if it's parent's name or it's own name is >> changed. >> >> Ex. label is RedHat/Engineering/Cloud for organization 'Cloud' with >> parents 'Engineering' and 'RedHat': >> >> If organization Engineering is renamed to 'Eng', then the label for >> 'Cloud' is renamed to 'RedHat/Eng/Cloud' >> >> Are you using 'label' as a 'slug' that doesn't change after creation >> no matter? > Ahh! Then they are two completely separate things and shouldn't be > unified. We're using label to: > > * have a meaningful and readable representation of an object that cannot > change in order to embed it within things like directory structures > * to have an ascii representation of various objects in order to be > compatible with yum > > Since they are very very different and I don't think it makes sense to > unify them, we probably should rename either foreman's label or > katello's. I'm not sure of the work involved to change foreman's but I > know katello's org label is fairly engrained in the application. > > Thanks for clarifying Joseph! > > -Justin >

bbuckingham · February 19, 2014, 5:20pm

Ideally, we should add the label to foreman and adapt katello
(model/api/cli/tests…etc) to use the foreman label instead of the one
we currently have in place for katello.

Since label is an attribute that katello uses for multiple models (e.g.
org, env, product, repo…), it would be nice if we could be consistent
in how we handle them in both katello and foreman.

For example:

label is assigned during object create
label is viewable (readonly) during object edit/show
if user provides a label during create, it is used (provided it passes
validation)
if user does not provide a label during create, it is defaulted to the
name, but goes through a 'labelize' process

We could attempt to override from katello the labelize logic that
foreman places on the attribute; however, it might be better to just
handle them consistently. For example, move the labelize logic from
katello to the core (foreman) and then use it within katello for those
other objects that need it.

Below are a few links to code that show how the label is handled in
katello (using org as an example):

github.com

Katello/katello/blob/master/app/models/katello/concerns/organization_extensions.rb#L41


#older association
has_many :org_tasks, :dependent => :destroy, :class_name => "Katello::TaskStatus", :inverse_of => :organization


attr_accessor :statistics


scope :having_name_or_label, ->(name_or_label) { where("name = :id or label = :id", :id => name_or_label) }
scoped_search :on => :label, :complete_value => :true


after_create :associate_default_capsule
validates_with Validators::KatelloLabelFormatValidator, :attributes => :label
validates :label, :uniqueness => true


def default_content_view
  ContentView.default.where(:organization_id => self.id).first
end


def promotion_paths
  #I'm sure there's a better way to do this
  self.kt_environments.joins(:priors).where("prior_id = #{self.library.id}").order(:name).collect do |env|
    env.path
  end

github.com

Katello/katello/blob/master/app/models/katello/concerns/organization_extensions.rb#L73


  self.providers.anonymous.first
end


def manifest_history
  imports.map { |i| OpenStruct.new(i) }
end


def repo_discovery_task
  self.task_statuses.where(:task_type => :repo_discovery).order('created_at DESC').first
end


def create_library
  self.library = Katello::KTEnvironment.new(:name => "Library", :label => "Library", :library => true, :organization => self)
end


def create_redhat_provider
  self.providers << Katello::Provider.new(:name => "Red Hat", :provider_type => Katello::Provider::REDHAT)
end


def associate_default_capsule
  capsule_content = Katello::CapsuleContent.default_capsule

github.com

Katello/katello/blob/master/app/models/katello/concerns/organization_extensions.rb#L75




def manifest_history
  imports.map { |i| OpenStruct.new(i) }
end


def repo_discovery_task
  self.task_statuses.where(:task_type => :repo_discovery).order('created_at DESC').first
end


def create_library
  self.library = Katello::KTEnvironment.new(:name => "Library", :label => "Library", :library => true, :organization => self)
end


def create_redhat_provider
  self.providers << Katello::Provider.new(:name => "Red Hat", :provider_type => Katello::Provider::REDHAT)
end


def associate_default_capsule
  capsule_content = Katello::CapsuleContent.default_capsule
  capsule_content.capsule.organizations << self if capsule_content
end

github.com

Katello/katello/blob/master/app/models/katello/concerns/organization_extensions.rb#L77


  imports.map { |i| OpenStruct.new(i) }
end


def repo_discovery_task
  self.task_statuses.where(:task_type => :repo_discovery).order('created_at DESC').first
end


def create_library
  self.library = Katello::KTEnvironment.new(:name => "Library", :label => "Library", :library => true, :organization => self)
end


def create_redhat_provider
  self.providers << Katello::Provider.new(:name => "Red Hat", :provider_type => Katello::Provider::REDHAT)
end


def associate_default_capsule
  capsule_content = Katello::CapsuleContent.default_capsule
  capsule_content.capsule.organizations << self if capsule_content
end


def create_anonymous_provider

github.com

Katello/katello/blob/master/app/models/katello/ext/label_from_name.rb

module Katello
  module Ext
    module LabelFromName
      def self.included(base)
        base.class_eval do
          before_validation :setup_label_from_name
          validate :label_not_changed, :on => :update
        end
      end

      def setup_label_from_name
        if label.blank?
          self.label = Util::Model.labelize(name)
          if self.class.where(:label => self.label).any?
            self.label = Util::Model.uuid
          end
        end
      end

      def label_not_changed

This file has been truncated. show original

github.com

Katello/katello/blob/master/app/lib/katello/util/model.rb#L34


end


def self.uuid
  SecureRandom.uuid
end


def self.controller_path_to_model_hash
  {
    "katello/environments" => "Katello::KTEnvironment"
  }
end


def self.controller_path_to_model(controller)
  if controller_path_to_model_hash.key? controller.to_s
    controller_path_to_model_hash[controller.to_s].constantize
  else
    controller.to_s.classify.constantize
  end
end


def self.model_to_controller_path_hash

github.com

Katello/katello/blob/master/app/lib/katello/validators/katello_label_format_validator.rb

module Katello
  module Validators
    class KatelloLabelFormatValidator < ActiveModel::EachValidator
      def validate_each(record, attribute, value)
        if value
          record.errors[attribute] << N_("cannot contain characters other than ascii alpha numerals, '_', '-'. ") unless value =~ /\A[a-zA-Z0-9_\-]+\z/
          NoTrailingSpaceValidator.validate_trailing_space(record, attribute, value)
          KatelloLabelFormatValidator.validate_length(record, attribute, value)
        else
          record.errors[attribute] << N_("can't be blank")
        end
      end

      def self.validate_length(record, attribute, value, max_length = 128, min_length = 1)
        if value
          record.errors[attribute] << N_("cannot contain more than %s characters") % max_length unless value.length <= max_length
          record.errors[attribute] << N_("must contain at least %s character") % min_length unless value.length >= min_length
        end
      end
    end

This file has been truncated. show original

thanks,
Brad

···

On 02/19/2014 12:06 PM, Justin Sherrill wrote: > On 02/19/2014 12:04 PM, Mike McCune wrote: >> On 02/19/2014 08:42 AM, Joseph Magen wrote: >>> Mike, >>> >>> Is the issue that the most recent migration of foreman wont run due >>> to this migration? >>> >>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb >>> >>> >>> or is it this line in the Katello migration from 2013-11-20? >>> >>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5 >>> >> >> I believe it is this one that is failing. >> >>> >>> Is it on a fresh install or existing environment that already has >>> katello plugin installed and database migrated? If the above run in >>> katello is deleted, then the migration should run on a fresh install. >>> >> >> fresh install, our CI is new environment for each test run. >> >>> I could rename the db field in taxonomies from 'label' to 'fullname' >>> or something similar? Does Katello allow editing on 'label', because >>> with Foreman, it's generated automatically. >>> >> >> >> katello does allow editing of the label, our UI generates it but >> allows for an override if they see fit. If you type: >> >> "Some object name" >> >> you get a label of: >> >> "Some_object_name" >> >> but the user is able to edit it to something else if they want. >> > > To clarify the label cannot be *changed* once the object is created, > but can be set by the user. > > -Justin > >> Mike >> >

Joseph_Magen · February 19, 2014, 5:50pm

> From: "Justin Sherrill" <jsherril@redhat.com>
> To: foreman-dev@googlegroups.com
> Cc: "Joseph Magen" <jmagen@redhat.com>, "Petr Chalupa" <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
> Sent: Wednesday, February 19, 2014 7:06:13 PM
> Subject: Re: [foreman-dev] FYI Katello CI is broken
>
> >> Mike,
> >>
> >> Is the issue that the most recent migration of foreman wont run due
> >> to this migration?
> >>
> >> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
> >>
> >>
> >> or is it this line in the Katello migration from 2013-11-20?
> >>
> >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5
> >>
> >
> > I believe it is this one that is failing.
> >
> >>
> >> Is it on a fresh install or existing environment that already has
> >> katello plugin installed and database migrated? If the above run in
> >> katello is deleted, then the migration should run on a fresh install.
> >>
> >
> > fresh install, our CI is new environment for each test run.
> >
> >> I could rename the db field in taxonomies from 'label' to 'fullname'
> >> or something similar? Does Katello allow editing on 'label', because
> >> with Foreman, it's generated automatically.
> >>
> >
> >
> > katello does allow editing of the label, our UI generates it but
> > allows for an override if they see fit. If you type:
> >
> > "Some object name"
> >
> > you get a label of:
> >
> > "Some_object_name"
> >
> > but the user is able to edit it to something else if they want.
> >
>
> To clarify the label cannot be changed once the object is created, but
> can be set by the user.

The foreman label may change if it's parent's name or it's own name is changed.

Ex. label is RedHat/Engineering/Cloud for organization 'Cloud' with parents 'Engineering' and 'RedHat':

If organization Engineering is renamed to 'Eng', then the label for 'Cloud' is renamed to 'RedHat/Eng/Cloud'

Are you using 'label' as a 'slug' that doesn't change after creation no matter?

···

----- Original Message ----- > On 02/19/2014 12:04 PM, Mike McCune wrote: > > On 02/19/2014 08:42 AM, Joseph Magen wrote:

-Justin

Mike

Justin_Sherrill · February 19, 2014, 5:59pm

>
>> From: "Justin Sherrill" <jsherril@redhat.com>
>> To: foreman-dev@googlegroups.com
>> Cc: "Joseph Magen" <jmagen@redhat.com>, "Petr Chalupa" <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
>> Sent: Wednesday, February 19, 2014 7:06:13 PM
>> Subject: Re: [foreman-dev] FYI Katello CI is broken
>>
>>>> Mike,
>>>>
>>>> Is the issue that the most recent migration of foreman wont run due
>>>> to this migration?
>>>>
>>>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
>>>>
>>>>
>>>> or is it this line in the Katello migration from 2013-11-20?
>>>>
>>>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5
>>>>
>>> I believe it is this one that is failing.
>>>
>>>> Is it on a fresh install or existing environment that already has
>>>> katello plugin installed and database migrated? If the above run in
>>>> katello is deleted, then the migration should run on a fresh install.
>>>>
>>> fresh install, our CI is new environment for each test run.
>>>
>>>> I could rename the db field in taxonomies from 'label' to 'fullname'
>>>> or something similar? Does Katello allow editing on 'label', because
>>>> with Foreman, it's generated automatically.
>>>>
>>>
>>> katello does allow editing of the label, our UI generates it but
>>> allows for an override if they see fit. If you type:
>>>
>>> "Some object name"
>>>
>>> you get a label of:
>>>
>>> "Some_object_name"
>>>
>>> but the user is able to edit it to something else if they want.
>>>
>> To clarify the label cannot be changed once the object is created, but
>> can be set by the user.
> The foreman label may change if it's parent's name or it's own name is changed.
>
> Ex. label is RedHat/Engineering/Cloud for organization 'Cloud' with parents 'Engineering' and 'RedHat':
>
> If organization Engineering is renamed to 'Eng', then the label for 'Cloud' is renamed to 'RedHat/Eng/Cloud'
>
> Are you using 'label' as a 'slug' that doesn't change after creation no matter?
Ahh! Then they are two completely separate things and shouldn't be
unified. We're using label to:

have a meaningful and readable representation of an object that cannot
change in order to embed it within things like directory structures
to have an ascii representation of various objects in order to be
compatible with yum

Since they are very very different and I don't think it makes sense to
unify them, we probably should rename either foreman's label or
katello's. I'm not sure of the work involved to change foreman's but I
know katello's org label is fairly engrained in the application.

Thanks for clarifying Joseph!

-Justin

···

On 02/19/2014 12:50 PM, Joseph Magen wrote: > ----- Original Message ----- >> On 02/19/2014 12:04 PM, Mike McCune wrote: >>> On 02/19/2014 08:42 AM, Joseph Magen wrote:

-Justin

Mike

Joseph_Magen · February 19, 2014, 6:12pm

> From: "Justin Sherrill" <jsherril@redhat.com>
> To: "Joseph Magen" <jmagen@redhat.com>
> Cc: foreman-dev@googlegroups.com, "Petr Chalupa" <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
> Sent: Wednesday, February 19, 2014 7:59:56 PM
> Subject: Re: [foreman-dev] FYI Katello CI is broken
>
> >
> >> From: "Justin Sherrill" <jsherril@redhat.com>
> >> To: foreman-dev@googlegroups.com
> >> Cc: "Joseph Magen" <jmagen@redhat.com>, "Petr Chalupa"
> >> <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
> >> Sent: Wednesday, February 19, 2014 7:06:13 PM
> >> Subject: Re: [foreman-dev] FYI Katello CI is broken
> >>
> >>>> Mike,
> >>>>
> >>>> Is the issue that the most recent migration of foreman wont run due
> >>>> to this migration?
> >>>>
> >>>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
> >>>>
> >>>>
> >>>> or is it this line in the Katello migration from 2013-11-20?
> >>>>
> >>>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5
> >>>>
> >>> I believe it is this one that is failing.
> >>>
> >>>> Is it on a fresh install or existing environment that already has
> >>>> katello plugin installed and database migrated? If the above run in
> >>>> katello is deleted, then the migration should run on a fresh install.
> >>>>
> >>> fresh install, our CI is new environment for each test run.
> >>>
> >>>> I could rename the db field in taxonomies from 'label' to 'fullname'
> >>>> or something similar? Does Katello allow editing on 'label', because
> >>>> with Foreman, it's generated automatically.
> >>>>
> >>>
> >>> katello does allow editing of the label, our UI generates it but
> >>> allows for an override if they see fit. If you type:
> >>>
> >>> "Some object name"
> >>>
> >>> you get a label of:
> >>>
> >>> "Some_object_name"
> >>>
> >>> but the user is able to edit it to something else if they want.
> >>>
> >> To clarify the label cannot be changed once the object is created, but
> >> can be set by the user.
> > The foreman label may change if it's parent's name or it's own name is
> > changed.
> >
> > Ex. label is RedHat/Engineering/Cloud for organization 'Cloud' with parents
> > 'Engineering' and 'RedHat':
> >
> > If organization Engineering is renamed to 'Eng', then the label for 'Cloud'
> > is renamed to 'RedHat/Eng/Cloud'
> >
> > Are you using 'label' as a 'slug' that doesn't change after creation no
> > matter?
> Ahh! Then they are two completely separate things and shouldn't be
> unified. We're using label to:
>
> * have a meaningful and readable representation of an object that cannot
> change in order to embed it within things like directory structures
> * to have an ascii representation of various objects in order to be
> compatible with yum
>
> Since they are very very different and I don't think it makes sense to
> unify them, we probably should rename either foreman's label or
> katello's. I'm not sure of the work involved to change foreman's but I
> know katello's org label is fairly engrained in the application.

It shouldn't be so difficult to the organization/location label in Foreman. I will send a PR soon.

···

---- Original Message ----- > On 02/19/2014 12:50 PM, Joseph Magen wrote: > > ----- Original Message ----- > >> On 02/19/2014 12:04 PM, Mike McCune wrote: > >>> On 02/19/2014 08:42 AM, Joseph Magen wrote:

Thanks for clarifying Joseph!

-Justin

-Justin

Mike

Joseph_Magen · February 19, 2014, 8:10pm

> From: "Justin Sherrill" <jsherril@redhat.com>
> To: "Joseph Magen" <jmagen@redhat.com>
> Cc: foreman-dev@googlegroups.com, "Petr Chalupa" <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
> Sent: Wednesday, February 19, 2014 7:59:56 PM
> Subject: Re: [foreman-dev] FYI Katello CI is broken
>
> >
> >> From: "Justin Sherrill" <jsherril@redhat.com>
> >> To: foreman-dev@googlegroups.com
> >> Cc: "Joseph Magen" <jmagen@redhat.com>, "Petr Chalupa"
> >> <pchalupa@redhat.com>, "Dominic Cleal" <dcleal@redhat.com>
> >> Sent: Wednesday, February 19, 2014 7:06:13 PM
> >> Subject: Re: [foreman-dev] FYI Katello CI is broken
> >>
> >>>> Mike,
> >>>>
> >>>> Is the issue that the most recent migration of foreman wont run due
> >>>> to this migration?
> >>>>
> >>>> https://github.com/theforeman/foreman/blob/develop/db/migrate/20140128123153_add_ancestry_to_taxonomies.rb
> >>>>
> >>>>
> >>>> or is it this line in the Katello migration from 2013-11-20?
> >>>>
> >>>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb#L5
> >>>>
> >>> I believe it is this one that is failing.
> >>>
> >>>> Is it on a fresh install or existing environment that already has
> >>>> katello plugin installed and database migrated? If the above run in
> >>>> katello is deleted, then the migration should run on a fresh install.
> >>>>
> >>> fresh install, our CI is new environment for each test run.
> >>>
> >>>> I could rename the db field in taxonomies from 'label' to 'fullname'
> >>>> or something similar? Does Katello allow editing on 'label', because
> >>>> with Foreman, it's generated automatically.
> >>>>
> >>>
> >>> katello does allow editing of the label, our UI generates it but
> >>> allows for an override if they see fit. If you type:
> >>>
> >>> "Some object name"
> >>>
> >>> you get a label of:
> >>>
> >>> "Some_object_name"
> >>>
> >>> but the user is able to edit it to something else if they want.
> >>>
> >> To clarify the label cannot be changed once the object is created, but
> >> can be set by the user.
> > The foreman label may change if it's parent's name or it's own name is
> > changed.
> >
> > Ex. label is RedHat/Engineering/Cloud for organization 'Cloud' with parents
> > 'Engineering' and 'RedHat':
> >
> > If organization Engineering is renamed to 'Eng', then the label for 'Cloud'
> > is renamed to 'RedHat/Eng/Cloud'
> >
> > Are you using 'label' as a 'slug' that doesn't change after creation no
> > matter?
> Ahh! Then they are two completely separate things and shouldn't be
> unified. We're using label to:
>
> * have a meaningful and readable representation of an object that cannot
> change in order to embed it within things like directory structures
> * to have an ascii representation of various objects in order to be
> compatible with yum
>
> Since they are very very different and I don't think it makes sense to
> unify them, we probably should rename either foreman's label or
> katello's. I'm not sure of the work involved to change foreman's but I
> know katello's org label is fairly engrained in the application.

I updated Foreman and renamed 'label' to 'fullname'.
Here is the PR https://github.com/theforeman/foreman/pull/1245

It was a little more involved than I originally thought since Hostgroup shares a common mixin that deals with ancestry.
But, I'm sure it was much less work than changing Katello.

···

----- Original Message ----- > On 02/19/2014 12:50 PM, Joseph Magen wrote: > > ----- Original Message ----- > >> On 02/19/2014 12:04 PM, Mike McCune wrote: > >>> On 02/19/2014 08:42 AM, Joseph Magen wrote:

Thanks for clarifying Joseph!

-Justin

-Justin

Mike

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Dominic_Cleal1 · February 19, 2014, 4:59pm

You could update the CI jobs to use a git ref that you're happy works
with the current version of Katello?

No need to test against develop HEAD if there's an incompatibility that
needs addressing.

···

On 19/02/14 16:35, Mike McCune wrote: > On 02/19/2014 07:05 AM, Petr Chalupa wrote: >> Commit >> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 >> introduced collision on field 'label' in table 'taxonomies' which is >> being added later in katello migration >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. >> Katello rake db:migrate is now broken. See >> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. >> >> > > Can we get this change backed out of Foreman until Katello can do work > to be compatible with this change? > > Until we get better automation and process (being discussed) for > handling changes in Foreman that effect plugins could we at least > informally agree that if things in mainline Foreman break plugins they > should be backed out until those plugins get updated such that things > remain functional?

–
Dominic Cleal
Red Hat Engineering

Mike_McCune · February 19, 2014, 5:18pm

that works as a band-aid for now but would be a pretty fragile CI setup
to have to randomly update our Jenkins job with git hashes and hope for
the best.

Mike

···

On 02/19/2014 08:59 AM, Dominic Cleal wrote: > On 19/02/14 16:35, Mike McCune wrote: >> On 02/19/2014 07:05 AM, Petr Chalupa wrote: >>> Commit >>> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 >>> introduced collision on field 'label' in table 'taxonomies' which is >>> being added later in katello migration >>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. >>> Katello rake db:migrate is now broken. See >>> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. >>> >>> >> >> Can we get this change backed out of Foreman until Katello can do work >> to be compatible with this change? >> >> Until we get better automation and process (being discussed) for >> handling changes in Foreman that effect plugins could we at least >> informally agree that if things in mainline Foreman break plugins they >> should be backed out until those plugins get updated such that things >> remain functional? > > You could update the CI jobs to use a git ref that you're happy works > with the current version of Katello? > > No need to test against develop HEAD if there's an incompatibility that > needs addressing. >

–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

Mike_McCune · February 19, 2014, 5:38pm

The problem with pinning things to git hashes is that development is
done against Foreman's develop branch so the team is all hacking away,
testing things locally and things work fine.

Something gets merged to develop, all the devs are now locally broken
as well as our CI. So we can move the CI to just stick with git hashes
but then we have to have some coordinated communication protocol to the
team:

'hey, everyone switch over to 2e66b04a2c92bc40fea1bfdc7f0414435754f49b,
that is now the stable hash to use'

we go and update our CI script and hope everyone noticed the
communication of the correct hash to use? Seems like a recipe for failure.

We could fork Foreman and merge upstream/develop to it when we know
things are stable but again, this requires coordination and is delaying
the inevitable breakage.

Can we get some acknowledgment that Foreman isn't going to just stick
with the mode where plugin developers have to just accept everything
landing in the dev branch?

Mike

···

On 02/19/2014 09:17 AM, Sam Kottler wrote: > > > ----- Original Message ----- >> From: "Dominic Cleal" >> To: foreman-dev@googlegroups.com >> Sent: Wednesday, February 19, 2014 11:59:55 AM >> Subject: Re: [foreman-dev] FYI Katello CI is broken >> >> On 19/02/14 16:35, Mike McCune wrote: >>> On 02/19/2014 07:05 AM, Petr Chalupa wrote: >>>> Commit >>>> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 >>>> introduced collision on field 'label' in table 'taxonomies' which is >>>> being added later in katello migration >>>> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. >>>> Katello rake db:migrate is now broken. See >>>> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. >>>> >>>> >>> >>> Can we get this change backed out of Foreman until Katello can do work >>> to be compatible with this change? >>> >>> Until we get better automation and process (being discussed) for >>> handling changes in Foreman that effect plugins could we at least >>> informally agree that if things in mainline Foreman break plugins they >>> should be backed out until those plugins get updated such that things >>> remain functional? >> >> You could update the CI jobs to use a git ref that you're happy works >> with the current version of Katello? >> >> No need to test against develop HEAD if there's an incompatibility that >> needs addressing. > > +1. We could test PR's against a recent, but known working, ref for pull requests. That'd probably also mean we need a job that runs katello tests against foreman HEAD, and won't block katello merges but will catch breakage. >

Sam_Kottler1 · February 19, 2014, 5:17pm

> From: "Dominic Cleal" <dcleal@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, February 19, 2014 11:59:55 AM
> Subject: Re: [foreman-dev] FYI Katello CI is broken
>
> >> Commit
> >> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43
> >> introduced collision on field 'label' in table 'taxonomies' which is
> >> being added later in katello migration
> >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb.
> >> Katello rake db:migrate is now broken. See
> >> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console.
> >>
> >>
> >
> > Can we get this change backed out of Foreman until Katello can do work
> > to be compatible with this change?
> >
> > Until we get better automation and process (being discussed) for
> > handling changes in Foreman that effect plugins could we at least
> > informally agree that if things in mainline Foreman break plugins they
> > should be backed out until those plugins get updated such that things
> > remain functional?
>
> You could update the CI jobs to use a git ref that you're happy works
> with the current version of Katello?
>
> No need to test against develop HEAD if there's an incompatibility that
> needs addressing.

+1. We could test PR's against a recent, but known working, ref for pull requests. That'd probably also mean we need a job that runs katello tests against foreman HEAD, and won't block katello merges but will catch breakage.

···

----- Original Message ----- > On 19/02/14 16:35, Mike McCune wrote: > > On 02/19/2014 07:05 AM, Petr Chalupa wrote:

–
Dominic Cleal
Red Hat Engineering

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

komidore64 · February 19, 2014, 5:32pm

> From: "Dominic Cleal" <dcleal@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, February 19, 2014 11:59:55 AM
> Subject: Re: [foreman-dev] FYI Katello CI is broken
>
> >> Commit
> >> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43
> >> introduced collision on field 'label' in table 'taxonomies' which is
> >> being added later in katello migration
> >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb.
> >> Katello rake db:migrate is now broken. See
> >> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console.
> >>
> >>
> >
> > Can we get this change backed out of Foreman until Katello can do work
> > to be compatible with this change?
> >
> > Until we get better automation and process (being discussed) for
> > handling changes in Foreman that effect plugins could we at least
> > informally agree that if things in mainline Foreman break plugins they
> > should be backed out until those plugins get updated such that things
> > remain functional?
>
> You could update the CI jobs to use a git ref that you're happy works
> with the current version of Katello?
>
> No need to test against develop HEAD if there's an incompatibility that
> needs addressing.

I disagree. As developers, we're always (should be) running with Foreman develop latest and Katello master latest. Jenkins should test the same to check for breakages.

Foreman PR's should run the test_katello jenkins job to make sure that nothing in Katello blows up, as well as whenever Foreman develop changes.

···

----- Original Message ----- > On 19/02/14 16:35, Mike McCune wrote: > > On 02/19/2014 07:05 AM, Petr Chalupa wrote:

–
Dominic Cleal
Red Hat Engineering

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

adam price

daviddavis · February 19, 2014, 5:35pm

I think Dominic means short term. I'll update the Jenknis job to run against fd3f24f8e05d8f4ab64bc61168fc4e0ead455025 for now until we can solve the cause.

David

···

----- Original Message ----- > From: "Adam Price" > To: foreman-dev@googlegroups.com > Sent: Wednesday, February 19, 2014 12:32:43 PM > Subject: Re: [foreman-dev] FYI Katello CI is broken > > ----- Original Message ----- > > From: "Dominic Cleal" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, February 19, 2014 11:59:55 AM > > Subject: Re: [foreman-dev] FYI Katello CI is broken > > > > On 19/02/14 16:35, Mike McCune wrote: > > > On 02/19/2014 07:05 AM, Petr Chalupa wrote: > > >> Commit > > >> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 > > >> introduced collision on field 'label' in table 'taxonomies' which is > > >> being added later in katello migration > > >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. > > >> Katello rake db:migrate is now broken. See > > >> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. > > >> > > >> > > > > > > Can we get this change backed out of Foreman until Katello can do work > > > to be compatible with this change? > > > > > > Until we get better automation and process (being discussed) for > > > handling changes in Foreman that effect plugins could we at least > > > informally agree that if things in mainline Foreman break plugins they > > > should be backed out until those plugins get updated such that things > > > remain functional? > > > > You could update the CI jobs to use a git ref that you're happy works > > with the current version of Katello? > > > > No need to test against develop HEAD if there's an incompatibility that > > needs addressing. > > I disagree. As developers, we're always (should be) running with Foreman > develop latest and Katello master latest. Jenkins should test the same to > check for breakages. > > Foreman PR's should run the test_katello jenkins job to make sure that > nothing in Katello blows up, as well as whenever Foreman develop changes. > > > > > -- > > Dominic Cleal > > Red Hat Engineering > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > - adam price > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

iNecas · February 19, 2014, 7:26pm

Even short-term it solved the issue just partly: the nightlies get broken as well.

We've been there few months ago (and similarly with pulp and candlepin long time before) and
we alwys ended up with Katello decinding when is time to update the deps
(and the issues were resolved on the time when the update happened).

We could probably have a branch in Foreman
repo that would point to the sha that we are targetting against.
But it would probably also mean maintaing the repo holding tha
foreman packages known to work with Katello. The downside is
the risk of breaking changes landing into Foreman and Katello
learning too late about that. Also, the burden of mainaing
different set of repos could be painful.

I would probably like more with CI running katello (and other plugins)
tests with every PR in Foreman, indicating, if it's breaking or not
and agreeing on the proceedure when some incombatible change is introduced:
if it's going to be merged anyway, would be nice to have the patch for Katello
prepared, so that we can just update simultaniously.

– Ivan

···

----- Original Message ----- > I think Dominic means short term. I'll update the Jenknis job to run against > fd3f24f8e05d8f4ab64bc61168fc4e0ead455025 for now until we can solve the > cause. > > David > > ----- Original Message ----- > > From: "Adam Price" > > To: foreman-dev@googlegroups.com > > Sent: Wednesday, February 19, 2014 12:32:43 PM > > Subject: Re: [foreman-dev] FYI Katello CI is broken > > > > ----- Original Message ----- > > > From: "Dominic Cleal" > > > To: foreman-dev@googlegroups.com > > > Sent: Wednesday, February 19, 2014 11:59:55 AM > > > Subject: Re: [foreman-dev] FYI Katello CI is broken > > > > > > On 19/02/14 16:35, Mike McCune wrote: > > > > On 02/19/2014 07:05 AM, Petr Chalupa wrote: > > > >> Commit > > > >> https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43 > > > >> introduced collision on field 'label' in table 'taxonomies' which is > > > >> being added later in katello migration > > > >> https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb. > > > >> Katello rake db:migrate is now broken. See > > > >> http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console. > > > >> > > > >> > > > > > > > > Can we get this change backed out of Foreman until Katello can do work > > > > to be compatible with this change? > > > > > > > > Until we get better automation and process (being discussed) for > > > > handling changes in Foreman that effect plugins could we at least > > > > informally agree that if things in mainline Foreman break plugins they > > > > should be backed out until those plugins get updated such that things > > > > remain functional? > > > > > > You could update the CI jobs to use a git ref that you're happy works > > > with the current version of Katello? > > > > > > No need to test against develop HEAD if there's an incompatibility that > > > needs addressing. > > > > I disagree. As developers, we're always (should be) running with Foreman > > develop latest and Katello master latest. Jenkins should test the same to > > check for breakages. > > > > Foreman PR's should run the test_katello jenkins job to make sure that > > nothing in Katello blows up, as well as whenever Foreman develop changes. > > > > > > > > -- > > > Dominic Cleal > > > Red Hat Engineering > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "foreman-dev" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to foreman-dev+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > > - adam price > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Petr_Chalupa · February 20, 2014, 8:53am

> Even short-term it solved the issue just partly: the nightlies get broken as well.
>
> We've been there few months ago (and similarly with pulp and candlepin long time before) and
> we alwys ended up with Katello decinding when is time to update the deps
> (and the issues were resolved on the time when the update happened).
>
> We could probably have a branch in Foreman
> repo that would point to the sha that we are targetting against.
> But it would probably also mean maintaing the repo holding tha
> foreman packages known to work with Katello. The downside is
> the risk of breaking changes landing into Foreman and Katello
> learning too late about that. Also, the burden of mainaing
> different set of repos could be painful.
>
> I would probably like more with CI running katello (and other plugins)
> tests with every PR in Foreman, indicating, if it's breaking or not
> and agreeing on the proceedure when some incombatible change is introduced:
> if it's going to be merged anyway, would be nice to have the patch for Katello
> prepared, so that we can just update simultaniously.

+1 run Katello tests on each Foreman PR

···

On 19.02.14 20:26, Ivan Necas wrote:

– Ivan

----- Original Message -----

I think Dominic means short term. I’ll update the Jenknis job to run against
fd3f24f8e05d8f4ab64bc61168fc4e0ead455025 for now until we can solve the
cause.

David

----- Original Message -----

From: “Adam Price” adprice@redhat.com
To: foreman-dev@googlegroups.com
Sent: Wednesday, February 19, 2014 12:32:43 PM
Subject: Re: [foreman-dev] FYI Katello CI is broken

----- Original Message -----

From: “Dominic Cleal” dcleal@redhat.com
To: foreman-dev@googlegroups.com
Sent: Wednesday, February 19, 2014 11:59:55 AM
Subject: Re: [foreman-dev] FYI Katello CI is broken

On 19/02/14 16:35, Mike McCune wrote:

On 02/19/2014 07:05 AM, Petr Chalupa wrote:

Commit
https://github.com/theforeman/foreman/commit/1fa008a4ec7d26855b9b67aac3e5f66b0e3e0670#diff-43
introduced collision on field ‘label’ in table ‘taxonomies’ which is
being added later in katello migration
https://github.com/Katello/katello/blob/master/db/migrate/20131120225132_add_organization_fields.rb.
Katello rake db:migrate is now broken. See
http://ci.theforeman.org/job/test_katello_core/database=postgresql,ruby=1.9.3/1421/console.

Can we get this change backed out of Foreman until Katello can do work
to be compatible with this change?

Until we get better automation and process (being discussed) for
handling changes in Foreman that effect plugins could we at least
informally agree that if things in mainline Foreman break plugins they
should be backed out until those plugins get updated such that things
remain functional?

You could update the CI jobs to use a git ref that you’re happy works
with the current version of Katello?

No need to test against develop HEAD if there’s an incompatibility that
needs addressing.

I disagree. As developers, we’re always (should be) running with Foreman
develop latest and Katello master latest. Jenkins should test the same to
check for breakages.

Foreman PR’s should run the test_katello jenkins job to make sure that
nothing in Katello blows up, as well as whenever Foreman develop changes.

–
Dominic Cleal
Red Hat Engineering

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

adam price

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Bryan_Kearney · February 20, 2014, 12:48pm

My suggestion would be that daily workflows be against a nightly or 2
day old build. That way one nightlu job looks for "core breaks plugin"
and a second CI supports the PR process. When a build passes the
nightly, it can get moved to the PR build. That way, we catch core
breakage but those do not stop active development

– bk

···

On 02/20/2014 03:53 AM, Petr Chalupa wrote: > > > On 19.02.14 20:26, Ivan Necas wrote: >> Even short-term it solved the issue just partly: the nightlies get >> broken as well. >> >> We've been there few months ago (and similarly with pulp and candlepin >> long time before) and >> we alwys ended up with Katello decinding when is time to update the deps >> (and the issues were resolved on the time when the update happened). >> >> We could probably have a branch in Foreman >> repo that would point to the sha that we are targetting against. >> But it would probably also mean maintaing the repo holding tha >> foreman packages known to work with Katello. The downside is >> the risk of breaking changes landing into Foreman and Katello >> learning too late about that. Also, the burden of mainaing >> different set of repos could be painful. >> >> I would probably like more with CI running katello (and other plugins) >> tests with every PR in Foreman, indicating, if it's breaking or not >> and agreeing on the proceedure when some incombatible change is >> introduced: >> if it's going to be merged anyway, would be nice to have the patch for >> Katello >> prepared, so that we can just update simultaniously. > > +1 run Katello tests on each Foreman PR