On 1 February 2018 at 15:36, Emilien Macchi <emil...@redhat.com> wrote:
> > > On Thu, Feb 1, 2018 at 6:35 AM, Derek Higgins <der...@redhat.com> wrote: > >> Hi All, >> I've been working on a set of patches as a WIP to test ironic in the >> overcloud[1], the approach I've started with is to add ironic into the >> overcloud controller in scenario004. Also to run a script on the controller >> (as a NodeExtraConfigPost) that sets up a VM with vbmc that can then be >> controlled by ironic. The WIP currently replaces the current tempest tests >> with some commands to sanity test the setup. This essentially works but >> things need to be cleaned up a bit so I've a few questions >> >> o Is scenario004 the correct choice? >> > > Because we might increase the timeout risk on scenario004, I would > recommend to create a new dedicated scenario that would deploy a very basic > overcloud with just ironic + dependencies (keystone, glance, neutron, and > nova?) > Ok, I can do this > > >> >> o Should I create a new tempest test for baremetal as some of the >> networking stuff is different? >> > > I think we would need to run baremetal tests for this new featureset, see > existing files for examples. > Do you mean that we should use existing tests somewhere or create new ones? > > >> >> o Is running a script on the controller with NodeExtraConfigPost the best >> way to set this up or should I be doing something with quickstart? I don't >> think quickstart currently runs things on the controler does it? >> > > What kind of thing do you want to run exactly? > The contents to this file will give you an idea, somewhere I need to setup a node that ironic will control with ipmi https://review.openstack.org/#/c/485261/19/ci/common/vbmc_setup.yaml > I'll let the CI squad replies as well but I think we need a new scenario, > that we would only run when touching ironic files in tripleo. Using > scenario004 really increase the risk of timeout and we don't want it. > Ok > > Thanks for this work! > -- > 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 > >
__________________________________________________________________________ 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
