Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment
Hisashi Osanai, yes, that is blocking the Ceilometer gate at all for now.
The reason might be in updated centos6 image in the gate, but I have no
opportunity to check it actually.
Infra folks, can you help us?
Thanks,
Dina
On Tue, Aug 12, 2014 at 1:47 PM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:
>
> Hi,
>
> I got an error message when Jenkins executed "tox -epy26" in the following
> fix.
> https://review.openstack.org/#/c/112771/
>
> I think that the reason of the error message is a mongod isn't installed
> in test
> environment. (it works in my test env)
>
> Do you have any idea to solve this?
>
> - setup-test-env.sh
> 16 export PATH=${PATH:+$PATH:}/sbin:/usr/sbin
> 17 if ! which mongod >/dev/null 2>&1
> 18 then
> 19 echo "Could not find mongod command" 1>&2
> 20 exit 1
> 21 fi
>
> - console.log
> 2014-08-12 07:25:03.329 | + tox -epy26
> 2014-08-12 07:25:03.542 | py26 create:
> /home/jenkins/workspace/gate-ceilometer-python26/.tox/py26
> 2014-08-12 07:25:05.255 | py26 installdeps:
> -r/home/jenkins/workspace/gate-ceilometer-python26/requirements.txt,
> -r/home/jenkins/workspace/gate-ceilometer-python26/test-requirements.txt
> 2014-08-12 07:28:01.581 | py26 develop-inst:
> /home/jenkins/workspace/gate-ceilometer-python26
> 2014-08-12 07:28:07.861 | py26 runtests: commands[0] | bash -x
> /home/jenkins/workspace/gate-ceilometer-python26/setup-test-env.sh python
> setup.py testr --slowest --testr-args=
> 2014-08-12 07:28:07.864 | + set -e
> 2014-08-12 07:28:07.865 | ++ mktemp -d CEILO-MONGODB-X
> 2014-08-12 07:28:07.866 | + MONGO_DATA=CEILO-MONGODB-t6f5p
> 2014-08-12 07:28:07.866 | + MONGO_PORT=29000
> 2014-08-12 07:28:07.866 | + trap clean_exit EXIT
> 2014-08-12 07:28:07.867 | + mkfifo CEILO-MONGODB-t6f5p/out
> 2014-08-12 07:28:07.868 | + export
> PATH=/home/jenkins/workspace/gate-ceilometer-python26/.tox/py26/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin
> 2014-08-12 07:28:07.869 | +
> PATH=/home/jenkins/workspace/gate-ceilometer-python26/.tox/py26/bin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin
> 2014-08-12 07:28:07.869 | + which mongod
> 2014-08-12 07:28:07.870 | + echo 'Could not find mongod command'
> 2014-08-12 07:28:07.870 | Could not find mongod command
> 2014-08-12 07:28:07.871 | + exit 1
> 2014-08-12 07:28:07.871 | + clean_exit
> 2014-08-12 07:28:07.872 | + local error_code=1
> 2014-08-12 07:28:07.872 | + rm -rf CEILO-MONGODB-t6f5p
> 2014-08-12 07:28:07.873 | ++ jobs -p
> 2014-08-12 07:28:07.873 | + kill
> 2014-08-12 07:28:07.874 | kill: usage: kill [-s sigspec | -n signum |
> -sigspec] pid | jobspec ... or kill -l [sigspec]
> 2014-08-12 07:28:07.875 | ERROR: InvocationError: '/bin/bash -x
> /home/jenkins/workspace/gate-ceilometer-python26/setup-test-env.sh python
> setup.py testr --slowest --testr-args='
>
> Best Regards,
> Hisashi Osanai
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Best regards,
Dina Belova
Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] tox -epy26 failed because of insufficient test environment
Folks, it looks like mongo packages were retired as a result of this ticket: https://fedorahosted.org/rel-eng/ticket/5963 Although also it looks like this mistake was quickly reverted here: http://pkgs.fedoraproject.org/cgit/mongodb.git/commit/?h=el6 Let's wait if it fixed the issue, but it looks like it should be ok for now. Thanks, Dina On Tue, Aug 12, 2014 at 2:23 PM, Osanai, Hisashi < osanai.hisa...@jp.fujitsu.com> wrote: > > On Tuesday, August 12, 2014 7:05 PM, Dina Belova wrote: > > that is blocking the Ceilometer gate at all for now. > > Thank you for your quick response. > I understand current situation. > > Thanks again! > Hisashi Osanai > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase
Hisashi Osanai, I have really strange feeling about this issue. It happens only with py33 job for icehouse branch? Because actually happy base is the same for the master code Jenkins jobs, so it looks like that exec file issue should appear in master runs as well... Do I understand everything right? As I understand Julien, he proposes to run this job only for master (as it works for now magically for master checks) and skip in for everything earlier - mostly because it won't work for stable branches anyway - as there were no fixed ceilometer code itself there. Thanks, Dina On Wed, Aug 13, 2014 at 2:11 PM, Osanai, Hisashi < osanai.hisa...@jp.fujitsu.com> wrote: > > On Wednesday, August 13, 2014 5:03 PM, Julien Danjou wrote: > > This is not a problem in tox.ini, this is a problem in the > > infrastructure config. Removing py33 from the envlist in tox.ini isn't > > going to fix anything unforunately. > > Thank you for your quick response. > > I may misunderstand this topic. Let me clarify ... > My understanding is: > - the py33 failed because there is a problem that the happybase-0.8 cannot > work with python33 env. (execfile function calls on python33 doesn't > work) > - the happybase is NOT an OpenStack component. > - the py33 doesn't need to execute on stable/icehouse > > One idea to solve this problem is: > If the py33 doesn't need to execute on stable/icehouse, just eliminate the > py33. > > > This is not a problem in tox.ini, > Means the py33 needs to execute on stable/icehouse. Here I misunderstand > something... > > > this is a problem in the infrastructure config. > Means execfile function calls on python33 in happybase is a problem. If my > understanding > is correct, I agree with you and I think this is the direct cause of this > problem. > > Your idea to solve this is creating a patch for the direct cause, right? > > Thanks in advance, > Hisashi Osanai > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase
Julien, will do right now. Thanks Dina On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou wrote: > On Wed, Aug 13 2014, Osanai, Hisashi wrote: > > > One idea to solve this problem is: > > If the py33 doesn't need to execute on stable/icehouse, just eliminate > > the py33. > > Yes, that IS the solution. > > But modifying tox.ini is not going be a working implementation of that > solution. > > >> This is not a problem in tox.ini, > > Means the py33 needs to execute on stable/icehouse. Here I misunderstand > something... > > Not it does not, that line in tox.ini is not use by the gate. > > >> this is a problem in the infrastructure config. > > Means execfile function calls on python33 in happybase is a problem. If > my understanding > > is correct, I agree with you and I think this is the direct cause of > this problem. > > > > Your idea to solve this is creating a patch for the direct cause, right? > > My idea to solve this is to create a patch on > http://git.openstack.org/cgit/openstack-infra/config/ > to exclude py33 on the stable/icehouse branch of Ceilometer in the gate. > > -- > Julien Danjou > # Free Software hacker > # http://julien.danjou.info > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase
Here it is: https://review.openstack.org/#/c/113842/ Thanks, Dina On Wed, Aug 13, 2014 at 2:40 PM, Dina Belova wrote: > Julien, will do right now. > > Thanks > Dina > > > On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou wrote: > >> On Wed, Aug 13 2014, Osanai, Hisashi wrote: >> >> > One idea to solve this problem is: >> > If the py33 doesn't need to execute on stable/icehouse, just eliminate >> > the py33. >> >> Yes, that IS the solution. >> >> But modifying tox.ini is not going be a working implementation of that >> solution. >> >> >> This is not a problem in tox.ini, >> > Means the py33 needs to execute on stable/icehouse. Here I >> misunderstand something... >> >> Not it does not, that line in tox.ini is not use by the gate. >> >> >> this is a problem in the infrastructure config. >> > Means execfile function calls on python33 in happybase is a problem. If >> my understanding >> > is correct, I agree with you and I think this is the direct cause of >> this problem. >> > >> > Your idea to solve this is creating a patch for the direct cause, right? >> >> My idea to solve this is to create a patch on >> http://git.openstack.org/cgit/openstack-infra/config/ >> to exclude py33 on the stable/icehouse branch of Ceilometer in the gate. >> >> -- >> Julien Danjou >> # Free Software hacker >> # http://julien.danjou.info >> >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase
Hisashi Osanai, np :) You're welcome :) On Thu, Aug 14, 2014 at 5:13 AM, Osanai, Hisashi < osanai.hisa...@jp.fujitsu.com> wrote: > > On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou wrote: > >> Means the py33 needs to execute on stable/icehouse. Here I > misunderstand something... > > Not it does not, that line in tox.ini is not use by the gate. > > >>> this is a problem in the infrastructure config. > >> Means execfile function calls on python33 in happybase is a problem. If > my understanding > >> is correct, I agree with you and I think this is the direct cause of > this problem. > >> > >> Your idea to solve this is creating a patch for the direct cause, right? > > My idea to solve this is to create a patch on > > http://git.openstack.org/cgit/openstack-infra/config/ > > to exclude py33 on the stable/icehouse branch of Ceilometer in the gate. > > Sorry to use your time for explanation above again and thanks for it. I'm > happy to have > clear understanding your thought. > > On Wednesday, August 13, 2014 7:54 PM, Dina Belova wrote: > > Here it is: https://review.openstack.org/#/c/113842/ > Thank you for providing the fix. I surprised the speed for it. it's really > fast... > > Thanks again! > Hisashi Osanai > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically because of wsme autodoc extension
Gordon, exactly. Moreover, I think percentage of failings is something close to the 15-20% of all the runs - sometimes it passes for the change, and next run on this exactly the same commit will be the failed for some reason. Thanks Dina On Thu, Aug 21, 2014 at 10:46 PM, gordon chung wrote: > is it possible that it's not on all the nodes? > > seems like it passed here: https://review.openstack.org/#/c/109207/ but > another patch at roughly the same time failed > https://review.openstack.org/#/c/113549/ > > cheers, > *gord* > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer]How to collect the real-time data
Jian, hello What do you actually mean by 'real-time data'? Here in Ceilometer we're having 'events' feature, for instance - so services like Nova, Cinder, etc. are notifying Ceilometer about recent changes like 'VM was created', 'IP was assigned', etc. - this data is more than recent one. May you provide us with kind of use case or example, whatever do you mean by 'real-time data'? Cheers, Dina On Tue, Sep 9, 2014 at 3:45 PM, lijian wrote: > Hi folks, > We know the ceilometer collect the data through poster periodically. > But how to collect the real-time data? whether plan to implement it > or not > > Thanks! > Jian Li > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core
Thank you folks, it's a big pleasure and responsibility, and I'm really happy to join you :) Thanks! Dina On Fri, Sep 19, 2014 at 12:54 PM, Eoghan Glynn wrote: > > > > Hi, > > > > Dina has been doing a great work and has been very helpful during the > > Juno cycle and her help is very valuable. She's been doing a lot of > > reviews and has been very active in our community. > > > > I'd like to propose that we add Dina Belova to the ceilometer-core > > group, as I'm convinced it'll help the project. > > > > Please, dear ceilometer-core members, reply with your votes! > > With seven yeas and zero nays, I think we can call a result in this > vote. > > Welcome to the ceilometer-core team Dina! > > Cheers, > Eoghan > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] How we agree to determine that an user has admin rights ?
I suppose it's ok - just rebase from Swann's commit to have is_admin param to use. On Wed, Nov 20, 2013 at 3:21 PM, Sylvain Bauza wrote: > Hi Yuriy, > > Le 20/11/2013 11:56, Yuriy Taraday a écrit : > > Looking at implementations in Keystone and Nova, I found the only use > for is_admin but it is essential. > > Whenever in code you need to run a piece of code with admin privileges, > you can create a new context with is_admin=True keeping all other > parameters as is, run code requiring admin access and then revert context > back. > My first though was: "Hey, why don't they just add 'admin' role then?". > But what if in current deployment admin role is named like > 'TheVerySpecialAdmin'? What if user has tweaked policy.json to better suite > one's needs? > > So my current understanding is (and I suggest to follow this logic): > - 'admin' role in context.roles can vary, it's up to cloud admin to set > necessary value in policy.json; > - 'is_admin' flag is used to elevate privileges from code and it's name is > fixed; > - policy check should assume that user is admin if either special role is > present or is_admin flag is set. > > > > Yes indeed, that's something coming into my mind. Looking at Nova, I found > a "context_is_admin" policy in policy.json allowing you to say which role > is admin or not [1] and is matched in policy.py [2], which itself is called > when creating a context [3]. > > I'm OK copying that, any objections to it ? > > > [1] https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L2 > [2] https://github.com/openstack/nova/blob/master/nova/policy.py#L116 > [3] https://github.com/openstack/nova/blob/master/nova/context.py#L102 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks everybody who joined us on our Climate weekly meeting. Here are logs/minutes from it: Minutes: http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-02-10.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-02-10.02.txt Log: http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-02-10.02.log.html -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] IRC meeting reschedule exceptionnally today
I think it's ok, but not more than a half of hour On Monday, December 9, 2013, Sylvain Bauza wrote: > Hi Dina, > Forwarding your request to openstack-dev@ as everyone needs to be aware > of that. > > Which time do you propose for meeting us today ? On my side, I'll be > travelling tomorrow and the day after, I'll be out of office with limited > access, so we need to sync up today. > I can propose 2000 UTC today, but that's very late for you :/ > > -Sylvain > > Le 09/12/2013 07:10, Dina Belova a écrit : > > Sylvin, > > Sergey and I have no opportunity to be today on meeting. > > What do you think about moving it to the evening (in #climate channel) > to have a full quorum? > > Thank you. > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] IRC meeting reschedule exceptionnally today
Ok, we'll discuss :) On Monday, December 9, 2013, Sylvain Bauza wrote: > Well, I wouldn't say more, I also have family concerns ;-) > > I will prepare the meeting by checking all individual actions, so I will > only raise the left ones. > Hooks clarification can be postponed to the next meeting or discussed > directly on chan. > > I saw you made a first pass on triaging blueprints for 0.1. Some are good, > some need to be discussed, IMHO. For example, not having policies in > Climate sounds a showstopper to me. > > -Sylvain > > Le 09/12/2013 10:38, Dina Belova a écrit : > > I think it's ok, but not more than a half of hour > > On Monday, December 9, 2013, Sylvain Bauza wrote: > >> Hi Dina, >> Forwarding your request to openstack-dev@ as everyone needs to be aware >> of that. >> >> Which time do you propose for meeting us today ? On my side, I'll be >> travelling tomorrow and the day after, I'll be out of office with limited >> access, so we need to sync up today. >> I can propose 2000 UTC today, but that's very late for you :/ >> >> -Sylvain >> >> Le 09/12/2013 07:10, Dina Belova a écrit : >> >> Sylvin, >> >> Sergey and I have no opportunity to be today on meeting. >> >> What do you think about moving it to the evening (in #climate channel) >> to have a full quorum? >> >> Thank you. >> >> -- >> >> Best regards, >> >> Dina Belova >> >> Software Engineer >> >> Mirantis Inc. >> >> >> > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] Weekly meeting accidental moving to Tuesday, 10:00 UTC
Hello! Guys, I have no opportunity to hold our IRC meeting today. I propose to move it tomorrow, the same time. Please let me know if you are OK with that. Thank you! Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a time-based resource management system
Hi, Alan! I'm really glad you have mentioned that problem, that was not really covered by OpenStack projects for much time. Our (Climate) team is working on implementing Reservation-as-a-Service. As I understand, you are interested in reserving (managing) virtual resources on a time-based criteria. We are going to have 0.1 release asap (we hope to make code freeze next week). You are welcome to join our IRC channel and participate in our weekly meetings. P.S. btw, we have it today, 10:00 UTC (usually we hold them on Mondays, but that's emergency case). P.P.S. would be nice to see you on it :) Thanks! On Tue, Dec 17, 2013 at 12:16 PM, Nikolay Starodubtsev < nstarodubt...@mirantis.com> wrote: > Hi all > I've looked at the wiki page and now I can say that Cafe have an overlap > with Climate. Feel free to contact us at #openstack-climate. Also, please > take a look at our patches on review.openstack.org: > https://review.openstack.org/#/q/status:open+project:stackforge/climate,n,z > > > > Nikolay Starodubtsev > > Software Engineer > > Mirantis Inc. > > > Skype: dark_harlequine1 > > > 2013/12/17 Tim Bell > >> There appears to be some overlap of this proposal with ‘climate’ which >> provides a resource reservation system. >> >> >> >> They meet regularly … see >> https://wiki.openstack.org/wiki/Meetings/Climate for contacts. >> >> >> >> Tim >> >> >> >> *From:* Alan Tan [mailto:y...@students.waikato.ac.nz] >> *Sent:* 16 December 2013 23:42 >> >> *To:* openstack-dev@lists.openstack.org >> *Subject:* [openstack-dev] a time-based resource management system >> >> >> >> Hi everyone, >> >> >> >> My name is Alan and I am from the Cyber Security Lab in University of >> Waikato. >> >> >> >> We have recently started deploying and using Openstack in our >> experimental private cloud testbed. The cloud testbed is mainly used in >> running our research and teaching purposes. However, we notice that current >> Openstack lacks the ability to control and manage user’s access to >> resources in a time-based manner. >> >> >> >> I.e. Current model for private clouds requires either the user to release >> their resources (VMs) voluntarily or for the administrators to manually >> remove the resources (VMs). >> >> >> >> This makes capacity management a laborious effort in private clouds that >> have a large user base. Hence, we have come up with the idea of an >> automatic time-based resource management system that manages user access to >> resources in a time slot booking style. We have detailed our plans and >> design in the following wiki page. We would love to hear feedbacks from the >> community and hopefully gather some interest in our project. >> >> >> >> https://wiki.openstack.org/wiki/Cafe >> >> >> >> We look forward to hearing from you. We can be contacted via email. Our >> addresses are listed on the wiki page. >> >> >> >> Thanks and have a good day. >> >> >> >> Cheers, >> >> Alan >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] a time-based resource management system
Sorry, forgot to add a link to our Launchpad: https://launchpad.net/climate Thanks! On Tue, Dec 17, 2013 at 12:27 PM, Dina Belova wrote: > Hi, Alan! > > I'm really glad you have mentioned that problem, that was not really > covered by OpenStack projects for much time. Our (Climate) team is working > on implementing Reservation-as-a-Service. As I understand, you are > interested in reserving (managing) virtual resources on a time-based > criteria. We are going to have 0.1 release asap (we hope to make code > freeze next week). > > You are welcome to join our IRC channel and participate in our weekly > meetings. > > P.S. btw, we have it today, 10:00 UTC (usually we hold them on Mondays, > but that's emergency case). > P.P.S. would be nice to see you on it :) > > Thanks! > > > On Tue, Dec 17, 2013 at 12:16 PM, Nikolay Starodubtsev < > nstarodubt...@mirantis.com> wrote: > >> Hi all >> I've looked at the wiki page and now I can say that Cafe have an overlap >> with Climate. Feel free to contact us at #openstack-climate. Also, please >> take a look at our patches on review.openstack.org: >> >> https://review.openstack.org/#/q/status:open+project:stackforge/climate,n,z >> >> >> >> Nikolay Starodubtsev >> >> Software Engineer >> >> Mirantis Inc. >> >> >> Skype: dark_harlequine1 >> >> >> 2013/12/17 Tim Bell >> >>> There appears to be some overlap of this proposal with ‘climate’ >>> which provides a resource reservation system. >>> >>> >>> >>> They meet regularly … see >>> https://wiki.openstack.org/wiki/Meetings/Climate for contacts. >>> >>> >>> >>> Tim >>> >>> >>> >>> *From:* Alan Tan [mailto:y...@students.waikato.ac.nz] >>> *Sent:* 16 December 2013 23:42 >>> >>> *To:* openstack-dev@lists.openstack.org >>> *Subject:* [openstack-dev] a time-based resource management system >>> >>> >>> >>> Hi everyone, >>> >>> >>> >>> My name is Alan and I am from the Cyber Security Lab in University of >>> Waikato. >>> >>> >>> >>> We have recently started deploying and using Openstack in our >>> experimental private cloud testbed. The cloud testbed is mainly used in >>> running our research and teaching purposes. However, we notice that current >>> Openstack lacks the ability to control and manage user’s access to >>> resources in a time-based manner. >>> >>> >>> >>> I.e. Current model for private clouds requires either the user to >>> release their resources (VMs) voluntarily or for the administrators to >>> manually remove the resources (VMs). >>> >>> >>> >>> This makes capacity management a laborious effort in private clouds that >>> have a large user base. Hence, we have come up with the idea of an >>> automatic time-based resource management system that manages user access to >>> resources in a time slot booking style. We have detailed our plans and >>> design in the following wiki page. We would love to hear feedbacks from the >>> community and hopefully gather some interest in our project. >>> >>> >>> >>> https://wiki.openstack.org/wiki/Cafe >>> >>> >>> >>> We look forward to hearing from you. We can be contacted via email. Our >>> addresses are listed on the wiki page. >>> >>> >>> >>> Thanks and have a good day. >>> >>> >>> >>> Cheers, >>> >>> Alan >>> >>> >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OS::Metering::Alarm?
RACE root File
> "/usr/lib/python2.7/dist-packages/heat/engine/resource.py", line 45, in
> get_class
>
> 2013-12-17 09:51:30.268 3341 TRACE root return
> resources.global_env().get_class(resource_type, resource_name)
>
> 2013-12-17 09:51:30.268 3341 TRACE root
>
> 2013-12-17 09:51:30.268 3341 TRACE root File
> "/usr/lib/python2.7/dist-packages/heat/engine/environment.py", line 326, in
> get_class
>
> 2013-12-17 09:51:30.268 3341 TRACE root return
> self.registry.get_class(resource_type, resource_name)
>
> 2013-12-17 09:51:30.268 3341 TRACE root
>
> 2013-12-17 09:51:30.268 3341 TRACE root File
> "/usr/lib/python2.7/dist-packages/heat/engine/environment.py", line 257, in
> get_class
>
> 2013-12-17 09:51:30.268 3341 TRACE root raise
> exception.StackValidationFailed(message=msg)
>
> 2013-12-17 09:51:30.268 3341 TRACE root
>
> 2013-12-17 09:51:30.268 3341 TRACE root StackValidationFailed: Unknown
> resource Type : OS::Metering::Alarm
>
> 2013-12-17 09:51:30.268 3341 TRACE root
>
> 2013-12-17 09:51:30.268 3341 TRACE root
>
> 2013-12-17 09:51:30.269 3341 DEBUG root [-] JSON response :
> {"explanation": "The server could not comply with the request since it is
> either malformed or otherwise incorrect.", "code": 400, "error":
> {"message": "Unknown resource Type : OS::Metering::Alarm", "traceback":
> "Traceback (most recent call last):\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/amqp.py\",
> line 461, in _process_data\n**args)\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/dispatcher.py\",
> line 172, in dispatch\nresult = getattr(proxyobj, method)(ctxt,
> **kwargs)\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/engine/service.py\", line 60, in
> wrapped\nreturn func(self, ctx, *args, **kwargs)\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/engine/service.py\", line 364, in
> validate_template\nResourceClass = resource.get_class(res['Type'])\n\n
> File \"/usr/lib/python2.7/dist-packages/heat/engine/resource.py\", line 45,
> in get_class\nreturn resources.global_env().get_class(resource_type,
> resource_name)\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/engine/environment.py\", line 326,
> in get_class\nreturn self.registry.get_class(resource_type,
> resource_name)\n\n File
> \"/usr/lib/python2.7/dist-packages/heat/engine/environment.py\", line 257,
> in get_class\nraise
> exception.StackValidationFailed(message=msg)\n\nStackValidationFailed:
> Unknown resource Type : OS::Metering::Alarm\n", "type":
> "StackValidationFailed"}, "title": "Bad Request"} to_json
> /usr/lib/python2.7/dist-packages/heat/common/wsgi.py:562
>
>
> Execption. I compared the on premise installation to my local devstack
> vm (where the template is accepted) and are unable to find the big
> difference in configuration. Where is the correct point to debug this
> thing? I also found no documentation which helps in this situation. :(
>
>
> And I also have to present recent things around openstack on our
> university tomorrow – for which I would be happy to get this
> (rudimentarily) working. :)
>
>
> Thanks.
>
>Sebastian
>
> --
> Sebastian Porombka, M.Sc.
> Zentrum für Informations- und Medientechnologien (IMT)
> Universität Paderborn
>
> E-Mail: porom...@uni-paderborn.de
> Tel.: 05251/60-5999
> Fax: 05251/60-48-5999
> Raum: N5.314
>
>
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> Please consider the environment before printing this email.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Best regards,
Dina Belova
Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OS::Metering::Alarm?
Sebastian, you are welcome :) On Tue, Dec 17, 2013 at 1:30 PM, Sebastian Porombka < porom...@uni-paderborn.de> wrote: > Hi Dina, hi developers. > > Thanks for the very very helpful hint. > > The problem issuing this exception is the lack of > /etc/heat/environment.d/default.yaml in the ubuntu cloud reposity packages. > > root@head2:# cd /etc/heat/ > > root@head2:/etc/heat# ls -alh environment.d/ > > total 12K > > drwxr-xr-x 2 heat heat 4.0K Dec 17 10:25 *.* > > drwxr-xr-x 3 heat heat 4.0K Dec 17 10:25 *..* > > -rw-rw-r-- 1 heat heat 436 Dec 17 10:25 default.yaml > > root@head2:/etc/heat# cat environment.d/default.yaml > > > resource_registry: > > # allow older templates with Quantum in them. > > "OS::Quantum*": "OS::Neutron*" > > # Choose your implementation of AWS::CloudWatch::Alarm > > #"AWS::CloudWatch::Alarm": > "file:///etc/heat/templates/AWS_CloudWatch_Alarm.yaml" > > "AWS::CloudWatch::Alarm": "OS::Heat::CWLiteAlarm" > > "OS::Metering::Alarm": "OS::Ceilometer::Alarm" > > "AWS::RDS::DBInstance": > "file:///etc/heat/templates/AWS_RDS_DBInstance.yaml" > > root@head2:/etc/heat# > > Big thanks. > Sebastian > > -- > Sebastian Porombka, M.Sc. > Zentrum für Informations- und Medientechnologien (IMT) > Universität Paderborn > > E-Mail: porom...@uni-paderborn.de > Tel.: 05251/60-5999 > Fax: 05251/60-48-5999 > Raum: N5.314 > > > Q: Why is this email five sentences or less? > A: http://five.sentenc.es > > Please consider the environment before printing this email. > > Von: Dina Belova > Antworten an: "OpenStack Development Mailing List (not for usage > questions)" > Datum: Dienstag, 17. Dezember 2013 10:08 > An: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Betreff: Re: [openstack-dev] OS::Metering::Alarm? > > As I see on > http://docs.openstack.org/developer/heat/template_guide/openstack.html, > there is type OS::Ceilometer::Alarm, not OS::Metering::Alarm... Maybe > it's somehow connected with your problem? > > > On Tue, Dec 17, 2013 at 12:59 PM, Sebastian Porombka < > porom...@uni-paderborn.de> wrote: > >> Hi Folks. >> >> I’m currently trying to understand the openstack mechanics in detail >> (e.g. to fix various ec2 api shortcomings) and reached heat. I tried to add >> heat to our on-premise installation and failed to try the >> ‚AutoScalingCeilometer.yaml‘ demo template. Heat-api throwed a >> >> ==> /var/log/upstart/heat-api.log <== >> >> 2013-12-17 09:51:30.268 3341 ERROR root [-] Unexpected error occurred >> serving API: Unknown resource Type : OS::Metering::Alarm >> >> 2013-12-17 09:51:30.268 3341 TRACE root Traceback (most recent call last): >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/common/wsgi.py", line 661, in >> __call__ >> >> 2013-12-17 09:51:30.268 3341 TRACE root request, **action_args) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/common/wsgi.py", line 729, in >> dispatch >> >> 2013-12-17 09:51:30.268 3341 TRACE root return method(*args, **kwargs) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py", line 30, >> in handle_stack_method >> >> 2013-12-17 09:51:30.268 3341 TRACE root return handler(controller, >> req, **kwargs) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py", line >> 314, in validate_template >> >> 2013-12-17 09:51:30.268 3341 TRACE root data.template()) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/rpc/client.py", line 121, in >> validate_template >> >> 2013-12-17 09:51:30.268 3341 TRACE root template=template)) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/openstack/common/rpc/proxy.py", line >> 126, in call >> >> 2013-12-17 09:51:30.268 3341 TRACE root result = rpc.call(context, >> real_topic, msg, timeout) >> >> 2013-12-17 09:51:30.268 3341 TRACE root File >> "/usr/lib/python2.7/dist-packages/heat/openstac
[openstack-dev] [climate] Meeting minutes
Thank everybody who were on our weekly meeting :) Meeting minutes are here: Minutes: http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.txt Log: http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.log.html -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation
Mark, I love that idea. It seems to me nice to have 'projects kindergarten' were every one is blessed because of youth and perspective from the point of OpenStack future, but at the same time it will be some scale of being talented and experienced for these 'children'. It might solve problem of better visibility for new (really good ones!) initiatives, but will make even more huge headache for TC, I suppose... This solution requires permanent observation and going deeper in tones of new ideas... Thanks, Dina On Tuesday, December 17, 2013, Mark McLoughlin wrote: > On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote: > > Mark McLoughlin wrote: > > > How about if we had an "emerging projects" page where the TC feedback > on > > > each project would be listed? > > > > > > That would give visibility to our feedback, without making it a yes/no > > > blessing. Ok, whether to list any feedback about the project on the > page > > > is a yes/no decision, but at least it allows us to fully express why we > > > find the project promising, what people need to help with in order for > > > it to be incubated, etc. > > > > > > With a formal yes/no status, I think we'd struggle with projects which > > > we're not quite ready to even bless with an "emerging" status but we > > > still want to encourage them - this allows us to bless a project as > > > "emerging" but be explicit about our level of support for it. > > > > I agree that being able to express our opinion on a project in shades of > > grey is valuable... The main drawback of using a non-boolean status for > > that is that you can't grant any benefit to it. So we'd not be able to > > say "emerging projects get design summit space". > > > > They can still collaborate in unconference space or around empty tables, > > but then we are back to the problem we are trying to solve: increase > > visibility of promising projects pre-incubation. > > Have an emerging projects track and leave it up to the track coordinator > to decide prioritize the most interesting sessions and the most advanced > projects (according to the TC's feedback) ? > > Mark. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?
I have Christmas holidays till 12th January... So I don't really know I if I will be available 6th Jan. On Thu, Dec 19, 2013 at 4:49 PM, Sylvain Bauza wrote: > Hi team, > > I won't be able to attend the next two weekly meetings (23Dec and 30Dec), > I would like to postpone our meetings till 6th January 2014. > Any objections to this ? > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Next two weekly meetings cancelled ?
+1 On Fri, Dec 20, 2013 at 1:57 PM, Sergey Lukjanov wrote: > +1 for Fridays 1500 UTC > > > On Fri, Dec 20, 2013 at 1:26 PM, Sylvain Bauza wrote: > >> Well, 2000UTC means midnight for you, guys. Not really safe for family >> concerns :-) >> Maybe you were meaning 2000 local time, so 1600 UTC ? >> >> I can propose Fridays 1500 UTC (so 19:00 your time ;-)) as an alternative >> (both meeting channels are free this time) >> >> Let's vote : +1 for Fridays 1500 UTC. >> >> Le 20/12/2013 05:43, Nikolay Starodubtsev a écrit : >> >> I'm on holidays till 9th January. And I don't think I'll have an internet >> access all the time on holidays. >> p.s. By the way, I'll prefer Friday's evenings as new meeting time if it >> is available - it only one day when I don't do my BJJ classes. Or we can >> move to 1900-2000UTC. it looks fine for me. Or move to early Europe morning. >> >> >> >> Nikolay Starodubtsev >> >> Software Engineer >> >> Mirantis Inc. >> >> >> Skype: dark_harlequine1 >> >> >> 2013/12/19 Sylvain Bauza >> >>> Le 19/12/2013 13:57, Dina Belova a écrit : >>> >>> I have Christmas holidays till 12th January... So I don't really know I >>> if I will be available 6th Jan. >>> >>> >>> Oh ok. Who else are still on vacation these times ? >>> We can do our next meeting on 12th Jan, but I'm concerned with the >>> delivery of Climate 0.1 which would be one week after. >>> >>> -Sylvain >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> ___ >> OpenStack-dev mailing >> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] PTL Candidacy
Howdy, guys! I’d like to announce my candidacy for Climate (Reservation-as-a-Service) PTL. I’m working with OpenStack about last two years since Diablo and have much experience in working with different customers within different projects. Last six months I’m everything about community work - since really early ideas of Climate. I proposed idea of global reservation opportunity to the OpenStack - for both virtual and physical resources, not just some of it. I also created architecture proposal for the Climate, that was discussed with our community and on what we agreed the time Climate was a ‘baby’. I’m leading subteam, that is working on implementing virtual reservations opportunity. I took significant participation in core related features that are important for every project - overall structure of DB layer, REST API, base logic for the internal Climate part and plugin mechanism, that allows to implement extensions for every resource type to make them reservable. I’m a top contributor and reviewer for Climate and spend much time on defining its future vectors of development and keeping Climate extensible and relevant to the current OpenStack ecosystem. Now I’m holding our team’s IRC meeting half times to keep our two subteams balanced and presented enough; and manage our Launchpad project to represent every side of it. Also I was the initiator of Climate presentation during OpenStack Icehouse summit in Hong Kong this fall and prepared much materials for it. I have expedience and know about release cycles, release management and other infrastructure specific things. I think, PTL is not only about reviews or code writing, it’s more about presenting project to the outside world. It’s about endless communication both internally with people contributing to Climate and externally to avoid overlaps and conflicts between contributors and Climate with other projects. I believe, PTL should think not only about Climate itself, but about its place in whole OpenStack ecosystem and how it may look like in future. As for Icehouse, as the closest point we should pass, I defined our scope for the first 0.1 Climate release and believe we will have it Jan 2014. Definitely we would like to find the appropriate OpenStack Program (or create a new one) and become incubated within it. Icehouse will be about close integration with other OpenStack projects to support reservation of different resources - not only compute hosts and virtual machines, proposed to our first release, but also volumes, network resources, etc. Finally we would like to propose architecture of integration with Heat and its stacks reservation, as a most complicated virtual resource. Integration with Horizon is also about creation of a better way for our users to communicate with Climate and definitely we hope to propose solution for that. It was a great time when different companies and people decided to unite and create this project with its special role and become a part of great OpenStack community. I believe we’ll do even more in future :) Thanks! Dina - Best regards, Dina Belova Software Engineer Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] PTL Candidacy
Sorry, completely forgot to add some useful links :) My changes: https://review.openstack.org/#/q/owner:dbelova+AND+(project:stackforge/climate+OR+project:stackforge/python-climateclient+OR+project:stackforge/climate-nova),n,z My reviews: https://review.openstack.org/#/q/reviewer:dbelova+AND+(project:stackforge/climate+OR+project:stackforge/python-climateclient+OR+project:stackforge/climate-nova),n,z Thanks! On Sat, Dec 21, 2013 at 1:43 AM, Sergey Lukjanov wrote: > Confirmed. > > https://wiki.openstack.org/wiki/Climate/PTL_Elections_Icehouse#Candidates > > > On Fri, Dec 20, 2013 at 11:01 PM, Dina Belova wrote: > >> Howdy, guys! >> >> I’d like to announce my candidacy for Climate (Reservation-as-a-Service) >> PTL. >> >> I’m working with OpenStack about last two years since Diablo and have >> much experience in working with different customers within different >> projects. Last six months I’m everything about community work - since >> really early ideas of Climate. I proposed idea of global reservation >> opportunity to the OpenStack - for both virtual and physical resources, not >> just some of it. I also created architecture proposal for the Climate, that >> was discussed with our community and on what we agreed the time Climate was >> a ‘baby’. >> >> I’m leading subteam, that is working on implementing virtual reservations >> opportunity. I took significant participation in core related features that >> are important for every project - overall structure of DB layer, REST API, >> base logic for the internal Climate part and plugin mechanism, that allows >> to implement extensions for every resource type to make them reservable. >> I’m a top contributor and reviewer for Climate and spend much time on >> defining its future vectors of development and keeping Climate extensible >> and relevant to the current OpenStack ecosystem. Now I’m holding our team’s >> IRC meeting half times to keep our two subteams balanced and presented >> enough; and manage our Launchpad project to represent every side of it. >> Also I was the initiator of Climate presentation during OpenStack Icehouse >> summit in Hong Kong this fall and prepared much materials for it. I have >> expedience and know about release cycles, release management and other >> infrastructure specific things. >> >> I think, PTL is not only about reviews or code writing, it’s more about >> presenting project to the outside world. It’s about endless communication >> both internally with people contributing to Climate and externally to avoid >> overlaps and conflicts between contributors and Climate with other >> projects. I believe, PTL should think not only about Climate itself, but >> about its place in whole OpenStack ecosystem and how it may look like in >> future. >> >> As for Icehouse, as the closest point we should pass, I defined our scope >> for the first 0.1 Climate release and believe we will have it Jan 2014. >> Definitely we would like to find the appropriate OpenStack Program (or >> create a new one) and become incubated within it. Icehouse will be about >> close integration with other OpenStack projects to support reservation of >> different resources - not only compute hosts and virtual machines, proposed >> to our first release, but also volumes, network resources, etc. Finally we >> would like to propose architecture of integration with Heat and its stacks >> reservation, as a most complicated virtual resource. Integration with >> Horizon is also about creation of a better way for our users to communicate >> with Climate and definitely we hope to propose solution for that. >> >> It was a great time when different companies and people decided to unite >> and create this project with its special role and become a part of great >> OpenStack community. I believe we’ll do even more in future :) >> >> Thanks! >> Dina >> >> - >> >> Best regards, >> >> Dina Belova >> >> Software Engineer >> >> Mirantis Inc >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
group concept here would be appropriate, in >> a way that roles are assigned to groups and people are assigned to the >> groups instead of assigning roles directly to individuals. >> >> - When I say "Quota" what I'm talking about is actually just a number, >> eventually assigned with some unit. It could be a static limit on a >> specific resource like number of VMs or the amount of memory or disk space, >> or it could be something different like computing performance or even >> something like a currency at the longer term >> >> - What is the right place to store such "groups" or "roles" ? What do >> people think ? >> >> We are currently only interested in limit settings for Nova. The >> described ideas could be implemented as part of Nova, or as an entirely >> independent external tool (which might be incorporated later). IMO the >> latter approach has some advantages but I'd like to hear peoples opinion >> about this. >> >> We'll have some man power available to work on the design and the >> implementation of this so I'd expect to see some rapid progress if everbody >> agrees that this is a useful thing to do. >> >> Thanks a lot for your comments/opinions! >> >> Kind regards, >> Ulrich >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] PTL elections: final results
Thank you guys :) Climate really has good community and it's a great opportunity for us to present our ideas to the world :) Anita, I believe we'll do the great job all together. Sylvain, I remember about 0.1 ;) Although in Russia we still have Christmas holidays, I'll find some day this week for reviews and some CR fixes. Thanks, DIna On Mon, Jan 6, 2014 at 2:54 AM, Sylvain Bauza wrote: > Kudos to Dina for the PTL position. 3 vs. 5 with 80% participation means > it's a good thing for Climate : this is not a Stackforge project pushed by > only one sponsor and having a benevolent dictator, but rather a mix of > various experiences and subprojects with people having various ideas. > > Now, let's focus on Climate 0.1 ! ;-) > > -Sylvain > > > 2014/1/5 Anita Kuno > >> Well done Climate electorate, 80% participation is a great rate. >> >> Thank you to both candidates for running. >> >> Congratulations Dina, I look forward to working with you as PTL. >> >> Nicely run election, Sergey. >> >> Good work, >> Anita. >> >> On 01/06/2014 02:15 AM, Sergey Lukjanov wrote: >> > Hi folks, >> > >> > thank you all for participating elections (80% participation). >> > >> > Here are the results of the PTL election process [0]. >> > >> > Congratulations to the Climate PTL for Icehouse release: *Dina Belova*! >> > >> > Elections process has been recorded in [1]. >> > >> > [0] >> > >> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_5d0aa38a04cc78ee >> > [1] https://wiki.openstack.org/wiki/Climate/PTL_Elections_Icehouse >> > >> > Thanks. >> > >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] Meeting minutes
Thank everyone who were on our Climate weekly meeting. Meeting minutes: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-10-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-10-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-10-15.00.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystoneclient] old keystone-client package on pypi
Guys, that's true :) Is it possible to update keystone client package in pypi? Thank you! Dina On Fri, Dec 27, 2013 at 1:24 PM, Nikolay Starodubtsev < nstarodubt...@mirantis.com> wrote: > Hi all, > Guys, I want to say that keystoneclient package on pypi is too old. For > example it hadn't Client func in keystoneclient/client.py. May be someone > can help me with this? > > > > Nikolay Starodubtsev > > Software Engineer > > Mirantis Inc. > > > Skype: dark_harlequine1 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystoneclient] old keystone-client package on pypi
Dolph, thank you so much :) You fixed lots of our problems :) On Mon, Jan 13, 2014 at 6:00 PM, Dolph Mathews wrote: > Ooh, I meant to get this done last week as I agree that keystoneclient > needed to see a new release, but it totally slipped my mind. > > python-keystoneclient 0.4.2 is now available on pypi! > > https://pypi.python.org/pypi/python-keystoneclient/0.4.2 > > What's included in the milestone: > > https://launchpad.net/python-keystoneclient/+milestone/0.4.2 > > > > On Mon, Jan 13, 2014 at 7:17 AM, Sylvain Bauza wrote: > >> Le 13/01/2014 13:49, Thierry Carrez a écrit : >> >> Sylvain Bauza wrote: >> >> Le 27/12/2013 10:24, Nikolay Starodubtsev a écrit : >> >> Hi all, >> Guys, I want to say that keystoneclient package on pypi is too old. >> For example it hadn't Client func in keystoneclient/client.py. May be >> someone can help me with this? >> >> Speaking of python-keystoneclient, the latest release is 0.4.1, which is >> indeed pretty old (Havana release timeframe). >> Any chance to get a fresher release soon ? The only solution as of now >> is pointing to the master eggfile, which is really bad... >> >> The solution is for the PTL to tag a new version, and then it will >> appear on PyPI. >> >> >> >> Thanks Thierry, my question was indeed when a new tag would be delivered >> (and consequently a package) ? >> >> 0.4.1 is 3 months old, and a lot of features have been implemented >> meanwhile : >> https://github.com/openstack/python-keystoneclient/compare/0.4.1...master >> >> In particular, Climate would use the keystoneclient.client.Client class >> for automatic discovery of the Keystone API, which is not part of the >> latest release. >> >> -Sylvain >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate][cafe] Climate and Café teams meeting
Guys from Cafe command are from New Zealand - UTC+13 :) On Mon, Jan 13, 2014 at 6:58 PM, Sergey Lukjanov wrote: > Are there any guys from PST timezone? > > > On Mon, Jan 13, 2014 at 5:32 PM, Sylvain Bauza wrote: > >> I can propose anytime at 0600 UTC, I can make efforts for waking up >> earlier :-) >> I can yet understand that other EU people couldn't attend the call, so I >> will aggregate and feedback all the topics for my French peers. >> >> -Sylvain >> >> >> 2014/1/13 Nikolay Starodubtsev >> >>> Hi, all! >>> Guys, both our teams (Climate and Cafe) want to make a cross-team >>> meeting to discuss our future plans. If you want to participate please tip >>> us with good time for you. >>> >>> Useful links: >>> * Climate https://launchpad.net/climate >>> * Cafe https://wiki.openstack.org/wiki/Cafe >>> >>> >>> >>> >>> Nikolay Starodubtsev >>> >>> Software Engineer >>> >>> Mirantis Inc. >>> >>> >>> Skype: dark_harlequine1 >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate][cafe] Climate and Cafe teams meeting
Ok for me :) On Tue, Jan 14, 2014 at 9:19 AM, Sergey Lukjanov wrote: > It's ok for me. > > P.S. link to the event time - > http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140117T06 > > CET 07:00 am > MSK 10:00 am > PST 10:00 pm > > > On Tue, Jan 14, 2014 at 2:07 AM, Alan TaN wrote: > >> Hi guys, >> >> >> >> Thanks for accommodating to our time. UTC 0600 sounds good for us. I was >> wondering if Friday (17th Jan) UTC 0600 will be a good time for everyone >> else? >> >> >> >> Cheers, >> >> Alan >> >> >> >> >> >> Date: Mon, 13 Jan 2014 19:52:28 +0400 >> >> From: Dina Belova >> >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> >> >> Subject: Re: [openstack-dev] [climate][cafe] Climate and Caf? teams >> >> meeting >> >> Message-ID: >> >> < >> cacsco2zx6wezkznbeu5040fuef91ddx27oa6nn08kpceqn3...@mail.gmail.com> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> >> >> Guys from Cafe command are from New Zealand - UTC+13 :) >> >> >> >> >> >> On Mon, Jan 13, 2014 at 6:58 PM, Sergey Lukjanov >> >> wrote: >> >> >> >> > Are there any guys from PST timezone? >> >> > >> >> > >> >> > On Mon, Jan 13, 2014 at 5:32 PM, Sylvain Bauza >> >> wrote: >> >> > >> >> >> I can propose anytime at 0600 UTC, I can make efforts for waking up >> >> >> earlier :-) I can yet understand that other EU people couldn't attend >> >> >> the call, so I will aggregate and feedback all the topics for my >> >> >> French peers. >> >> >> >> >> >> -Sylvain >> >> >> >> >> >> >> >> >> 2014/1/13 Nikolay Starodubtsev >> >> >> >> >> >>> Hi, all! >> >> >>> Guys, both our teams (Climate and Cafe) want to make a cross-team >> >> >>> meeting to discuss our future plans. If you want to participate >> >> >>> please >> >> tip >> >> >>> us with good time for you. >> >> >>> >> >> >>> Useful links: >> >> >>> * Climate https://launchpad.net/climate >> >> >>> * Cafe https://wiki.openstack.org/wiki/Cafe >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> Nikolay Starodubtsev >> >> >>> >> >> >>> Software Engineer >> >> >>> >> >> >>> Mirantis Inc. >> >> >>> >> >> >>> >> >> >>> Skype: dark_harlequine1 >> >> >>> >> >> >>> ___ >> >> >>> OpenStack-dev mailing list >> >> >>> OpenStack-dev@lists.openstack.org >> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >>> >> >> >>> >> >> >> >> >> >> ___ >> >> >> OpenStack-dev mailing list >> >> >> OpenStack-dev@lists.openstack.org >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > Sincerely yours, >> >> > Sergey Lukjanov >> >> > Savanna Technical Lead >> >> > Mirantis Inc. >> >> > >> >> > ___ >> >> > OpenStack-dev mailing list >> >> > OpenStack-dev@lists.openstack.org >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > >> >> > >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> >> >> Dina Belova >> >> >> >> Software Engineer >> >> >> >> Mirantis Inc. >> >> >> >> >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate][cafe] Climate and Cafe teams meeting
+1 for #openstack-climate Thanks :) On Tue, Jan 14, 2014 at 12:19 PM, Sylvain Bauza wrote: > One more thing, we can meet up on #openstack-climate (logging available), > or we can take a room in #openstack-meeting for starting a formal meeting > and get minutes. > > Both are convenient for me, but with a preference for #openstack-climate. > > -Sylvain > > > 2014/1/14 Sylvain Bauza > >> OK for me too, at the condition the meeting will last at max one hour >> (till 0700 UTC). >> >> -Sylvain >> >> >> 2014/1/14 Dina Belova >> >>> Ok for me :) >>> >>> >>> On Tue, Jan 14, 2014 at 9:19 AM, Sergey Lukjanov >> > wrote: >>> >>>> It's ok for me. >>>> >>>> P.S. link to the event time - >>>> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140117T06 >>>> >>>> CET 07:00 am >>>> MSK 10:00 am >>>> PST 10:00 pm >>>> >>>> >>>> On Tue, Jan 14, 2014 at 2:07 AM, Alan TaN wrote: >>>> >>>>> Hi guys, >>>>> >>>>> >>>>> >>>>> Thanks for accommodating to our time. UTC 0600 sounds good for us. I >>>>> was wondering if Friday (17th Jan) UTC 0600 will be a good time for >>>>> everyone else? >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Alan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Date: Mon, 13 Jan 2014 19:52:28 +0400 >>>>> >>>>> From: Dina Belova >>>>> >>>>> To: "OpenStack Development Mailing List (not for usage questions)" >>>>> >>>>> >>>>> >>>>> Subject: Re: [openstack-dev] [climate][cafe] Climate and Caf? teams >>>>> >>>>> meeting >>>>> >>>>> Message-ID: >>>>> >>>>> < >>>>> cacsco2zx6wezkznbeu5040fuef91ddx27oa6nn08kpceqn3...@mail.gmail.com> >>>>> >>>>> Content-Type: text/plain; charset="iso-8859-1" >>>>> >>>>> >>>>> >>>>> Guys from Cafe command are from New Zealand - UTC+13 :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jan 13, 2014 at 6:58 PM, Sergey Lukjanov >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> > Are there any guys from PST timezone? >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > On Mon, Jan 13, 2014 at 5:32 PM, Sylvain Bauza >>>>> >>>>> wrote: >>>>> >>>>> > >>>>> >>>>> >> I can propose anytime at 0600 UTC, I can make efforts for waking up >>>>> >>>>> >> earlier :-) I can yet understand that other EU people couldn't >>>>> attend >>>>> >>>>> >> the call, so I will aggregate and feedback all the topics for my >>>>> >>>>> >> French peers. >>>>> >>>>> >> >>>>> >>>>> >> -Sylvain >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> >> 2014/1/13 Nikolay Starodubtsev >>>>> >>>>> >> >>>>> >>>>> >>> Hi, all! >>>>> >>>>> >>> Guys, both our teams (Climate and Cafe) want to make a cross-team >>>>> >>>>> >>> meeting to discuss our future plans. If you want to participate >>>>> >>>>> >>> please >>>>> >>>>> tip >>>>> >>>>> >>> us with good time for you. >>>>> >>>>> >>> >>>>> >>>>> >>> Useful links: >>>>> >>>>> >>> * Climate https://launchpad.net/climate >>>>> >>>>> >>> * Cafe https://wiki.openstack.org/wiki/Cafe >>>>> >>>>> >>> >>>>> >
Re: [openstack-dev] [Climate] 0.1 status meeting
+1 On Tue, Jan 14, 2014 at 12:44 PM, Sylvain Bauza wrote: > Hi team, > > As agreed during our last meeting, we need to discuss on the progression > before code freeze next Tuesday. > > I could propose tomorrow Wed 15 1000 UTC on #openstack-climate. > +1/-1 to this, please. > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] Meeting minutes
Thanks everyone for attending our weekly meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-17-15.00.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate - Was: Next steps for Whole Host allocation / Pclouds
example, say a user wants 5 hosts while Climate only can give him 4, if the > lease would be 'best-effort', Climate would create the lease with 4 hosts > instead of 5, while a "normal" lease would be denied by Climate). Once the > hosts are here, the user can boot as many instances as he wants. > > The virtual instances plugin is also another possible use : provided you > want to provision an instance for a certain amount of time, Nova will > shelve it upon creation, Climate will unshelve it when the lease start and > Climate will destroy it at the lease end. > > > These both plugins (virtual instances plugin and compute hosts plugin) > need to define what we call a termination statement : what to do when the > lease ends ? With compute hosts, if instances are still running, should we > kill them, or leave them and not put back the host in the freepool ? All > these behaviors should be configuration-driven, so that the admin would > have the choice. > > A spot instance in such our system would be the fact that we allow Climate > to free up the resources (kill it or whatever) before the lease ends, > that's another scenario but possible. > > > > >> I'm wondering if managing spot instances and reservations across the >> whole of a Nova system wouldn't be a more general use case than having to >> manage this within a specific aggregate - or am I missing something ? >> > The main point is that you want to potentially provision other objects > than just instances or hosts, like Cinder volumes. That's why we think > reservations need to be managed by a separate Openstack service. That said, > we personnally think Climate and Nova can interact, at least about tenancy > isolation or scheduling of hosts (but that's Gantt's scope), and I would be > glad to help providing Nova such missing things. > > -Sylvain > > > Cheers, >> Phil >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] Future 0.2 release scope discussion
Hello folks :) We've started accumulating ideas for 0.2 release. Here is link to Etherpad: https://etherpad.openstack.org/p/climate-0.2 You are welcome to suggest ideas :) Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks everyone who joined our weekly meeting. Here are meeting minutes: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-24-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-24-15.01.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-01-24-15.01.log.html -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [novaclient] Old PyPi package
Yep, 2.16.0 will be nice to be released. As I see 2.15.0 is September 2013 [1] - that's quite old now, I suppose. [1] http://pypi.openstack.org/openstack/python-novaclient/ On Fri, Jan 24, 2014 at 8:13 PM, Sergey Lukjanov wrote: > It looks like more than 220 commits was merged to the nova client since > 2.15.0 version [1]. > > [1] https://github.com/openstack/python-novaclient/compare/2.15.0...master > > > On Fri, Jan 24, 2014 at 7:49 PM, Nikolay Starodubtsev < > nstarodubt...@mirantis.com> wrote: > >> Hi all! >> While we add new features to Climate 0.1 release we have some problems >> with novaclient. The problem is that novaclient 2.15.0 can't >> shelve/unshelve instances, but this feature is in master branch. Can anyone >> say when novaclient will be updated? >> >> >> >> Nikolay Starodubtsev >> >> Software Engineer >> >> Mirantis Inc. >> >> >> Skype: dark_harlequine1 >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Savanna Technical Lead > Mirantis Inc. > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] [Ceilometer] Integration
Julien, great :) Thanks for starting this initiative, it's really interesting and we want to include that functionality to 0.2 Climate - as discussed in https://etherpad.openstack.org/p/climate-0.2 Thank you Dina On Mon, Jan 27, 2014 at 8:12 PM, Julien Danjou wrote: > Hi, > > I've created a blueprint for Climate support in Ceilometer: > > https://blueprints.launchpad.net/ceilometer/+spec/climate-support > > I've added a list of resources that I think should be metered. I'm not > sure about the other ones that I encountered in Climate; feel free to > amend that list in the whiteboard if you think some are missing, or if > you have further details. > > I didn't create specifically a blueprint in Climate as I found this one: > > https://blueprints.launchpad.net/climate/+spec/notifications > > which should cover what's needed by Ceilometer. The implementation of > this one will depend on the oslo-messaging blueprint, so I've added it > as a dependency. > > Cheers, > -- > Julien Danjou > -- Free Software hacker - independent consultant > -- http://julien.danjou.info > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Lots of gating failures because of testtools
Please see that temporary solution: https://review.openstack.org/#/c/69840/ Thanks, Dina On Wed, Jan 29, 2014 at 3:18 PM, Matthieu Huin wrote: > Thanks so much for figuring this out, I was very puzzled by that this > morning,trying to run keystone tests on my local copy ! > > Matthieu Huin > > m...@enovance.com > > - Original Message - > > From: "Ivan Melnikov" > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > Sent: Wednesday, January 29, 2014 12:07:13 PM > > Subject: [openstack-dev] [all] Lots of gating failures because of > testtools > > > > Hi there, > > > > I see lots of unit tests jobs on gate fail with errors like > > > > 2014-01-29 10:48:44.933 | File > > > "/home/jenkins/workspace/gate-taskflow-python26/.tox/py26/lib/python2.6/site-packages/subunit/test_results.py", > > line 23, in > > 2014-01-29 10:48:44.934 | from testtools.compat import all > > 2014-01-29 10:48:44.935 | ImportError: cannot import name all > > 2014-01-29 10:48:44.992 | ERROR: InvocationError: > > '/home/jenkins/workspace/gate-taskflow-python26/.tox/py26/bin/python > > setup.py testr --slowest --testr-args=' > > > > Looks like subunit is not compatible with just-released testtools > > 0.9.35. I guess we will need to pin testtools to 0.9.34 in > > test-requirements.txt. Or there are better solution? > > > > I filed a bug to subunit upstream: > > https://bugs.launchpad.net/subunit/+bug/1274056 > > > > I also filed a bug for taskflow, feel free to add your projects there if > > it's affected, too: https://bugs.launchpad.net/taskflow/+bug/1274050 > > > > -- > > WBR, > > Ivan A. Melnikov > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] New date for closest team meeting
Hi, folks! We need to choose new date for our next weekly teem meeting due to some emergency - at least two our core members (Sylvain and Swann) and usually active meeting participants will be travelling to FOSDEM tomorrow 15:00 UTC. So they'll have no opportunity to participate. Have you any preferences on what date and time to choose? Cheers, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] New date for closest team meeting
I'm ok with Tuesday 1500 UTC. We may go to #openstack-meeting-3 if we'll need. I'm pretty sure it'll be free. Horizon folks have there meeting Tuesday 1600 UTC, but I'm sure 1 hour will be enough for us :) Folks, any other ideas? Cheers, Dina On Thu, Jan 30, 2014 at 6:42 PM, Sylvain Bauza wrote: > Le 30/01/2014 15:33, Dina Belova a écrit : > > Hi, folks! > > We need to choose new date for our next weekly teem meeting due to some > emergency - at least two our core members (Sylvain and Swann) and usually > active meeting participants will be travelling to FOSDEM tomorrow 15:00 > UTC. So they'll have no opportunity to participate. > > Have you any preferences on what date and time to choose? > > > Tuesday 1500 UTC would get my preference (I do have some family concerns > for Monday) > IIRC, #openstack-meeting will probably be busy at this time, but we can go > to other rooms if necessary. > > -Sylvain > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Hello, folks! Thanks for taking part in or emergency meeting moved from Friday :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-04-15.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-04-15.02.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-04-15.02.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] 0.1.0 release
Hi, folks! Today Climate has been released first time and I'm really glad to say that :) This release implements following use cases: - User wants to reserve virtual machine and use it later. He/she asks Nova to create server, passing special hints, describing information like lease start and end time. In this case instance will be not just booted, but also shelved not to use cloud resources when it's not needed. At the time user passed as 'lease start time' instance will be unshelled and used as user wants to. User may define different actions that might happen to instance at lease end - like snapshoting or/and suspending or/and removal. - User wants to reserve compute capacity of whole compute host to use it later. In this case he/she asks Climate to provide host with passed characteristics from predefined pool of hosts (that is managed by admin user). If this request might be processed, user will have the opportunity run his/her instances on reserved host when lease starts. Here are our release notes: Climate/Release_Notes/0.1.0<https://wiki.openstack.org/wiki/Climate/Release_Notes/0.1.0> Other useful links: - Climate Wiki <https://wiki.openstack.org/wiki/Climate> - Climate Launchpad <https://launchpad.net/climate> - Future plans for 0.2.x <https://etherpad.openstack.org/p/climate-0.2> Thanks all team who worked on Climate 0.1.0 and everybody who helped us! Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Governance] Integrated projects and new requirements
> > Perhaps we should start putting each project on the TC agenda for a > review of its current standing. For any gaps, I think we should set a > specific timeframe for when we expect these gaps to be filled. Really good idea. New requirements are great, but frankly speaking not all currently integrated projects fit all of them. Will be nice to find out all gaps there and fix them asap. Dina On Thu, Feb 6, 2014 at 2:47 AM, Monty Taylor wrote: > On 02/05/2014 10:38 PM, Sean Dague wrote: > >> On 02/06/2014 06:31 AM, Russell Bryant wrote: >> >>> On 02/05/2014 02:31 PM, Doug Hellmann wrote: >>> >>>> >>>> >>>> >>>> On Wed, Feb 5, 2014 at 1:24 PM, Russell Bryant >>> <mailto:rbry...@redhat.com>> wrote: >>>> >>>> Greetings, >>>> >>>> In the TC we have been going through a process to better define our >>>> requirements for incubation and graduation to being an integrated >>>> project. The current version can be found in the governance repo: >>>> >>>> http://git.openstack.org/cgit/openstack/governance/tree/ >>>> reference/incubation-integration-requirements >>>> >>>> Is it time that we do an analysis of the existing integrated >>>> projects >>>> against the requirements we have set? If not now, when? >>>> >>>> Perhaps we should start putting each project on the TC agenda for a >>>> review of its current standing. For any gaps, I think we should >>>> set a >>>> specific timeframe for when we expect these gaps to be filled. >>>> >>>> Thoughts? >>>> >>>> >>>> I like the idea of starting this soon, so projects can prioritize the >>>> work during the next cycle and have time to plan to discuss any related >>>> issues at the summit. Setting a deadline for finishing may depend on the >>>> nature and size of the gaps, but it seems fair to set a deadline for >>>> *starting* the work. >>>> >>> >>> Well, I think in all cases the work should start ASAP. >>> >>> We could set the deadline for when we expect it to be finished on a case >>> by case basis, though. >>> >> >> First, +1 on doing these kinds of reviews. I think as we've been >> applying the rules to new projects, we need to validate that they are >> sane by applying them to existing projects. >> >> My feeling is that we've been evolving these new requirements during >> Icehouse, and it's fair to say that all existing integrated projects >> need to be up to snuff by Juno, otherwise we take a project back to >> incubating status. >> >> I think it will be really good to do some gap analysis here and figure >> out where we think we have holes in our existing integrated projects. >> Because realistically I think we're going to find a number of projects >> that don't meet are current bar, and we'll need to come up with a way to >> get them in sync. >> >> From a gating perspective, I think a bunch of our issues are based on >> the fact that as the number of moving parts in OpenStack expands, our >> tolerance for any particular part not being up to par has to decrease, >> because the number of ways a badly integrated component can impact the >> OpenStack whole is really large. >> > > +100 > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Governance] Integrated projects and new requirements
> > I propose we do this in future TC meetings, time permitting. I > propose we start with projects where the PTL was also elected to the TC, > so that we give this new review's process some mileage. +1, good idea On Thu, Feb 6, 2014 at 5:47 PM, Thierry Carrez wrote: > Dina Belova wrote: > > Perhaps we should start putting each project on the TC agenda for a > > review of its current standing. For any gaps, I think we should set > a > > specific timeframe for when we expect these gaps to be filled. > > > > > > Really good idea. New requirements are great, but frankly speaking not > > all currently integrated projects fit all of them. > > Will be nice to find out all gaps there and fix them asap. > > Agreed. I propose we do this in future TC meetings, time permitting. I > propose we start with projects where the PTL was also elected to the TC, > so that we give this new review's process some mileage. > > So.. Nova, Cinder, Neutron ? > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks everyone who took part in our weekly meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-07-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-07-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-07-15.00.log.html Thanks everyone :) -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler
> > Like a restaurant reservation, it would "claim" the resources for use by > someone at a later date. That way nobody else can use them. > That way the scheduler would be responsible for determining where the > resource should be allocated from, and getting a reservation for that > resource. It would not have anything to do with actually instantiating the > instance/volume/etc. Although I'm quite new to topic of Solver Scheduler, it seems to me that in that case you need to look on Climate project. It aims to provide resource reservation to OS clouds (and by resource I mean here instance/compute host/volume/etc.) And Climate logic is like: create lease - get resources from common pool - do smth with them when lease start time will come. I'll say one more time - I'm not really common with this discussion, but it looks like Climate might help here. Thanks Dina On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen wrote: > On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote: > >> Second, there is nothing wrong with booting the instances (or >>> >> instantiating other >> >>> resources) as separate commands as long as we support some kind of >>> reservation token. >>> >> >> I'm not sure what reservation token would do, is it some kind of informing >> the scheduler that the resources would not be initiated until later ? >> > > Like a restaurant reservation, it would "claim" the resources for use by > someone at a later date. That way nobody else can use them. > > That way the scheduler would be responsible for determining where the > resource should be allocated from, and getting a reservation for that > resource. It would not have anything to do with actually instantiating the > instance/volume/etc. > > > Let's consider a following example: >> >> A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one >> with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM >> left, and another with 30 GB RAM left, using Filter Scheduler's default >> RamWeigher. >> >> If we pass the demand as two commands, there is a chance that the small VM >> arrives first. RamWeigher will put it in the 50 GB RAM host, which will be >> reduced to 30 GB RAM. Then, when the big VM request arrives, there will be >> no space left to host it. As a result, the whole demand is failed. >> >> Now if we can pass the two VMs in a command, SolverScheduler can put their >> constraints all together into one big LP as follow (x_uv = 1 if VM u is >> hosted in host v, 0 if not): >> > > Yes. So what I'm suggesting is that we schedule the two VMs as one call > to the SolverScheduler. The scheduler then gets reservations for the > necessary resources and returns them to the caller. This would be sort of > like the existing Claim object in nova/compute/claims.py but generalized > somewhat to other resources as well. > > The caller could then boot each instance separately (passing the > appropriate reservation/claim along with the boot request). Because the > caller has a reservation the core code would know it doesn't need to > schedule or allocate resources, that's already been done. > > The advantage of this is that the scheduling and resource allocation is > done separately from the instantiation. The instantiation API could remain > basically as-is except for supporting an optional reservation token. > > > That responses to your first point, too. If we don't mind that some VMs >> are placed and some are not (e.g. they belong to different apps), then >> it's OK to pass them to the scheduler without Instance Group. However, if >> the VMs are together (belong to an app), then we have to put them into an >> Instance Group. >> > > When I think of an "Instance Group", I think of " > https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension";. > Fundamentally Instance Groups" describes a runtime relationship between > different instances. > > The scheduler doesn't necessarily care about a runtime relationship, it's > just trying to allocate resources efficiently. > > In the above example, there is no need for those two instances to > necessarily be part of an Instance Group--we just want to schedule them > both at the same time to give the scheduler a better chance of fitting them > both. > > More generally, the more instances I want to start up the more beneficial > it can be to pass them all to the scheduler at once in order to give the > scheduler more information. Those instances could be parts of completely > independent Instance
Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler
> > This is something to explore to add in Nova, using > a local service or external service (need to explore Climate). I need to find out more about Climate. Here is Climate Launchpad: https://launchpad.net/climate That's still really young project, but I believe it'll have great future speaking about resource reservation. So if you need some kind of reservation logic, I also believe that should be implemented in Climate (as it's proposed and currently implemented as Reservation-as-a-Service) Thanks On Tue, Feb 11, 2014 at 8:23 PM, Yathiraj Udupi (yudupi) wrote: > Hi Dina, > > Thanks for note about Climate logic. This is something that will be > very useful, when we will have to schedule from Nova multiple instances (of > potentially different flavors) as a single request. If the Solver > Scheduler, can make a request to the Climate service to reserve the > resources soon after the placement decision has been made, then the nova > provisioning logic can handle the resource provisioning using the climate > reserved leases. Regarding Solver Scheduler for your reference, just sent > another email about this with some pointers about it. Otherwise this is > the blueprint - > https://blueprints.launchpad.net/nova/+spec/solver-scheduler > I guess this is something to explore more and see how Nova provisioning > logic to work with Climate leases. Or this is something that already works. > I need to find out more about Climate. > > Thanks, > Yathi. > > > On 2/11/14, 7:44 AM, "Dina Belova" wrote: > >Like a restaurant reservation, it would "claim" the resources for use >> by someone at a later date. That way nobody else can use them. >> That way the scheduler would be responsible for determining where the >> resource should be allocated from, and getting a reservation for that >> resource. It would not have anything to do with actually instantiating the >> instance/volume/etc. > > > Although I'm quite new to topic of Solver Scheduler, it seems to me that > in that case you need to look on Climate project. It aims to provide > resource reservation to OS clouds (and by resource I mean here > instance/compute host/volume/etc.) > > And Climate logic is like: create lease - get resources from common pool > - do smth with them when lease start time will come. > > I'll say one more time - I'm not really common with this discussion, but > it looks like Climate might help here. > > Thanks > Dina > > > On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen < > chris.frie...@windriver.com> wrote: > >> On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote: >> >>> Second, there is nothing wrong with booting the instances (or >>>> >>> instantiating other >>> >>>> resources) as separate commands as long as we support some kind of >>>> reservation token. >>>> >>> >>> I'm not sure what reservation token would do, is it some kind of >>> informing >>> the scheduler that the resources would not be initiated until later ? >>> >> >> Like a restaurant reservation, it would "claim" the resources for use by >> someone at a later date. That way nobody else can use them. >> >> That way the scheduler would be responsible for determining where the >> resource should be allocated from, and getting a reservation for that >> resource. It would not have anything to do with actually instantiating the >> instance/volume/etc. >> >> >> Let's consider a following example: >>> >>> A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one >>> with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM >>> left, and another with 30 GB RAM left, using Filter Scheduler's default >>> RamWeigher. >>> >>> If we pass the demand as two commands, there is a chance that the small >>> VM >>> arrives first. RamWeigher will put it in the 50 GB RAM host, which will >>> be >>> reduced to 30 GB RAM. Then, when the big VM request arrives, there will >>> be >>> no space left to host it. As a result, the whole demand is failed. >>> >>> Now if we can pass the two VMs in a command, SolverScheduler can put >>> their >>> constraints all together into one big LP as follow (x_uv = 1 if VM u is >>> hosted in host v, 0 if not): >>> >> >> Yes. So what I'm suggesting is that we schedule the two VMs as one call >> to the SolverScheduler. The scheduler then gets reservations for the >> necessary
Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler
> > So after a reservation lease for a VM is made by Climate, who acts on it > to finally instantiate the VM ? Is it Climate or Nova should act on the > lease to finally provision the VM. Now to take resources for VM it's actually created and then immediately shelved, not to be in active state and not to actually work while it's not needed. Climate then uses Keystone trusts to unshelve it the time lease actually starts. Thanks, Dina On Tue, Feb 11, 2014 at 9:28 PM, Yathiraj Udupi (yudupi) wrote: > hi Sylvain and Dina, > > Thanks for your pointers about Climate. I will take a closer look at it > and try it out. So after a reservation lease for a VM is made by Climate, > who acts on it to finally instantiate the VM ? Is it Climate or Nova should > act on the lease to finally provision the VM. > > Thanks, > Yathi. > > On 2/11/14, 8:42 AM, "Sylvain Bauza" wrote: > > Le 11/02/2014 17:23, Yathiraj Udupi (yudupi) a écrit : > > Hi Dina, > > Thanks for note about Climate logic. This is something that will be > very useful, when we will have to schedule from Nova multiple instances (of > potentially different flavors) as a single request. If the Solver > Scheduler, can make a request to the Climate service to reserve the > resources soon after the placement decision has been made, then the nova > provisioning logic can handle the resource provisioning using the climate > reserved leases. Regarding Solver Scheduler for your reference, just sent > another email about this with some pointers about it. Otherwise this is > the blueprint - > https://blueprints.launchpad.net/nova/+spec/solver-scheduler > I guess this is something to explore more and see how Nova provisioning > logic to work with Climate leases. Or this is something that already works. > I need to find out more about Climate. > > Thanks, > Yathi. > > > > There are possibly 2 ways for creating a lease : either thru the CLI or by > the python binding. > > We implemented these 2 possibilities within the current Climate 0.1 > release : > - a Nova extension plugin is responsible for creating the lease if a VM > should be reserved (using the Climate pythonclient binding) > - an user can request for reserving a compute host using the Climate > python client directly > > Both logics (VM and compute host) are actually referring to 2 distinct > plugins in the Climate manager, so the actions are completely different. > > Based on your use-case, you could imagine a call from the SolverScheduler > to Climate for creating a lease containing multiple VM reservations, and > either you would use the Climate VM plugin or you would use a dedicated > plugin if your need is different. > > I don't think that's a huge volume of work, as Climate already defines and > implements the main features that you need. > > -Sylvain > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] update.py copies more modules than expected
May we use smth like: module=notifier.api only to copy needed for middleware notifier? On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella < bucce...@linux.vnet.ibm.com> wrote: > On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote: > >> Hi, >> We've modified the openstack-commons.conf file for climate remove rpc and >> notifier modules. But when the update.py is executed, the notifier and rpc >> modules are still copied. Do you know what could be wrong? >> Here you can see a log showing this situation: >> http://paste.openstack.org/show/64674/ >> > > I think it's because you're pulling in middleware. The audit module > imports notifier, so notifier gets dragged along as a dependency. > > > -Chris > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] update.py copies more modules than expected
Cause it seems that such thing is not working: http://paste.openstack.org/show/64740/ It still downloads all directories for notifier and roc, although is only module=notifier.api in conf file. Thanks Dina On Wed, Feb 12, 2014 at 11:13 PM, Dina Belova wrote: > May we use smth like: > > module=notifier.api > > only to copy needed for middleware notifier? > > > On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella < > bucce...@linux.vnet.ibm.com> wrote: > >> On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote: >> >>> Hi, >>> We've modified the openstack-commons.conf file for climate remove rpc >>> and notifier modules. But when the update.py is executed, the notifier and >>> rpc modules are still copied. Do you know what could be wrong? >>> Here you can see a log showing this situation: >>> http://paste.openstack.org/show/64674/ >>> >> >> I think it's because you're pulling in middleware. The audit module >> imports notifier, so notifier gets dragged along as a dependency. >> >> >> -Chris >> >> >> >> _______ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo-incubator] update.py copies more modules than expected
I think variant with using oslo.messaging is nice here - cause now it looks strange when openstack.common.middleware asks to use openstack.common.notifier.api - and that leads to two unused really dirs downloaded by update.py script. Anyway, we should go further and begin using oslo.messaging where it's possible now. Dina On Wed, Feb 12, 2014 at 11:34 PM, Doug Hellmann wrote: > The update script tries to be smart about the dependencies between > modules, based on cross-module imports. > > It looks like the notifier middleware will need to move out of the > incubator, or be updated to use oslo.messaging or the rpc code from the > incubator. > > Doug > > > On Wed, Feb 12, 2014 at 2:23 PM, Dina Belova wrote: > >> Cause it seems that such thing is not working: >> http://paste.openstack.org/show/64740/ >> It still downloads all directories for notifier and roc, although is only >> module=notifier.api in conf file. >> >> Thanks >> Dina >> >> >> On Wed, Feb 12, 2014 at 11:13 PM, Dina Belova wrote: >> >>> May we use smth like: >>> >>> module=notifier.api >>> >>> only to copy needed for middleware notifier? >>> >>> >>> On Wed, Feb 12, 2014 at 10:55 PM, Chris Buccella < >>> bucce...@linux.vnet.ibm.com> wrote: >>> >>>> On 02/12/2014 11:50 AM, Sanchez, Cristian A wrote: >>>> >>>>> Hi, >>>>> We've modified the openstack-commons.conf file for climate remove rpc >>>>> and notifier modules. But when the update.py is executed, the notifier >>>>> and >>>>> rpc modules are still copied. Do you know what could be wrong? >>>>> Here you can see a log showing this situation: >>>>> http://paste.openstack.org/show/64674/ >>>>> >>>> >>>> I think it's because you're pulling in middleware. The audit module >>>> imports notifier, so notifier gets dragged along as a dependency. >>>> >>>> >>>> -Chris >>>> >>>> >>>> >>>> ___ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> >>> Dina Belova >>> >>> Software Engineer >>> >>> Mirantis Inc. >>> >> >> >> >> -- >> >> Best regards, >> >> Dina Belova >> >> Software Engineer >> >> Mirantis Inc. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks everyone who took part in our weekly meeting. It is real pleasure to work with you, folks! Meeting minutes are here: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-14-15.04.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-14-15.04.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-14-15.04.log.html Thanks! Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
Sylvain, as I understand in BP description, Christian is about not exactly reserving tenants itself like we actually do with VMs/hosts - it's just naming for that. I think he is about two moments: 1) mark some tenants as "needed to be reserved" - speaking about resources assigned to it 2) reserve these resources via Climate (VMs for first approximation) I suppose Christian is speaking now about hacking tenants creation process to mark them as "needed to be reserved" (1st step). Christian, correct me if I'm wrong, please Waiting for your comments On Thu, Feb 20, 2014 at 10:06 PM, Sylvain Bauza wrote: > Hi Christian, > > 2014-02-20 18:10 GMT+01:00 Martinez, Christian < > christian.marti...@intel.com>: > > Hello all, >> >> I'm working in the following BP: >> https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept, >> in which the idea is to have the possibility to create "special" tenants >> that have a lease for all of its associated resources. >> >> >> >> The BP is in discussing phase and we were having conversations on IRC >> about what approach should we follow. >> >> >> > > Before speaking about implementation, I would definitely know the > usecases you want to design. > What kind of resources do you want to provision using Climate ? The basic > thing is, what is the rationale thinking about hooking tenant creation ? > Could you please be more explicit ? > > At the tenant creation, Climate wouldn't have no information in terms of > calculating the resources asked, because the resources wouldn't have been > allocated before. So, generating a lease on top of this would be like a > non-formal contract in between Climate and the user, accounting nothing. > > The main reason behind Climate is to provide SLAs for either user requests > or projects requests, meaning that's duty of Climate to guarantee that the > desired associated resource with the lease will be created in the future. > Speaking of Keystone, the Keystone objects are tenants, users or domains. > In that case, if Climate would be hooking Keystone, that would say that > Climate ensures that the cloud will have enough capacity for creating these > resources in the future. > > IMHO, that's not worth implementing it. > > > First of all, we need to add some "parameters or flags" during the >> tenant creation so we can know that the associated resources need to have a >> lease. Does anyone know if Keystone has similar functionality to Nova in >> relation with Hooks/API extensions (something like the stuff mentioned on >> http://docs.openstack.org/developer/nova/devref/hooks.html ) ? My first >> idea is to intercept the tenant creation call (as it's being done with >> climate-nova) and use that information to associate a lease quota to the >> resources assigned to that tenant. >> >> > > Keystone has no way to know which resources are associated within a > tenant, see how the middleware authentication is done here [1] > Regarding the BP, the motivation is to possibly 'leasify' all the VMs from > one single tenant. IIRC, that should still be duty of Nova to handle that > workflow and send the requests to Climate. > > -Sylvain > > [1] : > http://docs.openstack.org/developer/keystone/middlewarearchitecture.html > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks everyone who was on our meeting :) Meeting minutes are here: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-21-15.01.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Tenant expiration dates
Cristian, hello I believe that should not be done in such direct way, really. Why not using project.extra field in DB to store this info? Is that not appropriate for your ideas or there will be problems with there implementing using extras? Thanks, Dina On Mon, Feb 24, 2014 at 5:25 PM, Sanchez, Cristian A < cristian.a.sanc...@intel.com> wrote: > Hi, > I'm thinking about creating a blueprint to allow the creating of tenants > defining start-date and end-date of that tenant. These dates will define a > time window in which the tenant is considered 'enabled' and auth tokens > will be given only when current time is between those dates. > This can be particularly useful for projects like Climate where resources > are reserved. And any resource (like VMs) created for a tenant will have > the same expiration dates as the tenant. > > Do you think this is something that can be added to Keystone? > > Thanks > > Cristian > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
I guess that's simple and that's why nice solution for this problem. So you propose to implement that feature in following way: 1) mark project as 'reservable' during its creation in extras specs 2) add some more logic to reservable resources creation/reservation. Like adding one more checking in instance creation request. Currently we're checking hints in request, you propose to check project extra info and if project is 'reservable' you'll use smth like default_reservation stuff for instances Although it looks ok (because of no changes to Keystone/Nova/etc. core code), I have some question about this solution: - info about project should be given only to admins, really. But all these VMs will be booted by simple users, am I right? In this case you'll have no possibility to get info about project and to process checking. Do you have some ideas about how to solve this problem? Dina On Tue, Feb 25, 2014 at 6:22 PM, Martinez, Christian < christian.marti...@intel.com> wrote: > Yeah.. That could be a good approach. > Just add some extra info to the tenant creation.. Then, on climate nova, > when a resource is created, check by the tenant id if that tenant has a > "lease param" (or smth like that). If it does, then act accordingly.. > Is that make sense? Dina, Sylvain ?? > > > -Original Message- > From: Sanchez, Cristian A [mailto:cristian.a.sanc...@intel.com] > Sent: Thursday, February 20, 2014 4:19 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design > > I agree with Bauza that the main purpose of Climate is to reserve > resources, and in the case of keystone it should reserve tenant, users, > domains, etc. > > So, it could be possible that climate is not the module in which the > tenant "lease" information should be saved. As stated in the use case, the > only purpose of this BP is to allow the creation of tenants with start and > end dates. Then when creating resources in that tenant (like VMs) climate > could take "lease" information from the tenant itself and create actual > leases for the VMs. > > Any thoughts of this? > > From: Sylvain Bauza sylvain.ba...@gmail.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Date: jueves, 20 de febrero de 2014 15:57 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design > > > > > 2014-02-20 19:32 GMT+01:00 Dina Belova dbel...@mirantis.com>>: > Sylvain, as I understand in BP description, Christian is about not exactly > reserving tenants itself like we actually do with VMs/hosts - it's just > naming for that. I think he is about two moments: > > 1) mark some tenants as "needed to be reserved" - speaking about resources > assigned to it > 2) reserve these resources via Climate (VMs for first approximation) > > > Well, I understood your BP, that's Christian's message which was a bit > misunderstanding. > Speaking of marking a tenant as "reserved" would then mean that it does > have kind of priority vs. another tenant. But again, at said, how could you > ensure at the marking (ie. at lease creation) that Climate can honor > contracts with resources that haven't been explicitely defined ? > > I suppose Christian is speaking now about hacking tenants creation process > to mark them as "needed to be reserved" (1st step). > > > Again, a lease is mutually and exclusively linked with explicit resources. > If you say "create a lease, for the love" without speaking of what, I don't > see the interest in Climate, unless I missed something obvious. > > -Sylvain > Christian, correct me if I'm wrong, please Waiting for your comments > > > On Thu, Feb 20, 2014 at 10:06 PM, Sylvain Bauza <mailto:sylvain.ba...@gmail.com>> wrote: > Hi Christian, > > 2014-02-20 18:10 GMT+01:00 Martinez, Christian < > christian.marti...@intel.com<mailto:christian.marti...@intel.com>>: > > Hello all, > I'm working in the following BP: > https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept, > in which the idea is to have the possibility to create "special" tenants > that have a lease for all of its associated resources. > > The BP is in discussing phase and we were having conversations on IRC > about what approa
Re: [openstack-dev] [Climate] Lease by tenants feature design
> > Why should it require to be part of Keystone to hook up on Climate ? Sorry, can't get your point. Provided we consider some projects as 'reservable', we could say this > should be a Climate API endpoint like CRUD /project/ and up to the admin > responsability to populate it. > If we say that new projects should automatically be 'reservable', that's > only policy from Climate to whiteboard these. So you propose to make some API requests to Climate (like for hosts) and mark some already existing projects as reserved. But how we'll automate process of some resource reservation belonging to that tenant? Or do you propose still to add some checkings to, for example, climate-nova extensions to check this somehow there? Thanks On Tue, Feb 25, 2014 at 6:48 PM, Sylvain Bauza wrote: > > > > 2014-02-25 15:38 GMT+01:00 Dina Belova : > > I guess that's simple and that's why nice solution for this problem. >> >> So you propose to implement that feature in following way: >> 1) mark project as 'reservable' during its creation in extras specs >> 2) add some more logic to reservable resources creation/reservation. Like >> adding one more checking in instance creation request. Currently we're >> checking hints in request, you propose to check project extra info and >> if project is 'reservable' you'll use smth like default_reservation stuff >> for instances >> >> Although it looks ok (because of no changes to Keystone/Nova/etc. core >> code), I have some question about this solution: >> - info about project should be given only to admins, really. But all >> these VMs will be booted by simple users, am I right? In this case you'll >> have no possibility to get info about project and to process checking. >> >> Do you have some ideas about how to solve this problem? >> >> Dina >> >> > > Why should it require to be part of Keystone to hook up on Climate ? > Provided we consider some projects as 'reservable', we could say this > should be a Climate API endpoint like CRUD /project/ and up to the admin > responsability to populate it. > > If we say that new projects should automatically be 'reservable', that's > only policy from Climate to whiteboard these. > > Provided a VM is booted by a single end-user, that would still be > Climate's responsability to verify that the user's tenant has been > previously granted. > > -Sylvain > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
Ok, so >>> I'm just asking why we should hack Keystone workflow by adding an hook, like we did for Nova. From my POV, that's not worth it. Idea was about some extra specs, that will be processed by Climate anyway. Keystone will know nothing about reservations or smth. >>> I think it should be a Climate "policy" (be careful, the name is confusing) : if admin wants to grant any new project for reservations, he should place a call to Climate. That's up to Climate-Nova (ie. Nova extension) to query Climate in order to see if project has been granted or not. Now I think that it'll be better, yes. I see some workflow like: 1) Mark project as reservable in Climate 2) When some resource is created (like Nova instance) it should be checked (in the API extensions, for example) via Climate if project is reservable. If is, and there is no special reservation flags passed, it should be used default_reservation stuff for this instance Sylvain, is that ira you're talking about? Dina On Tue, Feb 25, 2014 at 7:53 PM, Sylvain Bauza wrote: > > > > 2014-02-25 16:25 GMT+01:00 Dina Belova : > > Why should it require to be part of Keystone to hook up on Climate ? >> >> >> Sorry, can't get your point. >> >> > > I'm just asking why we should hack Keystone workflow by adding an hook, > like we did for Nova. From my POV, that's not worth it. > > > >> Provided we consider some projects as 'reservable', we could say this >>> should be a Climate API endpoint like CRUD /project/ and up to the admin >>> responsability to populate it. >>> If we say that new projects should automatically be 'reservable', that's >>> only policy from Climate to whiteboard these. >> >> >> So you propose to make some API requests to Climate (like for hosts) and >> mark some already existing projects as reserved. But how we'll automate >> process of some resource reservation belonging to that tenant? Or do you >> propose still to add some checkings to, for example, climate-nova >> extensions to check this somehow there? >> >> Thanks >> >> > > I think it should be a Climate "policy" (be careful, the name is > confusing) : if admin wants to grant any new project for reservations, he > should place a call to Climate. That's up to Climate-Nova (ie. Nova > extension) to query Climate in order to see if project has been granted or > not. > > Conceptually, this 'reservation' information is tied to Climate and should > not be present within the projects. > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
Don't think it's needed in this case. We may store this info in Climate not to intersect with Keystone without serious reasons. On Wednesday, February 26, 2014, Sanchez, Cristian A < cristian.a.sanc...@intel.com> wrote: > One question to clarify: the project will be marked as reservable by > calling Keystone API (from Climate) to store that info in the project extra > specs in Keystone DB. > Is this correct? > > From: Sylvain Bauza sylvain.ba...@gmail.com >> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Date: martes, 25 de febrero de 2014 17:55 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design > > > > > 2014-02-25 17:42 GMT+01:00 Dina Belova > <mailto:dbel...@mirantis.com >>: > > >>> I think it should be a Climate "policy" (be careful, the name is > confusing) : if admin wants to grant any new project for reservations, he > should place a call to Climate. That's up to Climate-Nova (ie. Nova > extension) to query Climate in order to see if project has been granted or > not. > > Now I think that it'll be better, yes. > I see some workflow like: > > 1) Mark project as reservable in Climate > 2) When some resource is created (like Nova instance) it should be checked > (in the API extensions, for example) via Climate if project is reservable. > If is, and there is no special reservation flags passed, it should be used > default_reservation stuff for this instance > > Sylvain, is that ira you're talking about? > > > tl;dr : Yes, let's define/create a new endpoint for the need. > > That's exactly what I'm thinking, Climate should manage reservations on > its own (including any new model) and projects using it for reserving > resources should place a call to it in order to get some information. > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
Also we have to mention Adam's letter - cause now he said he loves to see start/end date functionality in keystone. If so, we may store this info in Keystone - but anyway, I suppose that it might be somehow duplicated in Climate not to process one more request to Keystone when it'll be needed. I still have no clear idea how that will be looking speaking about user rights. Now we're using trusts + special admin user. We'll get rid of this special user in future. But to work with projects we still need admin's rights. Any ideas? On Wednesday, February 26, 2014, Dina Belova wrote: > Don't think it's needed in this case. We may store this info in Climate > not to intersect with Keystone without serious reasons. > > On Wednesday, February 26, 2014, Sanchez, Cristian A < > cristian.a.sanc...@intel.com> > wrote: > >> One question to clarify: the project will be marked as reservable by >> calling Keystone API (from Climate) to store that info in the project extra >> specs in Keystone DB. >> Is this correct? >> >> From: Sylvain Bauza > sylvain.ba...@gmail.com>> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>> >> Date: martes, 25 de febrero de 2014 17:55 >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>> >> Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design >> >> >> >> >> 2014-02-25 17:42 GMT+01:00 Dina Belova > dbel...@mirantis.com>>: >> >> >>> I think it should be a Climate "policy" (be careful, the name is >> confusing) : if admin wants to grant any new project for reservations, he >> should place a call to Climate. That's up to Climate-Nova (ie. Nova >> extension) to query Climate in order to see if project has been granted or >> not. >> >> Now I think that it'll be better, yes. >> I see some workflow like: >> >> 1) Mark project as reservable in Climate >> 2) When some resource is created (like Nova instance) it should be >> checked (in the API extensions, for example) via Climate if project is >> reservable. If is, and there is no special reservation flags passed, it >> should be used default_reservation stuff for this instance >> >> Sylvain, is that ira you're talking about? >> >> >> tl;dr : Yes, let's define/create a new endpoint for the need. >> >> That's exactly what I'm thinking, Climate should manage reservations on >> its own (including any new model) and projects using it for reserving >> resources should place a call to it in order to get some information. >> >> -Sylvain >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Lease by tenants feature design
Only problem here is that we'll remove admin climate user in the future and will use only trusts, so how you'll get needed info? I think we may keep info unduplicated only in one case: use trust from admin user who marked tenant as reservable to get needed info later. In this case storing needed info in keystone is ok for me. Dina On Thursday, February 27, 2014, Sanchez, Cristian A < cristian.a.sanc...@intel.com> wrote: > I don't think that duplicating the information in Climate is a really good > idea. Why don't let Keystone manage the tenant dates information? Moreover, > we can also add that to Horizon. > Then, during Lease creations, Climate should query Keystone to get the > tenant dates. > > What do you think? > > From: Dina Belova dbel...@mirantis.com >> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Date: miércoles, 26 de febrero de 2014 02:10 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design > > Also we have to mention Adam's letter - cause now he said he loves to see > start/end date functionality in keystone. > > If so, we may store this info in Keystone - but anyway, I suppose that it > might be somehow duplicated in Climate not to process one more request to > Keystone when it'll be needed. I still have no clear idea how that will be > looking speaking about user rights. > > Now we're using trusts + special admin user. We'll get rid of this special > user in future. But to work with projects we still need admin's rights. > > Any ideas? > > On Wednesday, February 26, 2014, Dina Belova > > <mailto:dbel...@mirantis.com >> wrote: > Don't think it's needed in this case. We may store this info in Climate > not to intersect with Keystone without serious reasons. > > On Wednesday, February 26, 2014, Sanchez, Cristian A < > cristian.a.sanc...@intel.com cristian.a.sanc...@intel.com ');>> wrote: > One question to clarify: the project will be marked as reservable by > calling Keystone API (from Climate) to store that info in the project extra > specs in Keystone DB. > Is this correct? > > From: Sylvain Bauza sylvain.ba...@gmail.com >> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Date: martes, 25 de febrero de 2014 17:55 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org >> > Subject: Re: [openstack-dev] [Climate] Lease by tenants feature design > > > > > 2014-02-25 17:42 GMT+01:00 Dina Belova > <mailto:dbel...@mirantis.com >>: > > >>> I think it should be a Climate "policy" (be careful, the name is > confusing) : if admin wants to grant any new project for reservations, he > should place a call to Climate. That's up to Climate-Nova (ie. Nova > extension) to query Climate in order to see if project has been granted or > not. > > Now I think that it'll be better, yes. > I see some workflow like: > > 1) Mark project as reservable in Climate > 2) When some resource is created (like Nova instance) it should be checked > (in the API extensions, for example) via Climate if project is reservable. > If is, and there is no special reservation flags passed, it should be used > default_reservation stuff for this instance > > Sylvain, is that ira you're talking about? > > > tl;dr : Yes, let's define/create a new endpoint for the need. > > That's exactly what I'm thinking, Climate should manage reservations on > its own (including any new model) and projects using it for reserving > resources should place a call to it in order to get some information. > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Thanks for taking part in our meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-02-28-15.00.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] New name voting results (round #1)
Hello everyone :) Just closed first round of voting to choose 5 best candidates for being new name of our "Climate" project. We needed to do that, because of some trademark issues and because there are already existing 'climate' repos on PyPi, readthedocs, etc. Here is link to the results of this first round :) http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_30ac36e0aa791e09 Most popular candidates are: 1. *Forecast* (Not defeated in any contest vs. another choice)2. *Reserva*, loses to Forecast by 7-43. *Prophecy*, loses to Reserva by 7-34. *Blazar*, loses to Prophecy by 7-65. *Cast*, loses to Blazar by 8-4 Thanks and have a nice day! P.S. round #2 will be started on Monday. Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Climate Incubation Application
Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation Additionally due to the project scope and the roadmap, we don't see any currently existing OpenStack program that fits Climate. So we've prepared new program request too: https://wiki.openstack.org/wiki/Climate/Program TL;DR Our team is working on providing OpenStack with resource reservation opportunity in time-based manner, including close integration with all other OS projects. As Climate initiative is targeting to provide not only compute resources revervation, but also volumes, network resources, storage nodes reservation opportunity, we consider it is not about being a part of some existing OpenStack program. This initiative needs to become a part of completely new Resource Reservation Program, that aims to implement time-based cloud resource management. Thanks! Best regards, Dina Belova Climate Technical Lead Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Hello Joe, Thierry, Sylvain. Joe, I pretty agree with Sylvain in how he had described Climate idea. I hope it is more understandable now. Thierry, thanks for answering. I'm sorry I did not send this email before :) Thanks Dina On Mon, Mar 3, 2014 at 4:42 PM, Sylvain Bauza wrote: > Hi Joe, > > Thanks for your reply, I'll try to further explain. > > > Le 03/03/2014 05:33, Joe Gordon a écrit : > > On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova >> wrote: >> >>> Hello, folks! >>> >>> I'd like to request Climate project review for incubation. Here is >>> official >>> incubation application: >>> >>> https://wiki.openstack.org/wiki/Climate/Incubation >>> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed >> Description' from the link above, and it states Climate is trying to >> solve two uses cases (and the more generalized cases of those). >> >> 1) Compute host reservation (when user with admin privileges can >> reserve hardware resources that are dedicated to the sole use of a >> tenant) >> 2) Virtual machine (instance) reservation (when user may ask >> reservation service to provide him working VM not necessary now, but >> also in the future) >> > Climate is born from the idea of dedicating compute resources to a single > tenant or user for a certain amount of time, which was not yet implemented > in Nova: how as an user, can I ask Nova for one compute host with certain > specs to be exclusively allocated to my needs, starting in 2 days and being > freed in 5 days ? > > Albeit the exclusive resource lock can be managed on the Nova side, there > is currently no possibilities to ensure resource planner. > > Of course, and that's why we think Climate can also stand by its own > Program, resource reservation can be seen on a more general way : what > about reserving an Heat stack with its volume and network nested resources ? > > > You want to support being able to reserve an instance in the future. >> As a cloud operator how do I take advantage of that information? As a >> cloud consumer, what is the benefit? Today OpenStack supports both >> uses cases, except it can't request an Instance for the future. >> > > Again, that's not only reserving an instance, but rather a complex mix of > resources. At the moment, we do provide way to reserve virtual instances by > shelving/unshelving them at the lease start, but we also give possibility > to provide dedicated compute hosts. Considering it, the logic of resource > allocation and scheduling (take the word as resource planner, in order not > to confuse with Nova's scheduler concerns) and capacity planning is too big > to fail under the Compute's umbrella, as it has been agreed within the > Summit talks and periodical threads. > > From the user standpoint, there are multiple ways to integrate with > Climate in order to get Capacity Planning capabilities. As you perhaps > noticed, the workflow for reserving resources is different from one plugin > to another. Either we say the user has to explicitly request for dedicated > resources (using Climate CLI, see dedicate compute hosts allocation), or we > implicitly integrate resource allocation from the Nova API (see virtual > instance API hook). > > We truly accept our current implementation as a first prototype, where > scheduling decisions can be improved (possibly thanks to some tight > integration with a future external Scheduler aaS, hello Gantt), where also > resource isolation and preemption must also be integrated with subprojects > (we're currently seeing how to provision Cinder volumes and Neutron routers > and nets), but anyway we still think there is a (IMHO big) room for > resource and capacity management on its own project. > > Hoping it's clearer now, > -Sylvain > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
have them, they will be much cheaper than guaranteed ones. Thanks Dina On Mon, Mar 3, 2014 at 6:27 PM, Anne Gentle wrote: > > > On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon wrote: > >> On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza >> wrote: >> > Hi Joe, >> > >> > Thanks for your reply, I'll try to further explain. >> > >> > >> > Le 03/03/2014 05:33, Joe Gordon a écrit : >> > >> >> On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova >> wrote: >> >>> >> >>> Hello, folks! >> >>> >> >>> I'd like to request Climate project review for incubation. Here is >> >>> official >> >>> incubation application: >> >>> >> >>> https://wiki.openstack.org/wiki/Climate/Incubation >> >> >> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed >> >> Description' from the link above, and it states Climate is trying to >> >> solve two uses cases (and the more generalized cases of those). >> >> >> >> 1) Compute host reservation (when user with admin privileges can >> >> reserve hardware resources that are dedicated to the sole use of a >> >> tenant) >> >> 2) Virtual machine (instance) reservation (when user may ask >> >> reservation service to provide him working VM not necessary now, but >> >> also in the future) >> > >> > Climate is born from the idea of dedicating compute resources to a >> single >> > tenant or user for a certain amount of time, which was not yet >> implemented >> > in Nova: how as an user, can I ask Nova for one compute host with >> certain >> > specs to be exclusively allocated to my needs, starting in 2 days and >> being >> > freed in 5 days ? >> > >> > Albeit the exclusive resource lock can be managed on the Nova side, >> there is >> > currently no possibilities to ensure resource planner. >> > >> > Of course, and that's why we think Climate can also stand by its own >> > Program, resource reservation can be seen on a more general way : what >> about >> > reserving an Heat stack with its volume and network nested resources ? >> > >> > >> >> You want to support being able to reserve an instance in the future. >> >> As a cloud operator how do I take advantage of that information? As a >> >> cloud consumer, what is the benefit? Today OpenStack supports both >> >> uses cases, except it can't request an Instance for the future. >> > >> > >> > Again, that's not only reserving an instance, but rather a complex mix >> of >> > resources. At the moment, we do provide way to reserve virtual >> instances by >> > shelving/unshelving them at the lease start, but we also give >> possibility to >> > provide dedicated compute hosts. Considering it, the logic of resource >> > allocation and scheduling (take the word as resource planner, in order >> not >> > to confuse with Nova's scheduler concerns) and capacity planning is too >> big >> > to fail under the Compute's umbrella, as it has been agreed within the >> > Summit talks and periodical threads. >> >> Capacity planning not falling under Compute's umbrella is news to me, >> are you referring to Gantt and scheduling in general? Perhaps I don't >> fully understand the full extent of what 'capacity planning' actually >> is. >> >> > >> > From the user standpoint, there are multiple ways to integrate with >> Climate >> > in order to get Capacity Planning capabilities. As you perhaps noticed, >> the >> > workflow for reserving resources is different from one plugin to >> another. >> > Either we say the user has to explicitly request for dedicated resources >> > (using Climate CLI, see dedicate compute hosts allocation), or we >> implicitly >> > integrate resource allocation from the Nova API (see virtual instance >> API >> > hook). >> >> I don't see how Climate reserves resources is relevant to the user. >> >> > >> > We truly accept our current implementation as a first prototype, where >> > scheduling decisions can be improved (possibly thanks to some tight >> > integration with a future external Scheduler aaS, hello Gantt), where >> also >> > resource isolation and preemption must also be integrate
Re: [openstack-dev] [openstack-tc] Climate Incubation Application
Hello, Sean I think your idea is really interesting. I mean, that thought "Gantt - where to schedule, Climate - when to schedule" is quite understandable and good looking. These two 'directions' of scheduling process really look like fitting into one Program - probably it should be named "Resource Allocation and Reclaiming" or something like this. My only idea is that even Gantt + Climate will be under this new Program umbrella, they can't be one project only because these functionalities may become wider - and projects may become too big to manage them as one. I mean, that future energy efficiency + probable billing interest for Climate is not 'horizontal' scheduling really, and that's why our scopes lay in different areas. High level idea "Gantt is for placing objects, Climate is for planning them" looks good IMHO. And, as said, Compute program is not about Climate, because we're implementing volumes reservation for 0.2.0 release, and that will be pushing us away from the Compute Pr. Anyway, it's an interesting discussion and I'm looking forward to continuing it. Thanks! On Mon, Mar 3, 2014 at 7:04 PM, Sean Dague wrote: > On 03/02/2014 02:32 PM, Dina Belova wrote: > > Hello, folks! > > > > I'd like to request Climate project review for incubation. Here is > > official incubation application: > > > > https://wiki.openstack.org/wiki/Climate/Incubation > > > > Additionally due to the project scope and the roadmap, we don't see any > > currently existing OpenStack program that fits Climate. So we've > > prepared new program request too: > > > > https://wiki.openstack.org/wiki/Climate/Program > > > > TL;DR > > > > Our team is working on providing OpenStack with resource reservation > > opportunity in time-based manner, including close integration with all > > other OS projects. > > > > As Climate initiative is targeting to provide not only compute resources > > revervation, but also volumes, network resources, storage nodes > > reservation opportunity, we consider it is not about being a part of > > some existing OpenStack program. > > > > This initiative needs to become a part of completely new Resource > > Reservation Program, that aims to implement time-based cloud resource > > management. > > At a high level this feels like this should be part of scheduling. > Scheduling might include resources you want right now, but it could > include resources you want in the future. It also makes sense for > scheduling to include deadlines, so that resources are reclaimed when > they expire. Especially given quota implications of asking for resources > now vs. resources that a user has reserved in the future. What happens > when a user has used all their quota in the present, and a future > reservation comes up for access? > > Scheduling today is under compute. The proposal to pull Gantt out still > leaves it in the compute program. So I would naturally assume this > should live under compute. I could understand that if this & Gantt > emerged together and wanted to create a "Resource Allocation" program, > that might make sense. But I think that's way down the road. > > However, that's just a quick look at this. I think it will be an > interesting discussion in how this effort moves forward. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > ___ > OpenStack-TC mailing list > openstack...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Joe, as said, Amazon reservation is not like implemented in Climate - and really we had different original use cases to have the same result. Amazon instances reservations do not guarantee that instance will be provided to user, as in Climate we started implemented reservations possibilities with this guarantee (due to original use cases). That's why we're mostly speaking about time-based resource management now, not billing purposes. Lease creation request now contains the following steps: create lease -> start lease -> end lease Also there are user notifications, but they are connected with lease start/end events, so that's not some separated stuff now. Although, if we'll implement one more second step like 'allocate resources' - that will allow us to have reservations with no guarantees, and that will make Climate possibilities containing Amazon use case. Thanks On Mon, Mar 3, 2014 at 9:04 PM, Joe Gordon wrote: > On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle wrote: > > > > > > On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon > wrote: > >> > >> On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza > >> wrote: > >> > Hi Joe, > >> > > >> > Thanks for your reply, I'll try to further explain. > >> > > >> > > >> > Le 03/03/2014 05:33, Joe Gordon a écrit : > >> > > >> >> On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova > >> >> wrote: > >> >>> > >> >>> Hello, folks! > >> >>> > >> >>> I'd like to request Climate project review for incubation. Here is > >> >>> official > >> >>> incubation application: > >> >>> > >> >>> https://wiki.openstack.org/wiki/Climate/Incubation > >> >> > >> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed > >> >> Description' from the link above, and it states Climate is trying to > >> >> solve two uses cases (and the more generalized cases of those). > >> >> > >> >> 1) Compute host reservation (when user with admin privileges can > >> >> reserve hardware resources that are dedicated to the sole use of a > >> >> tenant) > >> >> 2) Virtual machine (instance) reservation (when user may ask > >> >> reservation service to provide him working VM not necessary now, but > >> >> also in the future) > >> > > >> > Climate is born from the idea of dedicating compute resources to a > >> > single > >> > tenant or user for a certain amount of time, which was not yet > >> > implemented > >> > in Nova: how as an user, can I ask Nova for one compute host with > >> > certain > >> > specs to be exclusively allocated to my needs, starting in 2 days and > >> > being > >> > freed in 5 days ? > >> > > >> > Albeit the exclusive resource lock can be managed on the Nova side, > >> > there is > >> > currently no possibilities to ensure resource planner. > >> > > >> > Of course, and that's why we think Climate can also stand by its own > >> > Program, resource reservation can be seen on a more general way : what > >> > about > >> > reserving an Heat stack with its volume and network nested resources ? > >> > > >> > > >> >> You want to support being able to reserve an instance in the future. > >> >> As a cloud operator how do I take advantage of that information? As a > >> >> cloud consumer, what is the benefit? Today OpenStack supports both > >> >> uses cases, except it can't request an Instance for the future. > >> > > >> > > >> > Again, that's not only reserving an instance, but rather a complex mix > >> > of > >> > resources. At the moment, we do provide way to reserve virtual > instances > >> > by > >> > shelving/unshelving them at the lease start, but we also give > >> > possibility to > >> > provide dedicated compute hosts. Considering it, the logic of resource > >> > allocation and scheduling (take the word as resource planner, in order > >> > not > >> > to confuse with Nova's scheduler concerns) and capacity planning is > too > >> > big > >> > to fail under the Compute's umbrella, as it has been agreed within the > >> > Summit talks and periodical threads.
Re: [openstack-dev] Climate Incubation Application
Oh, Sylvain, you were first :) I have just small things to add here: Joe, resource usage planning is great feature, that, I believe, is not supported in OS services now. Resource planning will allow cloud providers to react on future picks of loads, because they *will know* about that. As Zane said, otherwise you need to spend much money keeping much extra capacity in common pool, or have real risks to run out of resources. Everything else was described by Sylvain, I guess :) -- Dina On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza wrote: > Hi Joe, > > > 2014-03-03 18:32 GMT+01:00 Joe Gordon : > > >> >> This sounds like something that belongs in nova, Phil Day has an >> elegant solution for this: >> https://blueprints.launchpad.net/nova/+spec/whole-host-allocation >> >> > This blueprint has already been addressed by Climate team, and we > discussed about this with Phil directly. > This blueprint has been recently abandoned by its author and Phil is > trying to focus on dedicated instances instead. > > As we identified this blueprint as non-supported yet, we implemented its > logic directly within Climate. That said, don't confuse 2 different things > : > - the locking process for isolating one compute node to a single tenant : > that should be done in Nova > - the timetable for scheduling hosts and electing which ones are > appropriate : that must be done in Climate (and in the future, should use > Gantt as external scheduler for electing from a pool of available hosts on > that timeframe) > > Don't let me say that the resource isolation must be done within Climate : > I'm definitely conviced that this logic should be done on the resource > project level (Nova, Cinder, Neutron) and Climate should use their > respective CLI for asking isolation. > The overall layer for defining what will available when, and what are the > dependencies in between projects, still relies on a shared service, which > is Climate. > > >> >> Heat? >> >> I spin up dev instances all the time and have never had this problem >> in part because if I forget my quota will remind me. >> >> > How do you ensure that you won't run out of resources when firing up an > instance in 3 days ? How can you guaranttee that in the next couple of > days, you would be able to create a volume with 50GB of space ? > > I'm not saying that the current Climate implementation does all the work. > I'm just saying it's duty of Climate to look at Quality of Service aspects > for resource allocation (or say SLA if you prefer) > > >> >> Why does he need to reserve them in the future? When he wants an >> instance can't he just get one? As Sean said, what happens if someone >> has no free quota when the reservation kicks in? >> >> > That's the role of the resource plugin to manage capacity and ensure > everything can be charged correctly. > Regarding the virtual instances plugin logic, that's something that can be > improved, but consider the thing that the instance is already created but > not spawned when the lease is created, so that the quota is decreased from > one. > > With the compute hosts plugin, we manage availability thanks to a resource > planner, based on a fixed set of resources (enrolled compute hosts within > Climate), so we can almost guaranttee this (minus the hosts outages we > could get, of course) > > > >> >> How is this different from 'nova boot?' When nova boot finishes the VM >> is completely ready to be used >> >> > > Nova boot directly creates the VM when the command is issued, while the > proposal here is to defer the booting itself only at the lease start (which > can happen far later than when the lease is created) > > >> >> > - if you're reserving resources far before you'll need them, it'll be >> > cheaper >> >> Why? How does this save a provider money? >> >> > From a cloud operator point of view, don't you think it's way preferrable > to get feedback for future capacity needs ? > Don't you feel it would be interesting for him to propose a business model > like this ? > > > > >> >> "Reserved Instances provide a capacity reservation so that you can >> have confidence in your ability to launch the number of instances you >> have reserved when you need them." >> https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ >> >> Amazon does guarantee the resource will be available. Amazon can >> guarantee the resource because they can terminate spot instances at >> wil
Re: [openstack-dev] Nova gate currently broken
Michael, hello. I've found this issue some days ago with oslo.messaging master (and now it's released, as you see..) The main problem here is: *Error importing module nova.openstack.common.sslutils: duplicate option: ca_file* That's because of https://review.openstack.org/#/c/71997/ merged to oslo.messaging - and now released Author changed opts not only in oslo.messaging files, but also in openstack.compute one - sslutils - and we've got duplicate option error with openstack.common.sslutils in nova. As I discussed that with Doug Hellmann (and understood him), on #openstack-dev some days ago, he proposed to merge the same fix to oslo-incubator and then update all other projects using oslo.messaging. Here is the fix: https://review.openstack.org/#/c/76300/ to oslo.incubator Although, I suppose now your idea with simply not using last oslo.messaging release will be much quicker due to code freeze. On Tue, Mar 4, 2014 at 2:38 PM, Michael Still wrote: > Hi. > > You might have noticed that the nova gate is currently broken. I > believe this is related to an oslo.messaging release today, and have > proposed a fix at https://review.openstack.org/#/c/77844/ > > Cheers, > Michael > > -- > Rackspace Australia > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
; each service should support natively. > * Reserved Volume: Not sure how that works. > * Virtual Private Cloud. It would be great to see OpenStack support a > hardware isolated virtual private cloud, but not sure what the best > way to implement that is. > * Capacity Planning. Sure, but it would be nice to see a more fleshed > out story for it. > > > It would be nice to see more of these use cases discussed. > > > On Mon, Mar 3, 2014 at 11:16 AM, Joe Gordon wrote: > > On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague wrote: > >> On 03/03/2014 01:35 PM, Joe Gordon wrote: > >>> On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter > wrote: > >>>> On 03/03/14 12:32, Joe Gordon wrote: > >>>>>> > >>>>>>> - if you're reserving resources far before you'll need them, it'll > be > >>>>>>> cheaper > >>>>> > >>>>> Why? How does this save a provider money? > >>>> > >>>> > >>>> If an operator has zero information about the level of future demand, > they > >>>> will have to spend a *lot* of money on excess capacity or risk > running out. > >>>> If an operator has perfect information about future demand, then they > need > >>>> spend no money on excess capacity. Everywhere in between, the amount > of > >>>> extra money they need to spend is a non-increasing function of the > amount of > >>>> information they have. QED. > >>> > >>> Sure. if an operator has perfect information about future demand they > >>> won't need any excess capacity. But assuming you know some future > >>> demand, how do you figure out how much of the future demand you know? > >>> But sure I can see this as a potential money saver, but unclear by how > >>> much. The Amazon model for this is a reservation is at minimum a year, > >>> I am not sure how useful short term reservations would be in > >>> determining future demand. > >> > >> There are other useful things with reservations though. In a private > >> context the classic one is running number for close of business. Or > >> software team that's working towards a release might want to preallocate > >> resources for longer scale runs during a particular week. > > > > Why can't they pre-allocate now? > > > >> > >> Reservation can really be about global policy giving some tenants more > >> priority in getting resources than others (because you pre-allocate > them). > >> > >> I also know that with a lot of the HPC teams using OpenStack, this is a > >> fundamental part of scheduling. Not just the when, but the how long. > >> Having systems automatically get reaped after a certain amount of time > >> is something they very much want. > > > > Agreed, I think this should either be part of Nova or Heat directly. > > > >> > >> So I think the general idea have merrit. I just think we need to make > >> sure it integrates well with the rest of OpenStack, which I believe > >> means strong coupling to the scheduler. > >> > >> -Sean > >> > >> -- > >> Sean Dague > >> Samsung Research America > >> s...@dague.net / sean.da...@samsung.com > >> http://dague.net > >> > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse
Sam, It really looks like you're having old *.pyc files locally in this repo (probably left from other branch testing)... As I understood, you just cloned clean repo and first tests you've ran were these ones? If no, removing all *.pyc files will help you, otherwise I have no clear idea why you might have unit tests failing in the new just cloned repository... Need to investigate. Cheers, Dina On Wed, Dec 3, 2014 at 12:34 PM, sam song wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, folks: > > I clone the stable/icehouse branch of ceilometer project from github, > use "tox -r -e py26" to run unit tests on CentOS 6.5 system. > Unfortunately there are many cases failed. You can find the output in > test.log, and pip.log is the output of "pip list" in py26 virtualenv. > All python packages are download from pypi.douban.com in China, which is > fresh according to http://www.pypi-mirrors.org/. > > Any ideas to fix it are appreciated. > Thanks in advance. > > Sam > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iQEcBAEBAgAGBQJUftk7AAoJEPDWvv0r0XeReC4IAKh+cN2JHGsOEd3/VUsdBnMi > Bxlvjp0uzMB8vs2zOljLntf9XZGjPBoOWZcwArYHL3aLe1A+cHxXqm6Y+i0zLmJ2 > jf0oV4War+MliptaJNE6BH9URBZ4p2WqxL2k6+V9SP+9dkCHjzTIOZ4zO31jbZy3 > P7lfTzQELYAys4CFl3kEV/hm2JIPZXvpVUYGdCEYBc3CVcopCq+wDBChnQx3tIhh > ao4KXzx/fOHQK2HLSiv+p2y4XNWDIMA8wpGyjn97JL/eF+lckrVIBd3zFlpT+VtE > nidK+rjzWpSDdObEKdEXh+C0jy0S5uBrSU+5hba0GNRVUbnnXP5jHrsP7HZ6900= > =mwtP > -END PGP SIGNATURE- > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] nominating Pablo Andres Fuente for the Climate core reviewers team
I propose to add Pablo Andreas Fuente (pafuent on the IRC) to Climate core team. He's Python contributor from Intel, and he took great part in Climate development including design suggestions and great ideas. He has been quite active during the Icehouse and given his skills, interest and background I suppose it'll be great to add him to the team. Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] nominating Pablo Andres Fuente for the Climate core reviewers team
Well, as 3/4 core team members are okay with it, I'll do this) On Thu, Apr 24, 2014 at 2:14 PM, Sylvain Bauza wrote: > http://russellbryant.net/openstack-stats/climate-reviewers-90.txt > > As per the stats, +1 to this. > > > 2014-04-24 12:10 GMT+02:00 Dina Belova : > >> I propose to add Pablo Andreas Fuente (pafuent on the IRC) to Climate >> core team. >> >> He's Python contributor from Intel, and he took great part in Climate >> development including design suggestions and great ideas. He has been >> quite active during the Icehouse and given his skills, interest and >> background I suppose it'll be great to add him to the team. >> >> Best regards, >> >> Dina Belova >> >> Software Engineer >> >> Mirantis Inc. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Meeting minutes
Christian, variant #2 looks good to me) On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian < christian.marti...@intel.com> wrote: > Hello, > > One comment regarding > https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud: > > One of Dina’s comments on the https://review.openstack.org/#/c/89833/ was > that it is her intention to not add this functionality into v1 API. > > If that’s the case, then the changes I proposed for the climateclient at > https://review.openstack.org/#/c/89837/ won’t make sense since the client > only works with v1 API. > > I see a couple of options here: > > · Give support for v1 and change the client accordantly > > · Give support only on v2, and open a bp for climateclient v2 > support. > > > > Hope I make myself clear. > > I’ll be waiting for your feedback J > > > > Regards, > > Christian > > *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com] > *Sent:* Friday, April 25, 2014 1:04 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Climate] Meeting minutes > > > > Hi, > > > > Sorry again about my non-presence for 20 mins, I had an IRC > client/connection issue. > > That impacted much the discussions, feel free to reply to this email with > any concerns you didn't had time to raise on the meeting, so we could > continue. > > > > That said, meeting minutes can be found here : > > > > (18:00:32) openstack: Minutes: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html > (18:00:33) openstack: Minutes (text): > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt > (18:00:34) openstack: Log: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html > > > > Thanks, > > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Climate] Meeting minutes
I'm ok with these steps))) Abandoning is very simple - just click "Abandon" button there ;) On Mon, Apr 28, 2014 at 4:21 PM, Martinez, Christian < christian.marti...@intel.com> wrote: > Great then! > > So new steps will be: > > · Abandon the https://review.openstack.org/#/c/89837/ (I never > done that, so I’ll need some help on that) > > · Open a bp for v2 support (I can do that) > > · Start working on the v2 client (I can also help with that) > > · Anything that you guys consider necessary > > > > Is that OK for you? > > > > Thanks in advance, > > Christian > > > > *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com] > *Sent:* Sunday, April 27, 2014 1:56 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Climate] Meeting minutes > > > > Agree with Dina, we should support V2 here. > > Sorry, I had no time for delivering a new client, but as V1 and V2 are > quite identical, I can take this blueprint. > > > > -Sylvain > > > > 2014-04-27 17:44 GMT+02:00 Dina Belova : > > Christian, variant #2 looks good to me) > > > > On Fri, Apr 25, 2014 at 9:59 PM, Martinez, Christian < > christian.marti...@intel.com> wrote: > > Hello, > > One comment regarding > https://blueprints.launchpad.net/climate/+spec/before-end-notification-crud: > > One of Dina’s comments on the https://review.openstack.org/#/c/89833/ was > that it is her intention to not add this functionality into v1 API. > > If that’s the case, then the changes I proposed for the climateclient at > https://review.openstack.org/#/c/89837/ won’t make sense since the client > only works with v1 API. > > I see a couple of options here: > > · Give support for v1 and change the client accordantly > > · Give support only on v2, and open a bp for climateclient v2 > support. > > > > Hope I make myself clear. > > I’ll be waiting for your feedback J > > > > Regards, > > Christian > > *From:* Sylvain Bauza [mailto:sylvain.ba...@gmail.com] > *Sent:* Friday, April 25, 2014 1:04 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [Climate] Meeting minutes > > > > Hi, > > > > Sorry again about my non-presence for 20 mins, I had an IRC > client/connection issue. > > That impacted much the discussions, feel free to reply to this email with > any concerns you didn't had time to raise on the meeting, so we could > continue. > > > > That said, meeting minutes can be found here : > > > > (18:00:32) openstack: Minutes: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.html > (18:00:33) openstack: Minutes (text): > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.txt > (18:00:34) openstack: Log: > http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-04-25-15.00.log.html > > > > Thanks, > > -Sylvain > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] cancelling team meeting for May 1st
Okay, thanks! Have a nice holiday then) On Mon, Apr 28, 2014 at 5:06 PM, Eoghan Glynn wrote: > > > > Hi Folks, > > > > Since our French, Hungarian, Chinese, Russian and Slovenian contributors > > (geo-diversity WTF!) will all be celebrating International Workers' Day > > A dyslexic moment: I meant geo-diversity FTW! :) > > > on May 1st, let's skip the weekly meeting. > > > > If anything pressing comes up, let's just have an emergent discussion to > > deal with it on Wednesday. > > > > Cheers, > > Eoghan > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] Friday Meeting
Folks, o/ I finally got my dates for the US trip, and I have to say, that I won't be able to attend our closest Friday meeting as I'll be flying at this moment) Sylvain, will you be able to hold the meeting? Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] Friday Meeting
+1 On Wed, Apr 30, 2014 at 11:41 PM, Sylvain Bauza wrote: > Hi Dina, > > I forgot yesterday to mention it was my last day at Bull, so the end of > week was off-work until Monday. > As a corollar, I won't be able to attend Friday meeting. > > Let's cancel this meeting and raise topics in mailing-list if needed. > > -Sylvain > > > 2014-04-30 19:17 GMT+02:00 Dina Belova : > >> Folks, o/ >> >> I finally got my dates for the US trip, and I have to say, that I won't >> be able to attend our closest Friday meeting as I'll be flying at this >> moment) >> >> Sylvain, will you be able to hold the meeting? >> >> Best regards, >> >> Dina Belova >> >> Software Engineer >> >> Mirantis Inc. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Blazar] Weekly meeting Blazar (previously Climate) [Climate]
It's still there, yes. I'll be there with 50% activity, I guess, so I'd like to ask Pablo to be chair on this one. On Fri, May 30, 2014 at 12:44 PM, Sylvain Bauza wrote: > Hi, > > Due to some important changes with Climate (which is now Blazar) and as > the team is quite changing, I want to make sure we run the weekly > meeting today at 3pm UTC. > > Thanks, > -Sylvain > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Blazar] [Ironic] Py26/27 gates failing because of keystoneclient-0.9.0
I did not look close to this concrete issue, but in the ceilometer there is almost the same thing: https://bugs.launchpad.net/ceilometer/+bug/1324885 and fixes were already provided. Will this help Blazar? -- Dina On Fri, May 30, 2014 at 4:00 PM, Sylvain Bauza wrote: > Hi Keystone developers, > > I just opened a bug [1] because Ironic and Blazar (ex. Climate) patches > are failing due to a new release in Keystone client which seems to > regress on midleware auth. > > Do you have any ideas on if it's quick to fix, or shall I provide a > patch to openstack/global-requirements.txt to only accept keystoneclient > < 0.9.0 ? > > Thanks, > -Sylvain > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] New setuptools release seems to break some of the OS projects
Folks, o/ I did not find the appropriate discussion in the ML, so decided to start it myself - I see that new setuptools release seems to break at least some of the OpenStack gates and even more. Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514 It hits Tempest, Ceilometer and Keystoneclient at least due to the discussion in the bug. Some of the variants were discussed in the #openstack-infra channel, but I see no solution found. Do we have idea how to fix it? Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New setuptools release seems to break some of the OS projects
Doug, thanks, will track this bug's solution there. On Mon, Jun 2, 2014 at 4:17 PM, Doug Hellmann wrote: > Alex reported the bug against setuptools > ( > https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation > ) > if you want to track progress. > > Doug > > On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova wrote: > > Folks, o/ > > > > I did not find the appropriate discussion in the ML, so decided to start > it > > myself - I see that new setuptools release seems to break at least some > of > > the OpenStack gates and even more. > > > > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514 > > > > It hits Tempest, Ceilometer and Keystoneclient at least due to the > > discussion in the bug. > > > > Some of the variants were discussed in the #openstack-infra channel, but > I > > see no solution found. > > > > Do we have idea how to fix it? > > > > Best regards, > > > > Dina Belova > > > > Software Engineer > > > > Mirantis Inc. > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New setuptools release seems to break some of the OS projects
The newest setuptools has been removed from the gate mirror - the latest there now is 3.6 - that *might* in the gate. We'll see if it'll help. It looks like there is first successful Neutron job there :) -- Dina On Mon, Jun 2, 2014 at 4:36 PM, Eoghan Glynn wrote: > > > > > Alex reported the bug against setuptools > > ( > https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation > ) > > if you want to track progress. > > > Thanks Doug, > > In the meantime, I'm wondering do we have any way of insulating > ourselves against breakages like this? > > (along the lines of a version-cap that we'd apply in the global > requirements.txt, for dependencies pulled in that way). > > Cheers, > Eoghan > > > > Doug > > > > On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova > wrote: > > > Folks, o/ > > > > > > I did not find the appropriate discussion in the ML, so decided to > start it > > > myself - I see that new setuptools release seems to break at least > some of > > > the OpenStack gates and even more. > > > > > > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514 > > > > > > It hits Tempest, Ceilometer and Keystoneclient at least due to the > > > discussion in the bug. > > > > > > Some of the variants were discussed in the #openstack-infra channel, > but I > > > see no solution found. > > > > > > Do we have idea how to fix it? > > > > > > Best regards, > > > > > > Dina Belova > > > > > > Software Engineer > > > > > > Mirantis Inc. > > > > > > > > > ___ > > > OpenStack-dev mailing list > > > OpenStack-dev@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New setuptools release seems to break some of the OS projects
Folks, setuptools 4.0.1 and 3.7.1 have been released - these should fix the issue. -- Dina On Mon, Jun 2, 2014 at 4:45 PM, Dina Belova wrote: > The newest setuptools has been removed from the gate mirror - the latest > there now is 3.6 - that *might* in the gate. > We'll see if it'll help. It looks like there is first successful Neutron > job there :) > > -- Dina > > > On Mon, Jun 2, 2014 at 4:36 PM, Eoghan Glynn wrote: > >> >> >> >> > Alex reported the bug against setuptools >> > ( >> https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation >> ) >> > if you want to track progress. >> >> >> Thanks Doug, >> >> In the meantime, I'm wondering do we have any way of insulating >> ourselves against breakages like this? >> >> (along the lines of a version-cap that we'd apply in the global >> requirements.txt, for dependencies pulled in that way). >> >> Cheers, >> Eoghan >> >> >> > Doug >> > >> > On Mon, Jun 2, 2014 at 8:07 AM, Dina Belova >> wrote: >> > > Folks, o/ >> > > >> > > I did not find the appropriate discussion in the ML, so decided to >> start it >> > > myself - I see that new setuptools release seems to break at least >> some of >> > > the OpenStack gates and even more. >> > > >> > > Here is the bug: https://bugs.launchpad.net/ceilometer/+bug/1325514 >> > > >> > > It hits Tempest, Ceilometer and Keystoneclient at least due to the >> > > discussion in the bug. >> > > >> > > Some of the variants were discussed in the #openstack-infra channel, >> but I >> > > see no solution found. >> > > >> > > Do we have idea how to fix it? >> > > >> > > Best regards, >> > > >> > > Dina Belova >> > > >> > > Software Engineer >> > > >> > > Mirantis Inc. >> > > >> > > >> > > ___ >> > > OpenStack-dev mailing list >> > > OpenStack-dev@lists.openstack.org >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][messaging] Further improvements and refactoring
Hello, stackers! Oslo.messaging is future of how different OpenStack components communicate with each other, and really I’d love to start discussion about how we can make this library even better then it’s now and how can we refactor it make more production-ready. As we all remember, oslo.messaging was initially inspired to be created as a logical continuation of nova.rpc - as a separated library, with lots of transports supported, etc. That’s why oslo.messaging inherited not only advantages of now did the nova.rpc work (and it were lots of them), but also some architectural decisions that currently sometimes lead to the performance issues (we met some of them while Ceilometer performance testing [1] during the Icehouse). For instance, simple testing messaging server (with connection pool and eventlet) can process 700 messages per second. The same functionality implemented using plain kombu (without connection pool and eventlet) driver is processing ten times more - 7000-8000 messages per second. So we have the following suggestions about how we may make this process better and quicker (and really I’d love to collect your feedback, folks): 1) Currently we have main loop running in the Executor class, and I guess it’ll be much better to move it to the Server class, as it’ll make relationship between the classes easier and will leave Executor only one task - process the message and that’s it (in blocking or eventlet mode). Moreover, this will make further refactoring much easier. 2) Some of the drivers implementations (such as impl_rabbit and impl_qpid, for instance) are full of useless separated classes that in reality might be included to other ones. There are already some changes making the whole structure easier [2], and after the 1st issue will be solved Dispatcher and Listener also will be able to be refactored. 3) If we’ll separate RPC functionality and messaging functionality it’ll make code base clean and easily reused. 4) Connection pool can be refactored to implement more efficient connection reusage. Folks, are you ok with such a plan? Alexey Kornienko already started some of this work [2], but really we want to be sure that we chose the correct vector of development here. Thanks! [1] https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing [2] https://review.openstack.org/#/q/status:open+owner:akornienko+project:openstack/oslo.messaging,n,z Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][messaging] Further improvements and refactoring
Dims, No problem with creating the specs, we just want to understand if the community is OK with our suggestions in general :) If so, I'll create the appropriate specs and we'll discuss them :) Thanks -- Dina On Tue, Jun 10, 2014 at 3:31 PM, Davanum Srinivas wrote: > Dina, Alexey, > > Do you mind filing some spec(s) please? > > http://markmail.org/message/yqhndsr3zrqcfwq4 > http://markmail.org/message/kpk35uikcnodq3jb > > thanks, > dims > > On Tue, Jun 10, 2014 at 7:03 AM, Dina Belova wrote: > > Hello, stackers! > > > > > > Oslo.messaging is future of how different OpenStack components > communicate > > with each other, and really I’d love to start discussion about how we can > > make this library even better then it’s now and how can we refactor it > make > > more production-ready. > > > > > > As we all remember, oslo.messaging was initially inspired to be created > as a > > logical continuation of nova.rpc - as a separated library, with lots of > > transports supported, etc. That’s why oslo.messaging inherited not only > > advantages of now did the nova.rpc work (and it were lots of them), but > also > > some architectural decisions that currently sometimes lead to the > > performance issues (we met some of them while Ceilometer performance > testing > > [1] during the Icehouse). > > > > > > For instance, simple testing messaging server (with connection pool and > > eventlet) can process 700 messages per second. The same functionality > > implemented using plain kombu (without connection pool and eventlet) > driver > > is processing ten times more - 7000-8000 messages per second. > > > > > > So we have the following suggestions about how we may make this process > > better and quicker (and really I’d love to collect your feedback, folks): > > > > > > 1) Currently we have main loop running in the Executor class, and I guess > > it’ll be much better to move it to the Server class, as it’ll make > > relationship between the classes easier and will leave Executor only one > > task - process the message and that’s it (in blocking or eventlet mode). > > Moreover, this will make further refactoring much easier. > > > > 2) Some of the drivers implementations (such as impl_rabbit and > impl_qpid, > > for instance) are full of useless separated classes that in reality > might be > > included to other ones. There are already some changes making the whole > > structure easier [2], and after the 1st issue will be solved Dispatcher > and > > Listener also will be able to be refactored. > > > > 3) If we’ll separate RPC functionality and messaging functionality it’ll > > make code base clean and easily reused. > > > > 4) Connection pool can be refactored to implement more efficient > connection > > reusage. > > > > > > Folks, are you ok with such a plan? Alexey Kornienko already started > some of > > this work [2], but really we want to be sure that we chose the correct > > vector of development here. > > > > > > Thanks! > > > > > > [1] > > > https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing > > > > [2] > > > https://review.openstack.org/#/q/status:open+owner:akornienko+project:openstack/oslo.messaging,n,z > > > > > > Best regards, > > > > Dina Belova > > > > Software Engineer > > > > Mirantis Inc. > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Davanum Srinivas :: http://davanum.wordpress.com > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Thierry, hello. > Anne Gentle wrote: > > It feels like it should be part of a scheduler or reservation program > > but we don't have one today. We also don't have a workflow, planning, or > > capacity management program, all of which these use cases could fall under. > > > > (I should know this but) What are the options when a program doesn't > > exist already? Am I actually struggling with a scope expansion beyond > > infrastructure definitions? I'd like some more discussion by next week's > > TC meeting. > > When a project files for incubation and covers a new scope, they also > file for a new program to go with it. Yes, we've prepared 'Resource Reservation' program - but it seems to me, that now we should reexamine it due to idea of common program for Gantt and Climate, and, probably, Mistral (as Anne said >>> We also don't have a workflow, planning, or capacity management program, all of which these use cases could fall under. <<<) > Dina Belova wrote: > > I think your idea is really interesting. I mean, that thought "Gantt - > > where to schedule, Climate - when to schedule" is quite understandable > > and good looking. > > Would Climate also be usable to support functionality like Spot > Instances ? "Schedule when spot price falls under X" ? Really good question. Personally I think that Climate might help implementing this feature, but probably it's not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: * that might be done by *online* counting of free capacity. If so, that's something that might be managed by billing service - price counting due to current load. In this case I can imagine hardly how lease service might help - that will be only some approximate capacity planning help in future * there is other way - if every instance in cloud will be reserved via Climate (so there will be full planning). If so, Climate will know for sure what and when will be running. And price will be some priority stuff there - due to it not started leases will be rescheduled. Like if capacity load in moment X is Y and user gives price Z for some VM and it's more than minimal price counted for that X moment, his VM will be leased for X. If not, place for VM will be found later. It were some quick thoughts about this idea, I'm pretty sure there might be some other variants about it. Thanks Dina On Wed, Mar 5, 2014 at 7:35 PM, Thierry Carrez wrote: > Dina Belova wrote: > > I think your idea is really interesting. I mean, that thought "Gantt - > > where to schedule, Climate - when to schedule" is quite understandable > > and good looking. > > Would Climate also be usable to support functionality like Spot > Instances ? "Schedule when spot price falls under X" ? > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Sylvain, I love your idea. As you said, that should be designed, but for the first sight your proposal looks quite nice. On Thu, Mar 6, 2014 at 3:11 PM, Sylvain Bauza wrote: > Hi Thierry, > > > 2014-03-06 11:46 GMT+01:00 Thierry Carrez : > > Dina Belova wrote: >> >> Would Climate also be usable to support functionality like Spot >> >> Instances ? "Schedule when spot price falls under X" ? >> > >> > Really good question. Personally I think that Climate might help >> > implementing this feature, but probably it's not the main thing that >> > will work there. >> > >> > Here are my concerns about it. Spot instances require way of counting >> > instance price: >> > [...] >> >> Not necessarily. It's a question of whether Climate would handle only >> "schedule at" (a given date), or more generally "schedule when" (a >> certain event happens, with date just being one event type). You can >> depend on some external system setting spot prices, or any other >> information, and climate rules that would watch regularly that external >> information to decide if it's time to run resources or not. I don't >> think it should be Climate's responsibility to specifically maintain >> spot price, everyone can come up with their own rules. >> >> > > I can't agree more on this. The goal of Climate is to provide some formal > contract agreement in betwen an user and the Reservation service, for > ensuring that the order will be placed and served correctly (with regards > to quotas and capacity). Of course, what we call 'user' doesn't formally > tend to be a 'real' user. > About spot instances use-case, I don't pretend to design it, but I could > easily imagine that a call to Nova for booting an instance would place an > order to Climate with a specific type of contract (what we began to call > 'best-effort' and which needs to be implemented yet) where notifications > for acquitting the order would come from Ceilometer (for instance). If no > notifications come to Climate, the lease would not be honored. > > See https://wiki.openstack.org/wiki/Climate#Lease_types_.28concepts.29 for > best-effort definition of a lease. > > -Sylvain > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Hello, OS folks! Thanks everyone for taking part in our weekly meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-07-15.01.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] New name voting results (round #2)
Hello everyone! I've closed round #2 of new name choosing voting for Climate: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_e2f53ce1b331590f *Blazar* is the most popular variant, heh :) 1. *Blazar* (Not defeated in any contest vs. another choice)2. Forecast, loses to Blazar by 6-53. Prophecy, loses to Forecast by 6-34. Reserva, loses to Prophecy by 5-45. Cast, loses to Reserva by 7-4 I remind you, that we needed new name because of some PyPi and readthedocs repos issues + trademark possible issues :) Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Thanks TC for spending time on Blazar (ex. Climate, in process of renaming) discussion! It was decided that potentially reservation idea is interesting for OS and it'll be great to have cross-project session on ongoing Atlanta Summit and discuss future of reservation/scheduling management in OpenStack. Here is link to cross-project session proposal: http://summit.openstack.org/cfp/details/45 Thanks everyone and let's keep working on that idea. Dina On Fri, Mar 7, 2014 at 12:56 PM, Thierry Carrez wrote: > Dina Belova wrote: > > I'd like to request Climate project review for incubation. Here is > > official incubation application: > > > > https://wiki.openstack.org/wiki/Climate/Incubation > > After watching this thread a bit, it looks like this is more a > preemptive "where fo I fit" advice request than a formal incubation > request. > > These are interesting questions, and useful answers to projects. We (the > TC) may need an avenue for projects to request such feedback without > necessarily engaging in a formal incubation request... > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
> > The biggest concern seemed to be that we weren't sure whether Climate > makes sense as an independent project or not. We think it may make more > sense to integrate what Climate does today into Nova directly. More > generally, we think reservations of resources may best belong in the > APIs responsible for managing those resources, similar to how quota > management for resources lives in the resource APIs. > There is some expectation that this type of functionality will extend > beyond Nova, but for that we could look at creating a shared library of > code to ease implementing this sort of thing in each API that needs it. Russel, sure. I guess we'll discuss that more carefully on summit, and I love see that feature implemented in the best way it should be done. I think in person discussion will help here much. I'm hoping to collect more feedback before summit to have multiple view on this problem. I truly agree with the fact that possibly users should not use a separate > API for reserving resources, but that would be worth duty for the project > itself (Nova, Cinder or even Heat). That said, we think that there is need > for having a global ordonancer managing resources and not siloing the > resources. Hence that's why we still think there is still a need for a > Climate Manager. > Once I said that, there are different ways to plug in with the Manager, > our proposal is to deliver a REST API and a python client so that there > could be still some operator access for managing the resources if needed. > The other way would be to only expose an RPC interface like the scheduler > does at the moment but as the move to Pecan/WSME is already close to be > done (reviews currently in progress), that's still a good opportunity for > leveraging the existing bits of code. Sylvain, I quite agree with you. -- Dina On Wed, Mar 12, 2014 at 8:14 PM, Sylvain Bauza wrote: > Hi Russell, > Thanks for replying, > > > 2014-03-12 16:46 GMT+01:00 Russell Bryant : > > On 03/12/2014 07:35 AM, Dina Belova wrote: >> > Thanks TC for spending time on Blazar (ex. Climate, in process of >> > renaming) discussion! >> > >> > It was decided that potentially reservation idea is interesting for OS >> > and it'll be great to have cross-project session on ongoing Atlanta >> > Summit and discuss future of reservation/scheduling management in >> OpenStack. >> > >> > Here is link to cross-project session proposal: >> > >> > http://summit.openstack.org/cfp/details/45 >> > >> > Thanks everyone and let's keep working on that idea. >> >> Yes, I do think it would be useful to discuss this in person. However, >> I don't think that was the most important feedback from the TC meeting. >> >> The biggest concern seemed to be that we weren't sure whether Climate >> makes sense as an independent project or not. We think it may make more >> sense to integrate what Climate does today into Nova directly. More >> generally, we think reservations of resources may best belong in the >> APIs responsible for managing those resources, similar to how quota >> management for resources lives in the resource APIs. >> >> There is some expectation that this type of functionality will extend >> beyond Nova, but for that we could look at creating a shared library of >> code to ease implementing this sort of thing in each API that needs it. >> > > > That's really a good question, so maybe I could give some feedback on how > we deal with the existing use-cases. > About the possible integration with Nova, that's already something we did > for the virtual instances use-case, thanks to an API extension responsible > for checking if a scheduler hint called 'reservation' was spent, and if so, > take use of the python-climateclient package to send a request to Climate. > > I truly agree with the fact that possibly users should not use a separate > API for reserving resources, but that would be worth duty for the project > itself (Nova, Cinder or even Heat). That said, we think that there is need > for having a global ordonancer managing resources and not siloing the > resources. Hence that's why we still think there is still a need for a > Climate Manager. > > Once I said that, there are different ways to plug in with the Manager, > our proposal is to deliver a REST API and a python client so that there > could be still some operator access for managing the resources if needed. > The other way would be to only expose an RPC interface like the scheduler > does at the moment but as the move to Pecan/WSME is already close to be > done (reviews cu
Re: [openstack-dev] Climate Incubation Application
Heat). That said, we think that > > there is need for having a global ordonancer managing resources and not > > siloing the resources. Hence that's why we still think there is still a > > need for a Climate Manager. > > What we need to dig in to is *why* do you feel it needs to be global? > > I'm trying to understand what you're saying here ... do you mean that > since we're trying to get to where there's a global scheduler, that it > makes sense there should be a central point for this, even if the API is > through the existing compute/networking/storage APIs? > > If so, I think that makes sense. However, until we actually have > something for scheduling, I think we should look at implementing all of > this in the services, and perhaps share some code with a Python library. > So, I'm thinking along the lines of ... > > 1) Take what Climate does today and work to integrate it into Nova, > using as much of the existing Climate code as makes sense. Be careful > about coupling in Nova so that we can easily split out the right code > into a library once we're ready to work on integration in another project. > > 2) In parallel, continue working on decoupling nova-scheduler from the > rest of Nova, so that we can split it out into its own project. > > 3) Once the scheduler is split out, re-visit what part of reservations > functionality belongs in the new scheduling project and what parts > should remain in each of the projects responsible for managing resources. > > > Once I said that, there are different ways to plug in with the Manager, > > our proposal is to deliver a REST API and a python client so that there > > could be still some operator access for managing the resources if > > needed. The other way would be to only expose an RPC interface like the > > scheduler does at the moment but as the move to Pecan/WSME is already > > close to be done (reviews currently in progress), that's still a good > > opportunity for leveraging the existing bits of code. > > Yes, I would want to use as much of the existing code as possible. > > As I said above, I just think it's premature to make this its own > project on its own, unless we're able to look at scheduling more broadly > as its own project. > > -- > Russell Bryant > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Hello stackers! Thanks everyone who took part in our meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-14-15.09.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Hello stackers! Thanks everyone who was attending our meeting :) Meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-21-15.00.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Climate] Meeting minutes
Hello stackers! Thanks for taking part in our meeting - meeting minutes are: Minutes: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.txt Log: http://eavesdrop.openstack.org/meetings/climate/2014/climate.2014-03-28-15.00.log.html Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] PTL Candidacy
Howdy, folks! I'd like to announce my wish to continue being Climate PTL during next Juno release cycle. I have been working on Climate initiative since really early stages of its development and was leading the subteam responsible for the implementation of core Climate functionality and virtual reservations possibility. I was chosen as a technical leader for this project about 4 months ago and would like to continue being the one. During previous development cycle I was really focused on making Climate work for both original use cases and improving not only its functionality but also a technical level, integrating with oslo.messaging and improving documentation coverage. We had our first release created, and currently I'm coordinating efforts of all our contributors trying to help them making Climate better without overlaps and unnecessary actions. For Juno release cycle I'd love to continue my Climate activities including code reviews, release management, IRC meeting holding and coordination. As for Climate itself I'm planning to present it on Atlanta summit and decide its overall future with OS community, focus on implementing new resources reservations and new flow for leases creation, not forgetting about energy efficiency feature and Tempest testing. My changes history [1] and reviews history [2] might be found below. [1] http://stackalytics.com/?release=all&metric=commits&project_type=all&module=climate&company=&user_id=dbelova [2] http://stackalytics.com/?release=all&metric=marks&project_type=all&module=climate&company=&user_id=dbelova Thanks! Dina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
