Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-12-07 Thread David Gurtner
I finally got around to split the RGW test into 3 steps: 1) mons/osds/keys 2) 
rgw/apache 3) keystone and got the tests for that to pass on Ubuntu. But it 
seems there is new EPEL dependency issue since yesterday:
https://review.openstack.org/#/c/252664/

David, maybe you wan't to rebase your changes on top of this for easier 
debugging?

- Original Message -
> I pushed an overly optimistic review [1] for updating Openstack to Liberty.
> Haven't had the time to look back at it yet.
> 
> The general idea was to defer the repository setup to openstack_extras and
> pull in
> the keystone setup mostly as-is directly from puppet-openstack-integration.
> 
> [1]: https://review.openstack.org/#/c/251531/
> 
> 
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> On Wed, Dec 2, 2015 at 5:45 AM, David Gurtner  wrote:
> 
> > So from the discussion I gather we should do the following:
> >
> > - Update the jobs to run Infernalis
> > - Split the RGW jobs into smaller chunks where one tests just the RGW and
> > another one tests Keystone integration
> > - Use Liberty (or at least Kilo) for the Keystone integration job
> > - Split the tests more to have a test specifically for cephx functionality
> > - re-enable the tests for CentOS once they work again
> >
> > Open points from my POV are:
> >
> > - should we test older Ceph versions via Jenkins (this would increase the
> > runtime again)
> > - should we still test CentOS 6 and Ubuntu 12.04
> > - if yes, where
> > - should we port more of the deprecated rspec-puppet-system tests? things
> > I can think of are: 1) the profile tests 2) the
> > scenario_node_terminus/hiera tests
> >
> > I'm happy to start working on the split of tests and the
> > Infernalis/Liberty version bump tonight.
> >
> > Cheers,
> > David
> >
> > - Original Message -
> > > Hey Adam,
> > >
> > > A bit late here, sorry.
> > > Ceph works fine with OpenStack Kilo but at the time we developed the
> > > integration tests for puppet-ceph with Kilo, there were some issues
> > > specific to our test implementation and we chose to settle with Juno
> > > at the time.
> > >
> > > On the topic of CI, I can no longer sponsor the third party CI
> > > (through my former employer, iWeb) as I am with Red Hat now.
> > > I see this as an opportunity to drop the custom system tests with
> > > vagrant and instead improve the acceptance tests.
> > >
> > > What do you think ?
> > >
> > >
> > > David Moreau Simard
> > > Senior Software Engineer | Openstack RDO
> > >
> > > dmsimard = [irc, github, twitter]
> > >
> > >
> > > On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
> > > > I'm confused, what is the context here? We use Ceph with OpenStack Kilo
> > > > without issue.
> > > >
> > > > On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:
> > > >>
> > > >> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> > > >> he bumped into some problems and we settled for Juno at the time [1].
> > > >> At this point we should already be testing against both Liberty and
> > > >> Infernalis, we're overdue for an upgrade in that regard.
> > > >>
> > > >> But, yes, +1 to split acceptance tests:
> > > >> 1) Ceph
> > > >> 2) Ceph + Openstack
> > > >>
> > > >> Actually learning what failed is indeed challenging sometimes, I don't
> > > >> have enough experience with the acceptance testing to suggest anything
> > > >> better.
> > > >> We have the flexibility of creating different logfiles, maybe we can
> > > >> find a way to split out the relevant bits into another file.
> > > >>
> > > >> [1]: https://review.openstack.org/#/c/153783/
> > > >>
> > > >> David Moreau Simard
> > > >> Senior Software Engineer | Openstack RDO
> > > >>
> > > >> dmsimard = [irc, github, twitter]
> > > >>
> > > >>
> > > >> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward 
> > wrote:
> > > >> > I think I have a good lead on the recent failures in openstack /
> > swift /
> > > >> > radosgw integration component that we have since disabled. It looks
> > like
> > > >> > there is a oslo.config version upgrade conflict in the Juno repo we
> > > >> > where
> > > >> > using for CentOS. I think moving to Kilo will help sort this out,
> > but at
> > > >> > the
> > > >> > same time I think it would be prudent to separate the Ceph v.s.
> > > >> > OpenStack
> > > >> > integration into separate jobs so that we have a better idea of
> > which is
> > > >> > a
> > > >> > problem. If there is census for this, I'd need some direction /
> > help, as
> > > >> > well as set them up as non-voting for now.
> > > >> >
> > > >> > Looking into this I also found that the only place that we do
> > > >> > integration
> > > >> > any of the cephx logic was in the same test so we will need to
> > create a
> > > >> > component for it in the ceph integration as well as use it in the
> > > >> > OpenStack
> > > >> > side.
> > > >> >

Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-12-02 Thread David Moreau Simard
I pushed an overly optimistic review [1] for updating Openstack to Liberty.
Haven't had the time to look back at it yet.

