| *** thrash is now known as thrash|g0ne | 00:35 | |
| *** mgagne has quit IRC | 02:19 | |
| *** mgagne has joined #openstack-shade | 02:22 | |
| *** mgagne is now known as Guest53680 | 02:22 | |
| *** gkadam_ has joined #openstack-shade | 04:38 | |
| *** gkadam_ has quit IRC | 04:39 | |
| *** gkadam has joined #openstack-shade | 04:40 | |
| *** gouthamr has quit IRC | 05:24 | |
| *** slaweq_ has joined #openstack-shade | 05:32 | |
| *** slaweq_ has quit IRC | 05:33 | |
| *** slaweq_ has joined #openstack-shade | 06:09 | |
| *** slaweq_ has quit IRC | 06:40 | |
| *** slaweq_ has joined #openstack-shade | 06:44 | |
| *** slaweq_ has quit IRC | 07:17 | |
| *** slaweq_ has joined #openstack-shade | 07:20 | |
| *** slaweq_ has quit IRC | 07:53 | |
| *** ioggstream has joined #openstack-shade | 07:55 | |
| *** slaweq_ has joined #openstack-shade | 08:02 | |
| *** slaweq_ has quit IRC | 08:35 | |
| *** slaweq_ has joined #openstack-shade | 08:44 | |
| *** slaweq_ has quit IRC | 09:17 | |
| *** slaweq_ has joined #openstack-shade | 09:21 | |
| *** slaweq_ has quit IRC | 09:55 | |
| *** slaweq_ has joined #openstack-shade | 10:00 | |
| *** thrash|g0ne is now known as thrash | 10:35 | |
| *** slaweq_ has quit IRC | 11:03 | |
| *** slaweq_ has joined #openstack-shade | 11:10 | |
| *** slaweq_ has quit IRC | 11:43 | |
| *** slaweq_ has joined #openstack-shade | 12:23 | |
| *** thrash is now known as thrash|biab | 12:23 | |
| *** slaweq_ has quit IRC | 12:56 | |
| *** slaweq_ has joined #openstack-shade | 13:01 | |
| *** thrash|biab is now known as thrash | 13:23 | |
| *** gkadam has quit IRC | 13:25 | |
| *** slaweq has quit IRC | 13:33 | |
| *** slaweq_ has quit IRC | 13:34 | |
| *** slaweq has joined #openstack-shade | 13:41 | |
| *** gouthamr has joined #openstack-shade | 13:49 | |
| *** gouthamr has quit IRC | 13:51 | |
| *** gouthamr has joined #openstack-shade | 13:51 | |
| *** slaweq has quit IRC | 14:13 | |
| *** slaweq has joined #openstack-shade | 14:23 | |
| *** slaweq has quit IRC | 14:56 | |
| *** slaweq has joined #openstack-shade | 15:03 | |
| *** slaweq has quit IRC | 15:36 | |
| *** slaweq has joined #openstack-shade | 15:41 | |
| *** slaweq has quit IRC | 16:14 | |
| *** slaweq has joined #openstack-shade | 16:16 | |
| *** slaweq has quit IRC | 16:18 | |
| *** slaweq has joined #openstack-shade | 16:18 | |
| *** ioggstream has quit IRC | 17:02 | |
| *** slaweq has quit IRC | 17:06 | |
| mordred | Shrews: shade image operations are working against rackspace - but there is a lurking bug in catalog discovery/url stuff - we've got double /v2 path pieces in there | 17:20 |
|---|---|---|
| SamYaple | mordred: are you refering ot https://bugs.launchpad.net/python-openstackclient/+bug/1685377/ ? | 17:24 |
| openstack | Launchpad bug 1685377 in python-openstackclient "Glance imagev2 api calls fail on urls with 'v2' in them" [Medium,Confirmed] | 17:24 |
| SamYaple | os some other issue | 17:24 |
| SamYaple | obviously not that exact issue becase thats filed against OSC, but related? | 17:25 |
| mordred | SamYaple: yes | 17:33 |
| SamYaple | got it. that was filed by my team because we had a second 'v2' in our url | 17:33 |
| *** slaweq has joined #openstack-shade | 17:37 | |
| *** Guest53680 is now known as mgagne | 18:14 | |
| *** mgagne has quit IRC | 18:14 | |
| *** mgagne has joined #openstack-shade | 18:14 | |
| *** slaweq has quit IRC | 18:43 | |
| *** gouthamr has quit IRC | 18:47 | |
| *** slaweq has joined #openstack-shade | 18:48 | |
| Shrews | mordred: is this a new bug? or just noticed but been around for a bit? | 18:59 |
| mordred | Shrews: I think it's likely actually a bug in the new keystoneauth discoveyr | 19:04 |
| mordred | I'm going to track it down as soon as I'm done with this cleanup thing - which is still being a little weird | 19:04 |
| samueldmq | mordred: Shrews: in the create and attach a public ip for this vm case | 19:09 |
| samueldmq | is it always the same API call? | 19:09 |
| mordred | samueldmq: nope | 19:10 |
| samueldmq | and we just don't know what the deployment will do? | 19:10 |
| samueldmq | like create and attach to public net | 19:10 |
| mordred | samueldmq: it's different calls | 19:10 |
| mordred | there are MANY different code paths for that one | 19:10 |
| samueldmq | create in a private net, then use NAT | 19:10 |
| samueldmq | mordred: hmm okay, so the create and attach to the public net call might just fail in some clouds | 19:10 |
| mordred | yes.... | 19:11 |
| mordred | if you want to include the whole picture ... | 19:11 |
| samueldmq | then you try: create in a private and attach IP via nat | 19:11 |
| mordred | first you need to know if nova or neutron are the ones controlling networking | 19:11 |
| mordred | then you need to figure out if there is a public network you can boot on - which is its own mess | 19:11 |
| mordred | if there is a public network you can boot on, then booting a vm on it works pretty sanely | 19:12 |
| mordred | but if there isn't, you may need to do private + NAT | 19:12 |
| mordred | even in *that* case there are 2 different mechanisms | 19:12 |
| samueldmq | and NAT is connecting private and public with a router I assume | 19:12 |
| mordred | one of them which is "better" is to pass the port id of the private ip of the server to the floating ip create call | 19:12 |
| mordred | the other, if that isn't possible, is to create a floating ip and then attach it to the server | 19:13 |
| mordred | samueldmq: yes, that's right | 19:13 |
| samueldmq | ok, do any of those always work? | 19:13 |
| samueldmq | I mean, whatever way you do it, it will work | 19:13 |
| samueldmq | port id of the private ip of the server to the floating ip create call OR create a floating ip and then attach it to the server | 19:13 |
| samueldmq | you just pick any of those and they always work. or you need trial and error with those too? | 19:14 |
| mordred | samueldmq: nope - there is literally nothing that will always work | 19:14 |
| mordred | samueldmq: now - it IS possible to eventually figure out most of the options with code | 19:15 |
| mordred | samueldmq: there are some pathological cases that code simply cannot infer - but shade can figure out te right thing I'd say 95% of the time | 19:15 |
| samueldmq | mordred: how does it do that? | 19:16 |
| samueldmq | how does it figure out the way to try it out with most chance of success | 19:16 |
| samueldmq | I mean, how does it "figure out most of the options with code"? | 19:16 |
| *** slaweq has quit IRC | 19:21 | |
| mordred | samueldmq: you can follow the "auto_ip" flag from http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/openstackcloud.py#n6432 :) | 19:21 |
| *** slaweq has joined #openstack-shade | 19:21 | |
| samueldmq | mordred: kk :) last question ... | 19:21 |
| samueldmq | mordred: do all these things happen if just neutron is used in the different clouds? | 19:21 |
| mordred | samueldmq: http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/openstackcloud.py#n2296 is one half that's interesting | 19:21 |
| samueldmq | all this behavior inconsistency | 19:21 |
| mordred | samueldmq: yes - all this still happens if just neutron is present | 19:22 |
| samueldmq | mordred: ok that will help explaining the issue | 19:22 |
| samueldmq | having different services for the same purpose is another big issue by itself | 19:22 |
| mordred | samueldmq: for instance, OVH provides public ipv4 directly, citycloud provides private ipv4 and you have to use NAT for public - vexxhost defaults to public but allows private+NAT | 19:23 |
| mordred | samueldmq: yah- luckily nova-net is mostly gone - but code still needs to account for it maybe existing | 19:23 |
| samueldmq | mordred: ++ | 19:23 |
| *** gouthamr_ has joined #openstack-shade | 19:24 | |
| samueldmq | what I have for now is | 19:26 |
| samueldmq | for syntactic issues: i) Functionality is exposed through different APIs (eg nova-net vs neutron, v2.0 vs v3), ii) Pluggable underlying mechanism (eg auth plugins) and iii) APIs were removed (identity v2.0 disapeared) | 19:27 |
| samueldmq | for semantic: i) different authorization requirements for the functionality (policy) ii) configurable restrictions in operations on the data (e.g hierarchy depth for projects) iii) | 19:27 |
| samueldmq | quotas (not config for the service, but what the customer paid for) | 19:27 |
| samueldmq | mordred: I will add this network stuff we just discussed | 19:28 |
| samueldmq | and the lack of standardization in data, like how do we get the latest ubuntu image in a cloud? | 19:28 |
| samueldmq | mordred: I think we'd be pretty much covered on listing interop issues shade accounts for | 19:28 |
| mordred | samueldmq: ++ - the doc is looking good! | 19:29 |
| mordred | samueldmq: there's also another fun one - glance image uploads - there are 2 different mechanisms in glance v2 - upload data directly via HTTP PUT and upload via uploading to swift and creating an import task in glance | 19:31 |
| samueldmq | mordred: ok, and one cloud can go for just one of those? | 19:32 |
| mordred | samueldmq: both of them are 'valid' API calls in every glance v2 cloud - but in some clouds upload via PUT is disabled, and in other clouds the task-import doesn't do anythin | 19:32 |
| mordred | samueldmq: but they're both 'syntacticly' valid API calls for that version of glance | 19:32 |
| samueldmq | do the thing. get the image and check | 19:32 |
| samueldmq | if it's there | 19:32 |
| samueldmq | if not, we might have called the noop task-import call :-) | 19:33 |
| samueldmq | mordred: I assume this is what shade does ^ | 19:33 |
| samueldmq | mordred: that is an interesting case ... thanks I will add it to the doc | 19:33 |
| mordred | what's even more fun is that with the 'task' interface payloads are all vendor/deployer plugin specific | 19:33 |
| mordred | samueldmq: so the task create call is a valid API call in all clouds with glance v2 - but the json payload to send them may vary :) | 19:34 |
| mordred | SamYaple: OK - so ... in this particular case it seems the problem with double v2 elements is actually related to pagination | 19:50 |
| SamYaple | got it. that makes sense too | 19:51 |
| mordred | SamYaple: "next": "/v2/images?marker=bb15732f-e016-4544-a7e9-c73db58ce3e5" is what's in the pagination footer, and we're appending that to https://dfw.images.api.rackspacecloud.com/v2 which is the URL found from version discovery | 19:51 |
| mordred | SamYaple: HAH | 19:52 |
| mordred | we have code to deal with this :) | 19:52 |
| mordred | SamYaple: | 19:52 |
| mordred | # Use the raw endpoint from the catalog not the one from | 19:52 |
| mordred | # version discovery so that the next links will work right | 19:52 |
| mordred | response = self._raw_image_client.get(endpoint) | 19:52 |
| * mordred head desks | 19:52 | |
| SamYaple | your work here is done! | 19:54 |
| SamYaple | lol | 19:54 |
| *** slaweq has quit IRC | 21:04 | |
| openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Handle glance image pagination links better https://review.openstack.org/511963 | 21:25 |
| *** slaweq has joined #openstack-shade | 21:37 | |
| *** slaweq has quit IRC | 22:10 | |
| *** slaweq has joined #openstack-shade | 22:19 | |
| *** gouthamr_ has quit IRC | 22:23 | |
| openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Handle glance image pagination links better https://review.openstack.org/511963 | 22:31 |
| mordred | Shrews: ^^ added more tests | 22:31 |
| mordred | SamYaple: ^^ you too - that should solve all extra /v2 things in shade ... it won't fix openstackclient - that issue isn't as related | 22:32 |
| SamYaple | awesome. | 22:33 |
| SamYaple | its currently python-openstackclient called with subprocess in a saltstack module (uuggghhhhh). ive been switching it to shade. now that this is fixed in shade, yay! | 22:33 |
| SamYaple | or will be at least | 22:33 |
| mordred | SamYaple: yah - I think I've got all your things in you needed for the salt stuff | 22:34 |
| SamYaple | mordred: you did, i had a list :) | 22:36 |
| SamYaple | well that ive found so far | 22:36 |
| SamYaple | i still have nova and neutron to salt-module out | 22:36 |
| *** slaweq has quit IRC | 22:52 | |
| *** slaweq has joined #openstack-shade | 23:00 | |
| openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Add devstack jobs for zuul v3 https://review.openstack.org/500365 | 23:02 |
| openstackgerrit | Monty Taylor proposed openstack-infra/shade master: Add devstack jobs for zuul v3 https://review.openstack.org/500365 | 23:03 |
| *** gouthamr has joined #openstack-shade | 23:30 | |
| *** slaweq has quit IRC | 23:33 | |
| *** gouthamr_ has joined #openstack-shade | 23:43 | |
| *** slaweq has joined #openstack-shade | 23:43 | |
| *** gouthamr has quit IRC | 23:46 | |
| *** gouthamr_ has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!