Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

I’d be comfortable with server_type. Adrian On Jul 15, 2015, at 11:51 PM, Jay Lau mailto:[email protected]>> wrote: After more thinking, I agree with Hongbin that instance_type might make customer confused with flavor, what about using server_type? Actually, nova has concept of server gro

[openstack-dev] [manila][puppet-manila] Support to configure GlusterFS drivers with Manila shares.

Hi, This patch [1] adds support to configure GlusterFS drivers (both NFS and GlusterFS-Native/FUSE) with Manila shares. I've tested the patch, using packstack patch [2] No obvious errors, looks good. Requesting to review the patch. [1] https://review.openstack.org/#/c/200811/ [2] https://revi

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

+ 1 about server_type. I also think it is OK. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: [email protected] Tel: 86-10-82451647 Address: Building 28(Ring Buil

Re: [openstack-dev] [Neutron]Request for help to review a patch

As it is a bug fix, perhaps you could add this to the agenda for the next Neutron IRC meeting, in the Bugs section?Regards,       Neil  

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Hi Peng, Just want to get more for Hyper. If we create a hyper bay, then can I set up multiple hosts in a hyper bay? If so, who will do the scheduling, does mesos or some others integrate with hyper? I did not find much info for hyper cluster management. Thanks. 2015-07-16 9:54 GMT+08:00 Peng

[openstack-dev] [Fuel] Getting rid of upgrade tarball

Dear colleagues, I'd like to suggest to get rid of Fuel upgrade tarball and convert this thing into fuel-upgrade rpm package. Since we've switched to online rpm/deb based upgrades, it seems we can stop packaging rpm/deb repositories and docker containers into tarball and instead package upgrade py

[openstack-dev] [neutron][port-security]Could not create vm in network with the port-security-enabled=False

Hi all, I could use the feature port-security-enabled on port. When I create net and subnet neutron net-create net2 --port-security-enabled=False neutron subnet-create net2 6.6.6.0/24 --enable-dhcp=False --name subnet2 it works well. Then i create

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

2015-07-16 7:54 GMT+08:00 Ken'ichi Ohmichi : > 2015-07-16 3:03 GMT+09:00 Sean Dague : > > On 07/15/2015 01:44 PM, Matt Riedemann wrote: > >> The osapi_v3.enabled option is False by default [1] even though it's > >> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and > >> we've fro

Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron

2015-07-15 22:57 GMT+08:00 Matt Riedemann : > > > On 7/15/2015 3:24 AM, Alex Xu wrote: > >> >> >> 2015-07-15 5:14 GMT+08:00 Matt Riedemann > >: >> >> >> >> >> On 7/14/2015 3:43 PM, Cale Rath wrote: >> >> Hi, >> >> I created a patch to fail on

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

FYI, this should be part work of https://github.com/openstack/nova-specs/blob/master/specs/liberty/approved/nova-api-remove-v3.rst 2015-07-16 16:27 GMT+08:00 Alex Xu : > > > 2015-07-16 7:54 GMT+08:00 Ken'ichi Ohmichi : > >> 2015-07-16 3:03 GMT+09:00 Sean Dague : >> > On 07/15/2015 01:44 PM, Matt

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

By the way, first step for this to happen is to move stackforge/fuel-web/fuel_upgrade_system into a separate repository. Fortunately, this directory is not the place where the code is continuously changing (changes are rather seldom) and moving this project is going to barely affect the whole deve

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

+1 On Thu, Jul 16, 2015 at 2:04 AM, Brian Haley wrote: > +1 > > > On 07/15/2015 02:47 PM, Carl Baldwin wrote: > >> As the Neutron L3 Lieutenant along with Kevin Benton for control >> plane, and Assaf Muller for testing, I would like to propose Cedric >> Brandily as a member of the Neutron core r

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

It is not possible to constrain this attribute to an enum, because there is no fixed list of device owners. Nevertheless it's good to document know device owners. Likewise the API layer should have checks in place to ensure accidental updates to this attributes do not impact control plane function

Re: [openstack-dev] Please add add 'Fuel' to list topic categories

Qiming Teng wrote: > I believe we are all receiving a large number of Fuel related messages > everyday, but not all of us have the abundant bandwidth to read them. > Maybe we can consider adding 'Fuel' to the topic categories we can check > on/off when customising the subscription. > > Currently,

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Hi, Vladimir, I like the initiative, just to add some steps: 10) patch to fuel-qa/ and jenkins jobs to change the workflow of upgrades tests, 11) clarification on how upgrade should be tested (against which repositories and ISO images), how update of upgrade rpm should be tested 12) documentation

