Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling
Also +1.__ 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] [openstack-ansible] Proposing Mohammed Naser as core reviewer
+2 from me. Marc Gariépy On 2018-04-24 11:05 AM, Jean-Philippe Evrard wrote: Hi everyone, I’d like to propose Mohammed Naser [1] as a core reviewer for OpenStack-Ansible. He has been working actively on fixing the telemetry stack, and is now willing to step up to improve the CentOS platform which is now in a very degraded state. I feel that it’s important that he’s able to safeguard the existing and future work about CentOS and help grow the maintenance community for it. [1] http://stackalytics.com/?module=openstackansible-group&user_id=mnaser&release=rocky&metric=person-day Best regards, Jean-Philippe Evrard IRC: evrardjp __ 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-dev] [qa] resigning from Tempest core
Hi folks, as already mentioned during the current code sprint: I am currently lacking time for reviews and code contributions. I think it better to step back and let other’s in that are more active. Thanks for all the support and it was really fun the past 3 years working with you! Regards Marc __ 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] [Neutron][ml2][Manila] API to query segments used during port binding
Hi folks,
I had a deep dive session with Bob (thx Bob).
We have a plan to solve the issue without any change of APIs or
manila driver reworks.
The process will look like the following:
1.) In case of multi-segment/hpb Manila creates a port like Ironic ML2
would do it [1]:
vif_type = baremetal
binding_profile = list of sw ports
device_owner = manila:ID
2.) Manila waits until all ports are actively bound
2.a) Neutron binds the port through the segments
2.b) A manila-neutron mech driver (a really simple one) fulfils the binding
and sets:
vif_details = {“share_segmentation_id" = XX,
“share_network_type" = YY}
3.) When the port becomes active Manila has all it needs to proceed
In 2.b. the manila MD will only search for device_owner == “manila:”,
sets the needed details and fulfils the binding (~10 LOC).
We also discussed about using ML2 GW [2] or trunk port [3].
I consider the design above as simple enough to get merged smoothly
in Newton.
@Ben: Will be back for bug hunting now.
Regards
Marc
[1]:
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
<https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html>
[2]: https://wiki.openstack.org/wiki/Neutron/L2-GW
[3]: https://wiki.openstack.org/wiki/Neutron/TrunkPort
> On 09 Mar 2016, at 09:25, Koderer, Marc wrote:
>
>>
>> On 09 Mar 2016, at 08:43, Sukhdev Kapur > <mailto:sukhdevka...@gmail.com>> wrote:
>>
>> Hi Marc,
>>
>> I am driving the ironic-ml2 integration and introduced baremetal type for
>> vmic_type.
>
> Basically that’s my plan. So in my current implementation
> I use the baremetal vnic_type [1] and add a binding profile [2].
>
>> You can very much use the same integration here - however, I am not
>> completely clear about your use case.
>> Do you want neutron/ML2 to plumb the network for Manila or do you want to
>> find out what VLAN (segmentation id) is used on the segment which connects
>> TOR to the storage device?
>
> Generally I want to find the best architecture for this feature :)
> Introducing a neutron-agent that does the plumbing will mean this agent needs
> to have a connection to the storage node itself. So we will end-up in a
> storage agent with a driver model (or an agent for each storage device). On
> the other side it follows the idea that neutron takes care about networking.
>
> From a Manila perspective the easiest solution would be to have an interface
> to
> get the segmentation id of the lowest bound segment.
>
>>
>> You had this on the agenda of ML2 meeting for tomorrow and I was going to
>> discuss this with you in the meeting. But, I noticed that you removed it
>> from the agenda. Do you have what you need? If not, you may want to join us
>> in the ML2 meeting tomorrow and we can discuss this use case there.
>
> Yeah I am sorry - I have to move the topic +1 week due to an internal meeting
> :(
> But we can have a chat on IRC (mkoderer on freenode).
>
> Regards
> Marc
>
> [1]: https://review.openstack.org/#/c/283494/
> <https://review.openstack.org/#/c/283494/>
> [2]: https://review.openstack.org/#/c/284034/
> <https://review.openstack.org/#/c/284034/>
>
>
>>
>> -Sukhdev
>>
>>
>> On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc > <mailto:m...@koderer.com>> wrote:
>>
>>> On 01 Mar 2016, at 06:22, Kevin Benton >> <mailto:ke...@benton.pub>> wrote:
>>>
>>> >This seems gross and backwards. It makes sense as a short term hack but
>>> >given that we have time to design this correctly I'd prefer to get this
>>> >information in a more straighforward way.
>>>
>>> Well it depends on what is happening here. If Manilla is wiring up a
>>> specific VLAN for a port, that makes it part of the port binding process,
>>> in which case it should be an ML2 driver. Can you provide some more details
>>> about what Manilla is doing with this info?
>>
>> The VLAN segment ID and IP address is used in the share driver to configure
>> the
>> corresponding interface resources within the storage. Just to give some
>> examples:
>>
>> - NetApp driver uses it to create a logical interface and assign it to a
>>“storage virtual machine” [1]
>> - EMC driver does it in similar manner [2]
>>
>> My idea was to use the same principle as ironic ml2 intregration is doing [3]
>> by setting the vnic_type to “baremetal”.
>>
>> In Manila's current implementation storage driv
Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding
> On 09 Mar 2016, at 08:43, Sukhdev Kapur wrote: > > Hi Marc, > > I am driving the ironic-ml2 integration and introduced baremetal type for > vmic_type. Basically that’s my plan. So in my current implementation I use the baremetal vnic_type [1] and add a binding profile [2]. > You can very much use the same integration here - however, I am not > completely clear about your use case. > Do you want neutron/ML2 to plumb the network for Manila or do you want to > find out what VLAN (segmentation id) is used on the segment which connects > TOR to the storage device? Generally I want to find the best architecture for this feature :) Introducing a neutron-agent that does the plumbing will mean this agent needs to have a connection to the storage node itself. So we will end-up in a storage agent with a driver model (or an agent for each storage device). On the other side it follows the idea that neutron takes care about networking. From a Manila perspective the easiest solution would be to have an interface to get the segmentation id of the lowest bound segment. > > You had this on the agenda of ML2 meeting for tomorrow and I was going to > discuss this with you in the meeting. But, I noticed that you removed it from > the agenda. Do you have what you need? If not, you may want to join us in the > ML2 meeting tomorrow and we can discuss this use case there. Yeah I am sorry - I have to move the topic +1 week due to an internal meeting :( But we can have a chat on IRC (mkoderer on freenode). Regards Marc [1]: https://review.openstack.org/#/c/283494/ <https://review.openstack.org/#/c/283494/> [2]: https://review.openstack.org/#/c/284034/ <https://review.openstack.org/#/c/284034/> > > -Sukhdev > > > On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc <mailto:m...@koderer.com>> wrote: > >> On 01 Mar 2016, at 06:22, Kevin Benton > <mailto:ke...@benton.pub>> wrote: >> >> >This seems gross and backwards. It makes sense as a short term hack but >> >given that we have time to design this correctly I'd prefer to get this >> >information in a more straighforward way. >> >> Well it depends on what is happening here. If Manilla is wiring up a >> specific VLAN for a port, that makes it part of the port binding process, in >> which case it should be an ML2 driver. Can you provide some more details >> about what Manilla is doing with this info? > > The VLAN segment ID and IP address is used in the share driver to configure > the > corresponding interface resources within the storage. Just to give some > examples: > > - NetApp driver uses it to create a logical interface and assign it to a >“storage virtual machine” [1] > - EMC driver does it in similar manner [2] > > My idea was to use the same principle as ironic ml2 intregration is doing [3] > by setting the vnic_type to “baremetal”. > > In Manila's current implementation storage drivers are also responsible to > setup the right networking setup. Would you suggest to move this part into the > port binding phase? > > Regards > Marc > > > [1]: > https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272 > > <https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272> > [2]: > https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609 > > <https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609> > [3]: > https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html > > <https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html> > > >> >> On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander > <mailto:b...@swartzlander.org>> wrote: >> On 02/29/2016 04:38 PM, Kevin Benton wrote: >> You're correct. Right now there is no way via the HTTP API to find which >> segments a port is bound to. >> This is something we can certainly consider adding, but it will need an >> RFE so it wouldn't land until Newton at the earliest. >> >> I believe Newton is the target for this work. This is feature freeze week >> after all. >> >> Have you considered writing an ML2 driver that just notifies Manilla of >> the port's segment info? All of this information is available to ML2 >> drivers in the PortContext object that is passed to them. >> >> This seems gross and backwards. It makes sense as a short term hack but >> given that w
Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding
> On 01 Mar 2016, at 06:22, Kevin Benton wrote: > > >This seems gross and backwards. It makes sense as a short term hack but > >given that we have time to design this correctly I'd prefer to get this > >information in a more straighforward way. > > Well it depends on what is happening here. If Manilla is wiring up a specific > VLAN for a port, that makes it part of the port binding process, in which > case it should be an ML2 driver. Can you provide some more details about what > Manilla is doing with this info? The VLAN segment ID and IP address is used in the share driver to configure the corresponding interface resources within the storage. Just to give some examples: - NetApp driver uses it to create a logical interface and assign it to a “storage virtual machine” [1] - EMC driver does it in similar manner [2] My idea was to use the same principle as ironic ml2 intregration is doing [3] by setting the vnic_type to “baremetal”. In Manila's current implementation storage drivers are also responsible to setup the right networking setup. Would you suggest to move this part into the port binding phase? Regards Marc [1]: https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272 <https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272> [2]: https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609 <https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609> [3]: https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html <https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html> > > On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander <mailto:b...@swartzlander.org>> wrote: > On 02/29/2016 04:38 PM, Kevin Benton wrote: > You're correct. Right now there is no way via the HTTP API to find which > segments a port is bound to. > This is something we can certainly consider adding, but it will need an > RFE so it wouldn't land until Newton at the earliest. > > I believe Newton is the target for this work. This is feature freeze week > after all. > > Have you considered writing an ML2 driver that just notifies Manilla of > the port's segment info? All of this information is available to ML2 > drivers in the PortContext object that is passed to them. > > This seems gross and backwards. It makes sense as a short term hack but given > that we have time to design this correctly I'd prefer to get this information > in a more straighforward way. > > -Ben Swartzlander > > > On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka <mailto:ihrac...@redhat.com> > <mailto:ihrac...@redhat.com <mailto:ihrac...@redhat.com>>> wrote: > > Fixed neutron tag in the subject. > > Marc mailto:m...@koderer.com> <mailto:m...@koderer.com > <mailto:m...@koderer.com>>> wrote: > > Hi Neutron team, > > I am currently working on a feature for hierarchical port > binding support in > Manila [1] [2]. Just to give some context: In the current > implementation Manila > creates a neutron port but let it unbound (state DOWN). > Therefore Manila uses > the port create only retrieve an IP address and segmentation ID > (some drivers > only support VLAN here). > > My idea is to change this behavior and do an actual port binding > action so that > the configuration of VLAN isn’t a manual job any longer. And > that multi-segment > and HPB is supported on the long-run. > > My current issue is: How can Manila retrieve the segment > information for a > bound port? Manila only is interested in the last (bottom) > segmentation ID > since I assume the storage is connected to a ToR switch. > > Database-wise it’s possible to query it using > ml2_port_binding_levels table. > But AFAIK there is no API to query this. The only information > that is exposed > are all segments of a network. But this is not sufficient to > identify which > segments actually used for a port binding. > > Regards > Marc > SAP SE > > [1]: > > https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support > <https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support> > [2]: https://review.openstack.org/#/c/277731
[openstack-dev] [Neuton][ml2][Manila] API to query segments used during port binding
Hi Neutron team, I am currently working on a feature for hierarchical port binding support in Manila [1] [2]. Just to give some context: In the current implementation Manila creates a neutron port but let it unbound (state DOWN). Therefore Manila uses the port create only retrieve an IP address and segmentation ID (some drivers only support VLAN here). My idea is to change this behavior and do an actual port binding action so that the configuration of VLAN isn’t a manual job any longer. And that multi-segment and HPB is supported on the long-run. My current issue is: How can Manila retrieve the segment information for a bound port? Manila only is interested in the last (bottom) segmentation ID since I assume the storage is connected to a ToR switch. Database-wise it’s possible to query it using ml2_port_binding_levels table. But AFAIK there is no API to query this. The only information that is exposed are all segments of a network. But this is not sufficient to identify which segments actually used for a port binding. Regards Marc SAP SE [1]: https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support <https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support> [2]: https://review.openstack.org/#/c/277731/ <https://review.openstack.org/#/c/277731/>__ 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] [OpenStack-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-groups
Hi Nidhi, It’s might also a good idea to have a short discussion during the manila meeting [1]. You can simply add your topic to the agenda. Regards Marc [1]: https://wiki.openstack.org/wiki/Manila/Meetings <https://wiki.openstack.org/wiki/Manila/Meetings> > On 26 Feb 2016, at 10:52, nidhi.h...@wipro.com wrote: > > Hi Manila Team, > > I am working on > https://blueprints.launchpad.net/manila/+spec/access-groups > <https://blueprints.launchpad.net/manila/+spec/access-groups> > > For this I have created initial document as attached with the mail. > It contains DB CLI REST API related changes. > > Could you please have a look and share your opinion. > > Kindly let me know, if there is some understanding gap, > or something I have missed to document or > share your comments in general to make it better. > > Thank you. > Nidhi Mittal Hada > Architect | PES / COE – Kolkata India > Wipro Limited > M +91 74 3910 9883 | O +91 33 3095 4767 | VOIP +91 33 3095 4767 > > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. WARNING: Computer viruses can be transmitted via > email. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com > <http://www.wipro.com/>__ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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] [qa] deprecating Tempest stress framework
I know that there are folks around that are using it. +1 to move it to a separate repo. Regards Marc > On 11 Feb 2016, at 13:59, Daniel Mellado wrote: > > +1 to that, it was my 2nd to-be-deprecated after javelin ;) > > El 11/02/16 a las 12:47, Sean Dague escribió: >> In order to keep Tempest healthy I feel like it's time to prune things >> that are outside of the core mission, especially when there are other >> options out there. >> >> The stress test framework in tempest is one of those. It builds on other >> things in Tempest, but isn't core to it. >> >> I'd propose that becomes deprecated now, and removed in Newton. If there >> are folks that would like to carry it on from there, I think we should >> spin it into a dedicated repository and just have it require tempest. >> >> -Sean >> > > > __ > 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-dev] [tempest][refstack] Data driven testing for tempest
Hi folks, I have a question for the refstack team. Does the idempotent_id has to be unique for a single test? To give more context: the ddt framework [1] will generate multiple similar tests with different data set. In the current implementation it’s something like a for- loop within the test itself. So refstack won’t recognize it. DDT autogenerated tests will look like independent tests from the test runner perspective. Introducing a mechanism to assign a unique idempotent_id would be quite channeling (but not impossible). So main question: is refstack fine with a idempotent_id that groups a set of tests? Please have a look to the qa-spec for more detail [2] and sample implementation [3]. Regards Marc SAP SE [1]: http://ddt.readthedocs.org/en/latest/ [2]: https://review.openstack.org/#/c/259934/ [3]: https://review.openstack.org/#/c/223953/ __ 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] [vitrage] Gerrit Upgrade 12/16
+1 I am also very confused about the new UI.. but maybe it takes time to get use to it. Regards Marc Am 17.12.2015 um 10:55 schrieb Mohan Kumar : > Eugene: +1 , Old Gerrit page was better than new one . Please fix > > On Thu, Dec 17, 2015 at 2:11 PM, Eugene Nikanorov > wrote: > I'm sorry to say that, but the new front page design is horrible and totally > confusing. > > I hope it'll change soon in the new release. > > E. > > > On Tue, Dec 15, 2015 at 10:53 AM, AFEK, Ifat (Ifat) > wrote: > Hi, > > Reminder: Gerrit upgrade is scheduled for tomorrow at 17:00 UTC. > > Ifat. > > > -Original Message- > From: Spencer Krum [mailto:n...@spencerkrum.com] > Sent: Monday, December 14, 2015 9:53 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Gerrit Upgrade 12/16 > > This is a gentle reminder that the downtime will be this Wednesday starting > at 17:00 UTC. > > Thank you for your patience, > Spencer > > -- > Spencer Krum > n...@spencerkrum.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
[openstack-dev] [NFV][Telco] Resigning TelcoWG core team
Hello TelcoWG, Due to personal reasons I have to resign my TelcoWG core team membership. I will remove myself from the core reviewer group. Thanks for all the support! Regards Marc __ 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] [tempest] Is there a sandbox project how to use tempest test plugin interface?
Am 14.09.2015 um 10:01 schrieb Lajos Katona : > Hi Matthew, > > Finally I made it working, so now I have a dummy plugin. > > Few questions, remarks: > - For me it was little hard to merge my weak knowledge from python packaging > with the documentation for tempest plugins, do you mind if I push an example > to github, and I add the link to that to the documentation. Can we add it directly into the documentation? I am fine with more code snippets there and external links can be broken over time. > - From this point the generation of the idempotent id is not clear for me. I > was able to use the check_uuid.py, and as I used a virtenv, the script edited > the .tox/venv/local/lib/python2.7/site-packages/dummyplugin/ file. > Would be good maybe to add an extra path option to the check_uuid.py to make > it possible to edit the real source files in similar cases not the ones in > the venv. Idempotent id’s aren’t covered in the first drop of tempest plugin interface. I am wondering if there is a need from refstack..? Regards Marc > Regards > Lajos > > On 09/11/2015 08:50 AM, Lajos Katona wrote: >> Hi Matthew, >> >> Thanks for the help, this helped a lot a start the work. >> >> regards >> Lajos >> >> On 09/10/2015 04:13 PM, Matthew Treinish wrote: >>> On Thu, Sep 10, 2015 at 02:56:31PM +0200, Lajos Katona wrote: >>> >>>> Hi, >>>> >>>> I just noticed that from tag 6, the test plugin interface considered ready, >>>> and I am eager to start to use it. >>>> I have some questions: >>>> >>>> If I understand well in the future the plugin interface will be moved to >>>> tempest-lib, but now I have to import module(s) from tempest to start to >>>> use >>>> the interface. >>>> Is there a plan for this, I mean when the whole interface will be moved to >>>> tempest-lib? >>>> >>> The only thing which will eventually move to tempest-lib is the abstract >>> class >>> that defines the expected methods of a plugin class [1] The other pieces >>> will >>> remain in tempest. Honestly this won't likely happen until sometime during >>> Mitaka. Also when it does move to tempest-lib we'll deprecate the tempest >>> version and keep it around to allow for a graceful switchover. >>> >>> The rationale behind this is we really don't provide any stability >>> guarantees >>> on tempest internals (except for a couple of places which are documented, >>> like >>> this plugin class) and we want any code from tempest that's useful to >>> external >>> consumers to really live in tempest-lib. >>> >>> >>>> If I start to create a test plugin now (from tag 6), what should be the >>>> best >>>> solution to do this? >>>> I thought to create a repo for my plugin and add that as a subrepo to my >>>> local tempest repo, and than I can easily import stuff from tempest, but I >>>> can keep my test code separated from other parts of tempest. >>>> Is there a better way of doing this? >>>> >>> To start I'd take a look at the documentation for tempest plugins: >>> >>> >>> http://docs.openstack.org/developer/tempest/plugin.html >>> >>> >>> >From tempest's point of view a plugin is really just an entry point that >>> >points >>> to a class that exposes certain methods. So the Tempest plugin can live >>> anywhere >>> as long as it's installed as an entry point in the proper namespace. >>> Personally >>> I feel like including it as a subrepo in a local tempest tree is a bit >>> strange, >>> but I don't think it'll cause any issues if you do that. >>> >>> >>>> If there would be an example plugin somewhere, that would be the most >>>> preferable maybe. >>>> >>> There is a cookiecutter repo in progress. [2] Once that's ready it'll let >>> you >>> create a blank plugin dir that'll be ready for you to populate. (similar to >>> the >>> devstack plugin cookiecutter that already exists) >>> >>> For current examples the only project I know of that's using a plugin >>> interface >>> is manila [3] so maybe take a look at what they're doing. >>> >>> -Matt Treinish >>> >>> [1] >>> http://git.openstack.org/cgit/openstack/
[openstack-dev] [manila] [third-party][qa]: Tempest plugin concept: 3rd party CI
Hello Manila team, as discussed in the Manila mid-cycle we want to move forward with the tempest plugin porting. The initial patch is already up and ready for review [1]. For more details please see [2]. Please note that 3rd party CI systems may need to be adapted. All tests are currently moved from contrib/tempest to manila_tempest_tests/. From now on the tests are discovered automatically, so please make sure that you don’t copy them into tempest directory. The usage of venv can be problematic currently. Make sure that you use a Tempest without a venv or activate system-site- packages within the configuration. I will add this topic to the next Manila meeting to discuss the next steps. Regards Marc [1]: https://review.openstack.org/#/c/201955/ [2]: http://specs.openstack.org/openstack/qa-specs/specs/tempest/tempest-external-plugin-interface.html __ 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] [Cinder] Implementation of ABC MetaClasses
Hello Cinder, Instead of reverting nearly everything what was done (and is currently ongoing). I would strongly suggest to simply reduce the number of the classes stepwise. I spend some time to analyze what it actually implemented for all the drivers. Please see: https://docs.google.com/spreadsheets/d/1L_GuUCs-NMVbhbOj8Jtt8vjMQ23zhJ1yagSH4zSKWEw/edit?usp=sharing The following classes can be moved to BaseVD directly: - ClonableImageVD - CloneableVD For the following only BlockDeviceDriver has no implementation : - SnapshopVD - ExtendVD This would remove 4 sub classes out of 10. I used a script to produce this table [1]. Please let me know if you find a bug :) Regards Marc [1]: http://paste.openstack.org/show/391303/ Am 15.07.2015 um 22:26 schrieb John Griffith : > > > On Wed, Jul 8, 2015 at 12:48 AM, Marc Koderer wrote: > > Am 08.07.2015 um 01:37 schrieb Mike Perez : > > > On 18:38 Jun 22, Marc Koderer wrote: > >> > >> Am 20.06.2015 um 01:59 schrieb John Griffith : > >>> * The BaseVD represents the functionality we require from all drivers. > >>> Yep > >>> > >>> * The additional ABC classes represent features that are not required yet. > >>> * These are represented by classes because some features require a > >>> bundle of methods for it to be fulfilled. Consistency group is an > >>> example. [2] > >>> > >>> Sure, I suppose that's fine for things like CG and Replication. > >>> Although I would think that if somebody implemented something optional > >>> like CG's that they should be able to figure out they need all of the > >>> "cg" methods, it's kinda like that warning on ladders to not stand on the > >>> very top rung. By the way, maybe we should discuss the state of > >>> "optional API methods" at the mid-cycle. > >>> > >>> * Any driver that wishes to mark their driver as supporting a > >>> non-required feature inherits this feature and fulfills the required > >>> methods. > >>> > >>> Yeah... ok, I guess. > >>> > >>> * After communication is done on said feature being required, there > >>> would be time for driver maintainers to begin supporting it. > >>> * Eventually that feature would disappear from it's own class and be > >>> put in the BaseVD. Anybody not supporting it would have a broken > >>> driver, a broken CI, and eventually removed from the release. > >>> > >>> Sure, I guess my question is what's the real value in this intermediate > >>> step. The bulk of these are things that I'd argue shouldn't be optional > >>> anyway (snapshots, transfers, manage, extend, retype and even migrate). > >>> Snapshots in particular I find surprising to be considered as "optional“. > >> > >> Reducing the number of classes/optional functions sounds good to me. > >> I think it’s quite valuable to discuss what are the mandatory functions > >> of a cinder driver. Before ABC nobody really cared because all drivers > >> simply raised an run-time exception :) > > > > If Marc is fine with this, I see no harm in us trying out John's proposal of > > using decorators in the volume driver class. > > > > -- > > Mike Perez > > > +1 sure, happy to see the code :) > > Regards > Marc > > > > > __ > > 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 > > Ok, so I spent a little time on this; first gathering some detail around > what's been done as well as proposing a patch to sort of step back a bit and > take another look at this [1]. > > Here's some more detail on what is bothering me here: > * Inheritance model > > One of the things the work has done is moved us from a mostly singular > inheritance OO structure for the Volume Drivers where each level of > inheritance was specifically for a more general differentiation. For > example, in driver.py we had: > > Volume
Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses
Am 08.07.2015 um 01:37 schrieb Mike Perez : > On 18:38 Jun 22, Marc Koderer wrote: >> >> Am 20.06.2015 um 01:59 schrieb John Griffith : >>> * The BaseVD represents the functionality we require from all drivers. >>> Yep >>> >>> * The additional ABC classes represent features that are not required yet. >>> * These are represented by classes because some features require a >>> bundle of methods for it to be fulfilled. Consistency group is an >>> example. [2] >>> >>> Sure, I suppose that's fine for things like CG and Replication. Although >>> I would think that if somebody implemented something optional like CG's >>> that they should be able to figure out they need all of the "cg" methods, >>> it's kinda like that warning on ladders to not stand on the very top rung. >>> By the way, maybe we should discuss the state of "optional API methods" at >>> the mid-cycle. >>> >>> * Any driver that wishes to mark their driver as supporting a >>> non-required feature inherits this feature and fulfills the required >>> methods. >>> >>> Yeah... ok, I guess. >>> >>> * After communication is done on said feature being required, there >>> would be time for driver maintainers to begin supporting it. >>> * Eventually that feature would disappear from it's own class and be >>> put in the BaseVD. Anybody not supporting it would have a broken >>> driver, a broken CI, and eventually removed from the release. >>> >>> Sure, I guess my question is what's the real value in this intermediate >>> step. The bulk of these are things that I'd argue shouldn't be optional >>> anyway (snapshots, transfers, manage, extend, retype and even migrate). >>> Snapshots in particular I find surprising to be considered as "optional“. >> >> Reducing the number of classes/optional functions sounds good to me. >> I think it’s quite valuable to discuss what are the mandatory functions >> of a cinder driver. Before ABC nobody really cared because all drivers >> simply raised an run-time exception :) > > If Marc is fine with this, I see no harm in us trying out John's proposal of > using decorators in the volume driver class. > > -- > Mike Perez +1 sure, happy to see the code :) Regards Marc > > __ > 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] [QA][Tempest] Proposing Jordan Pittier for Tempest Core
+1 Am 23.06.2015 um 02:06 schrieb GHANSHYAM MANN : > +1 :) > > On Tue, Jun 23, 2015 at 5:23 AM, Matthew Treinish > wrote: > > > Hi Everyone, > > I'd like to propose we add Jordan Pittier (jordanP) to the tempest core team. > Jordan has been a steady contributor and reviewer on tempest over the past few > cycles and he's been actively engaged in the Tempest community. Jordan has had > one of the higher review counts on Tempest for the past cycle, and he has > consistently been providing reviews that show insight into both the project > internals and it's future direction. I feel that Jordan will make an excellent > addition to the core team. > > As per the usual, if the current Tempest core team members would please vote > +1 > or -1(veto) to the nomination when you get a chance. We'll keep the polls open > for 5 days or until everyone has voted. > > Thanks, > > Matt Treinish > > References: > > https://review.openstack.org/#/q/reviewer:jordan.pittier%2540scality.com+project:openstack/tempest+OR+project:openstack/tempest-lib,n,z > > http://stackalytics.com/?metric=marks&user_id=jordan-pittier > > __ > 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 > > > > > -- > Thanks & Regards > Ghanshyam Mann > > __ > 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] [Cinder] Implementation of ABC MetaClasses
Am 20.06.2015 um 01:59 schrieb John Griffith : > * The BaseVD represents the functionality we require from all drivers. > Yep > > * The additional ABC classes represent features that are not required yet. > * These are represented by classes because some features require a > bundle of methods for it to be fulfilled. Consistency group is an > example. [2] > > Sure, I suppose that's fine for things like CG and Replication. Although I > would think that if somebody implemented something optional like CG's that > they should be able to figure out they need all of the "cg" methods, it's > kinda like that warning on ladders to not stand on the very top rung. By the > way, maybe we should discuss the state of "optional API methods" at the > mid-cycle. > > * Any driver that wishes to mark their driver as supporting a > non-required feature inherits this feature and fulfills the required > methods. > > Yeah... ok, I guess. > > * After communication is done on said feature being required, there > would be time for driver maintainers to begin supporting it. > * Eventually that feature would disappear from it's own class and be > put in the BaseVD. Anybody not supporting it would have a broken > driver, a broken CI, and eventually removed from the release. > > Sure, I guess my question is what's the real value in this intermediate > step. The bulk of these are things that I'd argue shouldn't be optional > anyway (snapshots, transfers, manage, extend, retype and even migrate). > Snapshots in particular I find surprising to be considered as "optional“. Reducing the number of classes/optional functions sounds good to me. I think it’s quite valuable to discuss what are the mandatory functions of a cinder driver. Before ABC nobody really cared because all drivers simply raised an run-time exception :) > > * Some people had thoughts of having a way generate a matrix with this > information, which I dislike the idea of. > > Yeah, back to the dreaded "Matrix", I can't imagine anything worse for > Cinder than a matrix of supported API calls on a driver per driver basis. I agree that such a matrix tool isn’t the finial goal. But it helps to see which functions are already "common“ and which are "optional“. Just try it [1] ;) Regards Marc [1]: https://review.openstack.org/#/c/160346/ > > __ > 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] [Cinder] Implementation of ABC MetaClasses
Am 20.06.2015 um 02:34 schrieb Knight, Clinton : > Funny you should mention needing all of the CG methods... > > A VD group (ConsistencyGroupVD) was added to contain the 4 CG methods from > Juno. Then more CG methods were added to VolumeDriver in Kilo, but they > weren’t added to ConsistencyGroupVD. > > But you *can’t* add them to ConsistencyGroupVD until every driver that > advertises ConsistencyGroupVD has implemented them, lest ConsistencyGroupVD > imply something false. You could add them to ‘ConsistencyGroupVD_v2’, but > that’s ugly. > > This whole VD thing seems just a little too neat, since it doesn’t lend > itself to evolution of features over time. I’ve wondered if a little runtime > introspection wouldn’t be a cleaner solution. I agree that this is an open issue with ABC. Changing an interface only works if all drivers adapt their interface. IMHO a runtime exception should be only used as interim solution to get all drivers ported. If the driver interfaces changes quite often we need to use versions. Regards Marc > > -- > Clinton Knight > > From: John Griffith > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Friday, June 19, 2015 at 7:59 PM > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses > > Sure, I suppose that's fine for things like CG and Replication. Although I > would think that if somebody implemented something optional like CG's that > they should be able to figure out they need all of the "cg" methods > __ > 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-dev] [Cinder] ABCMeta driver porting
Dear cinder driver maintainers, the abc driver porting bp got merged [1] and with this we need to refactor all cinder driver classes slightly. I hope we will manage to deprecate the usage of driver.VolumeDriver during Liberty. The porting should be very trivial (~ 2 LOC) in the most cases (see [2]). I would like to use this Etherpad to coordinate the work: https://etherpad.openstack.org/p/cinder-abc-driver-update So, I need an assignee for each driver :) Regards Marc [1]: https://review.openstack.org/#/c/177114/ [2]: https://review.openstack.org/#/c/138661/ — Deutsche Telekom __ 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] [Manila] Two nominations for Manila Core Reviewer Team
[+1, +1] Am 24.04.2015 um 06:42 schrieb Ramana Raja : > +1 to both. > > - Original Message - > From: "Ben Swartzlander" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Wednesday, April 22, 2015 11:53:15 PM > Subject: [openstack-dev] [Manila] Two nominations for Manila Core Reviewer > Team > > I would like to nominate Thomas Bechtold to join the Manila core reviewer > team. Thomas has been contributing to Manila for close to 6 months and has > provided a good number of quality code reviews in addition to a substantial > amount of contributions. Thomas brings both Oslo experience as well as a > packager/distro perspective which is especially helpful as Manila starts to > get used in more production scenarios. > > I would also like to nominate Mark Sturdevant. He has also been active in the > community for about 6 months and has a similar history of code reviews. Mark > is the maintainer of the HP driver and would add vendor diversity to the core > team. > > -Ben Swartzlander > Manila PTL > > > __ > 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] [Openstack-operators] [Telco][NFV][infra] Review process of TelcoWG use cases
Hello everyone, We already got good feedback on my sandbox test review. So I would like to move forward. With review [1] we will get a stackforge repo called „telcowg-usecases“. Submitting a usecase will then follow the process of OpenStack development (see [2]). The is one thing currently open: Anita suggested to rename our IRC channel from #openstack-nfv to #openstack-telcowg which seems logical to me. If we agree to this I will register the channel and we can move forward. I won’t be able to participate in our meeting today, but feel free to discuss this topic there and let me know. Regards Marc [1]: https://review.openstack.org/#/c/155248/ [2]: https://wiki.openstack.org/wiki/How_To_Contribute Am 06.02.2015 um 12:11 schrieb Marc Koderer : > Hello everyone, > > we are currently facing the issue that we don’t know how to proceed with > our telco WG use cases. There are many of them already defined but the > reviews via Etherpad doesn’t seem to work. > > I suggest to do a review on them with the usual OpenStack tooling. > Therefore I uploaded one of them (Session Border Controller) to the > Gerrit system into the sandbox repo: > >https://review.openstack.org/#/c/152940/1 > > I would really like to see how many review we can get on it. > If this works out my idea is the following: > > - we create a project under Stackforge called telcowg-usecases > - we link blueprint related to this use case > - we build a core team and approve/prioritize them > > Regards > Marc > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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-dev] [Telco][NFV][infra] Review process of TelcoWG use cases
Hello everyone, we are currently facing the issue that we don’t know how to proceed with our telco WG use cases. There are many of them already defined but the reviews via Etherpad doesn’t seem to work. I suggest to do a review on them with the usual OpenStack tooling. Therefore I uploaded one of them (Session Border Controller) to the Gerrit system into the sandbox repo: https://review.openstack.org/#/c/152940/1 I would really like to see how many review we can get on it. If this works out my idea is the following: - we create a project under Stackforge called telcowg-usecases - we link blueprint related to this use case - we build a core team and approve/prioritize them Regards Marc __ 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] [Telco][NFV] Meeting facilitator for January 28th
Hi Steve, I can host it. Regards Marc Am 27.01.2015 um 08:40 schrieb Steve Gordon : > Hi all, > > As mentioned in the notes from last week's meeting I am going to be in > transit during our 1400 UTC meeting this Wednesday (28th) [1]. Is anyone else > willing and able to facilitate in my absence? > > Thanks, > > Steve > > [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup#Technical_Team_Meetings > > __ > 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] [nova][NFV][qa][Telco] Testing NUMA, CPU pinning and large pages
Hi Vladik, I added the [Telco] tag. see below.. Am 12.01.2015 um 03:02 schrieb Vladik Romanovsky : > Hi everyone, > > Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, and other > features, I'd like to start a discussion about the NUMA testing in particular. > > Recently we have started a work to test some of these features. > The current plan is to use the functional tests, in the Nova tree, to exercise > the code paths for NFV use cases. In general, these will contain tests > to cover various scenarios regarding NUMA, CPU pinning, large pages and > validate a correct placement/scheduling. I think we need to determine where these patches are belonging to. So IMHO Nova tree makes sense. But I am unsure if Tempest is the right place. I would say all tests with a general propose can be located in Tempest especially scenario tests. Since we are already planning to have a external CI system it would make sense to keep them somewhere outside and use the tempest lib (when ready). Regards Marc > In addition to the functional tests in Nova, we have also proposed two basic > scenarios in Tempest [2][3]. One to make sure that an instance can boot with a > minimal NUMA configuration (a topology that every host should have) and > one that would request an "impossible" topology and fail with an expected > exception. > > This work doesn't eliminate the need of testing on a real hardware, however, > these tests should provide coverage for the features that are currently being > submitted upstream and hopefully be a good starting point for future testing. > > Thoughts? > > Vladik > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2014-November/050306.html > [2] https://review.openstack.org/143540 > [3] https://review.openstack.org/143541 > > > __ > 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] [Manila] Manila project use-cases
Hi Valeriy, thanks for feedback. My answers see below. Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov : > Hello Marc, > > Here, I tried to cover mentioned use cases with "implemented or not" notes: > > 1) Implemented, but details of implementation are different for different > share drivers. > 2) Not clear for me. If you mean possibility to mount one share to any amount > of VMs, then yes. That means you have an existing shared volume in your storage system and import it to manila (like cinder manage). I guess this is not implemented yet. > 3) Nova is used only in one case - Generic Driver that uses Cinder volumes. > So, it can be said, that Manila interface does allow to use "flat" network > and a share driver just should have implementation for it. I will assume you > mean usage of generic driver and possibility to mount shares to different > machines except Nova VMs. - In that case network architecture should allow to > make connection in general. If it is allowed, then should not be any problems > with mount to any machine. Just access-allow operations should be performed. This point was actually a copy from the wiki [1]. I just removed the Bare-metal point since for me it doesn’t matter whether the infrastructure service is a Bare-metal machine or not. > 4) Access can be shared, but it is not as flexible as could be wanted. Owner > of a share can grant access to all, and if there is network connectivity > between user and share host, then user will be able to mount having provided > access. Also a copy from the wiki. > 5) Manila can not remove some "mount" of some share, it can remove access for > possibility to mount in general. So, looks like not implemented. > 6) Implemented. > 7) Not implemented yet. > 8) No "cloning", but we have snapshot-approach as for volumes in cinder. Regards Marc > > Regards, > Valeriy Ponomaryov > Mirantis > > On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer wrote: > Hello Manila Team, > > We identified use cases for Manila during an internal workshop > with our operators. I would like to share them with you and > update the wiki [1] since it seems to be outdated. > > Before that I would like to gather feedback and you might help me > with identifying things that aren’t implemented yet. > > Our list: > > 1.) Create a share and use it in a tenant > Initial creation of a shared storage volume and assign it to several VM’s > > 2.) Assign an preexisting share to a VM with Manila > Import an existing Share with data and it to several VM’s in case of > migrating an existing production - services to Openstack. > > 3.) External consumption of a share > Accommodate and provide mechanisms for last-mile consumption of shares by > consumers of the service that aren't mediated by Nova. > > 4.) Cross Tenant sharing > Coordinate shares across tenants > > 5.) Detach a share and don’t destroy data (deactivate) > Share is flagged as inactive and data are not destroyed for later > usage or in case of legal requirements. > > 6.) Unassign and delete data of a share > Destroy entire share with all data and free space for further usage. > > 7.) Resize Share > Resize existing and assigned share on the fly. > > 8.) Copy existing share > Copy existing share between different storage technologies > > Regards > Marc > Deutsche Telekom > > [1]: https://wiki.openstack.org/wiki/Manila/usecases > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com > vponomar...@mirantis.com > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Manila] Manila project use-cases
Hello Manila Team, We identified use cases for Manila during an internal workshop with our operators. I would like to share them with you and update the wiki [1] since it seems to be outdated. Before that I would like to gather feedback and you might help me with identifying things that aren’t implemented yet. Our list: 1.) Create a share and use it in a tenant Initial creation of a shared storage volume and assign it to several VM’s 2.) Assign an preexisting share to a VM with Manila Import an existing Share with data and it to several VM’s in case of migrating an existing production - services to Openstack. 3.) External consumption of a share Accommodate and provide mechanisms for last-mile consumption of shares by consumers of the service that aren't mediated by Nova. 4.) Cross Tenant sharing Coordinate shares across tenants 5.) Detach a share and don’t destroy data (deactivate) Share is flagged as inactive and data are not destroyed for later usage or in case of legal requirements. 6.) Unassign and delete data of a share Destroy entire share with all data and free space for further usage. 7.) Resize Share Resize existing and assigned share on the fly. 8.) Copy existing share Copy existing share between different storage technologies Regards Marc Deutsche Telekom [1]: https://wiki.openstack.org/wiki/Manila/usecases ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core
+1 Am 22.11.2014 um 15:51 schrieb Andrea Frittoli : > +1 > > On 21 Nov 2014 18:25, "Ken1 Ohmichi" wrote: > +1 :-) > > Sent from my iPod > > On 2014/11/22, at 7:56, Christopher Yeoh wrote: > > > +1 > > > > Sent from my iPad > > > >> On 22 Nov 2014, at 4:56 am, Matthew Treinish wrote: > >> > >> > >> Hi Everyone, > >> > >> I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core > >> team. Over > >> the past couple of cycles Ghanshyam has been actively engaged in the > >> Tempest > >> community. Ghanshyam has had one of the highest review counts on Tempest > >> for > >> the past cycle, and he has consistently been providing reviews that have > >> been > >> of consistently high quality that show insight into both the project > >> internals > >> and it's future direction. I feel that Ghanshyam will make an excellent > >> addition > >> to the core team. > >> > >> As per the usual, if the current Tempest core team members would please > >> vote +1 > >> or -1(veto) to the nomination when you get a chance. We'll keep the polls > >> open > >> for 5 days or until everyone has voted. > >> > >> Thanks, > >> > >> Matt Treinish > >> > >> References: > >> > >> https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z > >> > >> http://stackalytics.com/?user_id=ghanshyammann&metric=marks > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Telco] [NFV] [Heat] Telco Orchestration
Hi Angus, Am 25.11.2014 um 12:48 schrieb Angus Salkeld : > On Tue, Nov 25, 2014 at 7:27 PM, Marc Koderer wrote: > Hi all, > > as discussed during our summit sessions we would like to expand the scope > of the Telco WG (aka OpenStack NFV group) and start working > on the orchestration topic (ETSI MANO). > > Therefore we started with an etherpad [1] to collect ideas, use-cases and > requirements. > > Hi Marc, > > You have quite a high acronym per sentence ratio going on that etherpad;) Haha, welcome to the telco world :) > > From Heat's perspective, we have a lot going on already, but we would love to > support > what you are doing. That’s exactly what we are planning. What we have is a long list of use-cases and requirements. We need to transform them into specs for the OpenStack projects. Many of those specs won’t be NFV specify, for instance a Telco cloud will be highly distributed. So what we need is a multi-region heat support (which is already a planned feature for Heat as I learned today). > > You need to start getting specific about what you need and what the missing > gaps are. > I see you are already looking at higher layers (TOSCA) also check out Murano > as well. > Yep, I will check Murano.. I never had a closer look to it. Regards Marc > > Regards > -Angus > > > Goal is to discuss this document and move it onto the Telco WG wiki [2] when > it becomes stable. > > Feedback welcome ;) > > Regards > Marc > Deutsche Telekom > > [1] https://etherpad.openstack.org/p/telco_orchestration > [2] https://wiki.openstack.org/wiki/TelcoWorkingGroup > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Telco] [NFV] [Heat] Telco Orchestration
Hi all, as discussed during our summit sessions we would like to expand the scope of the Telco WG (aka OpenStack NFV group) and start working on the orchestration topic (ETSI MANO). Therefore we started with an etherpad [1] to collect ideas, use-cases and requirements. Goal is to discuss this document and move it onto the Telco WG wiki [2] when it becomes stable. Feedback welcome ;) Regards Marc Deutsche Telekom [1] https://etherpad.openstack.org/p/telco_orchestration [2] https://wiki.openstack.org/wiki/TelcoWorkingGroup ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Picking a Name for the Tempest Library
Hi all, Am 15.08.2014 um 23:31 schrieb Jay Pipes : > > I suggest that "tempest" should be the name of the import'able library, and > that the integration tests themselves should be what is pulled out of the > current Tempest repository, into their own repo called > "openstack-integration-tests" or "os-integration-tests“. why not keeping it simple: tempest: importable test library tempest-tests: all the test cases Simple, obvious and clear ;) Regards Marc > Best, > -jay > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Which program for Rally
Hi John, see below. Zitat von John Griffith : I have to agree with Duncan here. I also don't know if I fully understand the limit in options. Stress test seems like it could/should be different This is correct, Rally and Tempest Stress test have a different focus. The stress test framework doesn't do any measurements of performance. This was done by purpose since it is quite hard to measure performance with asynchronous requests all over the place and using polling to measure actions. So anyway I see that Rally already has an integration to run Tempest test cases as load profile. But it's doesn't have an jenkins job like the stress test has. In general I think in that area we could benefit in working closer together and decide together if it makes sense to move to Tempest or let it completely inside of Rally. [snip] Honestly I think who better to write tests for a project than the folks building and contributing to the project. At some point IMO the QA team isn't going to scale. I wonder if maybe we should be thinking about proposals for delineating responsibility and goals in terms of functional testing? I think we are a bit off-topic now ;) Anyway I do think that moving test cases closer to the project is a good idea. Regards Marc On Wed, Aug 6, 2014 at 12:25 PM, Duncan Thomas wrote: I'm not following here - you complain about rally being monolithic, then suggest that parts of it should be baked into tempest - a tool that is already huge and difficult to get into. I'd rather see tools that do one thing well and some overlap than one tool to rule them all. On 6 August 2014 14:44, Sean Dague wrote: > On 08/06/2014 09:11 AM, Russell Bryant wrote: >> On 08/06/2014 06:30 AM, Thierry Carrez wrote: >>> Hi everyone, >>> >>> At the TC meeting yesterday we discussed Rally program request and >>> incubation request. We quickly dismissed the incubation request, as >>> Rally appears to be able to live happily on top of OpenStack and would >>> benefit from having a release cycle decoupled from the OpenStack >>> "integrated release". >>> >>> That leaves the question of the program. OpenStack programs are created >>> by the Technical Committee, to bless existing efforts and teams that are >>> considered *essential* to the production of the "OpenStack" integrated >>> release and the completion of the OpenStack project mission. There are 3 >>> ways to look at Rally and official programs at this point: >>> >>> 1. Rally as an essential QA tool >>> Performance testing (and especially performance regression testing) is >>> an essential QA function, and a feature that Rally provides. If the QA >>> team is happy to use Rally to fill that function, then Rally can >>> obviously be adopted by the (already-existing) QA program. That said, >>> that would put Rally under the authority of the QA PTL, and that raises >>> a few questions due to the current architecture of Rally, which is more >>> product-oriented. There needs to be further discussion between the QA >>> core team and the Rally team to see how that could work and if that >>> option would be acceptable for both sides. >>> >>> 2. Rally as an essential operator tool >>> Regular benchmarking of OpenStack deployments is a best practice for >>> cloud operators, and a feature that Rally provides. With a bit of a >>> stretch, we could consider that benchmarking is essential to the >>> completion of the OpenStack project mission. That program could one day >>> evolve to include more such "operations best practices" tools. In >>> addition to the slight stretch already mentioned, one concern here is >>> that we still want to have performance testing in QA (which is clearly >>> essential to the production of "OpenStack"). Letting Rally primarily be >>> an operational tool might make that outcome more difficult. >>> >>> 3. Let Rally be a product on top of OpenStack >>> The last option is to not have Rally in any program, and not consider it >>> *essential* to the production of the "OpenStack" integrated release or >>> the completion of the OpenStack project mission. Rally can happily exist >>> as an operator tool on top of OpenStack. It is built as a monolithic >>> product: that approach works very well for external complementary >>> solutions... Also be more integrated in OpenStack or part of the >>> OpenStack programs might come at a cost (slicing some functionality out >>> of rally to make it more a framework and less a product) that might not >>> be what i
Re: [openstack-dev] [tc][rally][qa] Application for a new OpenStack Program: Performance and Scalability
Hello Boris, see below. Zitat von Boris Pavlovic : Jay, Thanks for review of proposal. Some my comments below.. I think this is one of the roots of the problem that folks like David and Sean keep coming around to. If Rally were less monolithic, it would be easier to say "OK, bring this piece into Tempest, have this piece be a separate library and live in the QA program, and have the service endpoint that allows operators to store and periodically measure SLA performance indicators against their cloud." Actually Rally was designed to be a glue service (and cli tool) that will bind everything together and present service endpoint for Operators. I really do not understand what can be split? and put to tempest? and actually why? Could you elaborate pointing on current Rally code, maybe there is some misleading here. I think this should be discussed in more details.. A good example for that is Rally's Tempest configuration module. Currently Rally has all the logic to configure Tempest and for that you have your own way to build the tempest conf out of a template [1]. If the QA team decides to rework the configuration Rally is broken. [1]: https://github.com/stackforge/rally/blob/master/rally/verification/verifiers/tempest/config.ini [snip] I found the Scalr incubation discussion: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-14-20.03.log.html The reasons of reject were next: *) OpenStack shouldn't put PaaS in OpenStack core # rally is not PaaS *) Duplication of functionality (actually dashboard) # Rally doesn't duplicate anything IMHO rally duplicates at least some pieces. So you can find parts of Tempest scenarios tests in the benchmarks area, Tempest stress tests and Tempest config. Regards Marc *) Development is done behind closed doors # Not about Rally http://stackalytics.com/?release=juno&metric=commits&project_type=All&module=rally Seems like Rally is quite different case and this comparison is misleading & irrelevant to current case. , that is why I think Rally should be a separated program (i.e. Rally scope is just different from QA scope). As well, It's not clear for me, why collaboration is possible only in case of one program? In my opinion collaboration & programs are irrelevant things. Sure, it's certainly possible for collaboration to happen across programs. I think what Sean is alluding to is the fact that the Tempest and Rally communities have done little collaboration to date, and that is worrying to him. Could you please explain this paragraph. What do you mean by "have done little collaboration" We integrated Tempest in Rally: http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/ We are working on spec in Tempest about tempest conf generation: https://review.openstack.org/#/c/94473/ # probably not so fast as we would like We had design session: http://junodesignsummit.sched.org/event/2815ca60f70466197d3a81d62e1ee7e4#.U9_ugYCSz1g I am going to work on integration OSprofiler in tempest, as soon as I get it in core projects. By the way, I am really not sure how being one Program will help us to collaborate? What it actually changes? About collaboration between Rally & Tempest teams... Major goal of integration Tempest in Rally is to make it simpler to use tempest on production clouds via OpenStack API. Plenty of folks run Tempest without Rally against production clouds as an acceptance test platform. I see no real benefit to arguing that Rally is for running against production clouds and Tempest is for non-production clouds. There just isn't much of a difference there. Hm, I didn't say anything about "Tempest is for non-prduction clouds"... I said that Rally team is working on making it simpler to use on production clouds.. The problem I see is that Rally is not *yet* exposing the REST service endpoint that would make it a full-fledged Operator Tool outside the scope of its current QA focus. Once Rally does indeed publish a REST API that exposes resource endpoints for an operator to store a set of KPIs associated with an SLA, and allows the operator to store the run schedule that Rally would use to go and test such metrics, *then* would be the appropriate time to suggest that Rally be the pilot project in this new Operator Tools program, IMO. It's really almost done.. It is all about 2 weeks of work... I'm sure all of those things would be welcome additions to Tempest. At the same time, Rally contributors would do well to work on an initial REST API endpoint that would expose the resources I denoted above. As I said before it's almost finished.. Best regards, Boris Pavlovic On Mon, Aug 4, 2014 at 8:25 PM, Jay Pipes wrote: On 08/04/2014 11:21 AM, Boris Pavlovic wrote: Rally is quite monolithic and can't be split I think this is one of
Re: [openstack-dev] [tc][rally][qa] Application for a new OpenStack Program: Performance and Scalability
Zitat von Sylvain Bauza : Le 30/07/2014 22:13, Boris Pavlovic a écrit : Hi all, This thread is very useful. We've detect issue related to the mission statement and name of proposed program on early steps. Seems like mission statement and name are totally unclear and don't present in the right perspective goals of this program. I updated name and mission statement: name: SLA Management mission: Provide SLA Management for production OpenStack clouds. This includes measuring and tracking performance of OpenStack Services, key API methods and cloud applications, performance and functional tests on demand, and everything that is required to detect and debug issues in live production clouds. As well, I updated patch to governance: https://review.openstack.org/#/c/108502/3 I hope now it's more clear, what is the goal of this program and why we should add new program. Thoughts? -1 -1 to it. SLA means that you create a contract in between a provider and an user. Here, you don't create a contract (ie. you don't create ratios and engagement) but you monitor these contracts. So I agree with Sylvain, SLA Management would imply to have a tool set that monitors agreements of a service. I don't see how this fits into the existing projects you are referring to. IMHO SLA Management would never consist of debugging or tracing anything. It would be always focused on a service and not on a root-cause analysis. Regards Marc As there are no SLAs now in OpenStack upstream (that's something for operators), we can't say if the KPIs are OK or not. How can you ensure that the code will be 9 nines if you don't look at how OpenStack will be deployed ? If you say the mission statement is to provide measurement tools for OpenStack, then it possibly goes either in QA or in Telemetry programs. If you say that the goal is to detect and debug issues in clouds, then it clearly goes into QA program. IMHO, both your name and your mission statement are confusing. Long story short, I'm pro Rally as a separate project but in the QA program. -Sylvain Best regards, Boris Pavlovic On Tue, Jul 29, 2014 at 12:39 AM, Boris Pavlovic mailto:bo...@pavlovic.me>> wrote: Hi Sean, I appreciate you valuing Rally so highly as to suggesting it should join the QA program. It is a great vote of confidence for me. While I believe that Rally and Tempest will always work closely together, the intended utility and the direction of where we are planing to take Rally will not be compatible with the direction of where I think the QA program is going. Please let me explain in more details below. Tempest is a collection of Functional and Performance Tests which is used by the developers to improve the quality of the OpenStack code. Rally on the other hand, is envisioned as a Tool that is going to be run by the cloud operators in order to measure, tune and continuously improve the performance of an OpenStack cloud. Moreover, we have an SLA module that allows the Operator to define what constitutes an acceptable level of performance and a profiler that would provide both the user and the developer the diagnostic set of performance data. Finally, Rally is designed to run on production clouds and to be integrated as a Horizon plugin. In the future, we envision integrating Rally with other services (e.g. Logging as a Service, Satori, Rubick, and other operator-targeted services). I believe that this is not the direction compatible with the mission of the the QA program . Before applying for a new Performance and Scalability program, we have thought that the best existing program that Rally could be a part of now and in the future is the Telemetry program. We have discussed with Eoghan Glynn the idea of extending the scope of its mission to include other operator related projects and include Rally to it. Eoghan liked the idea in general but felt that Ceilometer currently has too much on its plate and was not in a position to merge in a new project. However, I can still see the two programs maturing and potentially becoming one down the road. Now, regarding the point that you make of Rally and Tempest doing some duplicate work. I completely agree with you that we should avoid it as much as possible and we should stay in close communication to make sure that duplicate requirements are only implemented once. Following our earlier discussion, Rally is now using Tempest for those benchmarks that do not require special complex environments, we also encapsulated and automated Tempest usage to make it more accessible for the Operators (here is the Blog documenting it -- http://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/). We would like to further continue to de-dupli
Re: [openstack-dev] [QA] Proposed Changes to Tempest Core
+1 > -Ursprüngliche Nachricht- > Von: Matthew Treinish [mailto:mtrein...@kortar.org] > Gesendet: Dienstag, 22. Juli 2014 00:34 > An: openstack-dev@lists.openstack.org > Betreff: [openstack-dev] [QA] Proposed Changes to Tempest Core > > > Hi Everyone, > > I would like to propose 2 changes to the Tempest core team: > > First, I'd like to nominate Andrea Fritolli to the Tempest core team. Over > the past cycle Andrea has been steadily become more actively engaged in the > Tempest community. Besides his code contributions around refactoring > Tempest's authentication and credentials code, he has been providing reviews > that have been of consistently high quality that show insight into both the > project internals and it's future direction. In addition he has been active > in the qa-specs repo both providing reviews and spec proposals, which has > been very helpful as we've been adjusting to using the new process. Keeping > in mind that becoming a member of the core team is about earning the trust > from the members of the current core team through communication and quality > reviews, not simply a matter of review numbers, I feel that Andrea will make > an excellent addition to the team. > > As per the usual, if the current Tempest core team members would please vote > +1 or -1(veto) to the nomination when you get a chance. We'll keep the polls > open for 5 days or until everyone has voted. > > References: > > https://review.openstack.org/#/q/reviewer:%22Andrea+Frittoli+%22,n,z > > http://stackalytics.com/?user_id=andrea-frittoli&metric=marks&module=qa- > group > > > The second change that I'm proposing today is to remove Giulio Fidente from > the core team. He asked to be removed from the core team a few weeks back > because he is no longer able to dedicate the required time to Tempest > reviews. So if there are no objections to this I will remove him from the > core team in a few days. > Sorry to see you leave the team Giulio... > > > Thanks, > > Matt Treinish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Infra] Mid-Cycle Meet-up
Hi all, just some general information for your trip: - Darmstadt is quite close to Frankfurt am Main: >From Frankfurt Airport you can take a bus shuttle that takes you directly to >the office campus (the trip takes around 25 minutes depending on your arrival >gate): http://www.rmv.de/linkableblob/de/33548-59802/data/AirLiner_Direktbus_Darmstadt_Frankfurt_Flughafen_PDF.pdf - If your trip gets approved please send me your name, email and your company name in order to create badges for you in advance - I will create a wiki page with more details (like hotel information) and send it around Regards Marc > -Ursprüngliche Nachricht- > Von: Matthew Treinish [mailto:mtrein...@kortar.org] > Gesendet: Donnerstag, 29. Mai 2014 18:07 > An: openstack-dev@lists.openstack.org; openstack-in...@lists.openstack.org > Betreff: [openstack-dev] [QA][Infra] Mid-Cycle Meet-up > > > Hi Everyone, > > So we'd like to announce to everyone that we're going to be doing a > combined Infra and QA program mid-cycle meet-up. It will be the week of > July 14th in Darmstadt, Germany at Deutsche Telekom who has graciously > offered to sponsor the event. The plan is to use the week as both a time > for face to face collaboration for both programs respectively as well as > having a couple days of bootstrapping for new users/contributors. The > intent was that this would be useful for people who are interested in > contributing to either Infra or QA, and those who are running third party > CI systems. > > The current break down for the week that we're looking at is: > > July 14th: Infra > July 15th: Infra > July 16th: Bootstrapping for new users > July 17th: More bootstrapping > July 18th: QA > > We still have to work out more details, and will follow up once we have > them. > But, we thought it would be better to announce the event earlier so people > can start to plan travel if they need it. > > > Thanks, > > Matt Treinish > Jim Blair ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta
Hi, 7:30pm at Ted's Montana Grill. I called them and they put us on the list. Again the location: https://plus.google.com/100773563660993493024/posts/P9YSgT8AVXh It's quite near to all the hotels. See you there! Marc From: Koderer, Marc [m.kode...@telekom.de] Sent: Wednesday, May 07, 2014 7:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta Hi folks, ok seems to me more complex than expected ;) Monday is the OpenStack speakers dinner. Let's do it on Sunday. Matthew already suggested a location: Ted's Montana Grill https://plus.google.com/100773563660993493024/posts/P9YSgT8AVXh For all the people interested just send me your mobile number.. Regards Marc From: Koderer, Marc [m.kode...@telekom.de] Sent: Monday, May 05, 2014 8:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta All right, let’s meet on Monday ;) We can discuss the details after the QA meeting this week. Von: Frittoli, Andrea (HP Cloud) [mailto:fritt...@hp.com] Gesendet: Donnerstag, 1. Mai 2014 18:42 An: OpenStack Development Mailing List (not for usage questions) Betreff: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I will arrive Sunday late. If you meet on Monday I’ll see you there ^_^ From: Miguel Lavalle [mailto:mig...@mlavalle.com] Sent: 01 May 2014 17:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I arrive Sunday at 3:30pm. Either Sunday or Monday are fine with me. Lookging forward to it :-) On Wed, Apr 30, 2014 at 5:11 AM, Koderer, Marc mailto:m.kode...@telekom.de>> wrote: Hi folks, last time we met one day before the Summit started for a short meet-up. Should we do the same this time? I will arrive Saturday to recover from the jet lag ;) So Sunday 11th would be fine for me. Regards, Marc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta
Hi folks, ok seems to me more complex than expected ;) Monday is the OpenStack speakers dinner. Let's do it on Sunday. Matthew already suggested a location: Ted's Montana Grill https://plus.google.com/100773563660993493024/posts/P9YSgT8AVXh For all the people interested just send me your mobile number.. Regards Marc From: Koderer, Marc [m.kode...@telekom.de] Sent: Monday, May 05, 2014 8:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta All right, let’s meet on Monday ;) We can discuss the details after the QA meeting this week. Von: Frittoli, Andrea (HP Cloud) [mailto:fritt...@hp.com] Gesendet: Donnerstag, 1. Mai 2014 18:42 An: OpenStack Development Mailing List (not for usage questions) Betreff: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I will arrive Sunday late. If you meet on Monday I’ll see you there ^_^ From: Miguel Lavalle [mailto:mig...@mlavalle.com] Sent: 01 May 2014 17:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I arrive Sunday at 3:30pm. Either Sunday or Monday are fine with me. Lookging forward to it :-) On Wed, Apr 30, 2014 at 5:11 AM, Koderer, Marc mailto:m.kode...@telekom.de>> wrote: Hi folks, last time we met one day before the Summit started for a short meet-up. Should we do the same this time? I will arrive Saturday to recover from the jet lag ;) So Sunday 11th would be fine for me. Regards, Marc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta
All right, let’s meet on Monday ;) We can discuss the details after the QA meeting this week. Von: Frittoli, Andrea (HP Cloud) [mailto:fritt...@hp.com] Gesendet: Donnerstag, 1. Mai 2014 18:42 An: OpenStack Development Mailing List (not for usage questions) Betreff: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I will arrive Sunday late. If you meet on Monday I’ll see you there ^_^ From: Miguel Lavalle [mailto:mig...@mlavalle.com] Sent: 01 May 2014 17:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] QA Summit Meet-up Atlanta I arrive Sunday at 3:30pm. Either Sunday or Monday are fine with me. Lookging forward to it :-) On Wed, Apr 30, 2014 at 5:11 AM, Koderer, Marc mailto:m.kode...@telekom.de>> wrote: Hi folks, last time we met one day before the Summit started for a short meet-up. Should we do the same this time? I will arrive Saturday to recover from the jet lag ;) So Sunday 11th would be fine for me. Regards, Marc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] QA Summit Meet-up Atlanta
Hi folks, last time we met one day before the Summit started for a short meet-up. Should we do the same this time? I will arrive Saturday to recover from the jet lag ;) So Sunday 11th would be fine for me. Regards, Marc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] API schema location
> From: Matthew Treinish [mtrein...@kortar.org]
> Sent: Tuesday, March 18, 2014 7:08 PM
> On Tue, Mar 18, 2014 at 12:34:57PM +0100, Koderer, Marc wrote:
> > On Tue, 18 Marc 2014 12:00:00 +0100
> > Christopher Yeoh [mailto:cbky...@gmail.com] wrote:
> > > On Tue, 18 Mar 2014 10:39:19 +0100
> > > "Koderer, Marc" wrote:
> > > >
> > > > I just recognized that we have very similar interface definitions in
> > > > tempest/api_schema and etc/schema:
> > > >
> > > > https://github.com/openstack/tempest/tree/master/etc/schemas
> > > > https://github.com/openstack/tempest/tree/master/tempest/api_schema
> > > >
> > > > Any objections if I move them to a single location? I'd prefer to use
> > > > json as file format instead of .py. As final goal we should find a way
> > > > how to merge them competently but I feel like this is something for
> > > > the design summit ;)
> > > >
> > >
> > > Heh we just moved them but I'm open to other suggestions - they are are
> > > specific to API testing though aren't they? Long term the idea is that
> > > they should be generated by Nova rather than tempest. I think to prevent
> > > unintentional changes we'd probably cache a copy in tempest though rather
> > > than dynamically query them.
>
> The idea was never to dynamically query them; there should always be a copy in
> the tempest tree. Like you said to prevent unintentional changes which is the
> same reason we don't auto-discover api versions. The idea for querying nova to
> get the schemas was to enable a tool which could populate the schemas
> automatically so that we didn't have to manually generate them individually.
> I'd
> say, to a certain extent, that this new round of validation patches could use
> the same kind of tool.
>
> >
> > Sry that I didn't recognized this review.
> > Both definitions are coupled to API testing, yes.
> >
> > >
> > > My feeling at the moment is that they should .py files.
> > > Because I think there's cases where we will want to have some schema
> > > definitions based on others or share common parts and use bits of python
> > > code to achieve this. For example availability zone list and detailed
> > > listing have a lot in common (detailed listing just has a more
> > > parameters). I think there'll be similar cases for v2 and v3 versions as
> > > well. While we're still manually generating them and keeping them up to
> > > date I think it's worth sharing as much as we can.
> >
> > Ok understood. We just converted the negative testing
> > definitions to json files due to review findings..
>
> Well, when I left the review comment about it being a json file, I didn't
> think
> about inheritance. Chris has a good point about reusing common bits and just
> extending it. That wasn't how you proposed the negative test schemas would be
> used which is why I suggested using a raw json file.
> > It's just very confusing for new people if they see
> > two separate folders with schema definitions.
> >
> > But unfortunately there isn't an easy way.
>
> Am I missing something or are these schemas being added now just a subset of
> what is being used for negative testing? Why can't we either add the extra
> negative test info around the new test validation patches and get the double
> benefit. Or have the negative test schemas just extend these new schemas being
> added?
Yes, the api_schema files should theoretically be a
subsets of the negative test schemas.
But I don't think that extending them will be possible:
if you have a property definition like this:
"properties": {
"minRam": { "type": "integer",}
how can you extend it to:
"properties": {
"minRam": {
"type": "integer",
"results": {
"gen_none": 400,
"gen_string": 400
}
This is the reason why I am unsure how inheritance can solve something here.
> >
> > >
> > > I agree there's a lot of commonality and we should long term just have one
> > > schema definition. There's quite a bit to discuss (eg level of strictness
> > > is currently different) in this area and a summit session about it would
> > > be very useful.
> > >
> >
> > +1
> >
>
> I agree there is probably enough here to discuss during a summit session on
> where schema validation fits into tempest. As a part of that discussing how to
> store and manage schema definitions for both the negative test framework and
> validation tests.
>
>
> -Matt Treinish
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] API schema location
On Tue, 18 Marc 2014 12:00:00 +0100 Christopher Yeoh [mailto:cbky...@gmail.com] wrote: > On Tue, 18 Mar 2014 10:39:19 +0100 > "Koderer, Marc" wrote: > > > > I just recognized that we have very similar interface definitions in > > tempest/api_schema and etc/schema: > > > > https://github.com/openstack/tempest/tree/master/etc/schemas > > https://github.com/openstack/tempest/tree/master/tempest/api_schema > > > > Any objections if I move them to a single location? I'd prefer to use > > json as file format instead of .py. As final goal we should find a way > > how to merge them competently but I feel like this is something for > > the design summit ;) > > > > Heh we just moved them but I'm open to other suggestions - they are are > specific to API testing though aren't they? Long term the idea is that > they should be generated by Nova rather than tempest. I think to prevent > unintentional changes we'd probably cache a copy in tempest though rather > than dynamically query them. Sry that I didn't recognized this review. Both definitions are coupled to API testing, yes. > > My feeling at the moment is that they should .py files. > Because I think there's cases where we will want to have some schema > definitions based on others or share common parts and use bits of python > code to achieve this. For example availability zone list and detailed > listing have a lot in common (detailed listing just has a more > parameters). I think there'll be similar cases for v2 and v3 versions as > well. While we're still manually generating them and keeping them up to > date I think it's worth sharing as much as we can. Ok understood. We just converted the negative testing definitions to json files due to review findings.. It's just very confusing for new people if they see two separate folders with schema definitions. But unfortunately there isn't an easy way. > > I agree there's a lot of commonality and we should long term just have one > schema definition. There's quite a bit to discuss (eg level of strictness > is currently different) in this area and a summit session about it would > be very useful. > +1 > Regards, > > Chris > > > Regards, > > Marc > > > > > > DEUTSCHE TELEKOM AG > > Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud > > Technology Software Developer T-Online-Allee 1, 64211 Darmstadt > > E-Mail: m.kode...@telekom.de > > www.telekom.com > > > > LIFE IS FOR SHARING. > > > > DEUTSCHE TELEKOM AG > > Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of > > Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van > > Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. > > Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 > > Registered office: Bonn > > > > BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY > > E-MAIL. > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] API schema location
Hi Chris, hi all, I just recognized that we have very similar interface definitions in tempest/api_schema and etc/schema: https://github.com/openstack/tempest/tree/master/etc/schemas https://github.com/openstack/tempest/tree/master/tempest/api_schema Any objections if I move them to a single location? I'd prefer to use json as file format instead of .py. As final goal we should find a way how to merge them competently but I feel like this is something for the design summit ;) Regards, Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.kode...@telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] [Infra] pep8 issues in tempest gate / testscenarios lib
Hi folks, I can't make it to the QA meeting for today so I wanted to summarize the issue that we have with the pep8 and tempest gate. An example for the issue you can find here: https://review.openstack.org/#/c/79256/ http://logs.openstack.org/56/79256/1/gate/gate-tempest-pep8/088cc12/console.html pep8 check shows an error but the check itself is marked as success. For me this show two issues. First flake8 should return with an exit code !=0. I will have a closer look into hacking and what went wrong here. Second issue is the current implementation of the negative testing framework: we are using the testscenarios lib with the "load_tests" variable interpreted by the test runner. This forces us to build the scenario at import time and if we want to have tempest configurations for this (like introduced in https://review.openstack.org/#/c/73982/) the laziness for the config doesn't work. Although it seems like if I remove the inheritance of the xml class to the json class (https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_flavors_negative_xml.py#L24) that error doesn't appear any longer, I see a general problem with the usage of "import-time" code and we may think about a better solution in general. I'll try to address the missing pieces tomorrow. Bug: https://bugs.launchpad.net/tempest/+bug/1291826 Regards, Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.kode...@telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tempest - Stress Test][qa] : implement a full SSH connection on "ssh_floating.py" and improve it
> Von: LELOUP Julien [mailto:julien.lel...@3ds.com] > Gesendet: Montag, 3. März 2014 11:21 > An: OpenStack Development Mailing List (not for usage questions); Koderer, > Marc > Betreff: [Tempest - Stress Test][qa] : implement a full SSH connection on > "ssh_floating.py" and improve it > > Hello, > > It tourns out that this stress test maybe not implemented in the right > place. > > At ther moment I have put the SSH stress test in large_ops but Joe Gordon > pointed (in https://review.openstack.org/#/c/74067/) that the large_ops > gates are not meant to launch real servers. Yep, this is a discussion that came up in the last summit and I might undervalue the consequences. IMHO stress test's should both work with fake drivers and with real environments. If they don't and we really want to support such cases we need to flag such tests or make these checks optional. If we do so these check possibly never run in the gate. Especially for stress tests it's might the case that there are designed for in-house usage and not for the gate. > > So where should I put this test ? I'm thinking of creating a new scenario > file inheriting of the class specified in the large_ops file > (TestLargeOpsScenario) in order to avoid duplicating the "nova_boot" > method. > Is it OK for you ? > > Is there a better place where I should put my test ? I mean we still have the tempest/stress/actions/ and we could put something like that in there. In general I would like to discuss this topic in the next QA meeting.. @Julien: are you able to join the next meeting? It would be 22:00 UTC. > > Best Regards, > > Julien LELOUP > julien.lel...@3ds.com > Regards, Marc > > -Original Message- > From: LELOUP Julien [mailto:julien.lel...@3ds.com] > Sent: Monday, February 17, 2014 5:02 PM > To: OpenStack Development Mailing List (not for usage questions); Koderer, > Marc > Subject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a > full SSH connection on "ssh_floating.py" and improve it > > Hello Marc, > > I'm raising this subject again since I have pushed a patch set > implementing this SSH stress test in Tempest. > As you suggested, I wrote it as a scenario test : I'm currently using it > to check the ability of my stack to launch x servers at the same time and > having them fully available to use. > > As a reminder, here is the Blueprint : > https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip > > Plese feel free to check it and make feedback :) > > Best Regards, > > Julien LELOUP > julien.lel...@3ds.com > > -Original Message- > From: LELOUP Julien [mailto:julien.lel...@3ds.com] > Sent: Monday, January 20, 2014 11:55 AM > To: Koderer, Marc > Cc: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a > full SSH connection on "ssh_floating.py" and improve it > > Hello Marc, > > Thanks again for your help, your blog post is helpful. > > So I will start writing a new scenario test to get this full SSH stress > test on newly created VM. > I will put more details about it in the blueprint I created for this : > https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip > > Best Regards, > > Julien LELOUP > julien.lel...@3ds.com > > > -Original Message- > From: Koderer, Marc [mailto:m.kode...@telekom.de] > Sent: Saturday, January 18, 2014 10:11 AM > To: LELOUP Julien > Cc: openstack-dev@lists.openstack.org > Subject: RE: [qa] [Tempest - Stress Test] : implement a full SSH > connection on "ssh_floating.py" and improve it > > Hello Julien, > > maybe my blog post helps you with some more details: > > http://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress- > testing.html > > You can run single test if you add a new json file with the test function > you want to test. Like: > https://github.com/openstack/tempest/blob/master/tempest/stress/etc/sample > -unit-test.json > > With that you can launch them with the parameters you already described. > > Regards, > Marc > > > From: LELOUP Julien [julien.lel...@3ds.com] > Sent: Friday, January 17, 2014 3:49 PM > To: Koderer, Marc > Cc: openstack-dev@lists.openstack.org > Subject: RE: [Tempest - Stress Test] : implement a full SSH connection on > "ssh_floating.py" and improve it > > Hi Marc, > > The Etherpad you provided was helpful to know the current state of the > stress tests. > > I admit that I have some difficulties to understand how I can run a single > test built with the
Re: [openstack-dev] Cleaning OpenStack resources
Hi Forent, thanks for the link. Our current implementation of for the cleanup is a bit buggy. I will give your script a try. Maybe we could use it an replace the existing module. Regards Marc From: Florent Flament [florent.flament-...@cloudwatt.com] Sent: Thursday, February 20, 2014 10:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] Cleaning OpenStack resources Hi David, I have been working on an OpenStack resources cleanup script that allows you to wipe out all resources in a given project, I guess you could use / adapt it for your own case. It is available on github there: https://github.com/cloudwatt/ospurge You can also install it with pip (pip install ospurge). As for the floating ips, you should be able to list and remove them, by using the neutron CLI: * neutron floatingip-list * neutron floatingip-delete Forent Flament - Original Message - From: "David Kranz" To: "OpenStack Development Mailing List" Sent: Wednesday, February 19, 2014 10:15:12 PM Subject: [openstack-dev] [qa] Cleaning OpenStack resources I was looking at https://review.openstack.org/#/c/73274/1 which makes it configurable whether a brute-force cleanup of resources is done after success. This got my wondering how this should really be done. As admin, there are some resources that can be cleaned and some that I don't know how. For example, as admin you can list all servers and delete them with the --all-tenants flag. But for floating ips I don't see a way to list all of them even as admin through the apis. Is there a way that an admin can, through the api, locate all resources used by a particular tenant? -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] [Tempest - Stress Test] : some improvements / issues on the stress test framework
Hi Julien, please don't forget the [qa] tag - otherwise your lost in the ML noise ;) Ok thanks for the bug reports. I confirmed 1273245 and 1273254 but I am not totally sure with 1273186. Could you give some more details how the CLI interface will look like? Or simply propose a patch. It could end up in a quite confusing interface.. if you allow kwargs for such a generic case. Are you already working on those bugs? If yes, could you assign them to you? Regards, Marc > > From: LELOUP Julien [julien.lel...@3ds.com] > Sent: Monday, January 27, 2014 4:01 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [Tempest - Stress Test] : some improvements / issues > on the stress test framework > > Hi everyone, > > I would like to discuss some ideas / behavior that seems broken in the stress > test part of Tempest. > > I opened some tickets in Launchpad and I would like to get the feedback of > the community on these ideas / issues : > > - Provide kwargs from UnitTest to stress test scenarios > (https://bugs.launchpad.net/tempest/+bug/1273186 ) > > - Stress Test - tearDown() not called if an exception occurred > (https://bugs.launchpad.net/tempest/+bug/1273245 ) > > - Stress Test - cleanUp() removing all test resources as an admin > (https://bugs.launchpad.net/tempest/+bug/1273254 ) > > Best Regards, > > Julien LELOUP > julien.lel...@3ds.com > > > This email and any attachments are intended solely for the use of the > individual or entity to whom it is addressed and may be confidential and/or > privileged. > > If you are not one of the named recipients or have received this email in > error, > > (i) you should not read, disclose, or copy it, > > (ii) please notify sender of your receipt by reply email and delete this > email and all attachments, > > (iii) Dassault Systemes does not accept or assume any liability or > responsibility for any use of or reliance on this email. > > For other languages, go to http://www.3ds.com/terms/email-disclaimer > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it
Hello Julien, maybe my blog post helps you with some more details: http://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html You can run single test if you add a new json file with the test function you want to test. Like: https://github.com/openstack/tempest/blob/master/tempest/stress/etc/sample-unit-test.json With that you can launch them with the parameters you already described. Regards, Marc From: LELOUP Julien [julien.lel...@3ds.com] Sent: Friday, January 17, 2014 3:49 PM To: Koderer, Marc Cc: openstack-dev@lists.openstack.org Subject: RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hi Marc, The Etherpad you provided was helpful to know the current state of the stress tests. I admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology and a lot more on OpenStack/Tempest :) ). I used to run my test using "./run_stress.py -t -d ", which allowed me to run only one test with a dedicated configuration (number of threads, ...) For what I understand now in Tempest, I only managed to run all tests, using "./run_tests.sh" and the only configuration I found related to stress tests was the [stress] section in tempest.conf. For example : let say I ported my SSH stress test as a scenario test with the @stresstest decorator. How can I launch this test (and only this one) and use a dedicated configuration file like ones we can found in "tempest/stress/etc" ? Another question I have now : in the case that I have to use "run_test.sh" and not "run_stress.py" anymore, how do I get the test runs statistics I used to have, and where should I put some code to improve them ? When I will have cleared my mind with all these kinds of practical details, maybe I should add some content on the Wiki about stress tests in Tempest. Best Regards, Julien LELOUP julien.lel...@3ds.com -Original Message- From: Koderer, Marc [mailto:m.kode...@telekom.de] Sent: Friday, January 17, 2014 3:07 PM To: LELOUP Julien Cc: openstack-dev@lists.openstack.org Subject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hi Julien, most of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them. BTW here is the Etherpad from the summit talk that we had: https://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests It possible help to understand the state. I didn't managed to work on the action items that are left. Your suggestions sound good. So I'd happy so see some patches :) Regards Marc From: LELOUP Julien [julien.lel...@3ds.com] Sent: Friday, January 17, 2014 11:52 AM To: Koderer, Marc Cc: openstack-dev@lists.openstack.org Subject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hello Marc, Thanks for your answer. At the moment I'm willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test. Does this means that all stress tests available in "tempest/stress" should be ported as scenario tests with this decorator ? I do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks. I don't know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on "fresh" stress tests. Best Regards, Julien LELOUP -Original Message- From: Koderer, Marc [mailto:m.kode...@telekom.de] Sent: Friday, January 17, 2014 9:45 AM To: LELOUP Julien Cc: openstack-dev@lists.openstack.org Subject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hello Juilen, I forwarded your mail to the correct mailing list. Please do not use the qa list any longer. I am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55). Unfortunately it's not yet used for scenarios like you describe. I'd suggest to build a scenario test in tempest/scenario and use this decorator on it. Any patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be n
Re: [openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it
Hi Julien, most of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them. BTW here is the Etherpad from the summit talk that we had: https://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests It possible help to understand the state. I didn't managed to work on the action items that are left. Your suggestions sound good. So I'd happy so see some patches :) Regards Marc From: LELOUP Julien [julien.lel...@3ds.com] Sent: Friday, January 17, 2014 11:52 AM To: Koderer, Marc Cc: openstack-dev@lists.openstack.org Subject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hello Marc, Thanks for your answer. At the moment I'm willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test. Does this means that all stress tests available in "tempest/stress" should be ported as scenario tests with this decorator ? I do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks. I don't know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on "fresh" stress tests. Best Regards, Julien LELOUP -Original Message- From: Koderer, Marc [mailto:m.kode...@telekom.de] Sent: Friday, January 17, 2014 9:45 AM To: LELOUP Julien Cc: openstack-dev@lists.openstack.org Subject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hello Juilen, I forwarded your mail to the correct mailing list. Please do not use the qa list any longer. I am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55). Unfortunately it's not yet used for scenarios like you describe. I'd suggest to build a scenario test in tempest/scenario and use this decorator on it. Any patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting (https://wiki.openstack.org/wiki/Meetings/QATeamMeeting) Regards Marc From: LELOUP Julien [julien.lel...@3ds.com] Sent: Wednesday, January 15, 2014 5:57 PM To: openstack...@lists.openstack.org Subject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hi everyone, I’m quite new on OpenStack / Tempest and I’m actually working on stress tests. I want to suggest a new feature in a currently available stress test. Not sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ☺ At the moment the “ssh_floating.py” stress test seems really interesting but I would like to improve it a bit. By now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don’t allow us to check if this instance is really available. I’m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered “ACTIVE” but actually unusable. So I’m implementing a full SSH connection test using the “paramiko” SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file). I don’t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead. Is this feature interesting for the OpenStack community ? Should I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ? On a second time, I plan to overhaul improve this “ssh_floating.py” script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way. Should I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ? Cordialement / Best Regards, Julien LELOUP R&D 3DExperience Platform IaaS Factory Technology Engineer julien.lel...@3ds.com<mailto:j
[openstack-dev] [qa] negative test framework: ready for review
Hi all, first part of the negative test framework is ready for review: https://review.openstack.org/#/c/64733/ Please have a look. Regards Marc and David DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it
Hello Juilen, I forwarded your mail to the correct mailing list. Please do not use the qa list any longer. I am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55). Unfortunately it's not yet used for scenarios like you describe. I'd suggest to build a scenario test in tempest/scenario and use this decorator on it. Any patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting (https://wiki.openstack.org/wiki/Meetings/QATeamMeeting) Regards Marc From: LELOUP Julien [julien.lel...@3ds.com] Sent: Wednesday, January 15, 2014 5:57 PM To: openstack...@lists.openstack.org Subject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on "ssh_floating.py" and improve it Hi everyone, I’m quite new on OpenStack / Tempest and I’m actually working on stress tests. I want to suggest a new feature in a currently available stress test. Not sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ☺ At the moment the “ssh_floating.py” stress test seems really interesting but I would like to improve it a bit. By now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don’t allow us to check if this instance is really available. I’m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered “ACTIVE” but actually unusable. So I’m implementing a full SSH connection test using the “paramiko” SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file). I don’t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead. Is this feature interesting for the OpenStack community ? Should I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ? On a second time, I plan to overhaul improve this “ssh_floating.py” script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way. Should I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ? Cordialement / Best Regards, Julien LELOUP R&D 3DExperience Platform IaaS Factory Technology Engineer julien.lel...@3ds.com<mailto:julien.lel...@3ds.com> [cid:image003.gif@01CF1216.D43ECE20] 3DS.COM<http://www.3ds.com/> Dassault Systèmes | 10 rue Marcel Dassault, CS 40501 | 78946 Vélizy-Villacoublay Cedex | France This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email. For other languages, go to http://www.3ds.com/terms/email-disclaimer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] negative test generation and testscenarios
Hi Robert, https://review.openstack.org/#/c/64733 is updated and is using testscenarios now. I was wondering if it would make sense to use a decorator instead of a class attribute to mark a test case for a certain test scenario, like: @TestCaseWithScenario(_scenarios1) def test_demo(self): ... @TestCaseWithScenario(_scenarios2) def test_demo2(self): I already implement something that seems to work with subunit: http://paste.openstack.org/show/61175/ I think this would ease up the usage of testscenarios for the negative test framework in tempest and looks quite cool. Feedback is welcome! Regards Marc From: Robert Collins [robe...@robertcollins.net] Sent: Tuesday, January 07, 2014 3:59 AM To: David Kranz Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [qa] negative test generation and testscenarios On 7 January 2014 07:41, David Kranz wrote: > Thanks to all who looked at https://review.openstack.org/#/c/64733/. There > were a few minor issues I will address but the biggest one was the > suggestion to run each variation as a separate test case using > testscenarios. After looking into that I see a problem with this use case. > Many of these negative tests need to allocate resources such as servers that > are then referenced in the test cases. Our tests currently do stuff like > that in setUpClass. But testscenarios, unless I misunderstand the code, > replicates the whole class which means the resource setup would also be > duplicated for each test. I think we need to share allocated resources > across the potentially large number of negative variations, and see two > options for that: You don't understand the code :). testscenarios doesn't affect the class of tests. As long as the resulting suite is wrapped in a setUpClass compatible TestSuite object, setUpClass should keep working. > 1. Some magic similar to testscenarios but that creates test methods with > varying parameters instead of test classes with varying attributes. > Leave allocation in setUpClass. -1 No different to testscenarios, just different to be different. > 2. Using testscenarios as-is but move the allocation/cleanup to the module > level (fixtures?) > This would be a little complicated because a bunch of the setup stuff is > defined as methods on the test base classes. Also, the classes would > run in parallel. Long term perhaps, not needed for this work. -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [qa] api schema validation pattern changes
> Von: David Kranz [mailto:dkr...@redhat.com] > Gesendet: Montag, 13. Januar 2014 05:04 > An: openstack-dev@lists.openstack.org > Betreff: Re: [openstack-dev] [nova] [qa] api schema validation pattern > changes > > On 01/12/2014 10:14 PM, Matthew Treinish wrote: > > > >>> Last, is a question, is it possible to currently run the full API > an > >>> build a json schema for it all? Or to query these validating > >>> schemas? We *really* want that over in tempest, so we can > completely > >>> drop the manual creation of negative testing, and just fuzz known > bad against the schema definitions. > >> Sorry, I'm not sure I understand this question correctly. > >> We need to define schemas for each API with the separated schema > patches. > >> It is impossible to define one schema for all APIs. > >> > >> > >> Hi David, Marc, > >> > >> I guess the negative test generator of Tempest would need each API > definition. > >> Glance can provide API definitions through API with jsonschema > >> format, but Nova does not have such feature. > >> We need to port these API schema from Nova to Tempest, I guess. > right? > >> > > As I understand things after reviewing the first versions of the > > negative test generator patch is that we have to hard code the schema > > into a file (right now it's in the test file, but eventually it'll be > > an external input file). One of my issues with doing that is it's > > highly manual process, essentially a copy and paste from the nova > > tree. I think what we're looking for from this jsonschema validation > > work is an API which we can query the API and get the jsonschema > definitions; similar to what the glance API offers. > I looked at the glance schema api and it seemed to just return the > schema for the json returned by the call, not for the arguments to the > request. Am I wrong about that? > Additionally, the schema for the request json in these patches is not > enough for the negative test generator. The schema for negative > generation also needs the http method type and a description of the > resources that are part of the url of the request. The negative test > patch in the shared fork > https://github.com/mkoderer/tempest/tree/feature/negative_tests > defines such a schema. The tempest patch will be updated from this fork > on Monday. > > > > I wouldn't advocate making the negative test generator be fully > > dynamic for the same reason we don't autodetect which API versions > and > > extensions/features are enabled in tempest, but rather rely on the > > config file. But, instead have an additional tool which could query > > the schema for all the endpoints in nova and generate an input file > > for the negative test generator. That way we'll still catch breaking > > API changes in the gate, but it's not a manual process to update the > > input file with the schema definitions in tempest when there is a > > breaking API change. (Which hopefully should almost never happen) > I agree, it would be ideal if there were a way for tempest to grab the > appropriate schemas from somewhere else rather than hard-coding them in > tempest itself. But as far as I can see, most of the services don't > even have json schemas defined. I think at the end the hard coded json schema should be optional. If the endpoint supports an export of the schema it simply takes it and put the result automatically into the description of the negative test. For me this is a second step since currently we already "duplicating" somehow this in our manual negative tests. What we would need is at least one interface that exposes the schema. Marc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Moving the QA meeting time
Hi all! > -Ursprüngliche Nachricht- > Von: Kenichi Oomichi [mailto:oomi...@mxs.nes.nec.co.jp] > Gesendet: Donnerstag, 5. Dezember 2013 01:37 > An: OpenStack Development Mailing List (not for usage questions) > Betreff: Re: [openstack-dev] [qa] Moving the QA meeting time > > > Hi Matthew, > > Thank you for picking this up. > > > -Original Message- > > From: Matthew Treinish [mailto:mtrein...@kortar.org] > > Sent: Thursday, December 05, 2013 6:04 AM > > To: openstack-dev@lists.openstack.org > > Subject: [openstack-dev] [qa] Moving the QA meeting time > > > > Hi everyone, > > > > I'm looking at changing our weekly QA meeting time to make it more > > globally attendable. Right now the current time of 17:00 UTC doesn't > > really work for people who live in Asia Pacific timezones. (which > > includes a third of the current core review team) There are 2 > approaches that I can see taking here: > > > > 1. We could either move the meeting time later so that it makes it > easier for > > people in the Asia Pacific region to attend. > > > > 2. Or we move to a alternating meeting time, where every other week > the meeting > > time changes. So we keep the current slot and alternate with > something more > > friendly for other regions. > > > > I think trying to stick to a single meeting time would be a better > > call just for simplicity. But it gets difficult to appease everyone > > that way which is where the appeal of the 2nd approach comes in. > > > > Looking at the available time slots here: > > https://wiki.openstack.org/wiki/Meetings > > there are plenty of open slots before 1500 UTC which would be early > > for people in the US and late for people in the Asia Pacific region. > > There are plenty of slots starting at 2300 UTC which is late for > people in Europe. > > > > Would something like 2200 UTC on Wed. or Thurs work for everyone? > > > > What are people's opinions on this? > > I am in JST. > Is Chris in CST, and Marc in CET? Yes, Giulio and I are in CET. And Attila too, right? > > Here is timezone difference. > 15:00 UTC -> 07:00 PST -> 01:30 CST -> 16:00 CET - 24:00 JST 22:00 UTC > -> 14:00 PST -> 08:30 CST -> 23:00 CET - 07:00 JST 23:00 UTC -> 15:00 > PST -> 09:30 CST -> 24:00 CET - 08:00 JST > > I feel 22:00 would be nice. I'd prefer to have two slots since 22 UTC is quite late. But I am ok with it if all others are fine. Regards Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.kode...@telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Proposals for Tempest core
+1 for both! From: Sean Dague [s...@dague.net] Sent: Friday, November 15, 2013 2:38 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [qa] Proposals for Tempest core It's post summit time, so time to evaluate our current core group for Tempest. There are a few community members that I'd like to nominate for Tempest core, as I've found their review feedback over the last few months to be invaluable. Tempest core folks, please +1 or -1 as you feel appropriate: Masayuki Igawa His review history is here - https://review.openstack.org/#/q/reviewer:masayuki.igawa%2540gmail.com+project:openstack/tempest,n,z Ken'ichi Ohmichi His review history is here - https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com+project:openstack/tempest,n,z They have both been actively engaged in the Tempest community, and have been actively contributing to both Tempest and OpenStack integrated projects, working hard to both enhance test coverage, and fix the issues found in the projects themselves. This has been hugely beneficial to OpenStack as a whole. At the same time, it's also time, I think, to remove Jay Pipes from tempest-core. Jay's not had much time for reviews of late, and it's important that the core review team is a working title about actively reviewing code. With this change Tempest core would end up no longer being majority north american, or even majority english as first language (that kind of excites me). Adjusting to both there will be another mailing list thread about changing our weekly meeting time to make it more friendly to our APAC contributors. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Tracking development of scenario tests
Hi all, I think we have quite the same issue with the neutron testing. I already put it on the agenda for the QA meeting for today. Let's make it to a general topic. Regards Marc From: Giulio Fidente [gfide...@redhat.com] Sent: Thursday, November 14, 2013 6:23 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [qa] Tracking development of scenario tests On 11/14/2013 12:24 AM, David Kranz wrote: > 1. Developer checks in the zeroth version of a scenario test as work in > progress. It contains a description of the test, and possibly work > items. This will "claim" the area of the proposed scenario to avoid > duplication and allow others to comment through gerrit. > 2. The developer pushes new versions, removing work in progress if the > code is in working state and a review is desired and/or others will be > contributing to the scenario. > 3. When finished, any process-oriented content such as progress tracking > is removed and the test is ready for final review. +1 , the description will eventually contribute to documenting the scenarios yet the submitter (step 1) remains in charge of adding to the draft the reviewers how about we map at least one volunteer to each service (via the HACKING file) and ask submitters to add such a person as reviewer of its drafts when the tests touch the service? this should help avoid tests duplication. I very much like the idea of using gerrit for this -- Giulio Fidente GPG KEY: 08D733BA | IRC: giulivo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] moratorium on new negative tests in Tempest
Hi, see below. Regards Marc From: Kenichi Oomichi [oomi...@mxs.nes.nec.co.jp] Sent: Wednesday, November 13, 2013 7:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa] moratorium on new negative tests in Tempest >> -Original Message- >> From: David Kranz [mailto:dkr...@redhat.com] >> Sent: Wednesday, November 13, 2013 4:33 AM >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [qa] moratorium on new negative tests in Tempest >> So that is the starting point. Comments and suggestions welcome! Marc >> and I just started working on an etherpad >> https://etherpad.openstack.org/p/bp_negative_tests but any one is >> welcome to contribute there. >Negative tests based on yaml would be nice because of cleaning the code up >and making the tests more readable. >just one question: > On the etherpad, there are some "invaid_uuid"s. > Does that mean invalid string (ex. utf-8 string, not ascii)? > or invalid uuid format(ex. uuid.uuid4() + "foo")? Great that you already had a look! So my idea is that we have a battery of functions which can create erroneous input. My intention for invalid_uuid was just something like uuid.uuid4() - but the name is a bit misleading. We can use additional functions that create the input that you are suggesting. I think all of them make sense. > IIUC, in negative test session, we discussed that tests passing utf-8 string > as API parameter should be negative tests, and the server should return a > BadRequest response. > I guess we need to implement such API negative tests. After that, if finding > an unfavorable behavior of some server, we need to implement API validation > for the server. > (unfavorable behavior ex. When a client send utf-8 request, the server returns > a NotFound response, not a BadRequest one) +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] fuzzy testing of client functions
Hello folks, I remember that we had a quick chat about fuzzy testing in a QA meeting. IMHO we have much too many negative tests in tempest that aren't really complex. So I tried to build up a little tool that discovers the parameters of a client functions and randomizes the input for it. It works like this: ./run_fuzzy_test.py image_client update_image -n 100 2013-10-19 13:42:10.634 27748 ERROR ClientFuzzTest [-] Bad request 2013-10-19 13:42:10.658 27748 ERROR ClientFuzzTest [-] Bad request 2013-10-19 13:42:10.670 27748 ERROR ClientFuzzTest [-] must be string or buffer, not int 2013-10-19 13:42:10.709 27748 ERROR ClientFuzzTest [-] Object not found 2013-10-19 13:42:10.738 27748 ERROR ClientFuzzTest [-] Bad request Could you give me some feedback about your thoughts: https://review.openstack.org/#/c/52768 It's maybe just a starting point for a discussion on the summit. Regards, Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] New plugin
Hello, I am Marc Pinhède, working in Netvirt with professor Omar Cherkaoui. We started working on a Neutron plugin. A first version is now almost ready. To inform the community, we posted a blueprint: https://blueprints.launchpad.net/neutron/+spec/modular-adaptative-plugin We would like to make our code available soon. But wiki page https://wiki.openstack.org/wiki/NeutronDevelopment does not gives many clues on where and how to post code. As Havana is in feature-freeze stage, discussions on the blueprint and eventual integration in Neutron core may come once Havana would be released. Waiting for this, where is the better place to make our code available? Marc Pinhède ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] What is the purpose of stress test in tempest?
Hi all, After some refactoring work in tempest/stress I would like to raise a general question since I have the feeling we have different opinions about the purpose of tempest stress test. Giulio already put this topic on the agenda for the next QA meeting and I just want that we use the time in between to think about the problem ;) Please have a look to the discussions in: https://review.openstack.org/#/c/39752/ https://review.openstack.org/#/c/38980/ IMHO a stress test is not a independent test area (like api-tests, scenario test etc) it's just a way how tests are processed. So in theory any small API-test could be used as a stress test and any scenario test could be used too. I see two use cases for stress tests: - As a developer I want to find bugs that occur under load (like raise conditions) --> Leads to many small and concurrent api tests - As OPS/QA I want to generate load that simulates real life load in a production-like system --> Leads to concurrent scenario test Kind Regards Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (P&I) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt E-Mail: m.kode...@telekom.de www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
