| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-03 | |||
| 16:51:28 | bauzas | I got a new project | |
| 16:51:36 | bauzas | Burgers-As-a-Service | |
| 16:51:42 | dansmith | bauzas: you really like us better than your wife? | |
| 16:51:53 | bauzas | I do *love* my wife | |
| 16:51:56 | bauzas | even my kids | |
| 16:52:14 | bauzas | but sometimes, work/life balance is hard :) | |
| 16:52:20 | mriedem | dude, just go | |
| 16:56:26 | mriedem | ok, i think he's gone. now let's undo all of the claims stuff behind his back! | |
| 16:56:46 | dansmith | heh | |
| 17:03:24 | namnh | dansmith: Hi Mr.Smith, may I confirm with you a point? | |
| 17:06:26 | dansmith | namnh: you can try :) | |
| 17:06:47 | namnh | dansmith: thanks for your reply | |
| 17:06:52 | namnh | dansmith: Currenlty, Nova supported rolling-upgrade feature, it means old services in Nova can interact with new services. For example nova-api(Mitaka) can interact with nova-conductor(Nova). Is that right? | |
| 17:07:22 | dansmith | namnh: no. That statement is true for control services vs. computes, but that's all currently | |
| 17:07:30 | dansmith | namnh: i.e. api and conductor must be the same level, but compute may be old | |
| 17:10:37 | namnh | dansmith: during upgrade, I can use the "pinning version" option in nova.conf. I.e, during I upgrade M -> Newton, I can pin version in nova.conf at mitaka release | |
| 17:11:55 | namnh | dansmith: so in my understading, conductor can still interact with api at old release. am i right? | |
| 17:15:37 | dansmith | namnh: no | |
| 17:15:49 | dansmith | namnh: at no point can you have different versions of conductor and api | |
| 17:17:28 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Remove deprecated network APIs https://review.openstack.org/447728 | |
| 17:19:33 | namnh | dansmith: so it means that I have turn off all conductors and apis at the same time and then upgrade and start these services at the same time. | |
| 17:19:54 | namnh | dansmith: so it means that I have to turn off all conductors and apis at the same time and then upgrade and start these services at the same time. | |
| 17:20:03 | mriedem | sdague: i addressed the stuff you and alex_xu wanted to see in the os-services/os-hypervisors spec https://review.openstack.org/#/c/447149/, it's got a +2 from dansmith | |
| 17:20:16 | mriedem | dtp: have you started on the change to add uuid to the services table? | |
| 17:20:35 | dansmith | namnh: yes | |
| 17:25:14 | namnh | dansmith: thanks for your answer, I think I need to research more deeply Nova's document for this case | |
| 17:25:49 | mriedem | namnh: https://docs.openstack.org/developer/nova/upgrade.html in case you haven't seen that yet | |
| 17:27:14 | sdague | mriedem: looking | |
| 17:28:34 | openstackgerrit | Maxim Nestratov proposed openstack/nova master: libvirt: Virtuozzo containers config drive support https://review.openstack.org/449818 | |
| 17:29:08 | namnh | mriedem: thanks. Surely, I will research more deeply the link. | |
| 17:29:41 | mriedem | looks like we need to clarify between cells v1 and v2 in there | |
| 17:30:33 | mriedem | sdague: thanks. i'm going to update the searchlight spec after lunch. | |
| 17:32:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Distinguish between cells v1 and v2 in upgrades doc https://review.openstack.org/452872 | |
| 17:36:38 | dtp | mriedem about to now, why? | |
| 17:36:47 | mriedem | dtp: was just wondering | |
| 17:39:03 | sdague | mriedem: great | |
| 17:48:25 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 18:21:01 | tjones | mriedem: one of my guys want to work on https://review.openstack.org/#/c/402256 but we cannot restore it. does the owner have to restore? I thought we could take it over | |
| 18:24:51 | ildikov | mriedem: would the Cinder Nova meeting work for an hour earlier (1600 UTC) on Thursdays? | |
| 18:25:25 | mriedem | tjones: i've restored it | |
| 18:25:32 | mriedem | ildikov: for me yes | |
| 18:25:44 | ildikov | mriedem: cool, tnx | |
| 18:30:08 | clarkb | tjones: any core or the owner can restore | |
| 18:41:38 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 18:44:20 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 18:46:16 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 18:56:36 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: List instances using Searchlight (spec) https://review.openstack.org/441692 | |
| 18:56:37 | mriedem | sdague: there you go ^ | |
| 18:58:06 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 19:14:45 | mordred | mriedem, sdague: SO - over the weekend I was working on replacing the create server snapshot image call in shade with pure-rest - and I discovered that the value that nova returns in the header is wrong on at least 1 public cloud - but nobody has likely noticed because novaclient doesn't directly use the url returned, instead it pops the id off the end and uses that | |
| 19:14:56 | mordred | I'm fairly certain there is at least one bug somewhere | |
| 19:15:09 | mordred | but I'm not 100% sure in what, or where to file it | |
| 19:15:28 | sdague | mordred: can you be more specific about which cloud, and in what way it is wrong? | |
| 19:15:32 | mordred | yes! | |
| 19:15:39 | sdague | so we could at least narrow down where the disconnect is | |
| 19:17:09 | mriedem | talking about https://developer.openstack.org/api-ref/compute/?expanded=create-image-createimage-action-detail#create-image-createimage-action right? | |
| 19:17:23 | mordred | I was testing against vexxhost, which is running newton I believe ... | |
| 19:17:26 | mordred | (and yes) | |
| 19:17:36 | mordred | one sec - getting the actual value from my logs so I can paste the right things | |
| 19:18:26 | mriedem | might have been related to some glance v1 stuff that we intentionally broke in newton | |
| 19:18:28 | mriedem | for glance v2 | |
| 19:18:39 | mriedem | i seem to remember some issues there with returning locations to glance api servers | |
| 19:19:30 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1112 | |
| 19:20:08 | mriedem | https://github.com/openstack/nova/blob/master/nova/image/glance.py#L58 | |
| 19:20:13 | mordred | RESP: [202] Content-Type: text/html; charset=UTF-8 Content-Length: 0 Location: http://172.21.1.10:9292/images/f5d5b63b-e710-4d59-aa12-a9bd42f6652a Openstack-Api-Version: compute 2.1 X-Openstack-Nova-Api-Version: 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-4b6fb5ed-3055-4d84-a16f-4057685ce737 Date: Sun, 02 Apr 2017 13:26:20 GMT | |
| 19:20:18 | mordred | that's the response I got | |
| 19:20:52 | mordred | but the Location _should_ have been https://image-ca-ymq-1.vexxhost.net/v2/images/f5d5b63b-e710-4d59-aa12-a9bd42f6652a | |
| 19:21:06 | mriedem | yeah i was going to say, it's wrong b/c it's missing v1 or v2 right? | |
| 19:21:14 | mordred | well - and also the host is wrong | |
| 19:21:20 | mriedem | the host comes from the config in nova | |
| 19:21:24 | mriedem | for glance api servers | |
| 19:21:26 | mordred | 172.21.1.10:9292 is unreachable by me as a user | |
| 19:21:41 | mordred | so it seems it's returning the thing that is the internal url | |
| 19:21:41 | sdague | so, the host is going to because they have private glance servers | |
| 19:21:44 | mordred | yah | |
| 19:21:52 | mriedem | yeah comes from config https://github.com/openstack/nova/blob/master/nova/image/glance.py#L107 | |
| 19:22:03 | mriedem | we'd have to get the host from the service catalog right? | |
| 19:22:05 | sdague | yeh, for historical reasons that's just a randomly picked one of their api_services | |
| 19:22:06 | mriedem | for publicUrl | |
| 19:22:19 | sdague | mriedem: yeh, it's more complicated than that, but yes | |
| 19:22:24 | mordred | kk. so this is still just part of the whole "use the catalog for glance stuff" effort | |
| 19:22:30 | sdague | because the glance stuff doesn't use the catalog anywhere | |
| 19:22:33 | sdague | mordred: yes | |
| 19:22:33 | mordred | yah | |
| 19:22:43 | mordred | cool - ok - so no new issue to file | |
| 19:22:44 | mriedem | is that an effort? | |
| 19:22:51 | mriedem | no one is working on this | |
| 19:23:34 | mordred | maybe effort is the wrong word "aspirational future state that people would love to be in but nobody is currently driving" | |
| 19:23:36 | mriedem | mordred: you should report a bug regardless | |
| 19:23:39 | mordred | kk | |
| 19:23:41 | mordred | will do | |
| 19:23:51 | mordred | also - I'm just stealing novaclient's workaround for now | |
| 19:24:02 | mriedem | i'm surprised we actually returned a location header | |
| 19:24:10 | mordred | which is to just pop the uuid off the end of the url and return _that_ | |
| 19:24:13 | sdague | mriedem: that's been there for a long time | |
| 19:24:30 | mriedem | sdague: there's lots of things that have been around for lots of years that surprise me :) | |
| 19:24:35 | sdague | :) | |
| 19:25:01 | sdague | returning location is actually a pretty good pattern, it's just that it depends on too much config being correct | |
| 19:26:12 | sdague | I'm trying to figure out if vexxhost's config is going to hurt something else in terms of migration | |
| 19:26:13 | mriedem | sdague: so is the basic idea, long-term we want to drop CONF.glance.api_servers and just have nova lookup the image service url in the catalog? | |