| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-05-01 | |||
| 15:19:38 | gtmanfred | this is why we went with `create and assign by default. if there are no free ips, log a warning that we are going to be not multiprocess safe, because we need to list available ones and pick one from a list` | |
| 15:23:08 | openstackgerrit | Hongbin Lu proposed openstack/openstacksdk master: Add 'port_details' to Floating IP https://review.openstack.org/533811 | |
| 15:23:39 | mordred | yah. multi-process re-use of pre-existing floating ips is basically unpossible - without some sort of shared locking/brokering system | |
| 15:24:32 | mordred | in nodepool (which does this process in many many parallel threads) - we make sure we delete floating ips when we delete servers - and also have a cleanup thread that deletes any unattached floating ips it finds | |
| 15:25:13 | mordred | since if the create-with-server-port method is being used, there is no such thing as a validly unattached floating ip | |
| 15:25:27 | gtmanfred | ok, i think what I am just going to do is change the default `reuse_ips` to False, and allow them to set it if they really really really really really really really really are dumb and want to use it | |
| 15:26:25 | openstackgerrit | XiaojueGuan proposed openstack/keystoneauth master: Trivial: Update pypi url to new url https://review.openstack.org/565418 | |
| 15:26:57 | mordred | gtmanfred: yah | |
| 15:27:05 | mordred | gtmanfred: so - that said - there is an option we can do | |
| 15:27:36 | mordred | (it's on my list already = it's just deep down there and there's a few big ticket items we need to likely get done first) | |
| 15:28:46 | mordred | task number 1 is to finish making the caching tier use dogpile.cache everywhere (servers, ports and floating ips are currently done manually if caching is enabled - and there are some tricky interactions as it relates to batched operations and thundering herd that we hvae to be careful about when fixing that) | |
| 15:29:27 | mordred | but once we've got that, then we should be able to add in a locking/multi-process aware TaskManager (similar to the multithreaded TaskManager that's in nodepool right now) | |
| 15:29:43 | mordred | and leverge dogpile for the shared locking | |
| 15:29:47 | gtmanfred | :+1: | |
| 15:30:06 | gtmanfred | Lemme know what I can help with, i need to figure out what to contribute to so I can go to berlin. | |
| 15:30:06 | mordred | so if someone then wants to do multi-process with reuse_ips there will be a story for it | |
| 15:30:37 | mordred | cool. I'll write up the above into a more consumable story that doesn't involve memories in my head and ping you with it | |
| 15:30:47 | gtmanfred | that would be great | |
| 15:30:54 | mordred | \o/ winning | |
| 15:34:23 | gtmanfred | other than that, the new shade cloud driver has gotten rave reviews, and everyone says it is much easier to configure and more reliable than what we had before | |
| 15:54:29 | openstackgerrit | Merged openstack/openstacksdk master: Drop bogus attributes from network port resource https://review.openstack.org/565217 | |
| 16:56:47 | mordred | gtmanfred: yay! | |
| 19:21:55 | gtmanfred | mordred: also, with the cache stuff for servers, it is about 10 times faster | |
| 19:23:34 | mordred | yah. the cache stuff is really important - and the other thing is also about being able to enable at least in-memory caching by default | |
| 19:56:27 | crunchengine | mordred: hello | |
| 19:57:02 | mordred | crunchengine: hiya | |
| 19:57:11 | crunchengine | I am listing active instances, but compute give me migrating instances too | |
| 19:57:27 | crunchengine | self.conn.compute.servers(host=self.hostname, all_tenants=True, status="ACTIVE") | |
| 19:58:12 | crunchengine | those instances are still active, from kvm point of view but the filter should be state consistent no ? | |
| 19:59:23 | mordred | I dunno about the kvm POV - but the filter from a REST API perspective only knows about the value of teh status field. doesn't migration status show up in vm_state? | |
| 19:59:38 | mordred | ah - sorry - progress | |
| 19:59:54 | mordred | nope. thinking out loud - sorry :) | |
| 20:01:09 | mordred | yah - I'd expect for the status of the vm to be 'MIGRATING' from looking at the api docs | |
| 20:01:24 | crunchengine | print("uuid: {} status: {} task_state: {} vm_state: {}".format(i.id, i.status, i.task_state, i.vm_state)) | |
| 20:01:30 | crunchengine | uuid: 5a562937-b0e2-4e67-8b2e-490cd44bbc3d status: MIGRATING task_state: migrating vm_state: active | |
| 20:01:38 | crunchengine | too much state ! | |
| 20:01:45 | mordred | right? | |
| 20:01:47 | crunchengine | okay thanks ! | |
| 20:03:35 | crunchengine | so naming is inconsistent too: return self.conn.compute.servers(host=self.hostname, all_tenants=True, status="ACTIVE") | |
| 20:03:48 | crunchengine | status => vm_state in lowercase... | |
| 21:58:31 | openstackgerrit | Merged openstack/keystoneauth master: Allow tuples and sets in interface list https://review.openstack.org/564495 | |
| #openstack-sdks - 2018-05-02 | |||
| 10:24:46 | rabel | hi there. does osc support assigning system roles? ( https://developer.openstack.org/api-ref/identity/v3/#system-role-assignments ) | |
| 11:15:03 | pooja_jadhav | cmurphy: Hi | |
| 11:45:12 | umbSublime | is the ressource.Body updated on a ressource when something changes on the object. For example if i check a Server.hypervisor_hostname property, and then migrate the server. Do Ineed to recreate my server object to get the new Server.hypervisor_hostname ? | |
| 13:52:20 | openstackgerrit | Merged openstack/os-client-config master: Replace guts with openstack.config https://review.openstack.org/549307 | |
| 15:03:06 | umbSublime | perhaps my question isn't clear, feel free to ask if so. | |
| 15:21:51 | elmiko | umbSublime: that seems like a nova question, but if you migrated the server through an openstack interface then it _should_ update the resource for you | |
| 15:22:18 | elmiko | if you did the migration outside of openstack, then i'm not sure what the behavrior would be | |
| 15:22:40 | elmiko | in general, we trust the resource servers to be the source of truth for information about the resources they manage | |
| 15:22:48 | elmiko | hope that helps | |
| 15:33:54 | openstackgerrit | Merged openstack/openstacksdk master: Honor endpoint_override for get_session_client https://review.openstack.org/565489 | |
| 15:35:43 | umbSublime | elmiko: What I mean is, if I create an sdk Server ressource, and then call it's 'migration' method. Once the migration is completed, can I check the new hypervisor with my existing Server ressource, or should I create a new one with the SDK | |
| 15:36:07 | umbSublime | to reflect those changes | |
| 15:43:02 | openstackgerrit | Merged openstack/openstacksdk master: Don't assume a full config dict https://review.openstack.org/564493 | |
| 15:44:25 | elmiko | umbSublime: i'm not sure about the sdk specifics, but i would imagine that at the minimum the Server uuid would be the same. not sure if that means you can use the resource or not. sorry, i misunderstood what you were asking. | |
| 15:44:49 | umbSublime | np elmiko thanks for giving it a shot :p | |
| 15:45:03 | elmiko | i would think though, that if the resource has a migration method, then you can continue to use the same resource object | |
| 15:45:19 | elmiko | presumably it is communicating with the openstack server on the backend | |
| 15:45:33 | umbSublime | I'd agree, (i'm still novice prrgrammer), but when looking at the code I see no mechanism that do that | |
| 15:45:41 | elmiko | ahh, gotcha | |
| 15:45:58 | elmiko | it might be safest to aquire a new server resource using the id of the old one | |
| 15:46:08 | elmiko | for maximum paranoia ;) | |
| 15:46:52 | elmiko | theoretically, on the backend side, the server resource id should be the same, even after migration | |
| 15:59:29 | umbSublime | elmiko: yah for sure, I was talking hypervisor_hostname, which should change after a migration | |
| 15:59:42 | umbSublime | in the meantime I agree with you i'll update my ressource :) | |
| 16:19:33 | openstackgerrit | Merged openstack/keystoneauth master: Trivial: Update pypi url to new url https://review.openstack.org/565418 | |
| 16:20:42 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Use Status variables in tests https://review.openstack.org/564258 | |
| 16:20:49 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Reference class variable in Status https://review.openstack.org/564262 | |
| 18:39:57 | openstackgerrit | Merged openstack/keystoneauth master: fix a typo in session.py https://review.openstack.org/556397 | |
| 19:40:33 | mnaser | mordred: do you think we can get a small bump release for openstacksdk ? | |
| 19:41:15 | mnaser | say 0.13.1 | |
| #openstack-sdks - 2018-05-03 | |||
| 02:58:10 | pooja_jadhav | cmurphy: Hi | |
| 05:36:30 | pooja_jadhav | kmalloc: Hello | |
| 05:41:16 | pooja_jadhav | cmurphy, kmalloc, cdent : Actually, mordred has proposed patch[1] and that got merged. He has added split_loggers functionality in keystoneauth. Now I am trying to use that split_loggers parameter in core projects for enabling split logging. So instead of adding split_loggers parameter in individual projects, can we add one config option in keystoneauth for split_loggers so that, all core projects can use that config option for enabling the | |
| 05:41:16 | pooja_jadhav | split logging. Please give me your suggestions on the same. [1]https://review.openstack.org/#/c/505764 | |
| 06:56:49 | cmurphy | pooja_jadhav: keystoneauth isn't a central service, it's a library that each project consumes, so i don't see how you could set the logger option globally for all services | |
| 07:01:21 | pooja_jadhav | cmurphy: Then how can I configure the split_logger such a that core projects can use it? Can you guide me for the same? | |
| 07:18:16 | cmurphy | pooja_jadhav: hmm, we might need to expose the parameter in the Adapter class for openstack services to be use it, I'm not sure | |
| 07:21:09 | pooja_jadhav | cmurphy: Ohk | |
| 07:40:09 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/python-openstackclient master: Support locking user password https://review.openstack.org/564200 | |
| 07:53:12 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/python-openstackclient master: Support locking user password https://review.openstack.org/564200 | |
| 09:39:14 | openstackgerrit | Stephen Finucane proposed openstack/cliff master: Remove travis.yml https://review.openstack.org/566010 | |
| 11:27:33 | umbSublime | If possible, how can I get os-aggregates from the SDK ? Follow-up question, if not possible what is the current method to create a custom API call from a connection, in this case https://developer.openstack.org/api-ref/compute/#list-aggregates | |
| 11:44:38 | dtantsur | mordred: hey, can I bother you about os_ironic_node ansible thingy? and overall ansible support for ironic? | |
| 13:20:02 | umbSublime | any hints ? | |
| 13:52:27 | dtantsur | mordred: and am I the only one who find it weird to have baremetal stuff in shade referring to "machine", but then "node_set_provision_state"? :) | |
| 14:11:12 | mordred | dtantsur: what's up with os_ironic_node? and also - we can totally rename stuff in shade if you want | |
| 14:18:01 | mordred | umbSublime: you can make any rest call you want on the connection ... | |
| 14:18:30 | mordred | umbSublime: conn.compute.get('/os-aggregates') will return you a requests.Response object | |
| 14:18:55 | dtantsur | mordred: o/ to be honest, os_ironic_node is a bit of a mess.. I don't quite get why the same command does provisioning and setting maintenance :) anyway, is it possible to attach VIFs with it? and overall, are you open to developing something more high-level there? | |
| 14:19:45 | mordred | dtantsur: I have no idea why it is how it is - and yes, if you want to make something better and/or more high level ABSOLUTELY | |
| 14:20:01 | mordred | dtantsur: I'll happily accept it upstream and add you to the maintainers list for it | |
| 14:20:39 | dtantsur | heh, okay :) I'll see what I can do. It won't be quick though - I have a bit of prototyping ahead first. | |
| 14:21:28 | mordred | umbSublime: otherwise, we'd need to add a Resource for aggregates in openstack/compute/v2 - like probably openstack/compute/v2/aggregate.py - and then some methods in openstack/compute/v2/_proxy.py to go along with it | |
| 14:21:44 | mordred | umbSublime: it shouldn't be too hard to add if you feel like making a patch | |
| 14:22:18 | umbSublime | mordred: yah I'm getting more and more familiar with the code base every day. I'll consider it for sure | |
| 14:23:30 | mordred | cool. in the mean time, you should be able to just make direct rest calls when you hit things without direct support | |
| 14:30:42 | umbSublime | indeed that works as intented ! | |
| 14:40:02 | mordred | \o/ | |
| 14:41:14 | mordred | cmurphy: I think what pooja_jadhav might have been getting at is that keystoneauth has a set of config options and registration methods that can be used to add them to oslo.config things | |