Re: [openstack-dev] [tc][all] Tags, explain like I am five?

Joshua Harlow wrote: >> Tags can be proposed by anyone, not only by the TC and they get >> discussed and voted on gerrit. The proposed tags need to be as objective >> as possible. And there is a working group >> (https://etherpad.openstack.org/p/ops-tags-June-2015) among operators >> trying to defi

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

What do you think of just blocking all PUTs to that field? Is that a feasible change without inducing widespread riots about breaking changes? On Thu, Jul 16, 2015 at 2:53 AM, Salvatore Orlando wrote: > It is not possible to constrain this attribute to an enum, because there > is no fixed list o

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit more efforts, but still straightforward. We expect to finish both integration in v0.4 early August. Best, Pen

Re: [openstack-dev] [neutron] What does flavor mean for a network?

Thanks everyone for your responses... On 15/07/15 21:01, Doug Wiegley wrote: That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug On Jul 15, 2015, at 12:38 PM, Kev

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On 07/15/2015 08:12 PM, GHANSHYAM MANN wrote: > On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague wrote: >> On 07/15/2015 01:44 PM, Matt Riedemann wrote: >>> The osapi_v3.enabled option is False by default [1] even though it's >>> marked as the CURRENT API and the v2 API is marked as SUPPORTED (and >>>

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, I am fully support moving fuel-upgrade-system into repository of its own. However, I'm not 100% sure how docker containers are going to appear on the upgraded master node. Do we have public repository of Docker images already? Or we are going to build them from scratch during the upgrade

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhanc

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/15/2015 01:41 PM, Andrew Laski wrote: > On 07/15/15 at 12:19pm, Matt Riedemann wrote: >> The other part of the discussion is around the API changes, not just >> for libvirt, but having a microversion that removes the device from >> the request so it's no longer optional and doesn't provide s

[openstack-dev] [Freezer] Proposing new core reviewers

All, At the Freezer Team, we think it's time to revisit the core reviewers for the Project. The idea behind this would be add as core reviewer the engineers that delivered a complete feature in the Project and actively participated to the other reviews, meetings and conversations on the IRC cha

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Oleg, All docker containers currently are distributed as rpm packages. A little bit surprising, isn't it? But it works and we can easily deliver updates using this old plain rpm based mechanism. The package in 6.1GA is called fuel-docker-images-6.1.0-1.x86_64.rpm So, upgrade flow would be like thi

[openstack-dev] [Fuel] Getting rid of launchpad group fuel-astute

Dear colleagues, I'd like to get rid of group fuel-astute on launchpad. In group only 2 active members. Actually they are members of fuel-python team. Bugs for fuel-astute project always concern to fuel-web project. Bugs assigned to fuel-astute can stay without attention for a long time. Thus I pr

Re: [openstack-dev] [nova] Proposal for an Experiment

On 15 July 2015 at 19:25, Robert Collins wrote: > On 16 July 2015 at 02:18, Ed Leafe wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 > ... >> What I'd like to investigate is replacing the current design of having >> the compute nodes communicating with the scheduler via message queue

[openstack-dev] [Ironic] ENROLL node state is introduced - next steps [ACTION RECOMMENDED]

Hi all! Today we landed a patch [1] that switches (starting with API version 1.11) node creation API to default to ENROLL node state instead of AVAILABLE. Nothing to worry about right now: we don't default to this API version (yet?) in our clients. But read on to figure out how not to get bro

Re: [openstack-dev] FW: [nova] schedule instance based on CPU frequency ?

From: Chris Friesen [mailto:[email protected]] Sent: Thursday, July 16, 2015 8:07 AM > > On 07/15/2015 04:57 PM, Dugger, Donald D wrote: >> In re: Static CPU frequency. For modern Intel CPUs this really isn't true. >> Turbo Boost is a feature that allows certain CPUs in certain >> condit

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, Thank you, now it sounds concieving. My understanding that at the moment all Docker images used by Fuel are packaged in single RPM? Do you plan to split individual images into separate RPMs? Did you think about publishing those images to Dockerhub? -- Best regards, Oleg Gelbukh On Th

Re: [openstack-dev] [all][ptl][release] New library release request process

Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > Doug, > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > How do you want to handle these? There are some tools in the repository to extract the history from a repo. I'll see what I can do for those 2

Re: [openstack-dev] [neutron] Should we document the using of "device:owner" of the PORT ?

I think it is better to block PUT for device_owner/device_id by regular users. It can be controlled by policy.json. If we do this change, we need to do it carefully because nova calls neutron port operations with regular user privilege if port binding extension is not supported. I agree that it is

[openstack-dev] [nova] Nova API Meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Friday UTC1200. In other timezones the meeting is at: EST 08:00 (Fri) Japan 21:00 (Fri) China 20:00 (Fri) United Kingdom 13:00 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/wi

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Oleg, Yes, you are right. At the moment all docker containers are packaged into a single rpm package. Yes, it would be great to split them into several one-by-one rpms, but it is not my current priority. I'll definitely think of this when I'll be moving so called "late" packages (which depend on o

Re: [openstack-dev] [neutron][db] online-schema-migrations patch landed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/15/2015 04:03 PM, Salvatore Orlando wrote: > Do you reckon that the process that led to creating a migration > like [1] should also be documented in devref? https://review.openstack.org/202534 -BEGIN PGP SIGNATURE- Version: GnuPG v2 i

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Vladimir, Good, thank you for extended answer. -- Best regards, Oleg Gelbukh On Thu, Jul 16, 2015 at 3:30 PM, Vladimir Kozhukalov < [email protected]> wrote: > Oleg, > > Yes, you are right. At the moment all docker containers are packaged into > a single rpm package. Yes, it would be gre

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/15/2015 12:05 PM, Thierry Carrez wrote: > The "cost" of keeping stable branches around without CI is more a > branding cost than a technical cost, I think. Which is why I suggested to rename the branches, if it poses a problem. For example eol/icehouse would have been fine. > An OpenStack u

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

One item that will impact this separation is that fuel_upgrade implicitly depends on the openstack.yaml release file from fuel-nailgun. Without it, the upgrade process won't work. We should refactor fuel-nailgun to implement this functionality on its own, but then have fuel_upgrade call this piece.

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/15/2015 12:37 PM, Ihar Hrachyshka wrote: > On 07/14/2015 09:14 PM, Thomas Goirand wrote: >> On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote: >>> On 07/14/2015 12:33 AM, Thomas Goirand wrote: I missed this announce... >>> On 07/02/2015 05:32 AM, Jeremy Stanley wrote: > Per the Iceh

Re: [openstack-dev] [Fuel] Getting rid of launchpad group fuel-astute

Hi, Agree, most of the python developers are familiar with Astute. But at the same time it can look strange when we assign Astute (which is written in Ruby) bugs to the group which is called fuel-python :) Thanks, On Thu, Jul 16, 2015 at 2:21 PM, Alexander Kislitsky < [email protected]> wr

Re: [openstack-dev] [all][ptl][release] New library release request process

On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann wrote: > Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > > Doug, > > > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > > How do you want to handle these? > > There are some tools in the repository to

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

I am OK with server_type as well. From: Kai Qiang Wu [mailto:[email protected]] Sent: July-16-15 3:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? + 1 about server_type. I also

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: "Balle, Susanne" mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/16/2015 03:06 PM, Thomas Goirand wrote: > What we discussed was that distributions would run their own CI > and validate patches away from upstream CI, then we would agree on > a patch and share it. > That's fine. I think a good start would b

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/16/2015 03:27 AM, Alex Xu wrote: > >> Honestly, we should probably deprecate out osapi_v3.enabled make >> it osapi_v21 (or osapi_v2_microversions) so as to not confuse >> people further. > > +1 for renaming it to osapi_v21 (or osapi_v2_microv

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, guys, what if we "simplify" things a bit? All we need is: 1. Remove all the community modules from fuel-library. 2. Create 'Puppetfile' with list of community modules and their versions that we currently use. 3. Make sure all our customizations are proposed to the upstream modules

[openstack-dev] [Mercador] Meeting this week

The Mercador meeting this week will be a break-out from the Keystone sprint (as well as on IRC). See https://wiki.openstack.org/wiki/Meetings/MercadorTeamMeeting Geoff

[openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

Hi Folks, Keystone supports Fernet tokens which have payload encrypted by AES 128 bit key. Although AES 128 bit key looks secure enough for most OpenStack deployments [2], one may would like to rotate encryption keys according to already proposed 3 step key rotation scheme (in case keys get comprom

Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?

In re: Normalized units. I agree that this is dependent upon benchmarking and there are many issues with the reliability of benchmarks. Having said that, I think normalized units is a much better metric to be using than CPU frequency. The reality is that the end user doesn't care about CPU fr

[openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Hi all, I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 while chasing a keystone py34 CI problem since memcached is running in our CI VM: https://review.openstack.org/#/c/177661/ and got word from @zigo that this li

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper

Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassi

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 07/16/2015 03:29 PM, Ihar Hrachyshka wrote: > Working on upstream gate stability obviously does not invalidate any > effort to introduce distribution CI votes in gerrit, and I would be > happy to see RDO or Ubuntu meaningfully voting on backports. It's my > belief though that distribution CI vot

[openstack-dev] [os-ansible-deployment] [openstack-ansible] Using commit flags appropriately

Hey everyone, Now that the project is starting to grow and has some amount of documentation. We should really start using flags in our commits more appropriately, e.g., "UpgradeImpact", "DocImpact", etc. For example, my own recent change to upgrade our keystone module to use v3 should have also h

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Hi, Le 16/07/2015 17:00, Davanum Srinivas a écrit : I ended up here: https://github.com/linsomniac/python-memcached/issues/54 https://github.com/linsomniac/python-memcached/pull/67 Oh, that's my pull request :-) Multiple peoples asked to merge my pull request, and I pinged explicitly the main

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: > Hi all, > > I ended up here: > https://github.com/linsomniac/python-memcached/issues/54 > https://github.com/linsomniac/python-memcached/pull/67 > > while chasing a keystone py34 CI problem since memcached is running

[openstack-dev] [Fuel] Nailgun agent core reviewers nomination

Hi, we have created separate project for fuel-nailgun-agent. At now moment only i have core-reviewer rights.We hardly need more core reviewers here. I want to nominate Vladimir Kozhukalov to fuel-nailgun-agent core. At now moment Vladimir is one of the main contributor in nailgun-agent. Please r

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

+1, seems like the best choice. Ton Ngo, From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/16/2015 06:33 AM Subject:Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type? I am O

Re: [openstack-dev] [Neutron]Request for help to review a patch

Hi Neil, Nice suggestion :-) Thanks, Wei Wang 2015-07-16 15:46 GMT+08:00 : > As it is a bug fix, perhaps you could add this to the agenda for the next > Neutron IRC meeting, in the Bugs section? > > Regards, > Neil > > > *From: *Damon Wang > *Sent: *Thursday, 16 July 2015 07:18 > *To: *

Re: [openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

Adam, For 1, do we let user configure max_active_keys? what's the default? Please note that there is a risk that an active token may be invalidated if Fernet key rotation removes keys early. So that's a potential issue to keep in mind (relation of token expiry to period of key rotation). thanks,

Re: [openstack-dev] [os-ansible-deployment] [openstack-ansible] Using commit flags appropriately

+1 - I think we should start doing this immediately. -- Kevin Carter Racker, Developer, Hacker @ The Rackspace Private Cloud. From: Ian Cordasco Sent: Thursday, July 16, 2015 10:12 AM To: OpenStack Development Mailing List (not for usage questions) Subj

Re: [openstack-dev] [Fuel] Nominate Denys Klepikov for fuel-docs core

+1 -- *Kind Regards* *Miroslav Anashkin**L2 support engineer**,* *Mirantis Inc.* *+7(495)640-4944 (office receptionist)* *+1(650)587-5200 (office receptionist, call from US)* *35b, Bld. 3, Vorontsovskaya St.* *Moscow**, Russia, 109147.* www.mirantis.com [email protected]

Re: [openstack-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation

On Thu, Jul 16, 2015 at 10:29 AM, Davanum Srinivas wrote: > Adam, > > For 1, do we let user configure max_active_keys? what's the default? > The default in keystone is 3, simply to support having one key in each of the three phases of rotation. You can increase it from there per your desired rot

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

On Tue, Jul 14, 2015 at 03:31:49AM PDT, Kevin Benton wrote: > Unfortunately the security groups API does not have mac-level rules right > now. There is also the fact that the Security Group API is limited (by design) to do fairly simple things, and also that the model has similar fields to the AWS

Re: [openstack-dev] [Fuel] Nailgun agent core reviewers nomination

+1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov wrote: > Hi, > > we have created separate project for fuel-nailgun-agent. At now moment > only i have core-reviewer rights.We hardly need more core reviewers here. > > I want t

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Wait... so the issue is if you were to just use nova flavor, you don't have enough information to choose a set of templates that may be more optimal for that flavor type (like vm's or bare metal)? Is this a NaaS vs flatdhcp kind of thing? I just took a quick skim of the heat templates and it was

[openstack-dev] [nova] Non-Priorty Feature Proposal Freeze has happened

Hi, Just a quick heads up about today's blueprint activities. The main aims here are: * focus on the agreed priorities (including bug fixes) during liberty-3 * optimise for max number of complete blueprints * focus review effort on the things that are already being reviewed now The following doc

[openstack-dev] [Fuel Zabbix in deployment tasks

Hi, Working on granular deployment, I realized we still call zabbix.pp in deployment tasks. As far as I know zabbix was moved to plugin. Should we remove zabbix from 1. Deployment graph 2. fixtures 3. Tests 4. Any other places Are we going to clean up zabbix code as part of migration to plugin?

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 11:24 AM, Sean Dague wrote: > On 07/15/2015 01:41 PM, Andrew Laski wrote: >> On 07/15/15 at 12:19pm, Matt Riedemann wrote: > >>> The other part of the discussion is around the API changes, not just >>> for libvirt, but having a microversion that removes the device from >>> the reques

[openstack-dev] [all][api] New API Guidelines read for cross project review

hey all, we have 4 API Guidelines that are ready for final review. 1. Add generic name of each project for terms https://review.openstack.org/#/c/196918/ 2. Add new guideline for HTTP Headers https://review.openstack.org/#/c/186526/ 3. Adds guidance on request bodies with different Methods htt

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 05:47 PM, Nikola Đipanov wrote: > > Also, not being able to specify device names would make it impossible to > implement certain features that EC2 API can provide, such as overriding > the image block devices without significant effort. > I forgot to add links that explain this in

[openstack-dev] [rpm-packaging] Meeting minutes IRC meeting July 16th

Hi, extraction of the meeting minutes from https://etherpad.openstack.org/p/openstack-rpm-packaging we agreed to switch to the standard way of doing meeting minutes once the infra review got merged. its a bit of a short minutes, feel free to reach out to number80 or me in case you have questions.

Re: [openstack-dev] [nova] Why is osapi_v3.enabled = False by default?

On 7/16/2015 4:57 AM, Sean Dague wrote: On 07/15/2015 08:12 PM, GHANSHYAM MANN wrote: On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague wrote: On 07/15/2015 01:44 PM, Matt Riedemann wrote: The osapi_v3.enabled option is False by default [1] even though it's marked as the CURRENT API and the v2 AP

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/16/2015 05:08 PM, Thomas Goirand wrote: > On 07/16/2015 03:29 PM, Ihar Hrachyshka wrote: >> Working on upstream gate stability obviously does not invalidate >> any effort to introduce distribution CI votes in gerrit, and I >> would be happy to

Re: [openstack-dev] [all][ptl][release] New library release request process

Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500: > On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann > wrote: > > > Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200: > > > Doug, > > > > > > I'm missing openstackdocstheme and openstack-doc-tools in your import. > >

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 7/16/2015 11:47 AM, Nikola Đipanov wrote: On 07/16/2015 11:24 AM, Sean Dague wrote: On 07/15/2015 01:41 PM, Andrew Laski wrote: On 07/15/15 at 12:19pm, Matt Riedemann wrote: The other part of the discussion is around the API changes, not just for libvirt, but having a microversion that

[openstack-dev] Barbican : Need help as to how to test the integration of Barbican with the HSM

Hi All , I would need help to test the integration of Barbican with HSM. Have configured the Barbican client to connect to HSM server by registering barbican IP to the HSM server and have assigned the partition. Have modified the barbican.conf file with the following changes : #

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

On 07/14/2015 11:58 AM, Luigi Toscano wrote: On Tuesday 14 of July 2015 10:33:18 Ihar Hrachyshka wrote: On 07/14/2015 01:46 AM, Perry, Sean wrote: -Original Message- From: Doug Hellmann I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be ma

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

On 16/07/2015 12:05 AM, Angus Salkeld wrote: Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? yes, we discussed this last week during our midcycle. the plan going forward is to allow current existing Ceilometer alarm f

[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 07/16/2015

Hi Everyone, Thanks for joining the service chaining project meeting on 7/16/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ OpenStack Development M

Re: [openstack-dev] [Fuel Zabbix in deployment tasks

I thought it was done... Stas - do you know anything about it? On Thu, Jul 16, 2015 at 9:18 AM Sergii Golovatiuk wrote: > Hi, > > Working on granular deployment, I realized we still call zabbix.pp in > deployment tasks. As far as I know zabbix was moved to plugin. Should we > remove zabbix from

Re: [openstack-dev] [Fuel] Nominate Denys Klepikov for fuel-docs core

+1 On Thu, Jul 16, 2015 at 8:40 AM Miroslav Anashkin wrote: > +1 > > -- > > *Kind Regards* > > *Miroslav Anashkin**L2 support engineer**,* > *Mirantis Inc.* > *+7(495)640-4944 (office receptionist)* > *+1(650)587-5200 (office receptionist, call from US)* > *35b, Bld. 3, Vorontsovskaya St.* > *Mo

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 06:35 PM, Matt Riedemann wrote: > > > On 7/16/2015 11:47 AM, Nikola Đipanov wrote: >> On 07/16/2015 11:24 AM, Sean Dague wrote: >>> On 07/15/2015 01:41 PM, Andrew Laski wrote: On 07/15/15 at 12:19pm, Matt Riedemann wrote: >>> > The other part of the discussion is around th

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

To be clear we have two pursuits on this thread: 1) What to rename bay.blatform to. 2) How we might eliminate the attribute, or replace it with something more intuitive We have a consensus now on how to address #1. My direction to Kannan is to proceed using server_type as the new attribute name

[openstack-dev] [fuel] NodeGroups vs network-templates and static routes

In 6.0 we added nodegroups as part of the multiple-cluster-networks features. With these you can add additional sets of networks with so that the nodes can exist on different network segments. When these are used you will also need to set the gateway for each of your networks. When you do this, you

Re: [openstack-dev] [fuel] Meeting July 16

Meeting minutes are available at http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-16-16.00.html On Wed, Jul 15, 2015 at 3:36 PM Andrew Woodward wrote: > Please note the IRC meeting is scheduled for 16:00 UTC in > #openstack-meeting-alt > > Please review meeting agenda and update i

[openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

Hello everyone, I have committed the initial configuration required to start leveraging librarian-puppet as part of the way we pull in upstream puppet modules[0]. Additionally, I have also committed a change that would pull in the openstack-ironic module[1]. The one piece that is missing from thi

[openstack-dev] [nova] Exposing provider networks in network_data.json

Hi, I stubble on this review [1] which proposes adding info about provider networks in network_data.json. Concerns were raised by Kevin Benton about how those information shouldn't be exposed to virtual instances for various reasons you can read in the review and I totally agree with those concer

[openstack-dev] [neutron][fwaas] Usecase classification

Hi all, Over the past day at the Advanced Services midcycle in Seattle[1], a group of us gathered to try and categorize the usecases collected in the etherpad[2] into more specific buckets. The work product of that effort is located at https://trello.com/b/TIWf4dBJ/fwaas-usecase-categorization T

Re: [openstack-dev] [all] Non-responsive upstream libraries (python34 specifically)

On 07/16/2015 05:19 PM, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2015-07-16 11:00:33 -0400: >> Hi all, >> >> I ended up here: >> https://github.com/linsomniac/python-memcached/issues/54 >> https://github.com/linsomniac/python-memcached/pull/67 >> >> while chasing a

[openstack-dev] [sahara] keystone session upgrade

hi all, i've been researching, and coding, about how to upgrade sahara to use keystone sessions for authentication instead of our current method. i'm running into some issues that i believe might make the current proposed approach[1] unfeasible. one issue i'm running into is the nature of ho

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Good point. +1 on server_type. it seems reasonable. As for the need, I'd really rather not have my users have to know how to map flavors to server_types themselves. Its something they will get wrong at times, and we'll get emails about/spend time explaining. The lack of heat conditionals has b

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko wrote: > Hi, > > guys, what if we "simplify" things a bit? All we need is: > >1. Remove all the community modules from fuel-library. >2. Create 'Puppetfile' with list of community modules and their >versions that we currently us

Re: [openstack-dev] [Fuel] Getting rid of upgrade tarball

Hi, Let's put openstack.yaml to package if it requires for master node upgrade. Environment update part should be removed as it never reached production state. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 16, 2015 at 8:07 AM, Matthew Mosesohn wrote: > One item th

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

Kevin, You make a really good point. Reducing required inputs from users in exchange for a little more setup by cloud operators is a well justified tradeoff. I'm pretty sure flavors in Nova can have tag Metadata added without a nova extension, right? Can someone check to be sure? If we do have

Re: [openstack-dev] [nova] Exposing provider networks in network_data.json

On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: > So it looks like there is a missing part in this feature. There should > be a way to "hide" this information if the instance does not require to > configure vlan interfaces to make network functional. I just commented on the review, bu

Re: [openstack-dev] [neutron] What does flavor mean for a network?

Neil, flavor:network is for Metaplugin. It is unrelated to flavor framework. FYI, Metaplugin will be removed in liberty. https://review.openstack.org/#/c/192056/ Thanks. Itsuro Oda (oda-g) On Thu, 16 Jul 2015 10:44:01 +0100 Neil Jerram wrote: > Thanks everyone for your responses... > > On 1

Re: [openstack-dev] [qa] identity v3 issue causing non-admin job to fail

Hi David, admin_domain_name is used at the moment to fill in the domain when missing in a few cases. The get_credentials method is one of them. Another two are setting the default domain for the users in tempest.conf [0], and setting the domain for credentials loaded from a YAML file [1]. [0] htt

Re: [openstack-dev] [QA][Tempest] Proposing Jordan Pittier for Tempest Core

I'm late in my reply, but I can still give my +1 and say welcome to the team Jordan! On Mon, Jun 29, 2015 at 4:26 PM Jordan Pittier wrote: > Thanks a lot ! > I just want to say that I am happy about this and I look forward to > continue working on Tempest with you all. > > Cheers, > Jordan > > O

Re: [openstack-dev] [qa] Status of account creds in the [identity] section of tempest.conf

On Fri, Jun 19, 2015 at 10:30 AM Matthew Treinish wrote: > On Thu, Jun 18, 2015 at 02:13:56PM -0400, David Kranz wrote: > > We had a discussion about this at the qa meeting today around the > following > > proposal: > > > > tl;dr The test accounts feature provides the same functionality as the >

Re: [openstack-dev] [glance] Progress of the Python 3 port

On Wed, Jul 15, 2015 at 10:39:11AM +0200, Victor Stinner wrote: > Hi, > Any update on this release? This has now been released in glance_store 0.7.0 Cheers, Louis signature.asc Description: Digital signature __ OpenStack De

  1   2   >