The general idea was to defer the repository setup to openstack_extras and
pull in
the keystone setup mostly as-is directly from puppet-openstack-integration.

[1]: https://review.openstack.org/#/c/251531/



David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Wed, Dec 2, 2015 at 5:45 AM, David Gurtner  wrote:

> So from the discussion I gather we should do the following:
>
> - Update the jobs to run Infernalis
> - Split the RGW jobs into smaller chunks where one tests just the RGW and
> another one tests Keystone integration
> - Use Liberty (or at least Kilo) for the Keystone integration job
> - Split the tests more to have a test specifically for cephx functionality
> - re-enable the tests for CentOS once they work again
>
> Open points from my POV are:
>
> - should we test older Ceph versions via Jenkins (this would increase the
> runtime again)
> - should we still test CentOS 6 and Ubuntu 12.04
> - if yes, where
> - should we port more of the deprecated rspec-puppet-system tests? things
> I can think of are: 1) the profile tests 2) the
> scenario_node_terminus/hiera tests
>
> I'm happy to start working on the split of tests and the
> Infernalis/Liberty version bump tonight.
>
> Cheers,
> David
>
> - Original Message -
> > Hey Adam,
> >
> > A bit late here, sorry.
> > Ceph works fine with OpenStack Kilo but at the time we developed the
> > integration tests for puppet-ceph with Kilo, there were some issues
> > specific to our test implementation and we chose to settle with Juno
> > at the time.
> >
> > On the topic of CI, I can no longer sponsor the third party CI
> > (through my former employer, iWeb) as I am with Red Hat now.
> > I see this as an opportunity to drop the custom system tests with
> > vagrant and instead improve the acceptance tests.
> >
> > What do you think ?
> >
> >
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> >
> > On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
> > > I'm confused, what is the context here? We use Ceph with OpenStack Kilo
> > > without issue.
> > >
> > > On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:
> > >>
> > >> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> > >> he bumped into some problems and we settled for Juno at the time [1].
> > >> At this point we should already be testing against both Liberty and
> > >> Infernalis, we're overdue for an upgrade in that regard.
> > >>
> > >> But, yes, +1 to split acceptance tests:
> > >> 1) Ceph
> > >> 2) Ceph + Openstack
> > >>
> > >> Actually learning what failed is indeed challenging sometimes, I don't
> > >> have enough experience with the acceptance testing to suggest anything
> > >> better.
> > >> We have the flexibility of creating different logfiles, maybe we can
> > >> find a way to split out the relevant bits into another file.
> > >>
> > >> [1]: https://review.openstack.org/#/c/153783/
> > >>
> > >> David Moreau Simard
> > >> Senior Software Engineer | Openstack RDO
> > >>
> > >> dmsimard = [irc, github, twitter]
> > >>
> > >>
> > >> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward 
> wrote:
> > >> > I think I have a good lead on the recent failures in openstack /
> swift /
> > >> > radosgw integration component that we have since disabled. It looks
> like
> > >> > there is a oslo.config version upgrade conflict in the Juno repo we
> > >> > where
> > >> > using for CentOS. I think moving to Kilo will help sort this out,
> but at
> > >> > the
> > >> > same time I think it would be prudent to separate the Ceph v.s.
> > >> > OpenStack
> > >> > integration into separate jobs so that we have a better idea of
> which is
> > >> > a
> > >> > problem. If there is census for this, I'd need some direction /
> help, as
> > >> > well as set them up as non-voting for now.
> > >> >
> > >> > Looking into this I also found that the only place that we do
> > >> > integration
> > >> > any of the cephx logic was in the same test so we will need to
> create a
> > >> > component for it in the ceph integration as well as use it in the
> > >> > OpenStack
> > >> > side.
> > >> >
> > >> > Lastly un-winding the integration failure seemed overly complex. Is
> > >> > there a
> > >> > way that we can correlate the test status inside the job at a high
> level
> > >> > besides the entire job passed / failed without breaking them into
> > >> > separate
> > >> > jobs?
> > >> > --
> > >> >
> > >> > --
> > >> >
> > >> > Andrew Woodward
> > >> >
> > >> > Mirantis
> > >> >
> > >> > Fuel Community Ambassador
> > >> >
> > >> > Ceph Community
> > >> >
> > >> >
> > >> >
> > >> >
> __
> > >> > OpenStack Development Mailing List 

Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-12-02 Thread David Gurtner
So from the discussion I gather we should do the following:

