*** threestrands has joined #openstack-rally | 00:00 | |
*** anilvenkata has joined #openstack-rally | 04:52 | |
*** tobberydberg has joined #openstack-rally | 05:46 | |
*** threestrands has quit IRC | 05:54 | |
*** tosky has joined #openstack-rally | 07:23 | |
openstackgerrit | Merged openstack/rally-openstack master: [ci] Move osresources script under ci roles https://review.opendev.org/718452 | 07:56 |
---|---|---|
marosg | hello andreykurilin are you around? | 11:23 |
andreykurilin | marosg: hi! yes | 11:23 |
andreykurilin | marosg: how things are going? | 11:23 |
marosg | I would need an advice - I am working on designate+VM scenario where VM tries to resolve its own name against existing (not rally created) designate | 11:24 |
marosg | it works fine, but there is one thing - when you have several users in one tenant and they are executed in parallel, they all try to change domain for their rally vreated network | 11:25 |
marosg | they would each have different domain, but one network, so that cannot work | 11:25 |
marosg | question is if I can say there is a constraint of just one user per tenant | 11:26 |
marosg | and if it is possible to enforce it via decorator when checking requirements | 11:26 |
marosg | maybe a little better explanation - scenario creates a zone and changes rally created network to use this zone | 11:27 |
marosg | code like this | 11:29 |
marosg | https://paste.ubuntu.com/p/THRYvRp67n/ | 11:29 |
andreykurilin | marosg: first of all, I'm not familiar with designate at all, so I need more details before trying to help :) how designate works with neutron/nova? docs of designate says that it has integration with neutron and nova, i.e designate can create records in auto mode. If it so, no matter how many parallel calls for a new vm, it should create separate records. It sounds like a bug for mew, if it doesn't work | 11:41 |
marosg | no, not a bug. look at the code I posted. you have to modify tenant network to be aware of the zone which designate is using. then whenever there is a VM created within that zone, its IP will be automatically populated to designate | 11:43 |
andreykurilin | ok, I see | 11:43 |
andreykurilin | so there is can be only one zone for network or for subnet? | 11:44 |
marosg | and if this is onvoked in parallel for three VMs in the same tenant, they will each create new zone and update network with their zone, verwriting what others did | 11:44 |
andreykurilin | i guess for a network | 11:44 |
marosg | yes | 11:44 |
marosg | network | 11:44 |
andreykurilin | more generic question: what you are trying to check?:) I mean do you really need to create a new zone each time or zone can be attached to the network before workload execution as a preparation step(i.e at contexts)? | 11:46 |
marosg | that is openstack zone thing - only owner of the zone can change it (or admin) so if zone is created before rally, only owner and admin can write to it, there is no tenant shared zone yet | 11:47 |
marosg | hm, context, interesting, I am not familiar with that much | 11:48 |
andreykurilin | marosg: ok, let's talk about contexts :) | 11:48 |
marosg | lol | 11:48 |
andreykurilin | it sounds for me as something you actually need | 11:48 |
marosg | maybe | 11:49 |
andreykurilin | we are talking about rally task, right? | 11:49 |
marosg | yes | 11:49 |
andreykurilin | good | 11:49 |
marosg | ahhh, there is zones context | 11:55 |
andreykurilin | rally task samples are written using task format v1 that I should deprecate at some point...eh.. v2 format is much better, i'll use links to it for further explanations. rally task consists of subtasks (https://github.com/openstack/rally-openstack/blob/master/rally-jobs/nova.yaml#L10). Each subtask consists of workloads(https://github.com/openstack/rally-openstack/blob/master/rally-jobs/nova.yaml#L26). For simplification of subt | 11:57 |
andreykurilin | ask format, if it contains only one worload, workload configuration can be written at top of subtask section itself(https://github.com/openstack/rally-openstack/blob/master/rally-jobs/nova.yaml#L12-L23). A workload itself is described by scenario, runner, contexts and sla. SLA describes how results of execution should be treated. scenario describes what a single iteration should do. Runner runs iterations (actual workload to API | 11:57 |
andreykurilin | ). Contexts - the thing that includes pre step that is executed before all iterations and post step that is executed after all iterations are complited. We are using contexts to create temporary users, images, networks, etc. It is helpful to limit scenario to actual workload we want to check | 11:57 |
marosg | sure, I use contexts in rally.yaml when invoking task | 11:59 |
andreykurilin | so you can use(write a new since old one is designate v1 only) context plugin that will create a zone an attach to network | 12:00 |
andreykurilin | so each network will have only one zone | 12:01 |
marosg | I was afraid you would say I have to write new one instead of using existing ;) | 12:05 |
andreykurilin | 1) it is simple :) lol | 12:05 |
andreykurilin | 2) I guess the old one can be modified | 12:05 |
marosg | andreykurilin: I am looking at rally-openstack/rally_openstack/task/contexts/designate/zones.py | 12:06 |
marosg | there is no mention of network | 12:07 |
marosg | so if I want to modify network to be aware of the zone, I have to do it in scenario or can I do it somehow in contect? | 12:08 |
marosg | *context | 12:09 |
andreykurilin | if you are ok to the next workflow: create a single designate zone and attach to a network, use the network in paraller. yes, context is what you need | 12:10 |
andreykurilin | as for the current zones contexts - yeah, it looks useless. i.e. only precreates zones. For checking zones.list?! | 12:10 |
marosg | lets say I modify context. I will create one zone per tenant. But how do I modify network at this point? how do I know some is even created? can I influenece order of contexts? | 12:14 |
andreykurilin | see last argument here - https://github.com/openstack/rally-openstack/blob/master/rally_openstack/task/contexts/designate/zones.py#L24 | 12:14 |
andreykurilin | https://github.com/openstack/rally-openstack/blob/master/rally_openstack/task/contexts/network/networks.py#L31 <- networks context is executed earlier | 12:15 |
marosg | ahhh, nice | 12:16 |
marosg | thank you. I am sure you will hear from me again :) | 12:16 |
andreykurilin | also, it would be nice to get rid of zones_per_tenant. it sounds redundant. if we want to attach zones to networks, we should have number of zones equal to number of networks, not the number of tenants | 12:18 |
marosg | but that could break some tests | 12:28 |
marosg | if someone uses designate tests... | 12:28 |
andreykurilin | Are they working? | 12:28 |
marosg | some | 12:28 |
andreykurilin | heh, ok | 12:28 |
andreykurilin | I need to try to restore designate CI job. it was broken for a while.. | 12:29 |
marosg | andreykurilin: I think I could modify zones context to keep existing functionality plus modify first netwrok using first zone. that would be new boolean parameter which would be False if not provided | 12:35 |
andreykurilin | great | 12:35 |
openstackgerrit | Andrey Kurilin proposed openstack/rally master: Update password for dockehub account https://review.opendev.org/720198 | 13:11 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 13:17 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 13:21 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 13:30 |
*** rcernin has quit IRC | 13:37 | |
openstackgerrit | Andrey Kurilin proposed openstack/rally master: Update password for dockehub account https://review.opendev.org/720198 | 13:57 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 13:59 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: WIP: try to restore designate CI https://review.opendev.org/556825 | 14:04 |
openstackgerrit | Andrey Kurilin proposed openstack/rally master: Update password for dockehub account https://review.opendev.org/720198 | 14:26 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: WIP: try to restore designate CI https://review.opendev.org/556825 | 15:31 |
andreykurilin | marosg: wow - https://4d6809932811773c27c6-87320f1b85511885c71f0c1fb804eba8.ssl.cf2.rackcdn.com/556825/8/check/rally-task-designate/967c5c2/results/report.html as part of https://review.opendev.org/#/c/556825/ . I thought our code works only for designate v1... but it looks like something works for v2 as well | 16:33 |
marosg | yes, bits and pieces. for example when you create zone, it is V2 call. but cleanup tries to remove domain, which was deprecated and is only in v1. it finishes with success but you can see traceback | 16:34 |
marosg | that I already solved in my current code | 16:34 |
andreykurilin | nice | 16:35 |
andreykurilin | I think we can remove v1 support, since designateclient doesn't support it actually :) | 16:35 |
andreykurilin | marosg: am I right that doman, record, server are resources of V1 and zone&recordset are v2? | 16:38 |
marosg | domain for sure is v1, not sure about record and server | 16:40 |
marosg | and zone+recordset is v2, yes | 16:41 |
marosg | please don't change designate stuff now :) | 16:45 |
andreykurilin | marosg: okay... | 16:45 |
andreykurilin | marosg: Are you working on enabling CI for designate? | 16:46 |
andreykurilin | PS: I did not plan to change code related to designate, just tried to get some knowledge of the current state of plugins for it. | 16:47 |
marosg | andreykurilin: we had our own code which created network, router etc, then I it generated vm scenario yaml and ran rally, cleanup afterwards. Now i am trying to offload all that overhead to rally | 16:47 |
andreykurilin | good | 16:47 |
marosg | it will be very similar to manila - do some stuff, create vm, call a script (which will use dig to resolve name) | 16:48 |
andreykurilin | so you are not modifying https://github.com/openstack/rally-openstack/blob/master/tests/ci/playbooks/roles/list-os-resources/library/osresources.py and I can finish https://review.opendev.org/#/c/556825/ so we will have a CI job for the time you will push a change | 16:49 |
marosg | andreykurilin: no, I am not touching any of that | 16:49 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: Restore designate CI https://review.opendev.org/556825 | 16:54 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 16:55 |
*** anilvenkata has quit IRC | 17:00 | |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: wip: add regular pushes to dockerhub https://review.opendev.org/720199 | 17:01 |
openstackgerrit | Andrey Kurilin proposed openstack/rally-openstack master: Restore designate CI https://review.opendev.org/556825 | 18:20 |
marosg | andreykurilin: stupid thing - how can I access neutron utils from zone context? | 18:34 |
marosg | something similar to self.clients("neutron").update_subnet(subnet_id, body) in scenario | 18:34 |
andreykurilin | marosg: https://github.com/openstack/rally-openstack/blob/master/rally_openstack/task/contexts/network/routers.py#L100-L102 | 18:35 |
marosg | andreykurilin: that is some serious woodoo. I would never come up with that. thank you | 18:49 |
andreykurilin | oh...someday I'll have enough time to update docs... | 18:50 |
openstackgerrit | Merged openstack/rally-openstack master: Restore designate CI https://review.opendev.org/556825 | 21:21 |
*** rcernin has joined #openstack-rally | 22:45 | |
*** tosky has quit IRC | 23:39 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!