Re: [openstack-dev] [climate] PTL elections: nominations
Nominations closed. Here is the list of candidates: https://wiki.openstack.org/wiki/Climate/PTL_Elections_Icehouse#Candidates I'll setup voting soon. Thanks. On Thu, Dec 19, 2013 at 6:06 PM, Sergey Lukjanov slukja...@mirantis.comwrote: Hey all, It was decided to choose the PTL for Climate project and I've volunteered to handle it. All important questions was discussed on the last IRC team meeting [1]. You can find details on a wiki page [2]. So, we'd like to choose PTL for the rest Icehouse release cycle. To announce your candidacy please write to openstack-dev at lists.openstack.org mailing list thread with the following subject: [climate] PTL Candidacy. I'll confirm nomination and add your candidacy to the wiki page. Nominations are now opened and will remain open until 23:59 UTC December 24, 2013. Elections will be opened for Dec 25 - Jan 2. [1] http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-12-17-09.59.html [2] https://wiki.openstack.org/wiki/Climate/PTL_Elections_Icehouse Thanks. -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. -- 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
Re: [openstack-dev] Devstack Ceph
On 12/24/2013 07:49 PM, Sebastien Han wrote: Hello everyone, I’ve been working on a new feature for Devstack that includes a native support for Ceph. The patch includes the following: * Ceph installation (using the ceph.com repo) * Glance integration * Cinder integration (+ nova virsh secret) * Cinder backup integration * Partial Nova integration since master is currently broken. Lines are already there, the plan is to un-comment those lines later. * Everything works with Cephx (Ceph authentification system). Does anyone will be interested to see this going into Devstack mainstream? Cheers. Sébastien Han I very very much welcome your effort here. I have found it very unfortunate that OpenStack lost compatibility with Ceph boot-from-volume on the Havana release, and it's super nice to see that thanks to you, this mistake may never happen again! Cheers, Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [climate] PTL electinos: voting
Hi, voting for the PTL has been started and will continue till the 17:59 UTC January 4, 2014. You'll receive an email from Sergey Lukjanov (CIVS poll supervisor) slukja...@mirantis.com and subject Poll: Climate PTL Election. Thanks, have a good holidays. -- 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
Re: [openstack-dev] [OpenStack-Infra][qa][Tempest][Network] [Infra]Test for external connectivity
Hi, I wanted to retrieve the gate's DNS server (or google's 8.8.8.8) in order to check external connectivity, but I've been told that I'm running the risk of getting the Jenkins gate blacklisted by either DNS server. It was also brought to my attention, that testing actual external connectivity is not really helpful because my current test actually tests the external server's resolution ability and not the actual Openstack instance. So Here's my question: Infra - suppose that I can get devstack to configure it's own DNS server into tempest.conf (from resolve.conf), could I get the gate blacklisted for abusing the DNS (either local or google's) Neutron/Tempest/Maru - What is there to gain from pinging an external address/url? Could pinging the public network's default GW be enough? Please take into account the fact that we now have CrossTenant test checking L3 routing Yair - Original Message - From: Yair Fried yfr...@redhat.com To: openstack-in...@lists.openstack.org Sent: Monday, December 23, 2013 5:57:44 PM Subject: [OpenStack-Infra] Fwd: [openstack-dev] [Openstack][qa][Tempest][Network] [Infra]Test for external connectivity - Forwarded Message - From: Yair Fried yfr...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Sunday, December 22, 2013 10:00:52 PM Subject: Re: [openstack-dev] [Openstack][qa][Tempest][Network] [Infra]Test for external connectivity Hi Guys, So, I'm done with my patch: https://review.openstack.org/#/c/55146 1. ping an external IP 2. ping a url to test the dns 3. check VM's resolve.conf 4. change the dns server and recheck resolve.conf My issue now (same as before) is that this test cannot be executed (and therefore pass) on the gate unless the gate is configured for external connectivity. A. How do I get the neutron gate to allow it's VM external connectivity (i.e. ping 8.8.8.8)? Considering Jeremy's comment, I agree that depending on external ip/url introduces an unnecessary point of failure. However IMO, using multiple addresses is not the best way to proceed , I'd rather test against a local node. Therefore: B. Can I get the neutron gate to enter it's own (local) DNS server? A local url? C. I this a change I can push to some project by myself, or do I need someone to change this for me (infra?)? I would really like your input in this matter, as I am in the final stretch of this patch and cannot move any farther by myself Regards Yair Fried - Original Message - From: Jeremy Stanley fu...@yuggoth.org To: openstack-dev@lists.openstack.org Sent: Thursday, November 21, 2013 12:17:52 AM Subject: Re: [openstack-dev] [Openstack][qa][Tempest][Network] Test for external connectivity On 2013-11-20 14:07:49 -0800 (-0800), Sean Dague wrote: On 11/18/2013 02:41 AM, Yair Fried wrote: [...] 2. add fields in tempest.conf for * external connectivity = False/True * external ip to test against (ie 8.8.8.8) +1 for #2. In the gate we'll need to think about what that address can / should be. It may be different between different AZs. At this point I'd leave the rest of the options off the table until #2 is working reliably. [...] Having gone down this path in the past, I suggest the test check for no fewer than three addresses, sending several probes to each, and be considered successful if at least one gets a response. -- Jeremy Stanley ___ 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-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] PTL electinos: voting
Hi. I know that's pretty late for asking but could we consider having a quorum for voting ? As the election is running during vacations for most of the team, my concern is to make sure there are enough voters. Thanks, Sylvain Le 25 déc. 2013 11:08, Sergey Lukjanov slukja...@mirantis.com a écrit : Hi, voting for the PTL has been started and will continue till the 17:59 UTC January 4, 2014. You'll receive an email from Sergey Lukjanov (CIVS poll supervisor) slukja...@mirantis.com and subject Poll: Climate PTL Election. Thanks, have a good holidays. -- 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][qa][Tempest][Network] Test for external connectivity
On 11/18/2013 08:19 PM, Salvatore Orlando wrote: Basically I think we can assume test machines have access to the Internet IMO, we should assume test machines doesn't. It's a too dangerous assumption to make. I assume you want to check servers such as www.google.com http://www.google.com are reachable I don't know why we would like to check for www.google.com by default, especially one which is geo-distributed, and for which the IPs are changing without any warning. Why not using a domain which we control, like www.openstack.org? but the routing from the external_gateway_ip to the final destination is beyond's Neutron control. DNS resolution might be interesting, but however I think resolution of external names is too beyond Neutron's control. Agreed. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] PTL electinos: voting
Hey Sylvain, That's why I've already added several more days (Dec 25 - Jan 4). Are you expecting that someone will not be available for this period? Currently, we have 70% participation (poll have been started 18h ago). On Thu, Dec 26, 2013 at 2:27 AM, Sylvain Bauza sylvain.ba...@gmail.comwrote: Hi. I know that's pretty late for asking but could we consider having a quorum for voting ? As the election is running during vacations for most of the team, my concern is to make sure there are enough voters. Thanks, Sylvain Le 25 déc. 2013 11:08, Sergey Lukjanov slukja...@mirantis.com a écrit : Hi, voting for the PTL has been started and will continue till the 17:59 UTC January 4, 2014. You'll receive an email from Sergey Lukjanov (CIVS poll supervisor) slukja...@mirantis.com and subject Poll: Climate PTL Election. Thanks, have a good holidays. -- 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 ___ 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
[openstack-dev] [Openstack] Some question about image provision in openstack
Hi, I come across two question about the image provision and distribute in openstack(nova), 1.Afaik, in current version, nova-compute use the curl to download image from glance (or other places). Are there any alternative methods to choose (such torrent)? 2.In fact, to boot a VM above hypervisor (e.g.,KVM, Xen), there is no need to transfer the whole image-file to local. Will the mechanism to transfer the image on demand on VM booting process makes sense? Thanks, Pengfei Have a nice holiday! Pengfei Zhangakash...@icloud.com Geek, Programmer, Phd Candidate Changsha, Hunan, CN (t) +86 186 8476 1376___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack] Some question about image provision in openstack
Hi, I come across two question about the image provision and distribute in openstack(nova), 1.Afaik, in current version, nova-compute use the curl to download image from glance (or other places). Are there any alternative methods to choose (such torrent)? 2.In fact, to boot a VM above hypervisor, there is no need to transfer the whole image-file to local. Will the mechanism to transfer the image on demand makes sense? Thanks, Pengfei Have a nice holiday! Pengfei Zhangzpfalp...@gmail.com Geek, Programmer, Phd Candidate Changsha, Hunan, CN (t) +86 186 8476 1376 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Member status update mangled with pool stats API
Hi Eugene et al, As of today, during a stats API query, a pool member's status is gathered along with the pool stats and stored in the db. Subsequent GETs to the members will have the correct member status. In this approach, only when a North Bound API call for stats is performed the member's status would get refreshed. This is not desirable and the status should be up-to-date any point of time. My suggestion: We can introduce a new API as part of the driver interface like get_poolmember_statuses(poolid). The LBaaS plugin will call this on a periodic basis to collect member statuses and stores it in the db. HAProxy has taken a back door route to keep the status up-to-date. Here the HAProxy agent starts a periodic task that collects all pool stats + member status and updates the collected data in the db through a plugin driver callback. This approach is not suitable for agent less models. One could argue that a periodic task could be started by the plugin driver instead of the agent, to collect the member statuses. But since this is a requirement from many drivers, it is better to be implemented as part of the LBaaS plugin. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack] Quota delegation tool (for nova) ?
Dear all, I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need. I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake. Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a Quota delegation: - The main resource manager determines the fractions of the resources for each customer - He allocates a quota to each customer by giving it to a computing coordinater which is nominated by the customer - the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment and so on. I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here: - There are people with different roles in this game: +- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager. Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources +- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person above him +- a normal user: persons with this role can only consume resources - several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a 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
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
Hi, Ulrich Currently nova has per-project-user quota support, which was implemented in Havana. We also got some similar thoughts about quota management, here is some related blueprints: https://blueprints.launchpad.net/nova/+spec/per-user-quotas https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management and there are also some discussions to store quota data in keystone you may be interested, https://lists.launchpad.net/openstack/msg11558.html we did not get much progress about multiple level user quota management for now, so i would be glad if you could move this on. Regard, Yingjun 在 2013年12月26日，下午3:00，Ulrich Schwickerath ulrich.schwicker...@cern.ch 写道： Dear all, I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need. I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake. Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a Quota delegation: - The main resource manager determines the fractions of the resources for each customer - He allocates a quota to each customer by giving it to a computing coordinater which is nominated by the customer - the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment and so on. I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here: - There are people with different roles in this game: +- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager. Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources +- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person above him +- a normal user: persons with this role can only consume resources - several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a 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
Re: [openstack-dev] [Openstack] Quota delegation tool (for nova) ?
Hi, Ulrich Currently nova has per-project-user quota support, which was implemented in Havana. We also got some similar thoughts about quota management, here is some related blueprints: https://blueprints.launchpad.net/nova/+spec/per-user-quotas https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management and there are also some discussions to store quota data in keystone you may be interested, https://lists.launchpad.net/openstack/msg11558.html we did not get much progress about multiple level user quota management for now, so i would be glad if you could move this on. Regard, Yingjun 在 2013年12月26日，下午3:00，Ulrich Schwickerath ulrich.schwicker...@cern.ch 写道： Dear all, I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need. I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake. Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a Quota delegation: - The main resource manager determines the fractions of the resources for each customer - He allocates a quota to each customer by giving it to a computing coordinater which is nominated by the customer - the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment and so on. I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here: - There are people with different roles in this game: +- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager. Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources +- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person above him +- a normal user: persons with this role can only consume resources - several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a 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