- Update the jobs to run Infernalis
- Split the RGW jobs into smaller chunks where one tests just the RGW and 
another one tests Keystone integration
- Use Liberty (or at least Kilo) for the Keystone integration job
- Split the tests more to have a test specifically for cephx functionality
- re-enable the tests for CentOS once they work again

Open points from my POV are:

- should we test older Ceph versions via Jenkins (this would increase the 
runtime again)
- should we still test CentOS 6 and Ubuntu 12.04
- if yes, where
- should we port more of the deprecated rspec-puppet-system tests? things I can 
think of are: 1) the profile tests 2) the scenario_node_terminus/hiera tests

I'm happy to start working on the split of tests and the Infernalis/Liberty 
version bump tonight.

Cheers,
David

- Original Message -
> Hey Adam,
> 
> A bit late here, sorry.
> Ceph works fine with OpenStack Kilo but at the time we developed the
> integration tests for puppet-ceph with Kilo, there were some issues
> specific to our test implementation and we chose to settle with Juno
> at the time.
> 
> On the topic of CI, I can no longer sponsor the third party CI
> (through my former employer, iWeb) as I am with Red Hat now.
> I see this as an opportunity to drop the custom system tests with
> vagrant and instead improve the acceptance tests.
> 
> What do you think ?
> 
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> 
> On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
> > I'm confused, what is the context here? We use Ceph with OpenStack Kilo
> > without issue.
> >
> > On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:
> >>
> >> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> >> he bumped into some problems and we settled for Juno at the time [1].
> >> At this point we should already be testing against both Liberty and
> >> Infernalis, we're overdue for an upgrade in that regard.
> >>
> >> But, yes, +1 to split acceptance tests:
> >> 1) Ceph
> >> 2) Ceph + Openstack
> >>
> >> Actually learning what failed is indeed challenging sometimes, I don't
> >> have enough experience with the acceptance testing to suggest anything
> >> better.
> >> We have the flexibility of creating different logfiles, maybe we can
> >> find a way to split out the relevant bits into another file.
> >>
> >> [1]: https://review.openstack.org/#/c/153783/
> >>
> >> David Moreau Simard
> >> Senior Software Engineer | Openstack RDO
> >>
> >> dmsimard = [irc, github, twitter]
> >>
> >>
> >> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
> >> > I think I have a good lead on the recent failures in openstack / swift /
> >> > radosgw integration component that we have since disabled. It looks like
> >> > there is a oslo.config version upgrade conflict in the Juno repo we
> >> > where
> >> > using for CentOS. I think moving to Kilo will help sort this out, but at
> >> > the
> >> > same time I think it would be prudent to separate the Ceph v.s.
> >> > OpenStack
> >> > integration into separate jobs so that we have a better idea of which is
> >> > a
> >> > problem. If there is census for this, I'd need some direction / help, as
> >> > well as set them up as non-voting for now.
> >> >
> >> > Looking into this I also found that the only place that we do
> >> > integration
> >> > any of the cephx logic was in the same test so we will need to create a
> >> > component for it in the ceph integration as well as use it in the
> >> > OpenStack
> >> > side.
> >> >
> >> > Lastly un-winding the integration failure seemed overly complex. Is
> >> > there a
> >> > way that we can correlate the test status inside the job at a high level
> >> > besides the entire job passed / failed without breaking them into
> >> > separate
> >> > jobs?
> >> > --
> >> >
> >> > --
> >> >
> >> > Andrew Woodward
> >> >
> >> > Mirantis
> >> >
> >> > Fuel Community Ambassador
> >> >
> >> > Ceph Community
> >> >
> >> >
> >> >
> >> > __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 

Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-12-02 Thread Loic Dachary
Hi David,

