*** dschroeder has quit IRC | 00:30 | |
*** reldan has joined #openstack-freezer | 00:57 | |
*** reldan has quit IRC | 01:20 | |
*** openstack has joined #openstack-freezer | 02:28 | |
*** jonaspf has joined #openstack-freezer | 02:43 | |
*** jonaspf has quit IRC | 02:58 | |
*** jonaspf has joined #openstack-freezer | 04:14 | |
*** jonaspf has quit IRC | 04:29 | |
*** jonaspf has joined #openstack-freezer | 05:31 | |
*** jonaspf has quit IRC | 05:46 | |
*** jonaspf has joined #openstack-freezer | 09:41 | |
*** daemontool has joined #openstack-freezer | 09:42 | |
daemontool | all, today I think we need to solve the pbr issue and the last branching changes | 09:44 |
---|---|---|
*** daemontool has quit IRC | 09:47 | |
*** daemontool has joined #openstack-freezer | 09:48 | |
*** jonaspf has quit IRC | 09:56 | |
*** reldan has joined #openstack-freezer | 09:59 | |
*** openstackgerrit has quit IRC | 10:01 | |
*** openstackgerrit has joined #openstack-freezer | 10:02 | |
*** openstack has joined #openstack-freezer | 10:21 | |
*** jonaspf has joined #openstack-freezer | 11:03 | |
*** m3m0 has quit IRC | 11:22 | |
*** m3m0 has joined #openstack-freezer | 11:23 | |
*** reldan has quit IRC | 11:41 | |
*** reldan has joined #openstack-freezer | 12:02 | |
daemontool | all, please review this, it's quite critical https://review.openstack.org/#/c/246331/ | 12:13 |
daemontool | frescof__, Slashme vannif m3m0 reldan ^^ | 12:17 |
reldan | Done | 12:20 |
daemontool | m3m0, is this critical too? https://review.openstack.org/#/c/246957/ | 12:21 |
daemontool | reldan, ty | 12:21 |
m3m0 | yes daemontool, it is | 12:21 |
m3m0 | its a bug fix | 12:21 |
reldan | m3m0: dict.get(something, None) isn’t equal to dict.get(something) ? | 12:23 |
reldan | get(key[, default]) | 12:24 |
reldan | Return the value for key if key is in the dictionary, else default. If default is not given, it defaults to None, so that this method never raises a KeyError. | 12:24 |
daemontool | yes | 12:24 |
daemontool | it is | 12:24 |
daemontool | None ie the default value | 12:24 |
daemontool | returned | 12:24 |
vannif | added a comment on https://review.openstack.org/#/c/246331/ | 12:24 |
reldan | So here https://review.openstack.org/#/c/246957/ we can just simplify | 12:24 |
openstackgerrit | Merged openstack/freezer: Updated requirements to match Liberty's one https://review.openstack.org/246331 | 12:26 |
m3m0 | reldan | 12:27 |
m3m0 | in dict.get you are right | 12:27 |
m3m0 | but for pop, you need to set None in case the key doesnt exists | 12:27 |
reldan | m3m0: Yes, you are right | 12:29 |
reldan | So if you suppose that get is ok, i don’t mind. Just question | 12:29 |
Slashme | vannif: You are right. Global requirements changed during the time we merged the patch... | 12:31 |
Slashme | Creating a new one | 12:31 |
openstackgerrit | Pierre Mathieu proposed openstack/freezer: Updated python-keystoneclient requirement https://review.openstack.org/247476 | 12:34 |
*** reldan has quit IRC | 12:48 | |
*** reldan has joined #openstack-freezer | 12:50 | |
*** jonaspf has quit IRC | 13:14 | |
daemontool | vannif, yes you are right, it is python-keystoneclient>=1.6.0,!=1.8.0 | 13:39 |
daemontool | one sec | 13:39 |
daemontool | a ok Slashme did it | 13:40 |
vannif | yep | 13:40 |
openstackgerrit | Merged openstack/freezer: Updated python-keystoneclient requirement https://review.openstack.org/247476 | 13:43 |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 13:51 |
reldan | Please review it the same as https://review.openstack.org/#/c/246460/ | 13:51 |
reldan | But to master instead of stable/kilo | 13:52 |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 13:57 |
*** jonaspf has joined #openstack-freezer | 14:02 | |
*** daemontool_ has joined #openstack-freezer | 14:08 | |
*** daemontool has quit IRC | 14:09 | |
*** daemontool_ has quit IRC | 14:16 | |
*** daemontool_ has joined #openstack-freezer | 14:17 | |
*** jonaspf has quit IRC | 14:24 | |
*** jonaspf has joined #openstack-freezer | 14:25 | |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 14:27 |
openstackgerrit | Fausto Marzi proposed openstack/freezer-api: Align requirements to liberty global-requirements https://review.openstack.org/246993 | 14:50 |
daemontool_ | all, Slashme, Jokke_ reldan vannif m3m0 in particular please review https://review.openstack.org/#/c/246993/ | 14:51 |
daemontool_ | after that we need to move to testr from pytest | 14:51 |
daemontool_ | for freezer-api | 14:51 |
daemontool_ | I thought I did that... but not... | 14:51 |
daemontool_ | reldan, did you get how to commit to stable/kilo from master for https://review.openstack.org/#/c/246460/ ? | 14:53 |
daemontool_ | first the commit in master, then cherrypick | 14:53 |
daemontool_ | that's to avoid that the branches can diverge | 14:53 |
reldan | Yes, I see it now. There is my commit to master https://review.openstack.org/247518, please review. And after merging I will chery-pick it | 14:54 |
daemontool_ | reldan, one think if possible, I'm not sure I understand the bug without reading all the code, would be good if you can write some explanation on the commit message | 14:58 |
reldan | Sure, give me a sec | 14:58 |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 15:02 |
daemontool_ | vannif, question for you here: https://review.openstack.org/#/c/246993/ | 15:02 |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 15:02 |
reldan | daemontool_: fied | 15:03 |
reldan | fixed | 15:03 |
daemontool_ | reldan, ty, that's good | 15:04 |
reldan | daemontool_: thank you for the review ) | 15:05 |
daemontool_ | reldan, as soon as it's verified I'll give +2 | 15:05 |
reldan | daemontool_: Thank you. I’m not quite sure about metadata format in case of multiple storages and multiple containers. But suppose I can fix it later | 15:06 |
daemontool_ | where? like in the config file? | 15:07 |
daemontool_ | reldan, let's talk about that today in the meeting | 15:15 |
reldan | Yes, in case of config file I have a lot of containers and a lot of storages | 15:15 |
daemontool_ | so the challenge is, how to represent them int he metadata in the code? | 15:19 |
m3m0 | daemontool_ -1 https://review.openstack.org/#/c/246993/ | 15:30 |
m3m0 | reldan +1 https://review.openstack.org/#/c/247518/ | 15:31 |
vannif | there's an elasticsearch method which is being deprecated. I's removed from elasticsearch>=1.7.0 | 15:33 |
vannif | I'm on it | 15:33 |
*** reldan has quit IRC | 15:33 | |
m3m0 | Slashme did you have any issues with freezer version in setup.cfg ? | 15:35 |
m3m0 | for this commit https://review.openstack.org/#/c/246428/5 | 15:35 |
*** reldan has joined #openstack-freezer | 15:36 | |
reldan | m3m0: Thank you! | 15:36 |
daemontool_ | Slashme, https://review.openstack.org/#/c/246428/5/setup.py shouldn't be the exception caught? | 15:37 |
daemontool_ | try except finally? | 15:37 |
*** m3m0 has quit IRC | 15:38 | |
*** m3m0 has joined #openstack-freezer | 15:41 | |
daemontool_ | Slashme, or try except else ? | 15:49 |
daemontool_ | what would happen there if in the try block an exception is raised? | 15:49 |
*** frescof has joined #openstack-freezer | 15:50 | |
*** frescof is now known as ffresh | 15:50 | |
Slashme | We want the exception to be raised normally. No need to catch it. But we want to be sure the environment is set back to the original one | 15:55 |
Slashme | hence the finally | 15:55 |
daemontool_ | but if the exception is raised the program execution stops or goes forward? | 15:56 |
daemontool_ | cause I'm reading this http://stackoverflow.com/questions/1611561/can-i-get-the-exception-from-the-finally-block-in-python | 15:56 |
m3m0 | ok guys t minus 2 | 15:58 |
daemontool_ | if the program exection doesn't stop, it's OK for me | 15:58 |
daemontool_ | m3m0, countdown :) | 15:58 |
m3m0 | ok guys let's start | 16:00 |
m3m0 | #startmeeting openstack-freezer 19-11-2015 | 16:00 |
openstack | Meeting started Thu Nov 19 16:00:58 2015 UTC and is due to finish in 60 minutes. The chair is m3m0. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
openstack | The meeting name has been set to 'openstack_freezer_19_11_2015' | 16:01 |
m3m0 | first order of business pbr | 16:01 |
m3m0 | #topic pbr | 16:01 |
m3m0 | we currently have this commit that will enable the installation of freezer on windows and linuz | 16:02 |
m3m0 | linux | 16:02 |
m3m0 | https://review.openstack.org/#/c/246428/5 | 16:02 |
m3m0 | the problem is os specific dependencies and that pbr version on kilo doesn't support environment_markers | 16:02 |
m3m0 | so we need to do this within the setup.py file | 16:03 |
m3m0 | any objections or comments on this regard? | 16:03 |
Slashme | Yes. | 16:04 |
daemontool_ | Slashme, what comments and objections? :) | 16:05 |
m3m0 | hahahaha | 16:05 |
daemontool_ | we are blocked | 16:05 |
daemontool_ | :) | 16:05 |
daemontool_ | lol | 16:05 |
m3m0 | he is buffering | 16:06 |
daemontool_ | haha | 16:06 |
Slashme | With this, the package gets installed even on operations that shouldn't install anything. Like "pip wheel" | 16:06 |
Slashme | or python setup.py egg_info | 16:06 |
m3m0 | so this approach is not optimal? | 16:07 |
daemontool_ | thought patchset 5 was OK? https://review.openstack.org/#/c/246428/5..6/setup.py | 16:07 |
*** dschroeder has joined #openstack-freezer | 16:07 | |
daemontool_ | just doing try: except: finally would do it? | 16:08 |
daemontool_ | Slashme, if that's the idea (from patchset 6) then patchset 5 was OK | 16:08 |
daemontool_ | sorry | 16:08 |
daemontool_ | my bad | 16:08 |
Slashme | My concerns also apply on the stable/kilo current state. This patch just has the thing working in non activated venv's | 16:09 |
Slashme | So what is the difference between try finaly and try except raise finaly ? | 16:09 |
m3m0 | the value in sys.exc_info | 16:10 |
Slashme | So which is the best solution ? | 16:10 |
daemontool_ | Slashme, I think is the same | 16:10 |
daemontool_ | try finally probably is the best | 16:10 |
daemontool_ | less code to write | 16:10 |
m3m0 | if we need to know which exception was raised we need to re-reaise | 16:11 |
m3m0 | otherwise try finally is enough | 16:11 |
Slashme | Ok. So it is better to re-raise | 16:12 |
daemontool_ | my concern is, if we have to stop the program execution anyway | 16:12 |
m3m0 | but we still have the problem with the virtual environments right? | 16:12 |
daemontool_ | when the block in try throw an exception | 16:12 |
daemontool_ | then why have a finally statement | 16:12 |
daemontool_ | I think | 16:13 |
Slashme | daemontool_: unless it gets killed by a kill -9 the finaly will be executed | 16:13 |
daemontool_ | and after that the program keep running? | 16:13 |
Slashme | No, it stops | 16:14 |
daemontool_ | ok, so why we do that if the program stops anyway | 16:14 |
daemontool_ | I think probably I'm missing something :) | 16:15 |
m3m0 | raise will prevent the installation to continue so that's what we want | 16:16 |
daemontool_ | yes | 16:16 |
daemontool_ | ok let's talk about this after the meeting | 16:16 |
daemontool_ | and we'll solve this once for all | 16:17 |
daemontool_ | is that ok? | 16:17 |
m3m0 | yes, we need to solve this soon | 16:17 |
m3m0 | ok, does anyone has anything else to add on this topic? | 16:18 |
Slashme | Yes | 16:18 |
Slashme | On liberty this tim e | 16:18 |
Slashme | If an old version of PBR is already installed, we get an error because the setup_requires does not update pbr before doing the install | 16:19 |
m3m0 | so the problem will persist? | 16:19 |
Slashme | Just worth noticing. I don't think we can do anything against that | 16:19 |
daemontool_ | if we set the pbr version in setup.py will that be solved? | 16:19 |
Slashme | Nope | 16:20 |
daemontool_ | ok then nothing | 16:20 |
daemontool_ | it's a common problem everybody has | 16:20 |
m3m0 | even for setup_requires? instead of install_requires? | 16:20 |
daemontool_ | or both? | 16:20 |
Slashme | m3m0: both | 16:20 |
daemontool_ | ok | 16:21 |
Slashme | No easy solution here | 16:21 |
Slashme | Maybe we should still create a bug and describe the workaround | 16:21 |
daemontool_ | noop then | 16:21 |
daemontool_ | yes | 16:21 |
Slashme | ie: uninstalling pbr | 16:21 |
m3m0 | #agree | 16:21 |
daemontool_ | like a troubleshooting guide section in the wiki | 16:21 |
daemontool_ | ? | 16:21 |
Slashme | +1 | 16:21 |
daemontool_ | #agreed | 16:21 |
daemontool_ | or we can add pip as requirement | 16:22 |
m3m0 | don't like this, but if there is no other way.... | 16:22 |
daemontool_ | and skip the easy_install pip part | 16:22 |
daemontool_ | I'd like to understand if this is an issue that everybody has or only us... | 16:23 |
daemontool_ | because it looks to me a bit strange honestly... that also the other project has the same issue and no one fixed it | 16:23 |
Slashme | I checked a bit other projects | 16:24 |
daemontool_ | what they do in kilo? | 16:24 |
daemontool_ | well... probably they don't have this issue.. cause the packages are all in requirements | 16:24 |
daemontool_ | and there's no windows support | 16:25 |
daemontool_ | or did you find anything different Slashme ? | 16:25 |
Slashme | Mainly, either the don't support windows or if they do, they don't have weird plateform dependancies (ie: openstack clients) | 16:25 |
daemontool_ | ok | 16:25 |
daemontool_ | I think that code needs to be removed... | 16:26 |
daemontool_ | then we put pep3143daemon in requirements.txt of stable/kilo | 16:26 |
daemontool_ | and remove the windows module | 16:27 |
daemontool_ | and add it as requirement to install in the documentation | 16:27 |
daemontool_ | so kilo is solved | 16:27 |
Slashme | But then it breaks windows | 16:27 |
daemontool_ | then we use env markers in liberty | 16:27 |
Slashme | pep3143daemon doesn't install on windows | 16:27 |
daemontool_ | ah yes | 16:27 |
daemontool_ | that's true sorry | 16:27 |
daemontool_ | :( | 16:27 |
Slashme | I know ..... | 16:27 |
m3m0 | we can solve this by having a windows installer? | 16:28 |
m3m0 | a .msi? | 16:28 |
daemontool_ | that wouldn't be a bad idea | 16:28 |
daemontool_ | or distributing the win binary package from pypi? | 16:28 |
Slashme | m3m0: Yes but this is a big change then. No ? Is that something we want to backport to stable/kilo ? | 16:29 |
m3m0 | yes, that's true, we need to solve this problem and soon | 16:29 |
daemontool_ | like bdist_msi | 16:29 |
daemontool_ | Slashme, I think we can it's not a feature change | 16:30 |
daemontool_ | it's just a change on how we manage the packages and reqs | 16:30 |
m3m0 | and what about to write the dependencies in the readme? bad idea? | 16:30 |
daemontool_ | m3m0, yes | 16:32 |
daemontool_ | that's probably is the easiest thing to do | 16:32 |
daemontool_ | do you mean the pepdaemon dependancy? | 16:32 |
daemontool_ | for linux? | 16:32 |
daemontool_ | mmhhh | 16:32 |
daemontool_ | or put in the readme the window steps | 16:33 |
daemontool_ | and put pepdaemon in requirements? | 16:33 |
Slashme | How about we remove the pep3143 dependancy an rewrite that part in the freezer-scheduler | 16:33 |
daemontool_ | even that is ok | 16:33 |
Slashme | It wouldn't be a big amount of work said vannif | 16:33 |
Slashme | And we put the win32 dependancy in the readme | 16:34 |
daemontool_ | that works for me | 16:34 |
Slashme | Anyone againt that last solution ? | 16:35 |
vannif | I like it | 16:35 |
m3m0 | not me | 16:35 |
m3m0 | no problem for me :) | 16:35 |
daemontool_ | vannif, do you want to do it? | 16:36 |
vannif | not sure it can be done in 1 day though :) | 16:36 |
vannif | sure | 16:36 |
daemontool_ | why not? | 16:36 |
daemontool_ | ok | 16:36 |
daemontool_ | anyway | 16:36 |
daemontool_ | ++ | 16:36 |
daemontool_ | let's go for this approach | 16:36 |
daemontool_ | vannif, just in stable/kilo puts it in a lib directory | 16:37 |
daemontool_ | and we'll import it locally | 16:37 |
daemontool_ | then remove that code in setup.py | 16:37 |
daemontool_ | as Slashme said | 16:37 |
daemontool_ | all good? | 16:37 |
vannif | ok | 16:37 |
daemontool_ | let's move forward now | 16:37 |
daemontool_ | :) | 16:37 |
m3m0 | next topic | 16:38 |
m3m0 | #topic stable/kilo bug fixes | 16:38 |
m3m0 | who has commits that needs to be included in stable/kilo and why? | 16:39 |
daemontool_ | https://review.openstack.org/#/q/project:openstack/freezer+status:open+branch:stable/kilo,n,z | 16:39 |
daemontool_ | https://review.openstack.org/#/q/project:openstack/freezer-api+status:open+branch:stable/kilo,n,z | 16:40 |
reldan | I have this one https://review.openstack.org/#/c/247518/ | 16:40 |
daemontool_ | project:openstack/freezer-web-ui status:open branch:stable/kilo | 16:40 |
daemontool_ | in the freezer-api repo, I think the changes are ok | 16:40 |
daemontool_ | just minor | 16:40 |
m3m0 | https://review.openstack.org/#/c/246957/ | 16:41 |
m3m0 | I have this commit | 16:41 |
daemontool_ | remember we need to bumpt the minor version in setup.cfg when we modify stable/kilo | 16:41 |
m3m0 | is a minig bug fix | 16:41 |
daemontool_ | ok | 16:41 |
daemontool_ | that's ok | 16:41 |
daemontool_ | in freezer | 16:41 |
daemontool_ | we have two commits | 16:41 |
daemontool_ | https://review.openstack.org/#/q/project:openstack/freezer+status:open+branch:stable/kilo,n,z | 16:41 |
daemontool_ | the platform specific thing we were discussing so far | 16:41 |
daemontool_ | and the fix metadata storage from reldan | 16:42 |
m3m0 | for the api we are good? | 16:42 |
daemontool_ | I think so | 16:42 |
m3m0 | so please everyone review those commits | 16:42 |
daemontool_ | ok | 16:43 |
daemontool_ | reldan, why this needs to go to stable/kilo? https://review.openstack.org/#/c/246460/ | 16:44 |
daemontool_ | it's critical? | 16:44 |
daemontool_ | or we need that for backwards compatibility? | 16:44 |
reldan | Not this https://review.openstack.org/#/c/247518/ | 16:44 |
reldan | I should abandon 246460/ | 16:44 |
reldan | Because get_metadata is broken completely in stable/kilo | 16:44 |
daemontool_ | so it's a critical bug? | 16:45 |
m3m0 | yes | 16:45 |
m3m0 | very | 16:45 |
daemontool_ | ok so it needs to go | 16:45 |
daemontool_ | then all the current commits looks in order | 16:46 |
m3m0 | so we have 3 bug fixes | 16:46 |
m3m0 | please lets merge those | 16:46 |
m3m0 | so we can move forward with liberty | 16:47 |
daemontool_ | I agree, but we can move forward with liberty anyway :) | 16:47 |
m3m0 | does anyone has anything to say about this topic? | 16:47 |
m3m0 | yeah but let's not carry those bugs for more time | 16:47 |
daemontool_ | I agree | 16:47 |
daemontool_ | #agreed | 16:47 |
m3m0 | next topic | 16:48 |
m3m0 | #topic free4all | 16:48 |
daemontool_ | m3m0, please make sure the meeting notes are recorderd in freezer_meetings in launchpad | 16:49 |
m3m0 | does anyone has something to say unrelated to pbr and stable/kilo | 16:49 |
m3m0 | I will | 16:49 |
daemontool_ | yes | 16:49 |
daemontool_ | we need to define when we'll branch stable/kilo | 16:49 |
daemontool_ | so Jokke_ was pointing me to https://wiki.openstack.org/wiki/Mitaka_Release_Schedule | 16:50 |
daemontool_ | December 1-3 will be the first release milestone of Mitaka | 16:50 |
daemontool_ | if we want to match that | 16:50 |
daemontool_ | we need to branch stable/kilo | 16:50 |
daemontool_ | before that date | 16:50 |
daemontool_ | in order to do that, I think we need to do the following: | 16:51 |
daemontool_ | - parallel | 16:51 |
m3m0 | in that case we have to do the same for liberty but our times doesn't match | 16:51 |
daemontool_ | - all these bugs fixed | 16:51 |
daemontool_ | - most probably we need to move freezer-api to testr | 16:52 |
daemontool_ | - enable as voting the dvsm gate jobs on the 3 repos | 16:52 |
daemontool_ | question is: can we make all of this happen by Fri next week? | 16:52 |
daemontool_ | 27th? | 16:52 |
m3m0 | reldan, vannif? | 16:53 |
Slashme | daemontool_: You mean stable/liberty ? | 16:53 |
daemontool_ | anyone disagree with the previous items? | 16:53 |
daemontool_ | yes | 16:53 |
daemontool_ | yes sorry | 16:53 |
daemontool_ | stable/liberty | 16:53 |
reldan | daemontool_: I hope so. But you know this week we had 1) Broken test by pytest 2) Broken gerrit | 16:53 |
daemontool_ | so | 16:54 |
vannif | we should | 16:54 |
daemontool_ | I think we can make happen all the items | 16:54 |
daemontool_ | the only one is parallel | 16:54 |
daemontool_ | reldan, can we do that? | 16:54 |
m3m0 | and then release stable/liberty next friday? | 16:54 |
daemontool_ | yes | 16:54 |
daemontool_ | Mon 30th | 16:55 |
daemontool_ | or next Fri if all looks good | 16:55 |
daemontool_ | no later Mon 30th | 16:55 |
m3m0 | so 3 weeks before the previous agreement? | 16:55 |
daemontool_ | the hos 2.1 release and upstream stable/liberty branch | 16:55 |
daemontool_ | doesn't have to happen on the same time | 16:55 |
reldan | I hope so, now I’m testing it. But now we have storage and container in metadata. And actually it wasn’t in my plan to adopt it for parallel backup | 16:56 |
daemontool_ | we can have the features ready | 16:56 |
daemontool_ | and branch | 16:56 |
daemontool_ | then work on patches, bugs and fixes | 16:56 |
reldan | And I actually have no idea what I should return for metadata for several storages | 16:56 |
daemontool_ | reldan, ok that's a blocker | 16:56 |
reldan | I can return None for example | 16:57 |
daemontool_ | now we are running out of time | 16:57 |
reldan | And then we define it | 16:57 |
m3m0 | do you want to have a separate meeting for this? reldan? | 16:57 |
daemontool_ | let's do a meeting tomorrow | 16:57 |
Jokke_ | daemontool_: stable/liberto brnached you mean? | 16:57 |
reldan | I suppose meeting is too much | 16:57 |
daemontool_ | Jokke_, yes | 16:57 |
reldan | We can have None, we can have a list of strings | 16:57 |
Jokke_ | daemontool_: and remember you can backport bugfixes, you can't travel in time :P | 16:57 |
daemontool_ | Jokke_, yes :) | 16:58 |
reldan | Oh, no | 16:58 |
m3m0 | but I need to know the structure in order to integrate it with the ui | 16:58 |
reldan | We have ssh-username as well :) | 16:58 |
daemontool_ | we have two options: | 16:58 |
daemontool_ | 1) we miss mitaka-1 milestone and we have more time | 16:58 |
daemontool_ | 2) we send the code in and branch stable liberty and then solve the bugs | 16:59 |
daemontool_ | if we need to add a data structure internally it's not a big deal, not a new feature | 16:59 |
daemontool_ | reldan, can we release in liberty parallel with limited features? | 17:00 |
m3m0 | we are running out of time | 17:00 |
reldan | Sure. I don’t know what to do with new metadata | 17:00 |
daemontool_ | ok | 17:00 |
reldan | But I can just skip these field | 17:00 |
reldan | fields | 17:00 |
daemontool_ | ok let's talk about this tomorrow | 17:00 |
daemontool_ | new meeting | 17:00 |
m3m0 | thanks to everyone | 17:01 |
reldan | I actually hate our metadata | 17:01 |
reldan | completelly | 17:01 |
m3m0 | #endmeeting | 17:01 |
openstack | Meeting ended Thu Nov 19 17:01:35 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack_freezer_19_11_2015/2015/openstack_freezer_19_11_2015.2015-11-19-16.00.html | 17:01 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_freezer_19_11_2015/2015/openstack_freezer_19_11_2015.2015-11-19-16.00.txt | 17:01 |
openstack | Log: http://eavesdrop.openstack.org/meetings/openstack_freezer_19_11_2015/2015/openstack_freezer_19_11_2015.2015-11-19-16.00.log.html | 17:01 |
daemontool_ | lol | 17:01 |
Jokke_ | daemontool_: remember database schema changes are big nono as stable backport (not sure if it affects you, just saying) | 17:01 |
m3m0 | why? | 17:01 |
daemontool_ | Jokke_, it's not a db schema change | 17:02 |
daemontool_ | we need to define how to represent things in the config file | 17:02 |
reldan | Because we have cli it produces some dictionary, then we add additional fields from default and from config, then during the work we are changing this dictionary | 17:02 |
daemontool_ | so once it's defined and the structure is defined | 17:02 |
Jokke_ | incompatible config file changes are no-no as well :P | 17:02 |
daemontool_ | Jokke_, I agree | 17:03 |
daemontool_ | this is a config file extension | 17:03 |
daemontool_ | like multiple sections | 17:03 |
reldan | Very unpredictable way backup_opt_dict.lvm_volgroup = lvm_info['volgroup'] | 17:03 |
daemontool_ | of one section that already exists | 17:03 |
daemontool_ | anyway | 17:03 |
reldan | And then we create metadata from the same dict | 17:03 |
daemontool_ | there are details that I dont' know | 17:03 |
daemontool_ | so the let's have a meeting tomorrow to discuss that | 17:04 |
reldan | we are doing even something like this backup_opt_dict.mysql_db_inst.commit() . That means that we are using our config like a communication protocol between our methods | 17:05 |
daemontool_ | that's a pymysql module method | 17:06 |
daemontool_ | reldan, let's solve one problem at the time | 17:06 |
daemontool_ | we can't solve everything now | 17:07 |
daemontool_ | I think we can have a metadata change in mitaka | 17:07 |
daemontool_ | without any problem | 17:07 |
reldan | Sure, but it was very strange to get this problem for parallel backup | 17:07 |
daemontool_ | ok | 17:08 |
daemontool_ | we can move the parallel backup to mitaka if we need to have more time | 17:09 |
daemontool_ | and branch liberty without parallel backup | 17:09 |
daemontool_ | so we can do the parallel on mitaka with the metadata changed | 17:09 |
daemontool_ | reldan, let me know there are multiple ways we can approach this if we need to implement major changes in order to have the parallel feature | 17:10 |
daemontool_ | let's talk about this tomorrow | 17:11 |
reldan | Ok, daemontool_ please merget it https://review.openstack.org/#/c/247518/ | 17:22 |
reldan | And I will send cherry-pick to stable/kilo | 17:22 |
daemontool_ | ok rember also to bump the version | 17:22 |
*** daemontool_ has quit IRC | 17:44 | |
*** daemontool_ has joined #openstack-freezer | 17:44 | |
daemontool_ | all, to backport bugs on stable/* please refer to: https://wiki.openstack.org/wiki/StableBranch | 18:01 |
*** reldan has quit IRC | 18:06 | |
daemontool_ | Slashme, m3m0 https://bugs.launchpad.net/pbr/+bug/1341341 | 18:18 |
openstack | Launchpad bug 1341341 in PBR "python setup.py install doesn't install requirements that are also setup_requires." [High,Fix released] | 18:18 |
daemontool_ | I don't understand what's the fix tho | 18:23 |
daemontool_ | lol | 18:23 |
ffresh | Salkazzo3 | 18:28 |
daemontool_ | ffresh, hahhaa | 18:32 |
daemontool_ | :D | 18:32 |
daemontool_ | lol | 18:32 |
*** jonaspf has quit IRC | 18:34 | |
*** jonaspf has joined #openstack-freezer | 18:35 | |
*** reldan has joined #openstack-freezer | 18:46 | |
*** jonaspf has quit IRC | 18:49 | |
*** arun has joined #openstack-freezer | 18:58 | |
*** arun is now known as Guest48450 | 18:58 | |
*** Guest48450 is now known as arunb | 18:59 | |
*** reldan has quit IRC | 19:41 | |
*** openstackgerrit has quit IRC | 19:46 | |
*** openstackgerrit has joined #openstack-freezer | 19:47 | |
*** arunb has quit IRC | 20:05 | |
*** daemontool_ has quit IRC | 21:41 | |
*** daemontool_ has joined #openstack-freezer | 21:42 | |
*** reldan has joined #openstack-freezer | 22:05 | |
*** reldan has quit IRC | 22:10 | |
*** reldan has joined #openstack-freezer | 22:15 | |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix metadata storage https://review.openstack.org/247518 | 23:40 |
openstackgerrit | Eldar Nugaev proposed openstack/freezer: temporary log https://review.openstack.org/247840 | 23:40 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!