| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-05-01 | |||
| 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 | split logging. Please give me your suggestions on the same. [1]https://review.openstack.org/#/c/505764 | |
| 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 | |
| 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 | |
| 14:42:02 | mordred | like register_adapter_conf_options | |
| 14:43:10 | mordred | so if nova, for instance, wanted to set the split_loggers option on an Adapter they're using, currently all of that flows through the nova.ini file - and if we don't have a split_loggers option in register_*_conf_options, then it gets awkward to set | |
| 14:43:41 | mordred | I think it might want to be in register_session_conf_options actually | |
| 15:24:12 | openstackgerrit | Merged openstack/cliff master: Remove travis.yml https://review.openstack.org/566010 | |
| 16:01:12 | elmiko | dtantsur: ping | |
| 16:01:18 | dtantsur | o/ | |
| 16:48:52 | edleafe | elmiko: dtantsur: ready for review https://etherpad.openstack.org/p/api-sig-newsletter | |
| 16:50:07 | edleafe | <homer> Mmmm... fried brain </homer> | |
| 16:52:48 | edleafe | dtantsur: https://www.youtube.com/watch?v=dc77--BjFYQ | |
| 16:52:57 | dtantsur | hehe | |
| 17:00:09 | elmiko | edleafe: lgtm | |
| 17:02:58 | edleafe | sent | |
| 17:06:21 | elmiko | thanks edleafe, heads up, i'll be out next week | |
| 17:06:26 | elmiko | dtantsur|afk: ^^ | |
| 17:25:11 | edleafe | elmiko: ack | |
| 17:31:31 | jroll | fwiw, I did some graphql in the time I spent away from openstack. super awesome for quickly iterating on a product, especially the separation between front and back end | |
| 17:31:57 | jroll | also, pretty neat on the backend, in terms of only building the response you need and such, in general writing the code was pleasant | |
| 17:32:27 | jroll | that said, the python tooling for graphql backends is absolutely terrible, and if we started using it I highly suspect we'd end up writing our own | |
| 17:32:42 | mordred | jroll: awesome | |
| 17:35:01 | mordred | jroll: yah - it seems like a thing like oaktree would be an excellent place (especially since doing joins across things like servers, networks, subnets and ports is a legit thing) | |
| 17:36:06 | jroll | ++ | |