On 02/12/2015 11:45, David Gurtner wrote:
> So from the discussion I gather we should do the following:
> 
> - Update the jobs to run Infernalis
> - Split the RGW jobs into smaller chunks where one tests just the RGW and 
> another one tests Keystone integration
> - Use Liberty (or at least Kilo) for the Keystone integration job
> - Split the tests more to have a test specifically for cephx functionality
> - re-enable the tests for CentOS once they work again

Sounds good to me.

> 
> Open points from my POV are:
> 
> - should we test older Ceph versions via Jenkins (this would increase the 
> runtime again)
> - should we still test CentOS 6 and Ubuntu 12.04
> - if yes, where
> - should we port more of the deprecated rspec-puppet-system tests? things I 
> can think of are: 1) the profile tests 2) the scenario_node_terminus/hiera 
> tests

Since Ceph stopped testing CentOS 6 and Ubuntu 12.04, even for existing stable 
versions, I think it will be increasingly difficult for puppet-ceph to support 
these operating systems. This is not to say this is futile, on the contrary ;-)

My 2cts.

> I'm happy to start working on the split of tests and the Infernalis/Liberty 
> version bump tonight.
> 
> Cheers,
> David
> 
> - Original Message -
>> Hey Adam,
>>
>> A bit late here, sorry.
>> Ceph works fine with OpenStack Kilo but at the time we developed the
>> integration tests for puppet-ceph with Kilo, there were some issues
>> specific to our test implementation and we chose to settle with Juno
>> at the time.
>>
>> On the topic of CI, I can no longer sponsor the third party CI
>> (through my former employer, iWeb) as I am with Red Hat now.
>> I see this as an opportunity to drop the custom system tests with
>> vagrant and instead improve the acceptance tests.
>>
>> What do you think ?
>>
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>>
>> On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
>>> I'm confused, what is the context here? We use Ceph with OpenStack Kilo
>>> without issue.
>>>
>>> On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:

 Last I remember, David Gurtner tried to use Kilo instead of Juno but
 he bumped into some problems and we settled for Juno at the time [1].
 At this point we should already be testing against both Liberty and
 Infernalis, we're overdue for an upgrade in that regard.

 But, yes, +1 to split acceptance tests:
 1) Ceph
 2) Ceph + Openstack

 Actually learning what failed is indeed challenging sometimes, I don't
 have enough experience with the acceptance testing to suggest anything
 better.
 We have the flexibility of creating different logfiles, maybe we can
 find a way to split out the relevant bits into another file.

 [1]: https://review.openstack.org/#/c/153783/

 David Moreau Simard
 Senior Software Engineer | Openstack RDO

 dmsimard = [irc, github, twitter]


 On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
> I think I have a good lead on the recent failures in openstack / swift /
> radosgw integration component that we have since disabled. It looks like
> there is a oslo.config version upgrade conflict in the Juno repo we
> where
> using for CentOS. I think moving to Kilo will help sort this out, but at
> the
> same time I think it would be prudent to separate the Ceph v.s.
> OpenStack
> integration into separate jobs so that we have a better idea of which is
> a
> problem. If there is census for this, I'd need some direction / help, as
> well as set them up as non-voting for now.
>
> Looking into this I also found that the only place that we do
> integration
> any of the cephx logic was in the same test so we will need to create a
> component for it in the ceph integration as well as use it in the
> OpenStack
> side.
>
> Lastly un-winding the integration failure seemed overly complex. Is
> there a
> way that we can correlate the test status inside the job at a high level
> besides the entire job passed / failed without breaking them into
> separate
> jobs?
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 

Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-11-30 Thread David Moreau Simard
Hey Adam,

