Alex, we can do this (and I hope we'll do) after we fix https://bugs.launchpad.net/fuel/+bug/1567367
Regards, Alex On Thu, Apr 7, 2016 at 5:04 PM, Alex Schultz <aschu...@mirantis.com> wrote: > > On Thu, Apr 7, 2016 at 7:41 AM, Aleksandr Didenko <adide...@mirantis.com> > wrote: > >> Hi, >> >> thanks to Dima, we now have ROLE annotations in noop tests [0]. I've >> updated all the noop rspec tests that we currently have and added >> appropriate role annotation [1]. So after this patch is merged, we no >> longer need to put any new fixtures into dozens of rspec files in order to >> enable it. >> Please make sure to update ROLE annotations if you introduce new roles >> (deployment groups) or change task-to-roles assignments in *tasks.yaml >> files. Core reviewers, please don't forget to check this as well ;) >> >> > Is there a reason we can't leverage the existing definitions in the > tasks.yaml files for this? It seems like requiring people to provide this > information might lead to cases where it's gets out of sync. Shouldn't we > use the task files as the source of truth for the roles? > > -Alex > > >> Regards, >> Alex >> >> [0] https://review.openstack.org/300649 >> [1] https://review.openstack.org/302313 >> >> On Tue, Apr 5, 2016 at 12:11 PM, Aleksandr Didenko <adide...@mirantis.com >> > wrote: >> >>> Hi folks, >>> >>> we've merged all the changes related to fixtures update [0] and bugfix >>> to unblock noop tests [1]. So if you see -1 from fuel_noop_tests [2] in >>> tests not related to your patch, then please rebase. >>> >>> Regards, >>> Alex >>> >>> [0] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0 >>> [1] https://review.openstack.org/301107 >>> [2] https://ci.fuel-infra.org/job/fuellib_noop_tests/ >>> >>> On Fri, Apr 1, 2016 at 7:16 PM, Vladimir Kuklin <vkuk...@mirantis.com> >>> wrote: >>> >>>> Hi Alex >>>> >>>> +1 to your proposal - this is long-awaited change. >>>> >>>> On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko < >>>> adide...@mirantis.com> wrote: >>>> >>>>> One more thing about spec to fixture mapping [0]. What if instead of: >>>>> >>>>> # RUN: (hiera1) (facts1) >>>>> >>>>> we'll use >>>>> >>>>> # RUN: (roles_array1) (facts1) >>>>> >>>>> ? >>>>> >>>>> We don't need to duplicate complicated task graph calculations to >>>>> understand which task to execute, because we don't care about tasks >>>>> ordering and dependencies in noop tests. All we need is to map rspec task >>>>> tests to astute.yaml fixtures. And it could be done via roles. >>>>> >>>>> Regards, >>>>> Alex >>>>> >>>>> [0] >>>>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations >>>>> >>>>> >>>>> On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko < >>>>> adide...@mirantis.com> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> As you may know, we're still using some very old astute.yaml >>>>>> fixtures (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides >>>>>> that, >>>>>> we have problems with fixture-to-rspec mapping [1]. So we've started to >>>>>> work on those problems [2]. >>>>>> >>>>>> So please be aware of upcoming changes in noop rspec fixtures and >>>>>> tests. If you see, that some important fixtures are missing (thus not >>>>>> covered by tests) please let me know in this email thread or via >>>>>> IRC/email/slack. >>>>>> >>>>>> Also, we should stop updating astute.yaml fixtures manually and >>>>>> start using some kind of automation approach instead [3][4]. I propose to >>>>>> use [5] script until we find a better solution. So if you want to add >>>>>> some >>>>>> new astute.yaml fixture for noop tests, please propose a patch to this >>>>>> script instead of uploading yaml file. >>>>>> >>>>>> Currently the following is missing in the new set of fixtures for >>>>>> fuel-9.0: >>>>>> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to >>>>>> properly enable it via nailgun, any help is much appreciated) >>>>>> - selective ssl fixtures - since configuration data is not serialized >>>>>> from nailgun, I think that we should move this into 'hiera/override' >>>>>> along >>>>>> with implementation of new hiera overrides tests workflow [6] >>>>>> - vmware related fixtures >>>>>> >>>>>> Please feel free to share your ideas/comments on this topic. >>>>>> >>>>>> Thanks, >>>>>> Alex >>>>>> >>>>>> [0] https://bugs.launchpad.net/fuel/+bug/1535339 >>>>>> [1] >>>>>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations >>>>>> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0 >>>>>> [3] >>>>>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst >>>>>> [4] >>>>>> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator >>>>>> [5] >>>>>> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh >>>>>> [6] https://bugs.launchpad.net/fuel/+bug/1564919 >>>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Yours Faithfully, >>>> Vladimir Kuklin, >>>> Fuel Library Tech Lead, >>>> Mirantis, Inc. >>>> +7 (495) 640-49-04 >>>> +7 (926) 702-39-68 >>>> Skype kuklinvv >>>> 35bk3, Vorontsovskaya Str. >>>> Moscow, Russia, >>>> www.mirantis.com <http://www.mirantis.ru/> >>>> www.mirantis.ru >>>> vkuk...@mirantis.com >>>> >>>> >>>> __________________________________________________________________________ >>>> 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