14:01:02 <andreykurilin_> #startmeeting Rally
14:01:03 <rallydev-bot2> [From Gitter] astarove : Hi
14:01:03 <openstack> Meeting started Mon Mar 13 14:01:02 2017 UTC and is due to finish in 60 minutes.  The chair is andreykurilin_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:06 <openstack> The meeting name has been set to 'rally'
14:01:39 <hai_shi> hi
14:02:40 <andreykurilin_> we do not have meetings for a long time. It is time to return back that event
14:02:54 <andreykurilin_> I have several items to discuss
14:03:04 <andreykurilin_> #topic Status of Rally 0.9.0
14:03:14 <andreykurilin_> Rally 0.9.0 is our new release
14:04:02 <andreykurilin_> We merged all features required for that release
14:04:13 <andreykurilin_> but they produced some "bugs" :)
14:05:18 <andreykurilin_> our new cleanup mechanism doesn't cover the case of auto-created resources :(
14:05:59 <andreykurilin_> for example in case of booting VM with auto_assign_nic=True, Nova will assign floating IP which we don't cleanup
14:06:17 <andreykurilin_> such resources doesn't match our name patterns and it is hard to identify them
14:07:10 <andreykurilin_> I'll try to find the way to discover and remove such resources
14:07:19 <andreykurilin_> it is only one blocker for Rally 0.9.0
14:07:57 <hai_shi> Do you find some better way to resolve it?
14:08:21 <andreykurilin_> hai_shi: not yet :)
14:08:44 <andreykurilin_> we should not revert your change, since it is a big step forward
14:09:11 <andreykurilin_> but should add support for another method of discovering resources
14:09:28 <andreykurilin_> hope, today I'll produce a PoC
14:10:34 <hai_shi> can we update those resources' name?
14:11:48 <hai_shi> or before use it, we should tag them.
14:12:07 <andreykurilin_> hai_shi: no. for example, we do not have access for creating params of floating-ip created while  "booting VM with auto_assign_nic=True", since that resource is not created by Rally itself. Nova-API does it automatically
14:15:00 <andreykurilin_> ok, let's move to the next topic
14:15:09 <andreykurilin_> #topic plans for the next release
14:15:54 <andreykurilin_> Version 1.0.0 was reserved long time ago for the release of Rally that will support not-only OpenStack platforms
14:16:05 <andreykurilin_> and it looks like the time is come
14:16:33 <andreykurilin_> I hope that tohin will finish refactor of credentials and deployment during the next release
14:16:36 <andreykurilin_> :)
14:17:20 <chenhb_> Hi
14:17:22 <andreykurilin_> another things that should be finally merged: glance and cinder "services"..
14:17:30 <andreykurilin_> hi chenhb_!
14:17:36 <hai_shi> hi
14:18:05 <andreykurilin_> also, RaaS stuff should be started and atomic actions refactoring
14:18:13 <andreykurilin_> actually, we have a lot of items for the next release
14:18:15 <andreykurilin_> :)
14:18:41 <hai_shi> a big step!
14:19:38 <chenhb-> ping
14:19:47 <andreykurilin_> chenhb- pong
14:20:23 <andreykurilin_> So let's schedule Rally 1.0.0 release to the middle-end of April.
14:21:23 <hai_shi> No problem.
14:21:32 <andreykurilin_> cool
14:22:13 <chenhb-> copy
14:22:17 <andreykurilin_> ok, so list with items to share is finished
14:22:23 <andreykurilin_> *my list
14:22:27 <andreykurilin_> any topics to discuss?
14:22:54 <andreykurilin_> #topic Free discussion
14:23:09 <hai_shi> hi, andrey. Do we have some policies about disater-cleanup?
14:23:51 <hai_shi> I see we have many items to do in bp of cleanup.
14:24:06 <chenhb-> about service module, do we need to generate name in service?
14:24:23 <chenhb-> or move to scenarios
14:25:56 <andreykurilin_> hai_shi: policies? so it is one more "nice to have" feature :) I need to revise spec for it (I do not remember work-items from it), but it looks like we need just to implement entry point for it and call cleanup mechanism with proper task uuid
14:25:58 <hai_shi> i see generate_name in scenarios' util serveral times.
14:27:07 <hai_shi> Ok, I just see some items need to do in bp.
14:27:38 <andreykurilin_> chenhb-: In most cases scenario(or context) doesn't interested in name of resource, so for simplification and unification, services should generate names by default(if name is not transmitted by scenario)
14:28:19 <hai_shi> Why we should transmitted name by scenarios?
14:29:33 <hai_shi> user transmited name and we didn't use it~~
14:30:01 <chenhb-> If user use custom name,our new cleanup can clean them?
14:30:25 <andreykurilin_> when I said scenario, I mean python code. Setting names from task (via JSON/Yaml) should be restricted
14:31:17 <andreykurilin_> chenhb-: no, our cleanup mechanism will not remove resources with custom names
14:31:59 <hai_shi> https://review.openstack.org/#/c/432138/3/rally/plugins/openstack/scenarios/cinder/utils.py@430
14:33:39 <andreykurilin_> @hai_shi: we should restrict such scenarios. For checking feature of "updating name", we should accept boolean argument "update_name" via task, and call generate_random_name by in python scenario
14:33:42 <hai_shi> andrey: What is your idea about this test? it is transmited name in scenario.
14:33:47 <fungi> mordred: http://lists.openstack.org/pipermail/openstack-infra/2017-March/005240.html seems to suggest that manage-projects isn't updating. any chance you want to take a look?
14:34:00 <hai_shi> ok, copy that.
14:34:08 <chenhb_> ok,  keep name in python code
14:34:14 <fungi> oops, sorry, wrong channel :/
14:34:27 <andreykurilin_> fungi: np :)
14:36:32 <andreykurilin_> chenhb: I see a lot of "reconnection" messages for you. If you have problems with IRC, you can use our gitter channel for meetings, it has configured sync-bot too
14:37:26 <chenhb_> yep, nothing from me now: )
14:37:45 <andreykurilin_> about cleanups and names: Since we merged "new cleanup", let's check all scenarios and restrict setting names via tasks
14:38:18 <chenhb_> copy
14:38:26 <hai_shi> ok
14:38:37 <andreykurilin_> anything else?
14:39:19 <hai_shi> small question
14:39:54 <andreykurilin_> sure
14:40:28 <hai_shi> when use auto_assign_nic, we would use the same network again and again due to the random function.
14:40:49 <hai_shi> But it is not a good way to test.
14:44:06 <andreykurilin_> hai_sho: it is not random at all:) picking random networks tries to balance the load between available networks. if you setup networks context to create N networks, where N is a number of iterations, each iteration will use separate network
14:44:11 <andreykurilin_> *hai_shi
14:44:33 <hai_shi> in this lines https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/neutron/utils.py#L296-L297
14:45:02 <andreykurilin_> ok, so it is not about auto_assign_nic at all
14:45:24 <andreykurilin_> https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/nova/utils.py#L98-L106
14:45:29 <hai_shi> ok, i forget details:(
14:45:33 <andreykurilin_> that function is used with booting vms
14:47:01 <hai_shi> it looks better.
14:48:18 <andreykurilin_> as for neutron scenarios, some of them use https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/neutron/utils.py#L296-L297 and yes, it makes unfair situation. There are two possible solutions- adopt _get_or_create_network to do not use random (as it done in _pick_random_nic) or abandon ability to use pre-created networks
14:50:20 <hai_shi> thanks, andrey. I have no other problem.
14:50:43 <andreykurilin_> any other topics to discuss?
14:51:03 <andreykurilin_> ok, let's finish
14:51:18 <andreykurilin_> thanks to everyone!
14:51:19 <andreykurilin_> bye
14:51:22 <andreykurilin_> #endmeeting