[openstack-dev] [Nova] Turbo hipster
Hi, This appears to be broken over the last 24 hours. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Turbo hipster
Hi Gary, Thanks for the notification. Our nodepool had built a corrupt image which was returning false positives. I have fixed this up and rerun tests on changes that had negative votes where Jenkins passed. If you notice any changes that seem like a false negative please issue a recheck migrations. If it fails a second time please let us know at rc...@rcbops.com. FYI, you can see our testing progress at http://zuul.rcbops.com Cheers, Josh Rackspace Australia On 6/29/14 5:48 PM, Gary Kotton wrote: Hi, This appears to be broken over the last 24 hours. Thanks Gary ___ 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] [trove] how to trigger a recheck of reddwarf CI?
The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On 6/28/14 10:40 AM, James E. Blair wrote: An alternate approach would be to have third-party CI systems register jobs with OpenStack's Zuul rather than using their own account. This would mean only a single report of all jobs (upstream and 3rd-party) per-patchset. It significantly reduces clutter and makes results more accessible -- but even with one system we've never actually wanted to have Jenkins results in comments, so I think one of the other options would be preferred. Nonetheless, this is possible with a little bit of work. I agree this isn't the preferred solution, but I disagree with the little bit of work. This would require CI systems registering with gearman which would mean security issues. The biggest problem with this though is that zuul would be stuck waiting from results from 3rd parties which often have very slow return times. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] how to trigger a recheck of reddwarf CI?
Hello, Mat. You need to log into https://rdjenkins.dyndns.org/job/Trove-Gate/ (Auth system uses Launchpad OpenID). Then you need to find certaun job you need to click Retrigger. The End. FYI i already retrigged your job. You're welcome. Best regards, Denis Makogon On Sun, Jun 29, 2014 at 4:34 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ 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] DVR and FWaaS integration
The east/west case is the only case with this asymmetric routing problem being discussed. However, the north/south case might still be interesting from a FWaaS perspective. The fact that the router is distributed in pieces may affect it depending on the firewall implementation. Carl On Jun 28, 2014 10:27 PM, Richard Woo richardwoo2...@gmail.com wrote: Regarding of user case of this feature, are you referring E-W traffic or N-S traffic? On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. --- end of forwarding YI ___ 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
[openstack-dev] [OpenStack-Dev] Conf update forced for stable/icehouse
Hey Everyone, Just noticed some failing jobs on Cinder stable/icehouse due to sample conf being out of date. Looks like some things were added/changed in perhaps OSLO for Redis. My concern is has this been verified for folks that may be using Redis in stable/icehouse. I'm looking to see what the implications might be for existing installs that update their Icehouse bits... I'm not very familiar with these options so I thought I'd raise it here on the ML to make sure folks are aware of it. Deltas in the conf file here [1] Thanks, John [1]: https://review.openstack.org/#/c/103426/1/etc/cinder/cinder.conf.sample ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [third-party] Neutron 3rd Party CI status dashboard
Hi! During last couple weeks there is an increasing demand on tracking 3rd-party CI statuses. We at Stackalytics decided to be in trend and (with some inspiration from Salvatore's proposal) implemented report that shows summary on external CI status. The initial version is available for Neutron - http://stackalytics.com/report/ci/neutron/7 The report shows summary of all CI jobs during specified period of time, including: * stats of runs on merged patch sets: - total number of runs - success rate (success to total ratio) - time of the latest run - last test result * stats for all patch sets (the same set as for merged) * last test results for every merged patch set grouped by days (useful to see how different CIs correlate with each other and how often they run) Under merged patch set report means the last patch set in the merged change request, thus it is almost the same as the trunk code. CI configuration is taken from DriverLog's default data https://git.openstack.org/cgit/stackforge/driverlog/tree/etc/default_data.json. Standard Stackalytics screen is also available for CIs - http://stackalytics.com/?metric=ci, including votes breakdown and activity log. Since this is the first version there are some open questions: * Currently report shows results per CI id, but there are CIs that run tests against multiple drivers and this case is not supported. What would be more useful: to get stats for a driver or for CI? * Most CIs run tests when patch set is posted. So even if change request is merged within selected time period corresponding CI results may be missing. * Patterns for non-voting CIs need to be verified. For example Cisco CI now runs 5 jobs, but DriverLog data still contains old data. Thanks, Ilya 2014-06-16 17:52 GMT+04:00 Salvatore Orlando sorla...@nicira.com: However, it would be great if we could start devising a solution for having health reports from the various CI systems. This report should report the following kind of information: - timestamp of last run - timestamp of last vote (a system might start job which then get aborted for CI infra problems) - % of success vs failures (not sure how important is that one but provides a metric of comparison with upstream jenkins) - % of disagreements with jenkins (this might allow us to quickly spot those CI systems which are randomly -1'ing patches) The percentage metrics might be taken over a 48 hours or 7 days interval, or both. Does this idea sound reasonable? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] oslo.messaging 1.4.0.0a1 released
Thanks Mark! I’ll try reposting my commits for review, now that the new Oslo release is out. PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pcm_ (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 On Jun 28, 2014, at 5:15 PM, Mark McLoughlin mar...@redhat.com wrote: On Fri, 2014-06-27 at 13:28 +, Paul Michali (pcm) wrote: Mark, When would we be able to get a release of Oslo with 102909 fix in? It’s preventing Jenkins passing for some commits in Neutron. I've just pushed 1.4.0.0a2 with the following changes: 244a902 Fix the notifier example a7f01d9 Fix slow notification listener tests da2abaa Fix formatting of TransportURL.parse() docs 13fc9f2 Fix info method of ListenerSetupMixin 0cfafac encoding error in file 0102aa9 Replace usage of str() with six.text_type Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] how to trigger a recheck of reddwarf CI?
On Jun 29, 2014 7:09 PM, Nikhil Manchanda nik...@manchanda.me wrote: Long term, we're looking to move away from running the integration tests in the third party reddwarf-jenkins, so this should soon go away. FWIW, in the short term, the re-trigger permissions are based on the trove-developers group in LaunchPad (https://launchpad.net/~trove). Matt, I've added you as a member of that group, so you should now have retrigger permission in rdjenkins. As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Thanks, Nikhil On Sun, Jun 29, 2014 at 10:27 AM, Denis Makogon dmako...@mirantis.com wrote: Hello, Mat. You need to log into https://rdjenkins.dyndns.org/job/Trove-Gate/ (Auth system uses Launchpad OpenID). Then you need to find certaun job you need to click Retrigger. The End. FYI i already retrigged your job. You're welcome. Best regards, Denis Makogon On Sun, Jun 29, 2014 at 4:34 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] Neutron 3rd Party CI status dashboard
On 06/29/2014 03:25 PM, Ilya Shakhat wrote: Hi! During last couple weeks there is an increasing demand on tracking 3rd-party CI statuses. We at Stackalytics decided to be in trend and (with some inspiration from Salvatore's proposal) implemented report that shows summary on external CI status. The initial version is available for Neutron - http://stackalytics.com/report/ci/neutron/7 The report shows summary of all CI jobs during specified period of time, including: * stats of runs on merged patch sets: - total number of runs - success rate (success to total ratio) - time of the latest run - last test result * stats for all patch sets (the same set as for merged) * last test results for every merged patch set grouped by days (useful to see how different CIs correlate with each other and how often they run) Under merged patch set report means the last patch set in the merged change request, thus it is almost the same as the trunk code. CI configuration is taken from DriverLog's default data https://git.openstack.org/cgit/stackforge/driverlog/tree/etc/default_data.json. Standard Stackalytics screen is also available for CIs - http://stackalytics.com/?metric=ci, including votes breakdown and activity log. Since this is the first version there are some open questions: * Currently report shows results per CI id, but there are CIs that run tests against multiple drivers and this case is not supported. What would be more useful: to get stats for a driver or for CI? * Most CIs run tests when patch set is posted. So even if change request is merged within selected time period corresponding CI results may be missing. * Patterns for non-voting CIs need to be verified. For example Cisco CI now runs 5 jobs, but DriverLog data still contains old data. Thanks, Ilya 2014-06-16 17:52 GMT+04:00 Salvatore Orlando sorla...@nicira.com: However, it would be great if we could start devising a solution for having health reports from the various CI systems. This report should report the following kind of information: - timestamp of last run - timestamp of last vote (a system might start job which then get aborted for CI infra problems) - % of success vs failures (not sure how important is that one but provides a metric of comparison with upstream jenkins) - % of disagreements with jenkins (this might allow us to quickly spot those CI systems which are randomly -1'ing patches) The percentage metrics might be taken over a 48 hours or 7 days interval, or both. Does this idea sound reasonable? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Ilya: I look forward to hearing more about this dashboard and ensuring you or someone else associated with this dashboard are available for questions at the third party meeting tomorrow: https://wiki.openstack.org/wiki/Meetings/ThirdParty We missed you last week. Thanks Ilya, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] Neutron 3rd Party CI status dashboard
On 06/29/2014 07:43 PM, Anita Kuno wrote: On 06/29/2014 03:25 PM, Ilya Shakhat wrote: Hi! During last couple weeks there is an increasing demand on tracking 3rd-party CI statuses. We at Stackalytics decided to be in trend and (with some inspiration from Salvatore's proposal) implemented report that shows summary on external CI status. The initial version is available for Neutron - http://stackalytics.com/report/ci/neutron/7 The report shows summary of all CI jobs during specified period of time, including: * stats of runs on merged patch sets: - total number of runs - success rate (success to total ratio) - time of the latest run - last test result * stats for all patch sets (the same set as for merged) * last test results for every merged patch set grouped by days (useful to see how different CIs correlate with each other and how often they run) Under merged patch set report means the last patch set in the merged change request, thus it is almost the same as the trunk code. CI configuration is taken from DriverLog's default data https://git.openstack.org/cgit/stackforge/driverlog/tree/etc/default_data.json. Standard Stackalytics screen is also available for CIs - http://stackalytics.com/?metric=ci, including votes breakdown and activity log. Since this is the first version there are some open questions: * Currently report shows results per CI id, but there are CIs that run tests against multiple drivers and this case is not supported. What would be more useful: to get stats for a driver or for CI? * Most CIs run tests when patch set is posted. So even if change request is merged within selected time period corresponding CI results may be missing. * Patterns for non-voting CIs need to be verified. For example Cisco CI now runs 5 jobs, but DriverLog data still contains old data. Thanks, Ilya 2014-06-16 17:52 GMT+04:00 Salvatore Orlando sorla...@nicira.com: However, it would be great if we could start devising a solution for having health reports from the various CI systems. This report should report the following kind of information: - timestamp of last run - timestamp of last vote (a system might start job which then get aborted for CI infra problems) - % of success vs failures (not sure how important is that one but provides a metric of comparison with upstream jenkins) - % of disagreements with jenkins (this might allow us to quickly spot those CI systems which are randomly -1'ing patches) The percentage metrics might be taken over a 48 hours or 7 days interval, or both. Does this idea sound reasonable? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Ilya: I look forward to hearing more about this dashboard and ensuring you or someone else associated with this dashboard are available for questions at the third party meeting tomorrow: https://wiki.openstack.org/wiki/Meetings/ThirdParty We missed you last week. Thanks Ilya, Anita. And one question I will have when we discuss this is regarding this statement: Green cell - tests ran successfully, Currently we don't have community consensus around the use of the statement tests ran successfully regarding third party ci systems. This is as statement, you recall, we had discussed at the third party meeting when we talked about driverlog. 18:46:02 krtaylor but what does CI tested really mean? just running tests? or tested to pass some level of requirements? http://eavesdrop.openstack.org/meetings/third_party/2014/third_party.2014-06-16-18.00.log.html Using a statement to convey success prior to having a definition from the community about what the statement means will create confusion in the community and frustration from folks, including myself, who are willing to have the conversation about what it means, who feel circumvented by this second use of a phrase which implies a decided meaning where none yet exists. Please participate in conversations around the definition of phrases of success and failure regarding third party systems and point to the logs where consensus is reached prior it its use in future. In addition to attending the third party meeting, please attend the infra meeting or the qa meeting, and hopefully meetings that include programs that have interactions with third party ci systems including nova, neutron, and cinder (if there are other programs interacting with third party ci systems please attend the third party meeting so I know about you). Thanks Ilya, I look forward to our future discussions, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Meeting this week?
Hi. The meeting this week would be on the 3rd of July, which I assume means that many people will be out of the office. Do people think its worth running the meeting or shall we give this week a miss? Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] Adding filter seach option to python client
Hi, folks! I just noticed that review of cinder backup filter option was verified which Juan has uploaded. https://review.openstack.org/#/c/90996/ I have requested to review the python client side of backup filter option. Please review my code and we use the functions more efficiently. Here is my gerrit revew. https://review.openstack.org/#/c/78233/ Thanks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] how to trigger a recheck of reddwarf CI?
As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Which is one of the major reasons why we're planning on killing the whole third-party rdjenkins tests, and moving all of our trove testing to OpenStack infra. At this point, I'd really like to concentrate our efforts on moving the Trove tests to OpenStack infra (i.e. in Tempest, and functional tests in Infra) rather than on beefing up our rdjenkins third party testing story to align with the third party testing requirements (which is slated to be killed anyway). Also just wanted to clear up some confusion regarding the time frames around this. By short term, I was referring to the next couple weeks. We're looking to get rid of the rdjenkins third party CI by the end of Juno-2. Thanks, Nikhil On Sun, Jun 29, 2014 at 4:24 PM, Joe Gordon joe.gord...@gmail.com wrote: On Jun 29, 2014 7:09 PM, Nikhil Manchanda nik...@manchanda.me wrote: Long term, we're looking to move away from running the integration tests in the third party reddwarf-jenkins, so this should soon go away. FWIW, in the short term, the re-trigger permissions are based on the trove-developers group in LaunchPad (https://launchpad.net/~trove). Matt, I've added you as a member of that group, so you should now have retrigger permission in rdjenkins. As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Thanks, Nikhil On Sun, Jun 29, 2014 at 10:27 AM, Denis Makogon dmako...@mirantis.com wrote: Hello, Mat. You need to log into https://rdjenkins.dyndns.org/job/Trove-Gate/ (Auth system uses Launchpad OpenID). Then you need to find certaun job you need to click Retrigger. The End. FYI i already retrigged your job. You're welcome. Best regards, Denis Makogon On Sun, Jun 29, 2014 at 4:34 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ 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 ___ 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] [trove] how to trigger a recheck of reddwarf CI?
On 06/29/2014 08:38 PM, Nikhil Manchanda wrote: As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Which is one of the major reasons why we're planning on killing the whole third-party rdjenkins tests, and moving all of our trove testing to OpenStack infra. At this point, I'd really like to concentrate our efforts on moving the Trove tests to OpenStack infra (i.e. in Tempest, and functional tests in Infra) rather than on beefing up our rdjenkins third party testing story to align with the third party testing requirements (which is slated to be killed anyway). Also just wanted to clear up some confusion regarding the time frames around this. By short term, I was referring to the next couple weeks. We're looking to get rid of the rdjenkins third party CI by the end of Juno-2. Thanks, Nikhil On Sun, Jun 29, 2014 at 4:24 PM, Joe Gordon joe.gord...@gmail.com wrote: On Jun 29, 2014 7:09 PM, Nikhil Manchanda nik...@manchanda.me wrote: Long term, we're looking to move away from running the integration tests in the third party reddwarf-jenkins, so this should soon go away. FWIW, in the short term, the re-trigger permissions are based on the trove-developers group in LaunchPad (https://launchpad.net/~trove). Matt, I've added you as a member of that group, so you should now have retrigger permission in rdjenkins. As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Thanks, Nikhil Nik and I have talked. Since J2 is too far away to let a system run without recheck capability (as Joe points out, this is not in compliance with third party ci requirements), Nik is currently following up on Sukdev's wiki page (if someone can help Sukdev learn enough wiki markup to get this information off the google doc and into the wiki page, I will be really grateful): https://wiki.openstack.org/wiki/Arista-third-party-testing Nik and I will be staying in contact on this and working to provide a smoother process for developers who need to fire a recheck on this third party ci system. Thank you, Anita. On Sun, Jun 29, 2014 at 10:27 AM, Denis Makogon dmako...@mirantis.com wrote: Hello, Mat. You need to log into https://rdjenkins.dyndns.org/job/Trove-Gate/ (Auth system uses Launchpad OpenID). Then you need to find certaun job you need to click Retrigger. The End. FYI i already retrigged your job. You're welcome. Best regards, Denis Makogon On Sun, Jun 29, 2014 at 4:34 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ 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 ___ 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
Re: [openstack-dev] DVR and FWaaS integration
From real solution scenario, we usually have to integrate hardware to provide tenant north-south traffic. So the DVR should work not only for distributed FWaaS, but also for central FWaaS/SNAT/FIP for north-south traffic. Best Regards Chaoyi Huang ( Joe Huang ) 发件人: Richard Woo [mailto:richardwoo2...@gmail.com] 发送时间: 2014年6月29日 12:23 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] DVR and FWaaS integration Regarding of user case of this feature, are you referring E-W traffic or N-S traffic? On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun beyo...@gmail.commailto:beyo...@gmail.com wrote: All, During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to follow up the issue. To not slow down the discussion, I'm forwarding out the email that I sent out as the follow up to the IRC meeting here, so that whoever may be interested on the topic can continue to discuss about it. First some background about the issue: In the normal case, FW and router are running together inside the same box so that FW can get route and NAT information from the router component. And in order to have FW to function correctly, FW needs to see the both directions of the traffic. DVR is designed in an asymmetric way that each DVR only sees one leg of the traffic. If we build FW on top of DVR, then FW functionality will be broken. We need to find a good method to have FW to work with DVR. ---forwarding email--- During the IRC meeting, we think that we could force the traffic to the FW before DVR. Vivek had more detail; He thinks that since the br-int knowns whether a packet is routed or switched, it is possible for the br-int to forward traffic to FW before it forwards to DVR. The whole forwarding process can be operated as part of service-chain operation. And there could be a FWaaS driver that understands the DVR configuration to setup OVS flows on the br-int. The concern is that normally firewall and router are integrated together so that firewall can make right decision based on the routing result. But what we are suggesting is to split the firewall and router into two separated components, hence there could be issues. For example, FW will not be able to get enough information to setup zone. Normally Zone contains a group of interfaces that can be used in the firewall policy to enforce the direction of the policy. If we forward traffic to firewall before DVR, then we can only create policy based on subnets not the interface. Also, I’m not sure if we have ever planed to support SNAT on the DVR, but if we do, then it depends on at which point we forward traffic to the FW, the subnet may not even work for us anymore (even DNAT could have problem too). Another thing that I may have to get detail is that how we handle the overlap subnet, it seems that the new namespaces are required. --- end of forwarding YI ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Trove] Trove Blueprint Meeting on 30 Jun CANCELLED
Hey folks: There's nothing to discuss on the BP Agenda for this week and most folks are busy working on existing BPs and bugs, so I'd like to cancel the Trove blueprint meeting for this week. See you guys at the regular Trove meeting on Wednesday. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] how to trigger a recheck of reddwarf CI?
On Jun 29, 2014 8:53 PM, Anita Kuno ante...@anteaya.info wrote: On 06/29/2014 08:38 PM, Nikhil Manchanda wrote: As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Which is one of the major reasons why we're planning on killing the whole third-party rdjenkins tests, and moving all of our trove testing to OpenStack infra. At this point, I'd really like to concentrate our efforts on moving the Trove tests to OpenStack infra (i.e. in Tempest, and functional tests in Infra) rather than on beefing up our rdjenkins third party testing story to align with the third party testing requirements (which is slated to be killed anyway). Also just wanted to clear up some confusion regarding the time frames around this. By short term, I was referring to the next couple weeks. We're looking to get rid of the rdjenkins third party CI by the end of Juno-2. Thanks, Nikhil On Sun, Jun 29, 2014 at 4:24 PM, Joe Gordon joe.gord...@gmail.com wrote: On Jun 29, 2014 7:09 PM, Nikhil Manchanda nik...@manchanda.me wrote: Long term, we're looking to move away from running the integration tests in the third party reddwarf-jenkins, so this should soon go away. FWIW, in the short term, the re-trigger permissions are based on the trove-developers group in LaunchPad (https://launchpad.net/~trove). Matt, I've added you as a member of that group, so you should now have retrigger permission in rdjenkins. As per http://ci.openstack.org/third_party.html#requirements this is not an acceptable short term solution. Thanks, Nikhil Nik and I have talked. Since J2 is too far away to let a system run without recheck capability (as Joe points out, this is not in compliance with third party ci requirements), Nik is currently following up on Sukdev's wiki page (if someone can help Sukdev learn enough wiki markup to get this information off the google doc and into the wiki page, I will be really grateful): https://wiki.openstack.org/wiki/Arista-third-party-testing Nik and I will be staying in contact on this and working to provide a smoother process for developers who need to fire a recheck on this third party ci system. Thank you! Thank you, Anita. On Sun, Jun 29, 2014 at 10:27 AM, Denis Makogon dmako...@mirantis.com wrote: Hello, Mat. You need to log into https://rdjenkins.dyndns.org/job/Trove-Gate/ (Auth system uses Launchpad OpenID). Then you need to find certaun job you need to click Retrigger. The End. FYI i already retrigged your job. You're welcome. Best regards, Denis Makogon On Sun, Jun 29, 2014 at 4:34 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: The reddwarf 3rd party CI is failing on an oslo sync patch [1] but Jenkins is fine, I'm unable to find any wiki or guideline on how to recheck just the reddwarf CI, is that possible? [1] https://review.openstack.org/#/c/103232/ -- Thanks, Matt Riedemann ___ 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 ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][baremetal] Scheduling baremetal deployment on different hw model
Hi, I am working on deploying images to bare-metal machines using nova bare-metal. My datacenter has 2 types of hw models, IBM and Dell. In existing implementation, if I want to deploy image on specified type of hw model, I need to setup 2 baremetal compute nodes, one for container of IBM machine, the other for Dell machine. Then baremetal register machines to their corresponding compute node. Finally use nova flavor and heterogeneous group to map specified compute node so I can explicitly specify the hw model to deploy, as illustrated as following flow chart: Flavor_IBM - (mapping by flavor extra_spec) - Heterogeneous_Group_IBM - Compute_Node_IBM - IBM machines Flavor_Dell - (mapping by flavor extra_spec) - Heterogeneous_Group_Dell - Compute_Node_Dell - Dell machines The existing approach has a drawback: I need to setup 1 baremetal compute node for each hw model. If I have 10 hw models in my datacenter, I need to setup 10 baremetal compute node, which would be a high overhead. Is there any update in ironic to tackle this? I think one of the possible enhancement is adding a field like hw_model in nova.bm_nodes DB and passing to nova scheduler, so different hw models of machine can under the same baremetal compute node and heterogeneous group. Just using different extra_spec in nova flavor to specifiy hw_model. Is it a good idea? Regards, Taurus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][baremetal] Scheduling baremetal deployment on different hw model
Firstly, use Ironic. Nova BM is deprecated. Secondly, yes, you can use extra-specs, but you only need to do that if your machines are identical in CPU, disk and memory - which the scheduler will look at anyway. Why do you need to group IBM and Dell machines together? -Rob On 30 June 2014 16:26, Taurus Cheung taurus.che...@harmonicinc.com wrote: Hi, I am working on deploying images to bare-metal machines using nova bare-metal. My datacenter has 2 types of hw models, IBM and Dell. In existing implementation, if I want to deploy image on specified type of hw model, I need to setup 2 baremetal compute nodes, one for container of IBM machine, the other for Dell machine. Then baremetal register machines to their corresponding compute node. Finally use nova flavor and heterogeneous group to map specified compute node so I can explicitly specify the hw model to deploy, as illustrated as following flow chart: Flavor_IBM - (mapping by flavor extra_spec) - Heterogeneous_Group_IBM - Compute_Node_IBM - IBM machines Flavor_Dell - (mapping by flavor extra_spec) - Heterogeneous_Group_Dell - Compute_Node_Dell - Dell machines The existing approach has a drawback: I need to setup 1 baremetal compute node for each hw model. If I have 10 hw models in my datacenter, I need to setup 10 baremetal compute node, which would be a high overhead. Is there any update in ironic to tackle this? I think one of the possible enhancement is adding a field like hw_model in nova.bm_nodes DB and passing to nova scheduler, so different hw models of machine can under the same baremetal compute node and heterogeneous group. Just using different extra_spec in nova flavor to specifiy hw_model. Is it a good idea? Regards, Taurus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][baremetal] Scheduling baremetal deployment on different hw model
Hi Rob, Thanks your reply. As I know, Ironic not yet graduate. It is still under rapid development as replied by Chris Krelle in Feb-2014: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026647.html . Or I should change to Ironic now? No - I am not group IBM and Dell machines together. They are under the same datacenter and I want to provision them under a single OpenStack controller, which I think a very common use case. What I want to do is to choose specified hw model (IBM or Dell) when I deploy image in baremetal style. Regards, Taurus -Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Monday, June 30, 2014 12:46 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Taurus Cheung Subject: Re: [openstack-dev] [nova][baremetal] Scheduling baremetal deployment on different hw model Firstly, use Ironic. Nova BM is deprecated. Secondly, yes, you can use extra-specs, but you only need to do that if your machines are identical in CPU, disk and memory - which the scheduler will look at anyway. Why do you need to group IBM and Dell machines together? -Rob On 30 June 2014 16:26, Taurus Cheung taurus.che...@harmonicinc.com wrote: Hi, I am working on deploying images to bare-metal machines using nova bare-metal. My datacenter has 2 types of hw models, IBM and Dell. In existing implementation, if I want to deploy image on specified type of hw model, I need to setup 2 baremetal compute nodes, one for container of IBM machine, the other for Dell machine. Then baremetal register machines to their corresponding compute node. Finally use nova flavor and heterogeneous group to map specified compute node so I can explicitly specify the hw model to deploy, as illustrated as following flow chart: Flavor_IBM - (mapping by flavor extra_spec) - Heterogeneous_Group_IBM - Compute_Node_IBM - IBM machines Flavor_Dell - (mapping by flavor extra_spec) - Heterogeneous_Group_Dell - Compute_Node_Dell - Dell machines The existing approach has a drawback: I need to setup 1 baremetal compute node for each hw model. If I have 10 hw models in my datacenter, I need to setup 10 baremetal compute node, which would be a high overhead. Is there any update in ironic to tackle this? I think one of the possible enhancement is adding a field like hw_model in nova.bm_nodes DB and passing to nova scheduler, so different hw models of machine can under the same baremetal compute node and heterogeneous group. Just using different extra_spec in nova flavor to specifiy hw_model. Is it a good idea? Regards, Taurus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [OpenStack-Infra] openstack CI infra
Hi Vinay, OpenStack handles that by using a dependant pipeline in zuul to gate on changes. You can read about it here: http://ci.openstack.org/zuul/gating.html Hopefully that answers your questions! Cheers, Josh From: Vinay Mahuli [vm.vi...@gmail.com] Sent: Friday, June 27, 2014 8:31 PM To: openstack-infra@lists.openstack.org Subject: [OpenStack-Infra] openstack CI infra Hi, We have a similar continuous integration (CI) as in openstack ci.openstack.orghttp://ci.openstack.org In such a setup, we have different projects (repositories) against which the developers commit the patches. My query is how to handle the dependencies between projects? At times the developers might have changes across projects/repositories and which might be in-turn dependent on each other. There will be a situation where in all the fixes (across projects) needed to be pushed at the same time. But openstack CI works on a single project. It schedules the build for one project and merges that specific fix. Do you have any solution to handle this situation in openstack CI? Regards, Vinay ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] openstack CI infra
On 2014-06-29 10:37:19 + (+), Joshua Hesketh wrote: OpenStack handles that by using a dependant pipeline in zuul to gate on changes. You can read about it here: http://ci.openstack.org/zuul/gating.html [...] Though I think the question was about cross-project dependencies for changes, something we're working on but for which we haven't implemented a solution yet. The short answer is that most of the time they're a bad idea, because it implies you're developing your applications to require tightly-coupled or possibly even lock-step upgrades, which is a disservice to anyone who may be continuously deploying your software. Where possible dependencies in feature changes between interdependent projects should implement backward compatibility and deprecation periods to ease these transitions instead. Sometimes there's no way to get around it though, so at the moment we deal with the problem through a combination of integration test changes, notes in commit messages to core reviewers indicating the order in which related changes to different projects have to merge, manually -2'ing changes which shouldn't merge until we've confirmed their dependencies are in place, and so on. Not ideal, which is why we've discussed solutions (most of which either involve Zuul analyzing specially-crafted commit message headers, or trying to convince upstream Gerrit developers that there is a valid use case for tracking some sort of metadata there). -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [Openstack] [OpenStack] [nova] Is there any method to record the operation of a nova user
Hi sylecn, Thank you for your information, I will then do more investigations about the notification system. Thank you! -- zym On Fri, Jun 27, 2014 at 7:39 PM, sylecn syl...@gmail.com wrote: On Fri, Jun 27, 2014 at 7:32 PM, sylecn syl...@gmail.com wrote: On Fri, Jun 27, 2014 at 5:03 PM, yangmin zhu zym00...@gmail.com wrote: Hi all, I want to record a user's operation for later audit purpose. For example, A user may start/reboot/shutdown a VM using nova command from terminal or using the dashboard from browser. How can I record this action and it's result to a log file(or some other database) for later check? And I also want to do this for user's operations in cinder and nova-network, such as creating a volume or assigning a floating ip to a VM. Is there any existing solution for this purpose? If not, where and how should I start to do it myself by modifying the current nova's(or cinder, nova-network) code? I think this can be done via a WSGI middleware. You can add WSGI middleware in paste deploy config file (api-paste.erb). I see there is already a logrequest filter, you can check what it does and implement something similar. Another solution will be wrap openstack API with your API and only expose your API to user. This way you can do any logging you want. You can also log the result of the request. -- Thanks, Yuanle I should also mention the notification system. I don't know which kind of events are published to rabbitmq, but it may have enough information for logging purpose. https://wiki.openstack.org/wiki/NotificationSystem -- Thanks, Yuanle ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [OpenStack] [nova] Is there any method to record the operation of a nova user
On 6/29/2014 8:41 AM, yangmin zhu wrote: Hi sylecn, Thank you for your information, I will then do more investigations about the notification system. Thank you! -- zym On Fri, Jun 27, 2014 at 7:39 PM, sylecn syl...@gmail.com wrote: On Fri, Jun 27, 2014 at 7:32 PM, sylecn syl...@gmail.com wrote: On Fri, Jun 27, 2014 at 5:03 PM, yangmin zhu zym00...@gmail.com wrote: Hi all, I want to record a user's operation for later audit purpose. For example, A user may start/reboot/shutdown a VM using nova command from terminal or using the dashboard from browser. How can I record this action and it's result to a log file(or some other database) for later check? And I also want to do this for user's operations in cinder and nova-network, such as creating a volume or assigning a floating ip to a VM. Is there any existing solution for this purpose? If not, where and how should I start to do it myself by modifying the current nova's(or cinder, nova-network) code? I think this can be done via a WSGI middleware. You can add WSGI middleware in paste deploy config file (api-paste.erb). I see there is already a logrequest filter, you can check what it does and implement something similar. Another solution will be wrap openstack API with your API and only expose your API to user. This way you can do any logging you want. You can also log the result of the request. -- Thanks, Yuanle I should also mention the notification system. I don't know which kind of events are published to rabbitmq, but it may have enough information for logging purpose. https://wiki.openstack.org/wiki/NotificationSystem -- Thanks, Yuanle ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Take a look at pycadf and the audit middleware: http://docs.openstack.org/developer/pycadf/middleware.html -- Thanks, Matt Riedemann ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Restart instances after node reboot
Hi, I just rode about ops in nodes reboot. http://docs.openstack.org/openstack-ops/content/maintenance.html I found that one of my nodes had a bug in openvswitch (I have to report it) that made it to coredump. So I loose conectivity to this node everytime it happens. Normally only solution is reboot the node. The problem is that after reboot all instances get shutdown. But I need to reboot the instances that were up. The only way to do it now it's by hand. So I must log to the cluster to do it. Is there any way to tell openstack to reboot anything that were up after node recovers? Document says: nova list --host c01.example.com --all-tenants nova reboot uuid This can be tedious if you have lots of instances... Best regards. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] DHCP server with external dns server
Hi, I know this is asked several times. but I cannot find a solution. The more I found is https://lists.launchpad.net/openstack/msg21048.html And the dns as service plugin that I think is not ready. https://wiki.openstack.org/wiki/DNSaaS So here is the question. Is there any way to setup a dhcpserver for the openstack lan so every instance that boots gets a dns? I mean. I configured my private dhcp and dns server to do the following: 1.- dhcp / bootp redirects any instances in my network to maas server. This is not needed for openstack. But I explain for completeness. 2.- Machine boots and gets an ip from dhcpd server. 3.- dhcpd server communicates the ip to the DNS and gets a name for a machine. 3.- dhcpd communicates network config to the server. 4.- Machine is fully resolvable under lan. I use rndc to do this with dns (bind9) and dhcpd. Is there any way to do this in openstack? So when a machine boots on lan gets a internal dns name, and when it gets a floating ip it gets another from the dns server? Do I explain myself? Best regards, ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Restart instances after node reboot
Hi Gonzalo: You may find the solution in: https://ask.openstack.org/en/question/5100/after-reboot-doesnt-run-guest Regards, --- JuanFra Rodriguez Cardoso 2014-06-29 19:36 GMT+02:00 Gonzalo Aguilar Delgado gagui...@aguilardelgado.com: Hi, I just rode about ops in nodes reboot. http://docs.openstack.org/openstack-ops/content/maintenance.html I found that one of my nodes had a bug in openvswitch (I have to report it) that made it to coredump. So I loose conectivity to this node everytime it happens. Normally only solution is reboot the node. The problem is that after reboot all instances get shutdown. But I need to reboot the instances that were up. The only way to do it now it's by hand. So I must log to the cluster to do it. Is there any way to tell openstack to reboot anything that were up after node recovers? Document says: nova list --host c01.example.com --all-tenantsnova reboot uuid This can be tedious if you have lots of instances... Best regards. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] DHCP server with external dns server
I think you're asking if it's possible for OpenStack to handle registering each public IP assigned to an instance with a DNS service so that each instance can be accessed by a hostname such as (instance name).mydomain.org ? I don't think OpenStack handles this today. If I were trying to assign host names to instances, I would look at a script installed into the instance either as part of the image or part of the first-boot setup. I used a program called 'ddclient' in the past to do this: http://sourceforge.net/p/ddclient/wiki/Home/ It also appears to be included in at least Ubuntu distributions today, the other major distributions probably have something similar. On Sun, Jun 29, 2014 at 12:50 PM, Gonzalo Aguilar Delgado gagui...@aguilardelgado.com wrote: Hi, I know this is asked several times. but I cannot find a solution. The more I found is https://lists.launchpad.net/openstack/msg21048.html And the dns as service plugin that I think is not ready. https://wiki.openstack.org/wiki/DNSaaS So here is the question. Is there any way to setup a dhcpserver for the openstack lan so every instance that boots gets a dns? I mean. I configured my private dhcp and dns server to do the following: 1.- dhcp / bootp redirects any instances in my network to maas server. This is not needed for openstack. But I explain for completeness. 2.- Machine boots and gets an ip from dhcpd server. 3.- dhcpd server communicates the ip to the DNS and gets a name for a machine. 3.- dhcpd communicates network config to the server. 4.- Machine is fully resolvable under lan. I use rndc to do this with dns (bind9) and dhcpd. Is there any way to do this in openstack? So when a machine boots on lan gets a internal dns name, and when it gets a floating ip it gets another from the dns server? Do I explain myself? Best regards, ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Andrew Mann DivvyCloud Inc. www.divvycloud.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Query about dnsmasq and neutron-ovs-cleanup [IceHouse]
Hello, I followed the exact steps mentioned at: http://docs.openstack.org/trunk/install-guide/install/yum/content/ .. to create a 3 node Openstack IceHouse environment (controller, network compute). I see that neutron-ovs-cleanup service is present on network compute node, but it is turned off on both. Should this be set to on (in chkconfig)? If yes, then on which node should this service supposed to run (I recon network node, but still wanna confirm with the community). Also, I have the same concern about dnsmasq service. I see that this service is installed on network node, but is turned off in chkconfig. However I can find a dnsmasq process currently running: nobody 10602 0.0 0.0 12884 772 ?S14:09 0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap47c93394-55 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/host --addn-hosts=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/opts --leasefile-ro --dhcp-range=tag0,192.168.1.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal The Openstack official guide for RHEL flavors does not mention whether these services should be turned on during server reboot (using chkconfig). My concern is whether to start them automatically in case of a server reboot. Please assist. Regards, Vimal ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Query about dnsmasq and neutron-ovs-cleanup [IceHouse]
Neutron itself starts the dnsmasq processes for tenant networks (neutron-dhcp-agent is the service for this I believe), so you should not enable dnsmasq in the system startup unless you are using another instance of dnsmasq for a non-neutron purpose (such as providing dns and dhcp services on your physical network to bare metal systems). I don't know much about neutron-ovs-cleanup, so I can't help with that part of the question. On Sun, Jun 29, 2014 at 1:56 PM, Vimal Kumar vimal7...@gmail.com wrote: Hello, I followed the exact steps mentioned at: http://docs.openstack.org/trunk/install-guide/install/yum/content/ .. to create a 3 node Openstack IceHouse environment (controller, network compute). I see that neutron-ovs-cleanup service is present on network compute node, but it is turned off on both. Should this be set to on (in chkconfig)? If yes, then on which node should this service supposed to run (I recon network node, but still wanna confirm with the community). Also, I have the same concern about dnsmasq service. I see that this service is installed on network node, but is turned off in chkconfig. However I can find a dnsmasq process currently running: nobody 10602 0.0 0.0 12884 772 ?S14:09 0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap47c93394-55 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/host --addn-hosts=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/opts --leasefile-ro --dhcp-range=tag0,192.168.1.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal The Openstack official guide for RHEL flavors does not mention whether these services should be turned on during server reboot (using chkconfig). My concern is whether to start them automatically in case of a server reboot. Please assist. Regards, Vimal ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Andrew Mann DivvyCloud Inc. www.divvycloud.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat] Stack Lifetime, Signaling, and AutoScaling Groups
On 18/06/14 05:47, Joe D'Andrea wrote: Hi, Zane! Thanks for all your responses. Regarding cfn-tools vs cloud-init, I'm starting out with Icehouse and no prior cfn-tools usage to maintain. I will likely look toward cloud-init, though Software Deployments + golden images sounds terrific. If cloud-init config meets your needs then you should consider using it. However keep in mind that cloud-init is boot-only configuration. This means that any change to cloud-init config during a stack update will result in your server resources being replaced with servers containing the new cloud-init boot configuration. If this behavior is not what you require then you should consider using SoftwareConfig/SoftwareDeployment resources instead. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Query about dnsmasq and neutron-ovs-cleanup [IceHouse]
Hello Andrew, Searching further, I find neutron-ovs-cleanup mentioned in the admin guide: http://docs.openstack.org/admin-guide-cloud/content/install_neutron-l3.html which says: If you reboot a node that runs the L3 agent, you must run the neutron-ovs-cleanup command before the neutron-l3-agent service starts. So I believe this service should start during server bootup of network node (where neutron-l3-agent service runs). Maybe they failed to include this in the official admin guide. On Mon, Jun 30, 2014 at 1:31 AM, Andrew Mann and...@divvycloud.com wrote: Neutron itself starts the dnsmasq processes for tenant networks (neutron-dhcp-agent is the service for this I believe), so you should not enable dnsmasq in the system startup unless you are using another instance of dnsmasq for a non-neutron purpose (such as providing dns and dhcp services on your physical network to bare metal systems). I don't know much about neutron-ovs-cleanup, so I can't help with that part of the question. On Sun, Jun 29, 2014 at 1:56 PM, Vimal Kumar vimal7...@gmail.com wrote: Hello, I followed the exact steps mentioned at: http://docs.openstack.org/trunk/install-guide/install/yum/content/ .. to create a 3 node Openstack IceHouse environment (controller, network compute). I see that neutron-ovs-cleanup service is present on network compute node, but it is turned off on both. Should this be set to on (in chkconfig)? If yes, then on which node should this service supposed to run (I recon network node, but still wanna confirm with the community). Also, I have the same concern about dnsmasq service. I see that this service is installed on network node, but is turned off in chkconfig. However I can find a dnsmasq process currently running: nobody 10602 0.0 0.0 12884 772 ?S14:09 0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap47c93394-55 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/host --addn-hosts=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/opts --leasefile-ro --dhcp-range=tag0,192.168.1.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal The Openstack official guide for RHEL flavors does not mention whether these services should be turned on during server reboot (using chkconfig). My concern is whether to start them automatically in case of a server reboot. Please assist. Regards, Vimal ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Andrew Mann DivvyCloud Inc. www.divvycloud.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Query about dnsmasq and neutron-ovs-cleanup [IceHouse]
Hi Andrew, I am trying out IceHouse manual install on CentOS 6.5, following the official docs available at http://docs.openstack.org/icehouse/install-guide/install/yum/content/. I have opened a bug at https://bugs.launchpad.net/openstack-manuals/+bug/1335724 But now I see another bug related with neutron-ovs-cleanup at https://bugs.launchpad.net/cloud-archive/+bug/1249708 in which it is recommended to start this service on all computes and network node. Hmm.. confused :-s On Mon, Jun 30, 2014 at 9:00 AM, Andrew Mann and...@divvycloud.com wrote: Hi Vimal, I'm using the OpenStack Icehouse packages in the Ubuntu 14.04 repository. These do start neutron-ovs-cleanup during boot of the network node. Did you install from packages or manually install the components? On Sun, Jun 29, 2014 at 10:09 PM, Vimal Kumar vimal7...@gmail.com wrote: Hello Andrew, Searching further, I find neutron-ovs-cleanup mentioned in the admin guide: http://docs.openstack.org/admin-guide-cloud/content/install_neutron-l3.html which says: If you reboot a node that runs the L3 agent, you must run the neutron-ovs-cleanup command before the neutron-l3-agent service starts. So I believe this service should start during server bootup of network node (where neutron-l3-agent service runs). Maybe they failed to include this in the official admin guide. On Mon, Jun 30, 2014 at 1:31 AM, Andrew Mann and...@divvycloud.com wrote: Neutron itself starts the dnsmasq processes for tenant networks (neutron-dhcp-agent is the service for this I believe), so you should not enable dnsmasq in the system startup unless you are using another instance of dnsmasq for a non-neutron purpose (such as providing dns and dhcp services on your physical network to bare metal systems). I don't know much about neutron-ovs-cleanup, so I can't help with that part of the question. On Sun, Jun 29, 2014 at 1:56 PM, Vimal Kumar vimal7...@gmail.com wrote: Hello, I followed the exact steps mentioned at: http://docs.openstack.org/trunk/install-guide/install/yum/content/ .. to create a 3 node Openstack IceHouse environment (controller, network compute). I see that neutron-ovs-cleanup service is present on network compute node, but it is turned off on both. Should this be set to on (in chkconfig)? If yes, then on which node should this service supposed to run (I recon network node, but still wanna confirm with the community). Also, I have the same concern about dnsmasq service. I see that this service is installed on network node, but is turned off in chkconfig. However I can find a dnsmasq process currently running: nobody 10602 0.0 0.0 12884 772 ?S14:09 0:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap47c93394-55 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/host --addn-hosts=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/18018aab-920b-42d4-99c3-c036155e60bf/opts --leasefile-ro --dhcp-range=tag0,192.168.1.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal The Openstack official guide for RHEL flavors does not mention whether these services should be turned on during server reboot (using chkconfig). My concern is whether to start them automatically in case of a server reboot. Please assist. Regards, Vimal ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Andrew Mann DivvyCloud Inc. www.divvycloud.com -- Andrew Mann DivvyCloud Inc. www.divvycloud.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
