| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-14 | |||
| 13:17:30 | vdrok | cdent: sure, will do :) | |
| 13:19:17 | jroll | vdrok: awesome, thanks! | |
| 13:22:29 | raghav | hi all i am getting below error..while stacking | |
| 13:22:39 | raghav | NO hosts found to map to cell | |
| 13:22:49 | raghav | ocata release | |
| 13:23:07 | raghav | i have not enabled n-cell servcie then also i am getting this error | |
| 13:23:14 | raghav | could anyone please help me | |
| 13:24:38 | sdague | raghav: this is a completely fresh install? | |
| 13:26:45 | johnthetubaguy | raghav: the install guide is in the process of being updated for ocata, so if you followed that there are some missing steps right now | |
| 13:27:06 | johnthetubaguy | sfinucan: sorry, I mean update the link | |
| 13:27:14 | raghav | i have done clean.sh on my previous devstack installation and then did stack | |
| 13:27:33 | johnthetubaguy | for context I was thinking about https://review.openstack.org/#/c/438328/ | |
| 13:27:36 | johnthetubaguy | oh | |
| 13:27:40 | raghav | john: i am using devstack | |
| 13:28:36 | sdague | raghav: honestly, given some of the other issues, please start with a completely fresh OS install | |
| 13:28:51 | sdague | once changes have been made to config, clean.sh may not delete some of those things | |
| 13:28:55 | sfinucan | johnthetubaguy: OK, think I've done that now | |
| 13:30:24 | johnthetubaguy | hmm gerrit appears to hate me | |
| 13:30:36 | raghav | sdague: can there be any other soln than re installation | |
| 13:32:07 | sdague | raghav: given the set of issues you were showing yesterday, I think that debugging the current state of your machine isn't going to be a productive use of anyone's time, including yours | |
| 13:32:10 | sdague | I would start fresh | |
| 13:33:27 | raghav | sdague: ok thank you | |
| 13:43:50 | raghav | sdague: Hi in fresh installation aslo i got same error | |
| 13:44:31 | sdague | raghav: please pastebin all the logs and your local.conf, we know that it's working in the general case, it's tested all the time | |
| 13:49:22 | raghav | sdague: http://paste.openstack.org/show/602688/ please find local.conf | |
| 13:49:53 | tdurakov | Hi folks, caught cold, so couldn't run live migration meeting this week, sorry for inconvenience | |
| 13:50:19 | cdent | tdurakov: we share an internet virus | |
| 13:50:55 | tdurakov | Get well cdent | |
| 13:51:08 | cdent | you too | |
| 13:52:46 | sdague | raghav: why did you set *_BRANCH ? | |
| 13:52:57 | mriedem | lyarwood: this is kind of a monster backport but is something we need to get released sooner than later https://review.openstack.org/#/c/445236/ | |
| 13:53:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform instance.reboot.error notification https://review.openstack.org/411791 | |
| 13:55:43 | openstackgerrit | Danfly proposed openstack/nova master: Completely remove mox from unit/network/test_linux_net.py https://review.openstack.org/445504 | |
| 13:56:47 | lyarwood | mriedem: ack, I'll queue that up now, can you unblock https://review.openstack.org/#/c/431540/ when you have time, should be good to go now. | |
| 13:57:01 | mriedem | lyarwood: yeah will look now | |
| 13:57:15 | lyarwood | thanks | |
| 14:00:53 | mriedem | lyarwood: +2 | |
| 14:01:00 | mriedem | tonyb: mtreinish: can one of you hit this? https://review.openstack.org/#/c/431540/ | |
| 14:01:46 | mtreinish | mriedem: looking | |
| 14:02:07 | openstackgerrit | Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754 | |
| 14:02:08 | openstackgerrit | Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163 | |
| 14:02:12 | mriedem | bauzas: cdent: jaypipes: so do we want to start looking at creating a placement client? i know mlavalle had already started an osc plugin. | |
| 14:02:54 | cdent | mriedem: just had a chat earlier in the day about that with vdrok | |
| 14:02:55 | dansmith | I thought the point of the simple design was to make it so we don't need a client | |
| 14:03:00 | mriedem | https://github.com/miguellavalle/python-placementclient/tree/adding-grp-support | |
| 14:03:05 | cdent | and we said pretty much what dansmith just said | |
| 14:03:23 | mtreinish | mriedem: +A | |
| 14:03:40 | mriedem | the original spec called out osc CLIs for things like associating resource providers via aggregates, | |
| 14:03:53 | mriedem | or simply listing resource providers as a sanity check | |
| 14:04:02 | mriedem | we expect everyone to just be using curl? | |
| 14:04:11 | mriedem | bra | |
| 14:04:13 | mriedem | *brb | |
| 14:04:40 | cdent | yes, the spec did say that, but I'm not sure we've actually hit those use cases yet, so might be just as easy to wait? | |
| 14:04:49 | cdent | sick bra, have a great time | |
| 14:05:45 | bauzas | mriedem: yeah, I began to work on providing a separate module for that, but I'd prefer to have a separate client | |
| 14:06:06 | dansmith | mriedem: a client for use in cron may make sense, but not a separate client for server code, IMHO | |
| 14:06:27 | dansmith | mriedem: like a simple thing you can run from the cli to report a particular thing, that's not overly complex, but I would expect cinder to just use requests | |
| 14:06:42 | bauzas | dansmith: well, a python client could be cool for OSC | |
| 14:06:58 | bauzas | and for other projects | |
| 14:07:04 | johnthetubaguy | dansmith: melwitt: macsz: seeing bug patterns emerge around this kind of thing: https://bugs.launchpad.net/nova/+bug/1672624 | |
| 14:07:04 | openstack | Launchpad bug 1672624 in OpenStack Compute (nova) "Ceph volumes attached to local deleted instance could not be correctly handled" [Undecided,New] | |
| 14:07:11 | dansmith | bauzas: for human usage, yes, which I think exists today | |
| 14:07:56 | openstackgerrit | Danfly proposed openstack/nova master: Completely remove mox from unit/network/test_linux_net.py https://review.openstack.org/445504 | |
| 14:08:54 | sdague | bauzas: so, honestly, I really think that clients are an anti-pattern | |
| 14:09:28 | bauzas | sdague: not sure I understand your concerns | |
| 14:09:53 | bauzas | IMHO, we could provide a python placementclient package so OSC could use it for providing CLI | |
| 14:10:08 | sdague | here is the issue with that | |
| 14:10:14 | sdague | and why I think it's an anti pattern | |
| 14:10:16 | bauzas | exactly like the same difference between nova CLI and novaclient python module | |
| 14:10:51 | sdague | if you say that the client code is the REST api, you have documentation and examples for that, which are part of our normal process | |
| 14:11:25 | sdague | if you say that the client is this other library, then you need to duplicate the entire set of documentation specific to the class structure for that. And no longer is your rest api your documentation. | |
| 14:11:48 | sdague | which needs to include all the examples, etc | |
| 14:12:31 | bauzas | well, other projects do that, nope ? | |
| 14:12:47 | bauzas | we have REST API documentation, but we also have CLI and python bindings docs | |
| 14:12:50 | sdague | they don't, which is why OSC has been gutting a bunch of that | |
| 14:12:58 | bauzas | and when I was an operator, it was not a problem for me | |
| 14:13:23 | bauzas | for example, when I was an operator by Diablo, I looked at the novaclient python bindings docs | |
| 14:13:33 | bauzas | well, Essex sorry by that time | |
| 14:13:42 | bauzas | and I wrote my scripts using those | |
| 14:13:56 | bauzas | for bash things I used CLI docs | |
| 14:14:13 | bauzas | and when I wanted to play with the REST API, well, then... actually I never did this :) | |
| 14:14:24 | cdent | sdague: I have never agreed with you more than I agree with this conclusion " And no longer is your rest api your documentation." | |
| 14:14:36 | bauzas | because getting a token is something a bit confusing honestly | |
| 14:14:48 | bauzas | now, I understand how to get a token | |
| 14:14:57 | sdague | bauzas: it is, and that's why we hide that behind keystoneauth1 | |
| 14:15:01 | bauzas | but as an user, I'd prefer to just use a python client for that | |
| 14:15:23 | sdague | but after that point, GET some json is pretty straight forward | |
| 14:15:30 | bauzas | I agree | |
| 14:15:43 | bauzas | if the REST API is well documented :) | |
| 14:15:55 | bauzas | which was not the case previously | |
| 14:15:57 | sdague | bauzas: right, and it would be much better to make that true | |
| 14:16:08 | sdague | then write tons of other equally poor bits of documentation | |
| 14:16:21 | bauzas | sdague: maybe because I'm more a developer than an operator, I looked at how novaclient was working | |
| 14:16:21 | sdague | I am excited that you found it good enough for your use case | |
| 14:16:58 | bauzas | sdague: but it was easier for me to look at the client code to understand the logic than trying to see how the REST API was working | |
| 14:17:01 | sdague | but the experience I've hit with other people is basically why they all use shade now instead of any of the clients | |
| 14:17:21 | sdague | bauzas: the REST api docs were pretty terrible at that time | |
| 14:17:28 | bauzas | that said, it's now 4 years later, and we're in a far better situation for the REST API thanks to you and other API people :) | |
| 14:17:34 | bauzas | yeah zactly | |
| 14:17:51 | sdague | bauzas: so, please don't use the lessons from 5 years ago about the right patterns for today | |