A bit late here, sorry.
Ceph works fine with OpenStack Kilo but at the time we developed the
integration tests for puppet-ceph with Kilo, there were some issues
specific to our test implementation and we chose to settle with Juno
at the time.

On the topic of CI, I can no longer sponsor the third party CI
(through my former employer, iWeb) as I am with Red Hat now.
I see this as an opportunity to drop the custom system tests with
vagrant and instead improve the acceptance tests.

What do you think ?


David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Mon, Nov 23, 2015 at 6:45 PM, Adam Lawson  wrote:
> I'm confused, what is the context here? We use Ceph with OpenStack Kilo
> without issue.
>
> On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:
>>
>> Last I remember, David Gurtner tried to use Kilo instead of Juno but
>> he bumped into some problems and we settled for Juno at the time [1].
>> At this point we should already be testing against both Liberty and
>> Infernalis, we're overdue for an upgrade in that regard.
>>
>> But, yes, +1 to split acceptance tests:
>> 1) Ceph
>> 2) Ceph + Openstack
>>
>> Actually learning what failed is indeed challenging sometimes, I don't
>> have enough experience with the acceptance testing to suggest anything
>> better.
>> We have the flexibility of creating different logfiles, maybe we can
>> find a way to split out the relevant bits into another file.
>>
>> [1]: https://review.openstack.org/#/c/153783/
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>>
>> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
>> > I think I have a good lead on the recent failures in openstack / swift /
>> > radosgw integration component that we have since disabled. It looks like
>> > there is a oslo.config version upgrade conflict in the Juno repo we
>> > where
>> > using for CentOS. I think moving to Kilo will help sort this out, but at
>> > the
>> > same time I think it would be prudent to separate the Ceph v.s.
>> > OpenStack
>> > integration into separate jobs so that we have a better idea of which is
>> > a
>> > problem. If there is census for this, I'd need some direction / help, as
>> > well as set them up as non-voting for now.
>> >
>> > Looking into this I also found that the only place that we do
>> > integration
>> > any of the cephx logic was in the same test so we will need to create a
>> > component for it in the ceph integration as well as use it in the
>> > OpenStack
>> > side.
>> >
>> > Lastly un-winding the integration failure seemed overly complex. Is
>> > there a
>> > way that we can correlate the test status inside the job at a high level
>> > besides the entire job passed / failed without breaking them into
>> > separate
>> > jobs?
>> > --
>> >
>> > --
>> >
>> > Andrew Woodward
>> >
>> > Mirantis
>> >
>> > Fuel Community Ambassador
>> >
>> > Ceph Community
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-11-23 Thread David Moreau Simard
Last I remember, David Gurtner tried to use Kilo instead of Juno but
he bumped into some problems and we settled for Juno at the time [1].
At this point we should already be testing against both Liberty and
Infernalis, we're overdue for an upgrade in that regard.

But, yes, +1 to split acceptance tests:
1) Ceph
2) Ceph + Openstack

Actually learning what failed is indeed challenging sometimes, I don't
have enough experience with the acceptance testing to suggest anything
better.
We have the flexibility of creating different logfiles, maybe we can
find a way to split out the relevant bits into another file.

[1]: https://review.openstack.org/#/c/153783/

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
> I think I have a good lead on the recent failures in openstack / swift /
> radosgw integration component that we have since disabled. It looks like
> there is a oslo.config version upgrade conflict in the Juno repo we where
> using for CentOS. I think moving to Kilo will help sort this out, but at the
> same time I think it would be prudent to separate the Ceph v.s. OpenStack
> integration into separate jobs so that we have a better idea of which is a
> problem. If there is census for this, I'd need some direction / help, as
> well as set them up as non-voting for now.
>
> Looking into this I also found that the only place that we do integration
> any of the cephx logic was in the same test so we will need to create a
> component for it in the ceph integration as well as use it in the OpenStack
> side.
>
> Lastly un-winding the integration failure seemed overly complex. Is there a
> way that we can correlate the test status inside the job at a high level
> besides the entire job passed / failed without breaking them into separate
> jobs?
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-11-23 Thread Adam Lawson
I'm confused, what is the context here? We use Ceph with OpenStack Kilo
without issue.
On Nov 23, 2015 2:28 PM, "David Moreau Simard"  wrote:

