| *** tetsuro has joined #openstack-placement | 00:03 | |
| *** tetsuro has quit IRC | 00:16 | |
| *** tetsuro_ has joined #openstack-placement | 00:16 | |
| *** mriedem has quit IRC | 00:43 | |
| *** tetsuro_ has quit IRC | 01:08 | |
| *** tetsuro has joined #openstack-placement | 01:09 | |
| *** takashin has joined #openstack-placement | 01:24 | |
| *** tetsuro has quit IRC | 01:33 | |
| *** dims has quit IRC | 01:40 | |
| *** dims has joined #openstack-placement | 02:11 | |
| *** dims has quit IRC | 02:25 | |
| *** tetsuro has joined #openstack-placement | 02:30 | |
| *** dims has joined #openstack-placement | 02:33 | |
| *** tetsuro has quit IRC | 02:46 | |
| *** tetsuro_ has joined #openstack-placement | 02:46 | |
| *** tetsuro_ has quit IRC | 03:53 | |
| *** tetsuro has joined #openstack-placement | 06:30 | |
| *** takashin has quit IRC | 07:32 | |
| *** takashin has joined #openstack-placement | 07:50 | |
| *** takashin has left #openstack-placement | 08:00 | |
| *** belmoreira has joined #openstack-placement | 08:02 | |
| *** e0ne has joined #openstack-placement | 08:10 | |
| *** e0ne has quit IRC | 08:33 | |
| *** ttsiouts has joined #openstack-placement | 08:33 | |
| *** ttsiouts has quit IRC | 08:47 | |
| *** ttsiouts has joined #openstack-placement | 08:48 | |
| *** tetsuro has quit IRC | 08:48 | |
| *** ttsiouts has quit IRC | 08:52 | |
| *** tssurya has joined #openstack-placement | 08:54 | |
| *** e0ne has joined #openstack-placement | 09:01 | |
| *** ttsiouts has joined #openstack-placement | 09:09 | |
| *** cdent has joined #openstack-placement | 10:25 | |
| *** ttsiouts has quit IRC | 11:13 | |
| *** ttsiouts has joined #openstack-placement | 11:58 | |
| *** cdent has quit IRC | 12:26 | |
| *** mriedem has joined #openstack-placement | 13:32 | |
| *** cdent has joined #openstack-placement | 13:56 | |
| *** ttsiouts has quit IRC | 14:09 | |
| *** ttsiouts has joined #openstack-placement | 14:17 | |
| cdent | lyarwood: thanks for the response on that thread. I have to admit I still don't fully get it, but will think upon it a while before I make any questions. | 14:19 |
|---|---|---|
| *** belmoreira has quit IRC | 14:20 | |
| *** belmoreira has joined #openstack-placement | 14:21 | |
| lyarwood | cdent: np, so IOW, having both the original placement and extracted openstack/placement around into the T release would allow projects like TripleO additional time to write and more importantly validate the required upgrade logic to migrate between the two. | 14:29 |
| lyarwood | cdent: If anything it just highlights how broken our approach to upgrades is in TripleO | 14:29 |
| cdent | but things like stable/rocky are always around? | 14:30 |
| lyarwood | cdent: right but we don't deploy mixed versions and always upgrade all components in the same step to the same release | 14:33 |
| lyarwood | cdent: so we wouldn't run stable/rocky openstack-nova-placement-api with stein for example | 14:33 |
| cdent | ah, right. okay that clarifies things a bit better. So if an actual deployment wanted to run rocky nova with stein placement they couldn't do that: the overcloud is a sort of unit? | 14:34 |
| lyarwood | cdent: if you really wanted to you could edit the images being pulled in but the deployment logic itself would assume you were using stein placement | 14:35 |
| lyarwood | cdent: btw, have the OSA folks actually landed support for an extracted placement service? | 14:36 |
| lyarwood | I'm digging around in gerrit now but I can't find any evidence that they have | 14:36 |
| lyarwood | and the same for kolla-ansible | 14:36 |
| cdent | as far as I can tell it is still in progress | 14:37 |
| cdent | I haven't been tracking it that closely in the past few weeks because of other obligations. | 14:37 |
| lyarwood | kk np | 14:38 |
| cdent | I also didn't want to be responsible for all things. I feel like if I was supposed to be responsible for being aware of all that, the ordering of things would have been different... | 14:38 |
| lyarwood | yeah understood, just trying to load context ahead of the call later | 14:40 |
| cdent | yup, is good to do that loading | 14:41 |
| cdent | lyarwood: from a tripleo standpoint, if the placement remains in nova after the end of stein, that helps. Is the fact that it is not tested an issue? If there is divergence between those codesets (there already is underneath, but not at the API level) is that a problem? | 14:45 |
| * cdent walks | 14:53 | |
| cdent | biab | 14:53 |
| *** cdent has quit IRC | 14:53 | |
| mnaser | lyarwood: we have not landed it yet unfortunately | 15:30 |
| mnaser | there's a bit of work that's left and our 'testing mechanism' really relies on most openstack projects using tempest | 15:31 |
| mnaser | so we dont have an easy way to validate placement working.. other than trying to find some other way to do it | 15:31 |
| mnaser | lyarwood: how are you validating the placement module in ic? | 15:31 |
| mnaser | s/ic/ci/ | 15:31 |
| lyarwood | mnaser: indirectly in TripleO and the puppet projects through the compute related tempest tests | 15:44 |
| lyarwood | mnaser: directly in RDO but only through the normal unit and func tests | 15:45 |
| mnaser | lyarwood: yeah i was hoping that we can just run tempest tests for placement only but apparently those dont exist | 15:45 |
| mnaser | and i dont really want to deploy with nova and all inside the role tests so yeah | 15:45 |
| lyarwood | mnaser: yeah and never have tbh so I don't see that as a blocker | 15:45 |
| mnaser | in OSA, we validate roles independently and then in openstack-ansible we test it all integrated together | 15:45 |
| lyarwood | mnaser: understood, do you have a topic for all of this btw? | 15:47 |
| mnaser | lyarwood: on gerrit? not really, we just have one kinda big role that's stalled a bit. https://review.openstack.org/#/c/618820/ | 15:47 |
| mnaser | i'm planning to get that moving again soon. | 15:47 |
| lyarwood | mnaser: ack thanks | 15:51 |
| *** cdent has joined #openstack-placement | 15:56 | |
| lyarwood | cdent: re your question earlier about testing, the fact this isn't tested in the upstream gate isn't an issue, unit and func are tested when building the packages in RDO and we are also testing the original service in the TripleO gate until the extraction lands. | 15:57 |
| cdent | lyarwood: cool, thanks | 15:58 |
| mnaser | cdent: i was asking what's the best way to run functional tests agains the api? | 15:59 |
| cdent | mnaser: it depends on what you mean by against the api | 15:59 |
| mnaser | in OSA world, we run tests against a specific service in the role, and we run everything all integerated in our integrated openstack-ansible repo | 15:59 |
| cdent | the existing functional tests in placement are "against the api" | 15:59 |
| mnaser | so for example, i'm building a mistral role, we'll drop mistral_tempest_tests and run mistral tests only inside the role | 16:00 |
| mnaser | ok so do they expect the api to be setup and running at a certain host/port/etc? | 16:00 |
| cdent | no, the api runs in the same process as the test | 16:00 |
| cdent | if what you're after is tests where the api is a different process, that's relatively easy to do, but fairly meaningless | 16:01 |
| cdent | sorry, fairly meaningless without something on the client side (like nova) | 16:01 |
| mnaser | it's meaningful in our case because in our role tests, we deploy a specific service only, so sometimes it's literally a matter of passing a "list all consumers and return a 200 ok" or something like that | 16:01 |
| cdent | does it have to be tempest or would you be happy with something simpler/faster? | 16:02 |
| cdent | see, for example: https://git.openstack.org/cgit/openstack/placement/tree/playbooks/perfload.yaml | 16:02 |
| mnaser | tempest would be the fastest path to success (i.e. we literally have to add a variable pointing to a tempest plugin and a whitelist of tests) | 16:02 |
| cdent | It was recently agreed that we wouldn't do placement api tests in tempest (there was a thread on that mid january) | 16:04 |
| mnaser | that's fine | 16:04 |
| cdent | what tempest would have is "tests of things that use placement" | 16:04 |
| mnaser | right, which would mean we'd have to deploy an entire openstack to test placement which will happen in our integrated repo, but in our 'role' only tests, it's a bit unnecessary | 16:04 |
| cdent | another pending strategy for live tests of a placement service is: https://review.openstack.org/#/c/607508/ | 16:04 |
| cdent | I get that that's bad, so I'm trying to understand what you want instead? | 16:05 |
| cdent | In a perfect universe what would exist? | 16:05 |
| *** openstackgerrit has joined #openstack-placement | 16:05 | |
| openstackgerrit | Merged openstack/placement master: Also time placeload when doing perfload https://review.openstack.org/628023 | 16:05 |
| mnaser | "something" i can run which can make requests against the placement service i just deployed to validate that it's functional (and in the term functional here, not run the entire test suite, but, maybe a *very* basic crud) | 16:06 |
| mnaser | just to know that ok: db is running properly, api is responding properly, the service seems to be deployed correctly | 16:06 |
| cdent | mnaser: presumably you already have bits in place which do the deployment and add placement to the service catalog, yes? If so, we can write about a four line shell script into a playbook, point it at some gabbi files and be done. Would that work? It sounds like you'd prefer something more tempest oriented, but placement is "built in" at the moment: | 16:08 |
| cdent | actually, never mind, you're using tempest in the "point at pre-existing stuff" sense | 16:08 |
| mnaser | cdent: tempest is easier but i'm not opposed to other solutions, we've in the past done something where we just call a task that talked to that cloud | 16:09 |
| mnaser | so yes, ideally if i can hit that shell script and point it at gabbi files and it can test that endpoint, that's perfect | 16:09 |
| cdent | If you want to create the first half of that: the environment that ends with a noop shell script, I can do the part that makes the shell script do something useful | 16:09 |
| mnaser | cdent: https://github.com/openstack/openstack-ansible-os_heat/blob/master/tests/test-heat-functional.yml this isn't ideal, but it's almost something like that | 16:10 |
| mnaser | so we don't always go to tempest, sometimes we fall off to something similar to that | 16:10 |
| mnaser | (that probably returns 300 even if the db is failing so it's not ideal but okay, i can do that | 16:10 |
| * cdent nods | 16:10 | |
| cdent | We've already got a huge mess of existing gabbi tests that can be cribbed from to get very complete coverage | 16:11 |
| cdent | mnaser: Cool, ping me when something exists and I can get right on it. | 16:12 |
| cdent | brb | 16:12 |
| *** ttsiouts has quit IRC | 16:18 | |
| *** ttsiouts has joined #openstack-placement | 16:18 | |
| *** ttsiouts has quit IRC | 16:23 | |
| mriedem | umm, so do we have a placement extraction meeting in 30 minutes? | 16:30 |
| edleafe | yup | 16:31 |
| mriedem | does everyone else know about that? | 16:32 |
| edleafe | ssshhh - it's a secret! | 16:32 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Use one ConfigOpts in placement-status https://review.openstack.org/633595 | 16:32 |
| mriedem | my point is do melwitt, lyarwood and dansmith know there is an extraction follow up meeting in 28 minutes? | 16:32 |
| cdent | mriedem: i made an email earlier today, and mentioned it at the scheduler meeting | 16:32 |
| mriedem | ah i see the email now | 16:33 |
| mriedem | sorry | 16:33 |
| dansmith | I hadn't noticed | 16:33 |
| cdent | a part of me was just going to wait and see, but that would have been churlish | 16:33 |
| cdent | dansmith: there's some context loading in the email, and also a bit earlier today in this channel from lyarwood | 16:36 |
| dansmith | ack, have now read it | 16:39 |
| mriedem | likely also want bauzas since it sounds like he's going to be making the updates to the libvirt reshaper patch | 16:40 |
| mriedem | which i burned out on | 16:40 |
| mriedem | dansmith: btw, i wanted to ask since you mentioned the cinder extraction having an overlapping release as an example in the last call we had - what was the db story with the cinder extraction? i'm assuming just copy the (single at the time) nova db and that was it? and downtime was less of a concern because people already dealt with downtime back in the essex/folsom days | 16:43 |
| dansmith | mriedem: I don't remember that specifically, but I think it was pretty much a dump and load, yeah.. | 16:44 |
| dansmith | the cinder thing is one example, which is worthy, but I think that in general nova has not removed things from its tree in the same release that you had to make a deployment change | 16:44 |
| dansmith | like all the cells stuff was planned to be "move to this release, *then* sideways adjust things before the next release where something is required/dropped" | 16:45 |
| dansmith | which is definitely how I think we *should* be doing things like this | 16:45 |
| mriedem | e.g. move to newton when cells v2 and placement are optional but available, and required to get to ocata | 16:46 |
| *** bauzas has joined #openstack-placement | 16:46 | |
| dansmith | right | 16:46 |
| efried | Is there a way to join the hangout from the hangouts app on mobile? I'm going to be on the move at the time. | 16:46 |
| mriedem | efried: i can maybe invite you | 16:46 |
| mriedem | yeah | 16:46 |
| efried | noyce, thanks. | 16:48 |
| melwitt | yeah. that model eases upgrades for deployers, in my experience from my time at yahoo. preferable to be able to deal with a code move/package change and data migration separately | 16:48 |
| dansmith | yeah, I've been saying that about the placement move since the beginning of the discussion, but alas. | 16:48 |
| cdent | does leaving code behind also mean not making changes in the extracted code? If not, NBD, if so, then presumably that's the reason we chose the current strategy, to not be so slow | 16:49 |
| cdent | because we are running years behind schedule... | 16:49 |
| efried | If we go that route, will it mean that we should reinstate some kind of testing around nova-in-placement? | 16:49 |
| mriedem | changes = new features | 16:49 |
| mriedem | ? | 16:49 |
| dansmith | cdent: yeah, that's not a reasonable excuse to me, but I understand the exhaustion | 16:49 |
| cdent | mriedem: yeah, I'm thinking the pending specs, for example. | 16:50 |
| edleafe | We have been making changes in the extracted code already. It means that the nova-placement code will basically stay unchanged | 16:50 |
| mriedem | edleafe: not api changes though | 16:50 |
| dansmith | IMHO, you can still make changes to the new thing, nova just has to *work* with the old thing | 16:50 |
| cdent | that's why we have microversions, yes? | 16:50 |
| edleafe | cdent: I was just typing that | 16:50 |
| mriedem | yes | 16:50 |
| cdent | if so, let's just do it, and re-open extracted placemen for business | 16:50 |
| efried | except this would mean we would need to start doing version discovery and conditionals. | 16:50 |
| mriedem | nova should be cool with at least n-1 of any dependent service api | 16:50 |
| cdent | efried: no, just be explicit | 16:51 |
| mriedem | and yeah, we said awhile back in nova that we weren't doing placement version discovery anymore | 16:51 |
| efried | right | 16:51 |
| mriedem | and that placement just had to be upgraded before nova | 16:51 |
| mriedem | like ironi | 16:51 |
| cdent | right | 16:51 |
| mriedem | *ironic | 16:51 |
| mriedem | regardless with 4 weeks to feature freeze i don't see us adding new code in nova that depends on new microversions in placement | 16:52 |
| cdent | yes | 16:52 |
| efried | so - if we make a new microversion in extracted placement, and write nova code to exploit it, that nova code needs to be conditioned to *not* use it if we discover we're using non-extracted placement. | 16:52 |
| mriedem | so version discovery is likely not an issue | 16:52 |
| mriedem | efried: correct | 16:52 |
| cdent | but we _could_ have those new features ready and waiting | 16:52 |
| edleafe | efried: we shouldn't be changing nova to use those new features until we can be sure that they will be there | 16:52 |
| efried | edleafe: which, when we were mandating upgrade-placement-before-nova, wasn't an issue. | 16:53 |
| mriedem | it's going to be a practice we have to get used to for placement anyway, | 16:53 |
| edleafe | IOW, if we keep nova-placement, nova has to rely on that code | 16:53 |
| mriedem | it's what we do with other services already like cinder and neutron | 16:53 |
| mriedem | we = nova | 16:54 |
| efried | mriedem: Not sure I understand that. | 16:54 |
| edleafe | mriedem: sure, but if we are allowing placement to NOT be separate, then upgrading placement doesn't mean anything | 16:54 |
| efried | If the upgrade-placement-first edict remains, we should never have to do those conditionals after this bridge release. | 16:54 |
| mriedem | nova does not (or should not) land feature code that relies on external service apis without making sure those are available first | 16:54 |
| mriedem | efried: i guess...but that kind of sucks | 16:55 |
| edleafe | mriedem: exactly. So nova code in Stein cannot depend on any of the Stein changes to placement | 16:55 |
| efried | this ^ | 16:55 |
| efried | and the plus side of the bridge release is what, again? Making it so deployers don't have to do two things? | 16:55 |
| mriedem | fwiw i don't think i was ever heavily in favor of the edict since version discovery is pretty simple and we do it for other external services already and it eases upgrades for people | 16:56 |
| dansmith | it's pretty common to want to just deploy new code.. tracking the config changes on each release is hard enough | 16:56 |
| dansmith | then any sort of architectural changes happen once things are up and running in a separate maintenance windo | 16:56 |
| dansmith | otherwise you're deploying new things in a new way all at once and it's much harder to plan and react | 16:56 |
| efried | we should, like, have a hangout or something to discuss this. | 16:57 |
| mriedem | let me enjoy 3 more minutes of nudity | 16:57 |
| edleafe | mriedem: then we get enjoy it? | 16:57 |
| mriedem | ha | 16:58 |
| mriedem | yes | 16:58 |
| * cdent is agnostic about nova doing version discovery | 16:58 | |
| mriedem | the version discovery thing is a different issue anyway | 16:58 |
| cdent | I guess it would be fair to say I'm agnostic about nova | 16:58 |
| efried | Personally, I like The Edict. Keeps the code clean, and seems like it wasn't a terribly onerous imposition on deployers? | 16:58 |
| mriedem | i just know there is a perception in operator land that all of openstack must be upgraded to the same release at the same time and that makes upgrades hard and it really shouldn't be that way | 16:59 |
| cdent | that's maintained by most of the deployment tools. lyarwood was making it clear to me earlier that tripleo makes it very hard to mix bits | 16:59 |
| cdent | vio is _very_ much the same way | 16:59 |
| cdent | which is annoying | 16:59 |
| mriedem | oh i'm sure | 17:00 |
| * cdent headphones up | 17:00 | |
| mriedem | public clouds don't need to run that way though, glance could be 2 years old | 17:00 |
| bauzas | on another meeting but will join as soon as it ends | 17:00 |
| mriedem | https://hangouts.google.com/call/C5h9TyVk5BMfSO8vGxZ_AEEE | 17:00 |
| bauzas | can someone point me the hangouts url ? | 17:00 |
| bauzas | oh snap | 17:00 |
| mriedem | https://etherpad.openstack.org/p/placement-extract-stein-5 | 17:04 |
| bauzas | thanks | 17:05 |
| *** tssurya has quit IRC | 17:09 | |
| mriedem | L41 for how grenade does post-upgrade validation of resources https://etherpad.openstack.org/p/placement-extract-stein-5 | 17:18 |
| edleafe | L42 now | 17:19 |
| sean-k-mooney | cdent: the funny thing is i had considerd buying the harware to test this personally in the past but i have not done so yet | 17:21 |
| cdent | fight corporate oppression sean-k-mooney ! | 17:24 |
| sean-k-mooney | hehe well the reason i did not by it was nvidas licencing | 17:24 |
| bauzas | nvidia licencing isn't really a problem when you work on that :) | 17:25 |
| bauzas | but man, the hardware layout for V100s is insane | 17:25 |
| mriedem | https://blueprints.launchpad.net/nova/stein | 17:27 |
| -openstackstatus- NOTICE: Any changes failed around 16:30 UTC today with a review comment from Zuul like "ERROR Unable to find playbook" can be safely rechecked; this was an unanticipated side effect of our work to move base job definitions between configuration repositories. | 17:28 | |
| *** e0ne has quit IRC | 17:33 | |
| cdent | mriedem, melwitt: question I didn't want to ask on the call just now, for fear of it pulling us away from making immediate decisions but: | 17:49 |
| cdent | Given that we've now changed the strategy of how to proceed does that have any impact on the governance agreement? It seems like it doesn't have to if we don't want it to, but it could if we do. | 17:50 |
| mriedem | i'm not opposed | 17:51 |
| cdent | basically: do we need to revisit the agreement, or is everyone still cool as it is? | 17:55 |
| cdent | (I'm in the camp of: things are already a certain way, de facto, may as well de jure too) | 17:56 |
| cdent | mriedem: to be clear: what are you not opposed to? | 17:58 |
| melwitt | I'm not opposed to revisiting it if people want to. I need a little time to digest the summary of what the new strategy is (extracted placement not required in stein, but I'm unclear on the data migration piece) | 17:58 |
| mriedem | cdent: i'm not opposed to splitting placement out in governance | 17:58 |
| cdent | to be completely up front about it: the only reason I'm asking/care about it that much _now_ is because of planning the rest of the year | 17:59 |
| mriedem | yar, my goals are due in a few weeks for the first half as well | 18:00 |
| mriedem | looking at http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html really the only thing that likely won't be done in stein is the deployment tool upgrade part (item 3) but that's basically no biggy in stein now because we aren't going to delete the placement-in-nova code in stein | 18:01 |
| mriedem | per the call | 18:01 |
| cdent | aye | 18:01 |
| mriedem | melwitt: the data migration piece remains the same as far as i know - the difference is you can upgrade nova to stein without having to worry about deploying extracted placemetn and doing the data migration during the upgrade *to* stein, | 18:04 |
| mriedem | you can deal with after you've upgraded to stein but before upgrading to train | 18:04 |
| mriedem | if you'rea new deploy in stein, then you just use extracted placement from the start since there is no upgrade | 18:04 |
| melwitt | ok, right. I have a hard time following all of it in my head | 18:07 |
| mnaser | cdent: https://github.com/openstack/placement/blob/master/placement/conf/database.py is there plans to move to [database] instead of [placement_database] ? | 18:15 |
| mnaser | given that there hasnt been 1.0.0 yet and everyone will be configuring things from scratch | 18:15 |
| cdent | mnaser: not any immediate plans no | 18:16 |
| mnaser | ok cool | 18:16 |
| cdent | there have been various discussions about it in the past but they resolved to "meh, keep it as is" | 18:16 |
| cdent | I actually like it being named, as it makes sense if there's a future with more than one database | 18:17 |
| mnaser | cdent: fair enough, i think i have a fully cleanly deployed placement over here so i should be able to push it up shortly | 18:17 |
| cdent | rad | 18:17 |
| edleafe | oh geez - please no more multiple databases | 18:18 |
| mnaser | im just trying to do a simple curl request | 18:18 |
| mnaser | to see what happens and if it responds correctly | 18:18 |
| cdent | / should give you a 1.30 microversion | 18:19 |
| cdent | (version doc) | 18:19 |
| mnaser | cdent: yeah but i dont know if that guarantees a successful db connection, thats what im trying to figure out :> | 18:20 |
| mnaser | (i get a successful response on /) | 18:20 |
| cdent | it doesn't, but it is a good starting point | 18:20 |
| mnaser | # curl http://127.0.0.1:8780 | 18:20 |
| mnaser | {"versions": [{"status": "CURRENT", "min_version": "1.0", "max_version": "1.30", "id": "v1.0", "links": [{"href": "", "rel": "self"}]}]} | 18:20 |
| cdent | /resource_providers will access the db but will need auth | 18:21 |
| cdent | actually, if the service is able to start, it will try to sync the traits to the db, before it will answer any web requests. if that fails, the service fails | 18:24 |
| cdent | so if you got the version doc, you should be going | 18:24 |
| cdent | even though that request itself does not need it | 18:24 |
| cdent | mnaser: you can see that traits sync in the logs of the placement service for you own human sanity check (but not great for automated) | 18:37 |
| cdent | mriedem, melwitt, efried : we didn't schedule another check in. Do we need one, or should we wait and see? | 18:38 |
| melwitt | I think it doesn't hurt to plan to have one. I've found them to be nice for clearly looking at where we are. either way sounds fine to me | 18:42 |
| cdent | melwitt: since I already wrote it this way in the notes, I'm gonna say that we'll book one when the time seems right | 18:45 |
| melwitt | sounds good to me | 18:46 |
| cdent | cool | 18:47 |
| *** e0ne has joined #openstack-placement | 19:29 | |
| mnaser | cdent: usefulness of a small test, db works but python-memcache was not isntalled of import fails for keystonemiddleware cache | 19:39 |
| mnaser | i think i'm almost done and i added a small test that grabs a keystone token, grabs the placement api url from service catalog and then hits /resource_providers expecting a 200 ok -- which should be ok in the interim until we get something more upstreamy. | 19:48 |
| mnaser | https://review.openstack.org/#/c/618820/ ok, this passes for me locally on centos, so we'll wait for CI to report for other OS (it'll probably work fine) | 19:55 |
| cdent | mnaser: cool, thanks, I'll mess with that a bit more tomorrow, I'm past my sell by date for today | 20:03 |
| mnaser | cdent: cool as the state it is, we can probably merge it because we get basic validation, so i guess all that to say it's probably not that high of a prio now that i have that in place | 20:04 |
| cdent | When I look at it tomorrow if I see something obvious/simple to do to make it more robust, I'll do a followup patch to check it out | 20:04 |
| cdent | but for now: good night all | 20:06 |
| *** cdent has quit IRC | 20:06 | |
| *** e0ne has quit IRC | 21:00 | |
| *** takashin has joined #openstack-placement | 21:51 | |
| *** bodgix has joined #openstack-placement | 22:17 | |
| *** bodgix has left #openstack-placement | 22:17 | |
| *** alex_xu has quit IRC | 22:38 | |
| *** alex_xu has joined #openstack-placement | 22:40 | |
| *** ttsiouts has joined #openstack-placement | 23:08 | |
| *** mriedem has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!