| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-01-24 | |||
| 16:51:47 | ankur-gupta-f1 | +1 | |
| 16:51:59 | dtroyer | yes it does. I'm thinking that is secondary here though | |
| 16:52:51 | reedip_ | dtroyer: I understand what you are saying is that the addresses are not yet allowed, then how can it be in the past tense | |
| 16:53:20 | reedip_ | and thats why allow-address makes a bit more sense | |
| 16:53:56 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk: Initial docs for bare-metal service https://review.openstack.org/411132 | |
| 16:54:44 | stevemar | briancurtin: hehe, dtroyer has skirted the question | |
| 16:55:17 | stevemar | briancurtin: when you're done moving things around, let me know when you're about to release, we can test OSC's functional tests with SDKs master branch now | |
| 16:55:20 | dtroyer | stevemar: which one? I'm juggling 3 things atm :) | |
| 16:55:26 | stevemar | dtroyer: :) | |
| 16:55:37 | stevemar | dtroyer: end-of-release-fun! | |
| 16:55:45 | stevemar | dtroyer: the one about needing a new sdk version | |
| 16:55:53 | dtroyer | whee!!! Plus TC _and_ board meetings this afternoon | |
| 16:55:54 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient: Updated from global requirements https://review.openstack.org/423277 | |
| 16:56:21 | dtroyer | ya, I think new release is simpler than unblacklisting, even with the risks. question is, how much do we trust our tests? :) | |
| 16:56:36 | dtroyer | and can it all get done in time? | |
| 16:57:31 | openstackgerrit | Artom Lifshitz proposed openstack/python-openstackclient: Use image client for images instead of compute https://review.openstack.org/424688 | |
| 16:58:26 | stevemar | dtroyer: its gonna have to! | |
| 17:04:10 | reedip_ | dtroyer : I am more inclined to allowed-address-pair | |
| 17:04:54 | reedip_ | because of negation primarily ( maybe a wrong case ) | |
| 17:05:26 | reedip_ | and also maybe because the user already decided to allow the addresses | |
| 17:05:27 | dtroyer | I am looking for consistency, and we have a rule regarding options and negation: add "—no-" to the beginning | |
| 17:05:44 | reedip_ | do we have a rule for the past tense ? | |
| 17:05:44 | dtroyer | that overrides English tenses in that regard | |
| 17:06:25 | dtroyer | I'm not certain it is written, it is in the HIG if so, but out longstanding practice is to make options 'active' or present tesnt: —enable rather than --enabled | |
| 17:06:47 | dtroyer | these are not passive commands | |
| 17:06:52 | reedip_ | makes sense to have active commands | |
| 17:07:30 | reedip_ | I do not have anything against the active command | |
| 17:18:34 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk: Add docs for the workflow service https://review.openstack.org/424755 | |
| 17:39:04 | openstackgerrit | Merged openstack/python-openstacksdk: Initial docs for bare-metal service https://review.openstack.org/411132 | |
| 17:44:04 | openstackgerrit | Brian Curtin proposed openstack/python-openstacksdk: Add docs for the workflow service https://review.openstack.org/424755 | |
| 18:27:50 | openstackgerrit | Merged openstack/python-openstacksdk: Add docs for the workflow service https://review.openstack.org/424755 | |
| 18:45:01 | briancurtin | stevemar: sdk master is currently at a state i’d like to release. what do you need to do now? | |
| 18:48:27 | stevemar | briancurtin: i need 25 minutes to test it | |
| 18:49:16 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient: test sdk https://review.openstack.org/424796 | |
| 18:49:39 | stevemar | briancurtin: you can play the jeopardy theme song while looking at the zuul results to ^ | |
| 19:11:34 | ankur-gupta-f1 | briancurtin: https://www.youtube.com/watch?v=IkdmOVejUlI here you go. | |
| 19:17:45 | briancurtin | hah | |
| 19:46:44 | stevemar | briancurtin: our fucntional tests pass! | |
| 19:46:56 | stevemar | briancurtin: you are in the clear to release 0.9.13 cc dtroyer | |
| 19:47:16 | stevemar | functional tests pass just fine https://review.openstack.org/#/c/424796/ | |
| 20:14:24 | openstackgerrit | Justin A Wilson proposed openstack/python-openstackclient: Add support for Cinder API 3.3 into OSC https://review.openstack.org/421585 | |
| 20:33:42 | dims | briancurtin stevemar : do you need this for ocata? | |
| 20:33:54 | briancurtin | dims: yes | |
| 20:34:29 | stevemar | dims: what is "this" | |
| 20:34:41 | dims | oops https://review.openstack.org/#/c/422069/ | |
| 20:35:51 | dims | stevemar : ^ | |
| 20:36:01 | dims | briancurtin : i know you filed it :) | |
| 20:36:19 | dims | briancurtin : freeze starts thu (email just hit -dev) | |
| 20:40:18 | briancurtin | dims: is my response to Matthew Thode on that review sufficient to answer your question? | |
| 20:43:52 | openstackgerrit | Justin A Wilson proposed openstack/python-openstackclient: Add support for Cinder API 3.3 into OSC https://review.openstack.org/421585 | |
| 20:50:03 | dims | y that helped briancurtin | |
| 20:58:51 | briancurtin | dims: thanks a lot! | |
| 22:07:59 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433 | |
| 23:11:46 | stevemar | dtroyer: heads up for https://review.openstack.org/#/c/418190/ and https://review.openstack.org/#/c/424847/ | |
| 23:12:51 | dtroyer | stevemar: I've got one coming too… standby one | |
| 23:31:05 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient: change assert_show_fields to not fail on new fields https://review.openstack.org/424433 | |
| 23:32:11 | stevemar | dtroyer: you may want to join -nova and talk to mriedem and andreyk about it | |
| 23:32:24 | dtroyer | stevemar: so do we need to get that novaclient review merged still? or do we need to work around that problem yet? I thought it was fixed? | |
| 23:32:34 | stevemar | dtroyer: currently the sdk requirements bump will break them | |
| 23:32:43 | stevemar | dtroyer: i have no effing clue and i'm too tired to think :) | |
| 23:32:58 | dtroyer | sure, because someone still hasn't fixed the real issue, which I'm not sure I know anymore what it is | |
| 23:33:21 | stevemar | all i know is i want the minimum sdk bumped, and nova is stopping us | |
| 23:33:25 | stevemar | i have no idea why | |
| 23:39:45 | briancurtin | how could that even occur? | |
| 23:42:35 | dtroyer | novaclient functional tests broke with 0.9.11, from something in the network refactor, we've apparenty still not got it fixed | |
| 23:43:24 | dtroyer | I don't know where the root bug is, I thought we'd worked around it in OSC, apparently not | |
| 23:45:54 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient: Add server test for image and flavor lookups https://review.openstack.org/424901 | |
| #openstack-sdks - 2017-01-25 | |||
| 00:12:36 | openstackgerrit | Merged openstack/python-openstackclient: Use image client for images instead of compute https://review.openstack.org/424688 | |
| 00:55:55 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-openstackclient: Updated from global requirements https://review.openstack.org/423277 | |
| 02:34:31 | openstackgerrit | Steve Martinelli proposed openstack/python-openstackclient: Add server test for image and flavor lookups https://review.openstack.org/424901 | |
| 03:57:35 | openstackgerrit | Merged openstack/python-openstacksdk: Remove discover from test-requirements https://review.openstack.org/416118 | |
| 04:01:55 | reedip | amotoki : ping | |
| 04:03:33 | amotoki | reedip: pong | |
| 04:03:38 | reedip | stevemar : everything fine , or is there a fire with the release of 0.9.13 | |
| 04:03:53 | reedip | amotoki: I had a question regarding your comment in https://review.openstack.org/#/c/356263/ | |
| 04:04:04 | stevemar | reedip: getting it fixed :) | |
| 04:04:11 | reedip | >> The possible way is to change --dhcp-options to take two parameters (nargs=2): --dhcp-option <opt-name> <opt-value>. | |
| 04:04:19 | reedip | stevemar : lemme know if I can help | |
| 04:05:14 | amotoki | reedip: ? | |
| 04:05:45 | reedip | amotoki : I am not sure about how you wanted the dhcp options to be handled | |
| 04:06:08 | reedip | amotoki : you stated --dhcp options can take 2 parameters (nargs = 2 ) | |
| 04:06:55 | amotoki | reedip: in the case of dhcp option, a value can vary and it can contain even a comma. | |
| 04:07:06 | reedip | amotoki : ok | |
| 04:07:52 | reedip | amotoki : so the value needs to be handled specially | |
| 04:08:00 | amotoki | reedip: parsing strdict now depends on a comma, and the current value format forces a special parsing. | |
| 04:08:06 | reedip | i mean the value parameter of dhcp-options | |
| 04:08:28 | amotoki | reedip: if the option takes two parameters (name and value), such parsing is no longer needed. | |
| 04:09:00 | amotoki | reedip: yes. the format of the value of dhcp-option is NOW opt_name=XXX,opt_value=YYY | |
| 04:09:10 | amotoki | reedip: this format needs parsing. | |
| 04:09:34 | amotoki | reedip: if we have two option, parsing is no longer needed. does it make sense? | |
| 04:10:25 | reedip | amotoki : oh , so that means --dhcp-options can have [name] , [opt-name,opt-value], [ip-version] | |
| 04:10:30 | reedip | amotoki : is that correct? | |
| 04:11:12 | amotoki | reedip: ah... I totally forget ip-version.... | |
| 04:12:10 | amotoki | reedip: if we always have two parameters, it can be simple, but ip-version is optional, so it would be complicated. | |
| 04:12:16 | reedip | amotoki : then is it opt_name,opt_value,ip_version ? | |
| 04:12:19 | amotoki | reedip: my idea does not seem to work | |
| 04:12:43 | amotoki | reedip: yeah. that looks better | |
| 04:12:54 | amotoki | that means 'opt_name,opt_value,ip_version' | |
| 04:13:27 | reedip | amotoki : yes, but the classless route would have a comma separated value in the opt_value | |
| 04:13:47 | reedip | amotoki : so we cannot use the default strdict option, and need to create one for ourselves | |