Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-05-15
15:24:27 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Use cliff formattable columns in volume v2 commands https://review.openstack.org/464641
15:24:28 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Use cliff formattable columns in object storage commands https://review.openstack.org/464639
15:24:28 openstackgerrit Akihiro Motoki proposed openstack/python-openstackclient master: Use cliff formattable columns in image commands https://review.openstack.org/464638
16:16:42 openstackgerrit David Rabel proposed openstack/python-openstackclient master: Use _get_token_resource in role assignment list https://review.openstack.org/464684
19:24:23 openstack Launchpad bug 1667794 in python-novaclient "assorted novaclient CLI commands treat hostname as pattern" [Undecided,In progress] - Assigned to NidhiMittalHada (nidhimittal19)
19:24:23 cfriesen Hi, just wondering whether openstackclient would be susceptible to this bug? https://bugs.launchpad.net/python-novaclient/+bug/1667794
19:38:46 dtroyer cfriesen: looking… at first glance (before I've looked at novaclient directly) I would suspect it is as the description in the bug implies it is the API that returns the multiple matches and novaclient just shows them all.
19:41:40 cfriesen the issue is that the novaclient is calling the /os-hypervisors/{hypervisor_hostname_pattern}/search API without realizing that it returns a substring match rather than an exact match.
19:41:58 cfriesen line 58 at openstackclient/compute/v2/hypervisor.py looks a bit suspicious
19:43:16 cfriesen dtroyer: ^ (just adding your name in case you're off doing something else)
19:43:44 dtroyer except in that case we do expect to get a list back
19:44:45 dtroyer and looking at novaclient do_host_servers_migrate() it also expects to get a list back
19:45:56 dtroyer This feels a bit like a case of expectations that are not clearly set by docs not matching assumptions made by users
19:47:06 dtroyer OSC's help uses 'substring' but I'll admit it could be clearer on what is happening there
19:47:29 dtroyer —matching for an option name should be a clue too
19:48:11 dtroyer in novaclient's _do_hypervisor_list() it is also expecting a list to be returned
19:48:34 dtroyer and it looks like OSC stole that —matching option name from there too
19:58:21 cfriesen yeah, for the hypervisor-list case it makes sense, and openstackclient doesn't do the problematic ones like "nova evacuate"
19:58:53 cfriesen oops, I meant "nova host-evacuate"
20:00:35 cfriesen dtroyer: so it looks like it's still an issue in novaclient but not in openstackclient. (incidentally is the expectation for osc that the user would implement a script or something to do the equivalent of "nova host-evacuate"?
20:01:42 dtroyer I don't think I had an explicit reason for not doing host-evacuate, possibly that I just never got around to it
20:03:25 openstack Launchpad bug 1690902 in python-openstackclient "doc/source/data/nova.csv is inaccurate for host-meta" [Undecided,New]
20:03:25 cfriesen incidentally, I opened up https://bugs.launchpad.net/python-openstackclient/+bug/1690902 while digging around for this issue. I think nova.csv isn't quite right in the "host-meta" case.
#openstack-sdks - 2017-05-16
02:08:19 openstackgerrit Merged openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/464392
02:30:22 chenyb4 med_, please help me review https://review.openstack.org/#/c/462818/ this patch, thaks
02:31:15 openstackgerrit Merged openstack/keystoneauth master: Fix V3ADFSPassword retrieval of scoped token https://review.openstack.org/463212
02:46:45 openstackgerrit Takashi NATSUME proposed openstack/python-openstackclient master: List/show all server migration types https://review.openstack.org/450119
03:14:32 chenyb4 Qiming, please help me review https://review.openstack.org/#/c/462818/ this patch about 'senlin service list', thaks
05:13:20 Qiming chenyb4, done.
05:40:53 openstackgerrit Divya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token https://review.openstack.org/464934
08:36:52 LuigiOpenstack Hi..is this the right IRC for development practice of Openstack and Luigi workflows?
08:45:09 LuigiOpenstack anybody has an idea of how to leverage luigi with Openstack ?
09:48:20 openstackgerrit Divya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token https://review.openstack.org/464934
12:48:20 LuigiOpenstack Can anyone assist me with Python code ?
13:49:07 mordred LuigiOpenstack: hi! I'm not sure what a luigi is. this is the right channel to discuss OpenStack SDKs though
14:41:20 edleafe mordred: it's a module to handle plumbing a series of tasks together. Mario Bros. reference
14:48:19 elmiko edleafe: lol
14:48:39 elmiko or were you referring to the actual luigi package
14:49:20 cdent elmiko: how doing after two solid weeks of conferencing?
14:49:34 elmiko cdent: almost fully recovered =)
14:49:43 elmiko finishing the last of my expense reports now lol
14:50:32 cdent I got home yesterday around 11am and just want to sleep
14:50:41 elmiko wow
14:50:55 elmiko hope you're feeling rested now =)
14:53:19 edleafe elmiko: both
14:53:40 edleafe cdent: go to sleep.
14:54:06 edleafe cdent: elmiko: btw, I'll be in Portland on Thursday for the start of PyCon, so I won't be at the meeting
14:54:14 cdent i slept most of yesterday, but it hasn't helped yet
15:00:49 elmiko edleafe: ack, also enjoy pycon! =)
15:03:13 edleafe elmiko: oh, I will!
15:03:58 cdent edleafe: make sure you come back with lots of ideas to change everything
15:04:28 edleafe cdent: yeah, that always goes over well in this community.
15:04:31 edleafe :)
15:04:41 cdent exactly why it is critical
15:05:33 elmiko re-write all services in ruby after visiting pycon? XD
15:07:11 edleafe elmiko: bite your tongue!
15:07:49 openstackgerrit Blake Covarrubias proposed openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword https://review.openstack.org/463432
15:38:43 mordred edleafe: somehow last week - several sessions ended up with the outcome "mordred will write a spec" ...
15:38:50 mordred edleafe: so, youknow - sorry in advance
15:39:22 mordred edleafe, cdent: speaking of - dhellmann mentioned someting in one of the sessions that I think bears thinking about deeply and making a plan for
15:40:25 mordred with some of the new things we're writing up - we're winding up with 3 audiences for some of these API related specs- OpenStack Developers writing API services, Deployers registering things in such a way that affects API consumers, and API Consumers using the API services the OpenSTack Developers have written
15:41:27 mordred so I _think_ I understood that dhellmann suggested we maybe make three different outputs that we publish - so we can point deployers at the info that's relevant to them without them needing to read about implementation internals or whatnot
15:41:30 mordred or - something similar
15:42:42 edleafe mordred: that sort of meshes with the feeling I had reviewing your discovery docs (besides the dizziness)
15:42:57 mordred the dizziness means it's working
15:43:04 mordred soon I will have the mind control overyou!
15:43:05 edleafe mordred: that these aren't API guidelines, but more like deployment guidelines
15:43:06 mordred wait
15:43:10 mordred sssh. I didnt' say that
15:43:24 edleafe or something like that
15:43:38 mordred edleafe: exactly. I mean - they're API guidelines in as much as we want the API to behave in a way, and the deployers have to participate on a few topics
15:43:39 edleafe I didn't hear that. I hear only what the master tells me to hear
15:43:44 mordred edleafe: :)
15:44:31 edleafe I think of these guidelines as helping the OpenStack developers make good choices when creating APIs
15:44:46 edleafe These seem... different
15:45:32 mordred do you think they seem different enough to put into a separate source repo? my original thought was "no" - since the corpus is about OpenStack REST APIs ...
15:45:49 mordred but I am more than happy to agree with whatever opinions y'all have on that topic
15:46:46 edleafe mordred: not really sure. I'd like to get cdent and elmiko to weigh in on this
15:47:39 mordred cdent, elmiko: ^^ ?
15:47:58 cdent I think putting creation and consumption in the same place is a good idea because it is more contextualized
15:54:37 dtroyer ++ separate sections in the same repo would be good with me, but having to look in multiple places to find thw whole story is just painful. More than a few of us fit multiples of those categories
15:55:55 dhellmann mordred : we're working through whether it makes sense to have separate guides in the discussion with asettle about the future of docs
15:56:09 dhellmann mordred : one option is to have 1 sphinx job that publishes nicely organized docs, but only one thing
15:56:22 dhellmann another option is to have separate jobs, publishing different sets of docs to different places
15:57:19 dhellmann there's more of a legacy concern there, because we want to deal with redirects if we change how things are published
15:57:20 dhellmann if this is new content, you don't have that concern
15:57:34 dhellmann so a single sphinx project publishing nicely organized content is more appealing
15:57:44 dhellmann edleafe, cdent, dtroyer : ^^
15:58:48 cdent ideally we'd see more places linking into the guidelines, and that makes even more sense if we're covering both creation and consumption
16:01:02 edleafe cdent: +1
16:04:52 elmiko mordred: edleafe, just saw the ping. reading back
16:06:46 elmiko mordred: so, i more or less agree with cdent, edleafe and dtroyer. seems more useful to have things in a place that is easier to find
16:07:22 elmiko i'm not sure what shape that would take, but i like the idea of being able to navigate between the different guideline types in a convenient fashion
16:10:21 mordred sweet
16:11:28 edleafe The only one that seems out of place a bit is the version discovery algorithm
16:11:45 edleafe but in the context of the others, it fits
16:12:00 mordred dhellmann: there is also at least one thing in the service-types-authority consumption spec that assumes we can publish the service-types-authority data to a location that will be solid/stable/well-known. It's currently written up as "https://specs.openstack.org/service-types.json" - which I think a job in s-t-a to publish post-merge should be easy enough to implement
16:13:00 dhellmann mordred: it feels a little odd to publish machine-readable data to the root of the specs site, but I think I get it
16:13:28 mordred dhellmann: yah - we could also spin up a new domain/web root for that I imagine too
16:13:55 cdent i think specs could very well be fine: it's sort of like a spec

Earlier   Later