> Last I remember, David Gurtner tried to use Kilo instead of Juno but
> he bumped into some problems and we settled for Juno at the time [1].
> At this point we should already be testing against both Liberty and
> Infernalis, we're overdue for an upgrade in that regard.
>
> But, yes, +1 to split acceptance tests:
> 1) Ceph
> 2) Ceph + Openstack
>
> Actually learning what failed is indeed challenging sometimes, I don't
> have enough experience with the acceptance testing to suggest anything
> better.
> We have the flexibility of creating different logfiles, maybe we can
> find a way to split out the relevant bits into another file.
>
> [1]: https://review.openstack.org/#/c/153783/
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward  wrote:
> > I think I have a good lead on the recent failures in openstack / swift /
> > radosgw integration component that we have since disabled. It looks like
> > there is a oslo.config version upgrade conflict in the Juno repo we where
> > using for CentOS. I think moving to Kilo will help sort this out, but at
> the
> > same time I think it would be prudent to separate the Ceph v.s. OpenStack
> > integration into separate jobs so that we have a better idea of which is
> a
> > problem. If there is census for this, I'd need some direction / help, as
> > well as set them up as non-voting for now.
> >
> > Looking into this I also found that the only place that we do integration
> > any of the cephx logic was in the same test so we will need to create a
> > component for it in the ceph integration as well as use it in the
> OpenStack
> > side.
> >
> > Lastly un-winding the integration failure seemed overly complex. Is
> there a
> > way that we can correlate the test status inside the job at a high level
> > besides the entire job passed / failed without breaking them into
> separate
> > jobs?
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

2015-06-30 Thread Emilien Macchi


On 06/29/2015 11:16 PM, Matt Fischer wrote:
 Ah, I don't have +2 on that repo, but the lgtm so your original plan is
 fine.
 
 On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer m...@mattfischer.com
 mailto:m...@mattfischer.com wrote:
 
 I can take a look at these tonight. Maybe also Clayton can review
 them? Neither of us were involved in the patches to my knowledge.
 
 On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com
 mailto:xar...@gmail.com wrote:
 
 Hi
 
 Recent changes in the puppet modules infra left
 stackforge/puppet-ceph CI broken. We've resolved the issues in
 [1][2] However we are short on non-involved core-reviewers. 

You'll have to sqash the commits because our CI is voting for puppet4 
beaker.

If this module does not fit for you, you can still patch project-config,
otherwise you'll need to fix everything in one single commit.

 I propose that we leave the patchs open through Wednesday and
 use lazy consensus and merge it if we don't receive any negative
 feedback.
 
 [1] https://review.openstack.org/#/c/179645/
 [2] https://review.openstack.org/#/c/195959/
 -- 
 
 --
 
 Andrew Woodward
 
 Mirantis
 
 Fuel Community Ambassador
 
 Ceph Community
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

2015-06-30 Thread David Moreau Simard
I merged the https://review.openstack.org/#/c/197302/ as we had agreed that 
once we had enough +1's on the EL7 review we would merge it.

The Puppet4 spec tests had already been approved.

--
David Moreau Simard
Cloud Engineering | Operations

On 2015-06-30 07:06 PM, Andrew Woodward wrote:


On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi 
emil...@redhat.commailto:emil...@redhat.com wrote:


On 06/29/2015 11:16 PM, Matt Fischer wrote:
 Ah, I don't have +2 on that repo, but the lgtm so your original plan is
 fine.

 On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer 
 mailto:m...@mattfischer.comm...@mattfischer.commailto:m...@mattfischer.com
 mailto:m...@mattfischer.commailto:m...@mattfischer.com wrote:

 I can take a look at these tonight. Maybe also Clayton can review
 them? Neither of us were involved in the patches to my knowledge.

 On Jun 29, 2015 5:09 PM, Andrew Woodward 
 mailto:xar...@gmail.comxar...@gmail.commailto:xar...@gmail.com
 mailto:xar...@gmail.commailto:xar...@gmail.com wrote:

 Hi

 Recent changes in the puppet modules infra left
 stackforge/puppet-ceph CI broken. We've resolved the issues in
 [1][2] However we are short on non-involved core-reviewers.

You'll have to sqash the commits because our CI is voting for puppet4 
beaker.
Thanks

David squished it up into [3]. The same message applies I'm going to use lazy 
census here and if we don't have any negative feed back we should just merge it 
so we get CI back to passing

[3] https://review.openstack.org/#/c/197302/


If this module does not fit for you, you can still patch project-config,
otherwise you'll need to fix everything in one single commit.

 I propose that we leave the patchs open through Wednesday and
 use lazy consensus and merge it if we don't receive any negative
 feedback.

 [1] https://review.openstack.org/#/c/179645/
 [2] https://review.openstack.org/#/c/195959/
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community


 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

2015-06-30 Thread Andrew Woodward
On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi emil...@redhat.com wrote:



 On 06/29/2015 11:16 PM, Matt Fischer wrote:
  Ah, I don't have +2 on that repo, but the lgtm so your original plan is
  fine.
 
  On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer m...@mattfischer.com
  mailto:m...@mattfischer.com wrote:
 
  I can take a look at these tonight. Maybe also Clayton can review
  them? Neither of us were involved in the patches to my knowledge.
 
  On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com
  mailto:xar...@gmail.com wrote:
 
  Hi
 
  Recent changes in the puppet modules infra left
  stackforge/puppet-ceph CI broken. We've resolved the issues in
  [1][2] However we are short on non-involved core-reviewers.

 You'll have to sqash the commits because our CI is voting for puppet4 
 beaker.

Thanks

David squished it up into [3]. The same message applies I'm going to use
lazy census here and if we don't have any negative feed back we should just
merge it so we get CI back to passing

[3] https://review.openstack.org/#/c/197302/



 If this module does not fit for you, you can still patch project-config,
 otherwise you'll need to fix everything in one single commit.

  I propose that we leave the patchs open through Wednesday and
  use lazy consensus and merge it if we don't receive any negative
  feedback.
 
  [1] https://review.openstack.org/#/c/179645/
  [2] https://review.openstack.org/#/c/195959/
  --
 
  --
 
  Andrew Woodward
 
  Mirantis
 
  Fuel Community Ambassador
 
  Ceph Community
 
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 --
 Emilien Macchi

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

2015-06-29 Thread Matt Fischer
Ah, I don't have +2 on that repo, but the lgtm so your original plan is
fine.

On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer m...@mattfischer.com wrote:

 I can take a look at these tonight. Maybe also Clayton can review them?
 Neither of us were involved in the patches to my knowledge.
 On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com wrote:

 Hi

 Recent changes in the puppet modules infra left stackforge/puppet-ceph CI
 broken. We've resolved the issues in [1][2] However we are short on
 non-involved core-reviewers.

 I propose that we leave the patchs open through Wednesday and use lazy
 consensus and merge it if we don't receive any negative feedback.

 [1] https://review.openstack.org/#/c/179645/
 [2] https://review.openstack.org/#/c/195959/
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

2015-06-29 Thread Matt Fischer
I can take a look at these tonight. Maybe also Clayton can review them?
Neither of us were involved in the patches to my knowledge.
On Jun 29, 2015 5:09 PM, Andrew Woodward xar...@gmail.com wrote:

 Hi

 Recent changes in the puppet modules infra left stackforge/puppet-ceph CI
 broken. We've resolved the issues in [1][2] However we are short on
 non-involved core-reviewers.

 I propose that we leave the patchs open through Wednesday and use lazy
 consensus and merge it if we don't receive any negative feedback.

 [1] https://review.openstack.org/#/c/179645/
 [2] https://review.openstack.org/#/c/195959/
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev