Re: [openstack-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes
Can we introduce both form-based and query language-based filter options? Like 'Simple' and 'Advanced' mode on JIRA 'Issues' - 'Search for issues' page. I also like a feature of saving custom user filters. Maybe it's not critical fot the first iteration but I would consider it to the next releases. And yes, this option will require an appropriate backend changes. On Tue, Jan 20, 2015 at 1:05 AM, Andrey Danin ada...@mirantis.com wrote: Definitely, it should be a form-based filter. It's much more simpler than a pure query. Also, you can translate a user selection to a query and add to a location string (like it's done now for the Logs tab [1], for instance). It would allow a user to use a full power of queries. [1] http://demo.fuel-infra.org:8000/#cluster/874/logs/type:local;source:api;level:info On Fri, Jan 16, 2015 at 3:50 PM, Nikolay Markov nmar...@mirantis.com wrote: It's also should be mentioned that these are several changes to do on backend in order for UI to work faster, not on UI itself. For example, these are: - Custom filters, as Vitaly mentioned - Pagination of collections - PATCH requests support - Probably both short and /full representations for some entities On Fri, Jan 16, 2015 at 8:48 AM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, Currently Fuel UI can handle large amounts of nodes due to a recent refactoring - rendering and operations with nodes became much faster. But that large amount of nodes also requires UX improvement, I'd love to hear your ideas and opinions on these proposals: Introduce compact node representation and let users switch between standart and compact view. Compact view will display only node name and status and will allow to display 4-8 nodes in a row instead of only one. Currently it is only possible to filter node by names. Filtering feature could be extended to allow filtering by other parameters: status, roles, manufacturer, RAM, disk space. There are 2 options (I'd like to hear which one you prefer): Form-based filter (beside a single input for name there will be controls for other parameters) Query language-based filter (like one used in Gerrit) Add ability to add arbitrary tags with values to nodes and also allow filtering by them. -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind Regards, Julia Aranovich, Software Engineer, Mirantis, Inc +7 (905) 388-82-61 (cell) Skype: juliakirnosova www.mirantis.ru jaranov...@mirantis.com jkirnos...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] What does it mean when a network's admin_state_up = false?
Hi Danny, I know that if we will set admin_state_up= false we will disable DHCP service for this network and new VMs will not get network settings by DHCP. On Wed, Dec 31, 2014 at 2:41 AM, Danny Choi (dannchoi) dannc...@cisco.com wrote: Hi, I have a VM with an interface attached to network “provider-net-1” and assigned IP 66.0.0.8. localadmin@qa4:~/devstack$ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | d4815a38-ea64-4189-95b2-fefe82a07b72 | vm-1 | ACTIVE | - | Running | provider_net-1=66.0.0.8 | +--+--+++-+--+ Verify ping 66.0.0.8 from the router namespace is successful. Then I set the admin_state_up = false for the network. localadmin@qa4:~/devstack$ neutron net-update --admin_state_up=false provider_net-1 Updated network: provider_net-1 localadmin@qa4:~/devstack$ neutron net-show provider_net-1 +---+--+ | Field | Value| +---+--+ | admin_state_up| False| | id| 9532b759-68a2-4dc0-bcd4-b372fccabe3c | | name | provider_net-1 | | provider:network_type | vlan | | provider:physical_network | physnet1 | | provider:segmentation_id | 399 | | router:external | False| | shared| False| | status| ACTIVE | | subnets | 8e75c110-9b31-4268-ba5c-e130fa139d32 | | tenant_id | e217fbc20a3b4f4fab49ec580e9b6a15 | +---+--+ Afterwards, the ping is still successful. I expect the ping to fail since the network admin_state_up= false. What is the expected behavior? What does it mean when a network's admin_state_up = false? Thanks, Danny ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc My OpenStack summit schedule: http://kilodesignsummit.sched.org/timur.nurlygayanov#.VFSrD8mhhOI __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Optional Properties in an Entity
On Mon, 19 Jan 2015, Dean Troyer wrote: Independent of actual implementations in OpenStack, I prefer always including null/empty properties here because it is slightly more self-documenting. Having spent the morning chasing down attributes for an API to be named at a later date by looking at server code, we do not help ourselves or the users of our APIs by omitting this sort of thing. +1 -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Raw vs Qcow2 images_type in nova/libvirt
On 01/20/2015 12:18 AM, Pádraig Brady wrote: On 19/01/15 20:41, Michael Still wrote: Mostly. qcow2 can do a copy on write layer, although it can be disabled IIRC. So if COW is turned on, you get only the delta in the instance directory when using qcow2. Cheers, Michael On Tue, Jan 20, 2015 at 7:40 AM, Dmitry Guryanov dgurya...@parallels.com wrote: Hello, Do I understand correctly, that both Qcow2 and Raw classes in libvirt/imagebackend.py can work with images in qcow2 format, but Raw copies the whole base image from cache to the instance's dir and Qcow2 only creates a delta (and use base image from cache)? Correct. That Raw class should be renamed to Copy, to clarify/distinguish from CopyOnWrite. BTW there are some notes on these settings at: http://www.pixelbeat.org/docs/openstack_libvirt_images/ Pádraig Thanks! Excellent article. -- Dmitry Guryanov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Skipping Cross-Project meeting today
Hi everyone, Given that the agenda docket is pretty slim this week, I'd like to skip this cross-project meeting and have the next one on Jan 27. sigmavirus24 posted the Cross-project DevRef akin to Nova's item but I'd prefer if we discussed it on the mailing-list first (not certain it requires everyone's attention just yet, and could just be proposed as a spec). Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Raw vs Qcow2 images_type in nova/libvirt
On 01/19/2015 11:41 PM, Michael Still wrote: Mostly. qcow2 can do a copy on write layer, although it can be disabled IIRC. So if COW is turned on, you get only the delta in the instance directory when using qcow2. It seems you have to set images_type=raw (or use_cow_images=false) to disable copy on write, image will be handled by Raw class from imagebackend.py. Cheers, Michael On Tue, Jan 20, 2015 at 7:40 AM, Dmitry Guryanov dgurya...@parallels.com wrote: Hello, Do I understand correctly, that both Qcow2 and Raw classes in libvirt/imagebackend.py can work with images in qcow2 format, but Raw copies the whole base image from cache to the instance's dir and Qcow2 only creates a delta (and use base image from cache)? -- Dmitry Guryanov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Dmitry Guryanov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Optional Properties in an Entity
On 1/20/15, 04:13, Chris Dent chd...@redhat.com wrote: On Mon, 19 Jan 2015, Dean Troyer wrote: Independent of actual implementations in OpenStack, I prefer always including null/empty properties here because it is slightly more self-documenting. Having spent the morning chasing down attributes for an API to be named at a later date by looking at server code, we do not help ourselves or the users of our APIs by omitting this sort of thing. +1 I’m in much the same position as Kevin. I’ve tried coming up with reasoning for both positions but I don’t see a really compelling reason for either side. On the one hand though, having strict schema about what is returned can be valuable, so not allowing something to be omitted **may** catch a bug somewhere else. Allowing things to be nullable is perfectly reasonable to me. It seems like a few of us are in agreement with this direction. Perhaps one of us should write a proposal for the API-WG to review about this. Cheers, Ian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] What does it mean when a network's admin_state_up = false?
Hi,
There was a discussion about the behaviour of admin_state_up. You can
take a look at the following link:
https://bugs.launchpad.net/neutron/+bug/1237807
Changing admin_state_up from True to False will break dhcp. it will remove
dhcp service ports from the network but dhcp agent will be alive.
To see the difference between network's admin_state_up=True and
admin_state_up=False, you can run the following commands:
# neutron agent-list (write down dhcp_agent ID)
# neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command
when admin state True)
# neutron agent-show 91e15f2f-2e27-460c-a305-a82d9e462c81 (run this command
when admin state False - wait a 1 min after you changed admin state from
True to False before running this command)
** When admin state set to TRUE ***
configurations {
subnets: 1,
use_namespaces: true,
dhcp_lease_duration: 86400,
dhcp_driver: neutron.agent.linux.dhcp.Dnsmasq,
networks: 1,
ports: 2
}
** When admin state set to FALSE **
configurations {
subnets: 0,
use_namespaces: true,
dhcp_lease_duration: 86400,
dhcp_driver: neutron.agent.linux.dhcp.Dnsmasq,
networks: 0,
ports: 0
}
Erhan,
On Tue, Jan 20, 2015 at 11:40 AM, Timur Nurlygayanov
tnurlygaya...@mirantis.com wrote:
Hi Danny,
I know that if we will set admin_state_up= false we will disable DHCP
service for this network and new VMs will not get network settings by DHCP.
On Wed, Dec 31, 2014 at 2:41 AM, Danny Choi (dannchoi) dannc...@cisco.com
wrote:
Hi,
I have a VM with an interface attached to network “provider-net-1” and
assigned IP 66.0.0.8.
localadmin@qa4:~/devstack$ nova list
+--+--+++-+--+
| ID | Name | Status | Task State |
Power State | Networks |
+--+--+++-+--+
| d4815a38-ea64-4189-95b2-fefe82a07b72 | vm-1 | ACTIVE | - |
Running | provider_net-1=66.0.0.8 |
+--+--+++-+--+
Verify ping 66.0.0.8 from the router namespace is successful.
Then I set the admin_state_up = false for the network.
localadmin@qa4:~/devstack$ neutron net-update --admin_state_up=false
provider_net-1
Updated network: provider_net-1
localadmin@qa4:~/devstack$ neutron net-show provider_net-1
+---+--+
| Field | Value|
+---+--+
| admin_state_up| False|
| id| 9532b759-68a2-4dc0-bcd4-b372fccabe3c |
| name | provider_net-1 |
| provider:network_type | vlan |
| provider:physical_network | physnet1 |
| provider:segmentation_id | 399 |
| router:external | False|
| shared| False|
| status| ACTIVE |
| subnets | 8e75c110-9b31-4268-ba5c-e130fa139d32 |
| tenant_id | e217fbc20a3b4f4fab49ec580e9b6a15 |
+---+--+
Afterwards, the ping is still successful.
I expect the ping to fail since the network admin_state_up= false.
What is the expected behavior? What does it mean when a network's
admin_state_up = false?
Thanks,
Danny
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
My OpenStack summit schedule:
http://kilodesignsummit.sched.org/timur.nurlygayanov#.VFSrD8mhhOI
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] RAID interface - backing disk hints
Hi All, This is regarding the RAID configuration spec that was posted for review some time back: https://review.openstack.org/#/c/135899/ This review consists of a generic RAID interface currently proposed jointly by Redhat (for DRAC hardware) and HP (for iLO hardware). This spec defines a common interface for doing RAID configuration which can be used for both drivers for now, and may be followed by any driver later on who wishes to implement RAID configuration. In the changes proposed in the spec, the driver should be able to figure out the disks to be used for creating RAID on the machine, when some hints are given by the operator to Ironic. The hints help Ironic to figure out what disks should be used for creating RAID. Initially we started with a few (namely disk type (ssd vs hdd) and interface type (scsi vs sata vs ...), etc. But later on due to request from some other folks to include some more criterias (namely filter disks based on inputs on model, firmware version, vendor due to various reasons), we added it to the list of hints. Now, we have * some set of folks *who don't want *model, firmware version, vendor as criteria because if they are added, every driver would need to implement them. * some set of folks *who want *model, firmware version, vendor as criteria because there are practical use-cases in an environment. We have confirmed that filtering based on model, firmware version and vendor can be done on both HP and DRAC hardware for now. I would like to hear everyone's thoughts and probably reach a conclusion of whether be open to include more criteria or not. Please pour in your thoughts on the thread Regards, Ramakrishnan (irc: rameshg87) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] iptables routes are not being injected to router namespace
Hi all, we've been doing some tests with openstack kilo and found out a problem: iptables routes are not being injected to the router namespace. Scenario: - a private network NOT connected to the outside world. - a router with only one interface connected to the private network. - a vm instance connected to the private network as well. From inside the instance, we try to get some information from the metadata service with curl: $ curl http://169.254.169.254 curl: (7) couldn't connect to host With the same set up in juno, there was no such problem and metadata information is shown. The request is not filtered at the instance and hits the router namespace (checked with tcpdump). However, when looking from the controller at the iptables rules at the router, they appear empty. stack@devstack: ~$ sudo ip netns exec qrouter-d4ec737a-c5fb-4f5b-8bd0-1b5353bbade3 iptables-save # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015 *raw :PREROUTING ACCEPT [12:1334] :OUTPUT ACCEPT [10:868] COMMIT # Completed on Tue Jan 20 14:05:48 2015 # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015 *nat :PREROUTING ACCEPT [10:913] :INPUT ACCEPT [3:493] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Tue Jan 20 14:05:48 2015 # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015 *mangle :PREROUTING ACCEPT [12:1334] :INPUT ACCEPT [5:914] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [10:868] :POSTROUTING ACCEPT [10:868] COMMIT # Completed on Tue Jan 20 14:05:48 2015 # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015 *filter :INPUT ACCEPT [5:914] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [10:868] COMMIT Is this some problem related to the refactoring of the l3 agent? Any pointer to what might be the problem here? I can provide more information on the subject if necessary to reproduce this. Any input would be appreciated. Cheers, Xavi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] Scheduler sub-group meeting agenda 1/70
On Jan 20, 2015, at 12:07 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: Note, I expect we’ll spend most of the time talking about 1. If we can come to agreement on that BP I’ll be ecstatic. And if we can't, it will be very difficult, if not impossible, to get the spec freeze exception. -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Weekly subteam status report
Hi all, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 19 Jan, 11:00 UTC) Open: 122 (-11). 4 new (-10), 31 in progress (-1), 0 critical (-1), 14 high (+1) and 6 incomplete (+1) Our bug day pretty well last week, let us repeat from time to time Drivers iLO (wanyen) Making progress on 3rd-party CI test setup. Uses 3-node setup: one for CI infrastructure one for agent-ilo test one for iscsi-ilo test design spec https://review.openstack.org/#/c/134022/ has been merged. converted uefi support for agent-ilo driver spec into 3 bug reports as changes are small. https://review.openstack.org/#/c/137024/ Still quite a few specs that needs reviews secure boot RAID configuration iLO zapping and cleaning IPA partition image iLO sensor // jim [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][client] Keeping Nailgun's log after running tests
+1 for this option. I use log while creating new tests sometimes. Aleksey Kasatkin On Mon, Jan 19, 2015 at 3:37 PM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks, at the moment run_test.sh script removes Nailgun's log file after running. The question is whether it is necessary to add an option for keeping it. - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] private symbols in Oslo libraries
tl;dr: The Oslo team differentiates between public and private parts of Oslo libraries using _ as a prefix in private names. Code using private symbols is going to break as we move things around in the libraries, so it should be changed to avoid those symbols. The Oslo team has been working over the last several cycles to define stable APIs for the code that is graduating into libraries. We are trying to follow good practices for defining those APIs, by making them as small as possible at first and by extending existing APIs in backwards-compatible ways. We haven't done this perfectly, and we've uncovered some interesting edge cases in a few situations. One challenge we have is with protecting implementation details from consuming projects. Languages like C++ and Java have language-level constructs for hiding data and methods inside classes and modules. Python is a more open language, and has no parallel to those data-hiding facilities. Instead, Python developers have adopted conventions of designating private parts of libraries by naming symbols that are private with a single underscore as the prefix for the name and by explicitly documenting the supported public interface of a library. The Oslo team is following these conventions throughout the Oslo code base. The work we are doing to move out of the oslo namespace package [1] is exposing places in several projects where symbols we have marked as private are being imported and used directly. Usually this happens in tests, but not always. This has been the source of problems in a couple of applications as we have released new versions of the libraries where those private symbols either no longer exist or have moved to a new location. As a result, we have built some tools to let us run the tests for projects with pre-release versions of the libraries. Running those tests is very expensive. A single pre-release of oslo.i18n currently requires running test jobs against 37 repositories. We run the py27 and pep8 jobs for each of those projects, so we actually run 74 jobs. We cannot do that on the CI infrastructure without consuming enough VMs to negatively impact the ability to land patches elsewhere [2], so we are using other resources and doing the testing by hand. We will be running these tests for the remaining namespace package releases, to try to minimize further breaks. However, I do not plan for us to continue doing this level of testing by hand after the namespace package changes are completed (currently scheduled for K-2) because we do not anticipate having the same level of code churn. At the same time, we do expect to be able to change the implementation details of libraries fairly freely -- that's why we go to such lengths to designate the public API, just as with the REST APIs of the applications. We expect consuming projects to honor the private designations of symbols and to avoid using them directly or mocking them in tests. Where it is impossible or inconvenient to mock the public API of the library, we have provided (and can continue to add) fixtures for configuring libraries to be used in application unit tests. We also have documentation for the public APIs of all Oslo libraries [3] to try to make clear what portion of the API is considered stable and supported. There are a couple of easy guidelines for determining what part of a library is private: 1. If the name of the module, class, function, variable, attribute, or other symbol starts with '_' it is private and should not be used. 2. If the symbol is not documented, it may be private and should probably not be used. There may be symbols we've missed in the documentation, so please ask in #openstack-oslo or here on the mailing list if you aren't sure. Doug [1] https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages [2] https://etherpad.openstack.org/p/juno-infra-library-testing [3] http://docs.openstack.org/developer/openstack-projects.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] RAID interface - backing disk hints
On Tue, Jan 20, 2015 at 07:28:46PM +0530, Ramakrishnan G wrote: Hi All, This is regarding the RAID configuration spec that was posted for review some time back: https://review.openstack.org/#/c/135899/ This review consists of a generic RAID interface currently proposed jointly by Redhat (for DRAC hardware) and HP (for iLO hardware). This spec defines a common interface for doing RAID configuration which can be used for both drivers for now, and may be followed by any driver later on who wishes to implement RAID configuration. In the changes proposed in the spec, the driver should be able to figure out the disks to be used for creating RAID on the machine, when some hints are given by the operator to Ironic. The hints help Ironic to figure out what disks should be used for creating RAID. Initially we started with a few (namely disk type (ssd vs hdd) and interface type (scsi vs sata vs ...), etc. But later on due to request from some other folks to include some more criterias (namely filter disks based on inputs on model, firmware version, vendor due to various reasons), we added it to the list of hints. Now, we have * some set of folks *who don't want *model, firmware version, vendor as criteria because if they are added, every driver would need to implement them. * some set of folks *who want *model, firmware version, vendor as criteria because there are practical use-cases in an environment. We have confirmed that filtering based on model, firmware version and vendor can be done on both HP and DRAC hardware for now. I would like to hear everyone's thoughts and probably reach a conclusion of whether be open to include more criteria or not. I think these filters make sense. An operator may want to say RAID all disks of this model; that's completely reasonable. We've already decided we want to implement the same filters for deciding which disk to put the root on[0], and so we'll need to write this code for most/all drivers anyway. We can simply re-use this code for the RAID use case. // jim [0] http://specs.openstack.org/openstack/ironic-specs/specs/kilo/root-device-hints.html Please pour in your thoughts on the thread Regards, Ramakrishnan (irc: rameshg87) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers
Thanks Deepak! Mike is also sending the announce to the vendors in the mail accounts listed in the CI Status page[1]. [1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status On Tue, Jan 20, 2015 at 6:47 AM, Deepak Shetty dpkshe...@gmail.com wrote: Yuck ! its Mar. 19, 2015 (bad copy paste before) On Tue, Jan 20, 2015 at 12:16 PM, Deepak Shetty dpkshe...@gmail.com wrote: Just so that people following this thread know about the final decision, Per https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines the deadline for CI is extended to Mar. 3, 2015 for all volume drivers. snip Deadlines All volume drivers https://github.com/openstack/cinder/tree/master/cinder/volume/drivers need to have a CI by end of* K-3, March 19th 2015*.* Failure will result in removal in the Kilo release.* Discussion regarding this was in the #openstack-meeting IRC room during the Cinder meeting. Read discussion logs http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21 /snip On Tue, Jan 13, 2015 at 3:55 AM, Mike Perez thin...@gmail.com wrote: On 09:03 Mon 12 Jan , Erlon Cruz wrote: Hi guys, Thanks for answering my questions. I have 2 points: 1 - This (remove drivers without CI) is a way impacting change to be implemented without exhausting notification and discussion on the mailing list. I myself was in the meeting but this decision wasn't crystal clear. There must be other driver maintainers completely unaware of this. I agree that the mailing list has not been exhausted, however, just reaching out to the mailing list is not good enough. My instructions back in November 19th [1][2] were that we need to email individual maintainers and the openstack-dev list. That was not done. As far as I'm concerned, we can't stick to the current deadline for existing drivers. I will bring this up in the next Cinder meeting. 2 - Build a CI infrastructure and have people to maintain a the CI for a new driver in a 5 weeks frame. Not all companies has the knowledge and resources necessary to this in such sort period. We should consider a grace release period, i.e. drivers entering on K, have until L to implement theirs CIs. New driver maintainers have until March 19th. [3] That's around 17 weeks since we discussed this in November [2]. This is part the documentation for how to contribute a driver [4], which links to the third party requirement deadline [3]. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines [4] - https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][oslo] plan till end-of-Kilo
On Mon, Jan 19, 2015 at 10:54 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi Kyle/all, (we were going to walk thru that on Mon, but since US is on vacation today, sending it via email to openstack-dev@.) Great, thanks Ihar! So I've talked to Doug Hellmann from oslo, and here is what we have in our oslo queue to consider: 1. minor oslo.concurrency cleanup for *aas repos (we need to drop lockutils-wrapper usage now that base test class sets lockutils fixture); 2. migration to namespace-less oslo libraries (this is blocked by pending oslo.messaging release scheduled this week, will revive patches for all four branches the end of the week) [1]; 3. oslo/kilo-2: graduation of oslo.policy; 4. oslo/kilo-3: graduation of oslo.cache, oslo.versionedobjects. I believe 1. and 2. should be handled in Kilo-2 neutron side. The 2. part will introduce some potential friction in gate due to merge conflicts and new hacking rule applied, so we may want to synchronize it with other refactoring activities. This looks good to me. For 3., I'm not sure we want to go with such a change this cycle. On the other side, while that is potentially unsafe, it may free us from later patching our local policy module copy due to security issues that could be revealed later in the incubator module. Taking into account that we claim support for 15 months for all stable branches, and who knows where it will lead later, earlier reducing our area of responsibility can be a good thing. Given the state of our policy code, we may want to look into this one for Kilo yet. It would be good to get Salv's opinion here as well. For 4., this will definitely need to wait for L. The oslo.cache migration can easily go with in L-1 (the module is used in single place only - metadata agent); as for oslo.versionedobjects, this will need to follow a proper spec process (we had someone willing to post a spec for that, but I don't remember his/her name). Does the plan sound ok? This all looks good to me! I'd like to explore the oslo.policy stuff a bit more before declaring it out of Kilo at this point though, but lets see what comes of that. Thanks, Kyle [1]: https://review.openstack.org/#/q/If0dce29a0980206ace9866112be52 9436194d47e,n,z /Ihar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Weekly subteam status report
On Tue, Jan 20, 2015 at 06:41:50AM -0800, Jim Rollenhagen wrote: Hi all, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 19 Jan, 11:00 UTC) Open: 122 (-11). 4 new (-10), 31 in progress (-1), 0 critical (-1), 14 high (+1) and 6 incomplete (+1) Our bug day pretty well last week, let us repeat from time to time Drivers iLO (wanyen) Making progress on 3rd-party CI test setup. Uses 3-node setup: one for CI infrastructure one for agent-ilo test one for iscsi-ilo test design spec https://review.openstack.org/#/c/134022/ has been merged. converted uefi support for agent-ilo driver spec into 3 bug reports as changes are small. https://review.openstack.org/#/c/137024/ Still quite a few specs that needs reviews secure boot RAID configuration iLO zapping and cleaning IPA partition image iLO sensor Oops, I missed the iRMC driver notes: iRMC (naohirot) Currently working on implemnting Deploy Driver, and good progress. Toward Kilo-2, Power Driver Code, Management Driver Spec and Code, and Deploy Driver Spec are solicited core team's review. https://review.openstack.org/#/q/owner:naohirot%2540jp.fujitsu.com+status:open,n,z // jim // jim [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][vpnaas] Can we require kernel 3.8+ for use with StrongSwan IPSec VPN for Kilo?
Review https://review.openstack.org/#/c/146508/ is adding support for StrongSwan VPN, which needs mount bind to be able to specify different paths for config files. The code, which used some older patch, does a test for /proc/1/ns/net, instead of /proc/1/ns/mnt, because it stated that the latter is only supported in kernel 3.8+. That was a while ago, and I'm wondering if the condition is still true. If we know that for Kilo and on, we'll be dealing with 3.8+ kernels, we could use the more accurate test. Can we require 3.8+ kernel for this? If so, how and where do we ensure that is true? Also, if you can kindly review the code here: https://review.openstack.org/#/c/146508/5/neutron_vpnaas/services/vpn/common/netns_wrapper.py, I'd really appreciate it, as I'm not versed in the Linux proc files at all. Thanks! PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] CentOS and PID file deletion - any solutions?
For review https://review.openstack.org/#/c/147852/, a workaround was created to resolve an issue with deleting a PID file. It adds a slash to the parent directory and then the ownership is correct and it works. Does anyone know of a permanent solution for this issue? Thanks! PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila]Rename driver mode
We have come to decision with it: http://eavesdrop.openstack.org/meetings/manila/2015/manila.2015-01-15-15.02.log.html https://etherpad.openstack.org/p/manila-driver-modes-discussion https://blueprints.launchpad.net/manila/+spec/rename-driver-modes Here is change that implements this decision: https://review.openstack.org/#/c/147821/ I ask people, who is able (driver maintainers?), to test share drivers for presence of some breakage by this change. On Thu, Jan 8, 2015 at 6:36 AM, Ben Swartzlander b...@swartzlander.org wrote: On 01/07/2015 09:20 PM, Li, Chen wrote: Update my proposal again: As a new bird for manila, I start using/learning manila with generic driver. When I reached driver mode,I became really confuing, because I can't stop myself jump into ideas: share server == nova instance svm == share virtual machine == nova instance. Then I tried glusterFS, it is working under single_svm_mode, I asked why it is single mode, the answer I get is This is approach without usage of share-servers == without using share-servers, then why single ??? More confusing ! :( Now I know, the mistake I made is ridiculous. Great thanks to vponomaryov ganso, they made big effort helping me to figure out why I'm wrong. But, I don't think I'm the last one person making this mistake. So, I hope we can change the driver mode name less confusing and more easy to understand. First, svm should be removed, at least change it to ss (share-server), make it consistent with share-server. I don't like single/multi, because that makes me think of numbers of share-servers, makes me want to ask: if I create a share, that share need multi share-servers ? why ? I agree the names we went with aren't the most obvious, and I'm open to changing them. Share-server is the name we have for virtual machines created by manila drivers so a name that refers to share servers rather than svms could make more sense. Also, when I trying glusterFS (installed it following http://www.gluster.org/community/documentation/index.php/QuickStart), when I testing the GlusterFS volume, it said: use one of the servers to mount the volume. Isn't that means using any server in the cluster can work and their work has no difference. So, is there a way to change glusterFS driver to add more than one glusterfs_target, and all glusterfs_targets are replications for each other. Then when manila create a share, chose one target to use. This would distribute data traffic to the cluster, higher bandwidth, higher performance, right ? == This is single_svm_mode, but obviously not single. vponomaryov ganso suggested basic_mode and advanced_mode, but I think basic/advanced is more driver perspective concept. Different driver might already have its own concept of basic advanced, beyong manila scope. This would make admin driver programmer confusing. I really do not like basic/advanced. I think you summarized one reason why it's a bad choice. The relevant difference between the modes is whether the driver is able to create tenant-specific instances of a share filesystem server or whether tenants share access to a single server. As single_svm_mode indicate driver just have information about where to go and how, it is gotten by config opts and some special actions of drivers while multi_svm_mode need to create where and how with infomation. My suggestion is single_svm_mode == static_mode multi_svm_mode == dynamic_mode. As where to go and how are static under single_svm_mode, but dynamically create/delete by manila under multi_svm_mode.\ Static/dynamic is better than basic/advanced, but I still think we can do better. I will think about it and try to come up with another idea before the meeting tomorrow. Also, about the share-server concept. share-server is a tenant point of view concept, it does not know if it is a VM or a dedicated hardware outside openstack because it is not visible to the tenant. Each share has its own share-server, no matter how it get(get from configuration under single_svm_mode, get from manila under multi_svm_mode). I think I understand what you mean here, but in a more technical sense, share servers are something we hide from the tenant. When a tenant asks for a share to be created, it might get created on a server that already exists, or a new one might get created. The tenant has no control over this, and ideally shouldn't even know which decision manila made. The only thing we promise to the tenant is that they'll get a share. The intent of this design is to offer maximum flexibility to the driver authors, and to accommodate the widest variety of possible storage controller designs, without causing details about the backends to leak through the API layer and break the primary goal of Manila which is to provide a standardized API regardless of what the actual implementation is. We need to keep the
[openstack-dev] [gantt] ad-hoc IRC meeting Wed, 1500UTC
We'll try and have an IRC meeting tomorrow so finalize the review for: Remove direct nova DB/API access by Scheduler Filters - https://review.opernstack.org/138444/ We'll start out on #openstack-nova and then create a new channel if needed (#openstack-gantt has a nice ring to it :) -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] 10Gbe performance issue.
On 20 Jan 2015, at 17:14, Piotr Korthals piotr.korth...@intel.com wrote: Hi, I am facing issue with performance of 10 Gigabit Ethernet. Environment 2 hosts each: - 2 * Intel(R) Xeon(R) CPU E5-2690 v2 - Intel 82599ES 10Gb Ethernet - 128GB RAM System: - Centos 6.5 delivered by fuel 6.0 iperf during test of network performance over single stream report 2,5-3Gbps (when using 4+ connection, cumulative transfer can hit over 9Gbps) For comparison, same test was run on official Centos 6.5 with result at minimum 9,3 Gbps In both cases default MTU 1500 was set. From my analyses it looks like something is limiting i/o performance per stream. Are you aware of this issue, and can you comment on it? This is critical for our deployment. How this was measured? VM to VM? Compute to compute? In any case, what is your deployment configuration, especially VLAND or GRE, networking gear, etc. Regards, -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Call for Testing: Ubuntu OpenStack Kilo-1 development milestone
Hi Folks! The Ubuntu Server Team is pleased to announce the general availability of the first development milestone of the OpenStack Kilo release in Ubuntu 15.04 development and for Ubuntu 14.04 LTS via the Ubuntu Cloud Archive. Ubuntu 14.04 LTS For now, you can enable the Ubuntu Cloud Archive for OpenStack Kilo on Ubuntu 14.04 installations by running the following commands: echo deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main \ | sudo tee /etc/apt/sources.list.d/cloud-archive.list sudo apt-get -y install ubuntu-cloud-keyring sudo apt-get update The Ubuntu Cloud Archive for Kilo includes updates for Nova, Glance, Keystone, Neutron, Cinder, Horizon, Swift, Ceilometer and Heat; Ceph (0.87), RabbitMQ (3.4.2), QEMU (2.1), libvirt (1.2.8) and Open vSwitch (2.3.1) back-ports from 15.04 development have also been provided. Ubuntu 15.04 development No extra steps required; just start installing OpenStack! Keystone is still pending update due to review of new dependencies by the Ubuntu MIR team, but that should happen in the next few weeks. New OpenStack components This cycle we’ve also provided packages for Trove, Sahara and Ironic – these projects are part of the integrated OpenStack release but remain in Ubuntu universe for this development cycle, which means they won’t get point release updates or security updates as part of ongoing stable release maintenance once Ubuntu 15.04 and the Kilo Cloud Archive for Ubuntu 14.04 LTS release. NOTE: that if you use the Neutron FWaaS driver, you will need to install the ‘python-neutron-fwaas’ package to continue using this functionality; we will improve this situation in the packaging prior to final release. Reporting bugs -- Let’s face it, as the first development milestone there are bound to be a few bugs so please use the ‘ubuntu-bug’ tool to report any bugs that you find – for example: sudo ubuntu-bug nova-conductor this will ensure that bugs get logged in the right place in Launchpad. Thanks and have fun! Cheers James -- James Page Technical Lead, Ubuntu Server and OpenStack Team Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] 10Gbe performance issue.
Hi, I am facing issue with performance of 10 Gigabit Ethernet. Environment 2 hosts each: - 2 * Intel(R) Xeon(R) CPU E5-2690 v2 - Intel 82599ES 10Gb Ethernet - 128GB RAM System: - Centos 6.5 delivered by fuel 6.0 iperf during test of network performance over single stream report 2,5-3Gbps (when using 4+ connection, cumulative transfer can hit over 9Gbps) For comparison, same test was run on official Centos 6.5 with result at minimum 9,3 Gbps In both cases default MTU 1500 was set. From my analyses it looks like something is limiting i/o performance per stream. Are you aware of this issue, and can you comment on it? This is critical for our deployment. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Optional Properties in an Entity
From: Kevin L. Mitchell [kevin.mitch...@rackspace.com] Sent: Monday, January 19, 2015 4:54 PM When we look at consistency, we look at everything else in OpenStack. From the standpoint of the nova API (with which I am the most familiar), I am not aware of any property that is ever omitted from any payload without versioning coming in to the picture, even if its value is null. Thus, I would argue that we should encourage the first situation, where all properties are included, even if their value is null. That is not the case for the Images API v2: An image is always guaranteed to have the following attributes: id, status, visibility, protected, tags, created_at, file and self. The other attributes defined in the image schema below are guaranteed to be defined, but is only returned with an image entity if they have been explicitly set. [1] [1] http://docs.openstack.org/api/openstack-image-service/2.0/content/image-entities.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.rootwrap 1.5.0 released
The Oslo team is pleased to announce the release of: oslo.rootwrap 1.5.0: Oslo Rootwrap The primary reason for this release is to move the code out of the oslo namespace package as part of https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages For more details, please see the git log history below and: http://launchpad.net/oslo.rootwrap/+milestone/1.5.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.rootwrap Changes in /home/dhellmann/repos/openstack/oslo.rootwrap 1.4.0..1.5.0 - 9c54b0c Add cross-testing script 414750e Updated from global requirements bdb739e Move files out of the namespace package c651d83 Activate pep8 check that _ is imported 44aa91f Workflow documentation is now in infra-manual Diffstat (except docs and test files) - CONTRIBUTING.rst| 7 +- README.rst | 8 +- benchmark/benchmark.py | 6 +- openstack-common.conf | 7 + oslo/rootwrap/__init__.py | 26 ++ oslo/rootwrap/client.py | 133 +- oslo/rootwrap/cmd.py| 113 + oslo/rootwrap/daemon.py | 140 +- oslo/rootwrap/filters.py| 339 +- oslo/rootwrap/jsonrpc.py| 197 +--- oslo/rootwrap/wrapper.py| 196 +--- oslo_rootwrap/__init__.py | 0 oslo_rootwrap/client.py | 144 ++ oslo_rootwrap/cmd.py| 124 + oslo_rootwrap/daemon.py | 151 ++ oslo_rootwrap/filters.py| 350 ++ oslo_rootwrap/jsonrpc.py| 208 + oslo_rootwrap/wrapper.py| 207 + setup.cfg | 2 + test-requirements-py3.txt | 3 + test-requirements.txt | 2 + tox.ini | 1 - 31 files changed, 2323 insertions(+), 1141 deletions(-) Requirements updates diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt index 238a0f8..f0c388c 100644 --- a/test-requirements-py3.txt +++ b/test-requirements-py3.txt @@ -24,0 +25,3 @@ mock=1.0 + +oslotest=1.2.0 # Apache-2.0 + diff --git a/test-requirements.txt b/test-requirements.txt index 4db6103..cfe73db 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -16,0 +17,2 @@ oslosphinx=2.2.0 # Apache-2.0 +oslotest=1.2.0 # Apache-2.0 + __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers
On 13:53 Tue 20 Jan , Erlon Cruz wrote: Thanks Deepak! Mike is also sending the announce to the vendors in the mail accounts listed in the CI Status page[1]. [1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status I've actually gone through each volume driver file and emailed whoever mostly appeared in git blame, as well as whoever appeared recently in commits with an obvious company email address. This has been cross checked with the proposed maintainers file [1]. -- Mike Perez [1] - https://review.openstack.org/#/c/116887/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Question on functional tests
Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function (OpenSwanProcess._get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Health Monitor association with pool
Hmm that is for lbaas v2 docs which shouldn't be in the docs yet because
it is not ready. We will need to file a bug with the docs team to get
the v1 docs back in until v2 is ready to be used (which should be
relatively soon). Thanks for letting us know!
Thanks,
Brandon
On Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:
Hi,
The openstack documentation for LBaaS Neutron v2 APIs does not clearly
define way to associate a HealthMonitor with a pool.
* Will it be done via pool update - put method at
/v2.0/pools/{pool_id}.
* Or it will be done via post method at
/v2.0/lb/pools/{pool_id}/health_monitors
Any other link detailing LBaaS v2 APIs will be great help.
Thanks in advance.
Regards
Shreshtha Joshi
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Pool member status 'ACTIVE' even on health check failure
Yeah before we get those stats in we'll need to finalize v2 because that will affect how the API shows those types of stats to the user. On Mon, 2015-01-19 at 22:33 -0800, Varun Lodaya wrote: Hey Brandon, Thanks for the response. My bad. Seems there is a small bug in horizon. The moment you configure a health monitor, it shows up in the pool. I thought it automatically got associated. But when I checked via CLI, it was not. After associating it via CLI (not able to associate it via horizon, the drop down for health-monitors doesn¹t seem to work), it seems to work fine :). As per stats, ideally, it¹s good to get counters like: ICMP successful requests: x ICMP response timeouts: y ICMP response failures: z HTTP successful responses: a HTTP timeouts: b . . . Just an initial thought, this sort of verifies that monitors are working as expected. Like in current situation, I had to manually login to the server to see if the server is catering to any health-monitoring requests. Even getting haproxy stats is not very straightforward, as you need to open a unix socket in haproxy cfg and restart the haproxy instance which might not be possible in production sometimes. Thanks, Varun On 1/19/15, 8:21 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi Varun, Could you tell me which driver you are using? If you're running the HaproxyOnHostPluginDriver then that should do a check every 6 seconds for members being down. However, other drivers may not do this. It's up to the driver. As for providing health monitor stats, those currently are not being provided. There haven't been any plans for that yet because everyone has been focused on getting the v2 API out. Which is almost complete and plan for that to be completed for Kilo-3. If you'd like to be able to retrieve some health stats, please list them and let us know. We'll hopefully be able to get them in after v2 has completed. Thanks, Brandon On Mon, 2015-01-19 at 14:42 -0800, Varun Lodaya wrote: Hi All, I am trying to get LBaaS running on stable Juno. I can get all the LBaaS components correctly installed and working as expected. But I am facing some issues with the health-monitor. I am not quite sure if it¹s working as expected. I have 2 ubuntu servers as members of http-pool and I have stopped apache process on 1 of the servers. I have HTTP health-monitor configured on the pool which runs every 1 min and checks for 200 response code on HTTP GET. I was expecting it to FAIL after 3 retries and make the status ³INACTIVE² for the member where apache is not running. But for some reason, it¹s always ACTIVE. Can somebody help me with how is it suppose to work and if it¹s a bug? Also, currently I don¹t see any health monitor stats with neutron. Is there any plan to get health monitor stats in future releases? Thanks, Varun _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] User self registration and management
Hi Brad in your scenario the users are already registered - in your corporate LDAP. So this is not too dissimilar to the federation case, where the users are already registered in a remote IDP. You get the user to present his LDAP credentials, which are validated by LDAP. Federation gets the user to enter his IDP credentials, which are validated by the IDP. Once either of these are done, you now have a valid authenticated user who you can give a keystone token to. So the next thing you need to decide, is what is this user authorised to do, which is what our VO roles code does. I therefore see that our VO roles code can work perfectly well with your LDAP authn code. regards David On 20/01/2015 17:43, Brad Pokorny wrote: At Symantec, we provide a simple signup button on the Horizon login page for self registration. Our goal is to not only make it easy for the user to register but to also set up some basic things to make it easy for them to start using OpenStack services. We don't use federated Keystone, so users have to go through the registration to access OpenStack services, but they can then manage their user accounts via existing corporate management tools. Having the signup button on the Horizon login page unifies the experience of working with OpenStack - to sign up, they go to Horizon, and then they log in to Horizon after signup. In our case the users are already in the corporate LDAP, so the user clicks the signup button and is redirected to a page to enter their LDAP credentials. A script behind the page validates the LDAP username and password and sets up the user with their own project and a network for the project (with quota restrictions on the project). So we enable self registration and also set a few extra things up to make it easy for users to start doing real work. Regards, Brad On 1/19/15, 10:03 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Hi Enrique You are right in that we have been addressing different problems. There are three aspects to managing users: registration, assigning authentication credentials, and assigning authorisation credentials. You appear to be primarily concerned with the first two. I have only concentrated on the latter, assuming that the users have already been registered somewhere (with an identity provider) and already have their authn tokens. In a federated infrastructure the authn and authz are split between the IdP and SP, so I have only concentrated on the authz aspects, assuming the authn is already sorted out. If you are interested in a centralised Keystone system, there is no need to split the functionality up, as Keystone can register users, assigns their passwords and their roles. The only place our work would overlap with yours, is in the assignment of roles to users. Our solution, though designed for a federated keystone, can equally well be used with a centralised keystone, since once the user is authenticated, he can then request to join a VO role regardless of who authenticated him (and we have demonstrated that local login works just as well as federated login in our prototype). So you may wish to use our work, once you have sorted out user registration and the assignment of authn credentials regards David On 19/01/2015 15:15, Enrique Garcia wrote: Hi everyone, Enrique, if you have a github repo or some project pages you can point me to that would be wonderful. I'm currently in the very early stages of our proof of concept/prototype, so it would be great to see some work others have done to solve similar issues. If I can find something that works for a few of our use cases it might be a better starting point or good to see what an approach others might find useful is. I'd much rather not duplicate work, nor build something only useful for our use cases, so collaboration towards a community variant would be ideal. Adrian, first of all we are currently working in this functionality so we don't have a final version yet, that's why we are also interested in joining efforts and collaborate in a community variant. Anyway, our first prototype was to do it all in Horizon, implementing a django app similar to what you can find in django registration https://django-registration.readthedocs.org/en/latest/. Currently I am working in moving all the backend logic to a keystone extension and keeping the views and form handling in a django app to make something similar to the current authentication system https://github.com/openstack/django_openstack_auth . You can check here https://github.com/ging/keystone/tree/registration/keystone/contrib/user _registration our current keystone extension if that helps you. Getting into the details, we went for a slightly different approach to the one you propose. Our idea is to have a service in keystone that exposes and API to register and activate users, as well as
[openstack-dev] [Rally] New awesome Rally Docs available on ReadTheDocs now!
Hi stackers, on behalf of the Rally team, I am happy to announce that we have completely redesigned our Rally documentation in ReadTheDocs http://rally.readthedocs.org/en/latest/. The docs have now received a simpler structure and have become much easier to get through! One of the nicest new things is the Rally step-by-step tutorial http://rally.readthedocs.org/en/latest/tutorial.html that explains, in a series of lessons, how to explore the power of Rally in benchmarking your OpenStack clouds. You are also welcome to take a look at the updated tutorial on how to set up a Rally gate job http://rally.readthedocs.org/en/latest/gates.html in your project. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] User self registration and management
At Symantec, we provide a simple signup button on the Horizon login page for self registration. Our goal is to not only make it easy for the user to register but to also set up some basic things to make it easy for them to start using OpenStack services. We don't use federated Keystone, so users have to go through the registration to access OpenStack services, but they can then manage their user accounts via existing corporate management tools. Having the signup button on the Horizon login page unifies the experience of working with OpenStack - to sign up, they go to Horizon, and then they log in to Horizon after signup. In our case the users are already in the corporate LDAP, so the user clicks the signup button and is redirected to a page to enter their LDAP credentials. A script behind the page validates the LDAP username and password and sets up the user with their own project and a network for the project (with quota restrictions on the project). So we enable self registration and also set a few extra things up to make it easy for users to start doing real work. Regards, Brad On 1/19/15, 10:03 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Hi Enrique You are right in that we have been addressing different problems. There are three aspects to managing users: registration, assigning authentication credentials, and assigning authorisation credentials. You appear to be primarily concerned with the first two. I have only concentrated on the latter, assuming that the users have already been registered somewhere (with an identity provider) and already have their authn tokens. In a federated infrastructure the authn and authz are split between the IdP and SP, so I have only concentrated on the authz aspects, assuming the authn is already sorted out. If you are interested in a centralised Keystone system, there is no need to split the functionality up, as Keystone can register users, assigns their passwords and their roles. The only place our work would overlap with yours, is in the assignment of roles to users. Our solution, though designed for a federated keystone, can equally well be used with a centralised keystone, since once the user is authenticated, he can then request to join a VO role regardless of who authenticated him (and we have demonstrated that local login works just as well as federated login in our prototype). So you may wish to use our work, once you have sorted out user registration and the assignment of authn credentials regards David On 19/01/2015 15:15, Enrique Garcia wrote: Hi everyone, Enrique, if you have a github repo or some project pages you can point me to that would be wonderful. I'm currently in the very early stages of our proof of concept/prototype, so it would be great to see some work others have done to solve similar issues. If I can find something that works for a few of our use cases it might be a better starting point or good to see what an approach others might find useful is. I'd much rather not duplicate work, nor build something only useful for our use cases, so collaboration towards a community variant would be ideal. Adrian, first of all we are currently working in this functionality so we don't have a final version yet, that's why we are also interested in joining efforts and collaborate in a community variant. Anyway, our first prototype was to do it all in Horizon, implementing a django app similar to what you can find in django registration https://django-registration.readthedocs.org/en/latest/. Currently I am working in moving all the backend logic to a keystone extension and keeping the views and form handling in a django app to make something similar to the current authentication system https://github.com/openstack/django_openstack_auth . You can check here https://github.com/ging/keystone/tree/registration/keystone/contrib/user _registration our current keystone extension if that helps you. Getting into the details, we went for a slightly different approach to the one you propose. Our idea is to have a service in keystone that exposes and API to register and activate users, as well as other common functionality like password reset, etc. This API is admin only, so Horizon(or whoever wants to register users) needs to have its own admin credentials to use it. If I understand correctly, what you suggest is that is the service the one that would have the credentials, so we differ here. I see some benefits and disadvantages in both approaches, we can discuss them if you want. Secondly, the way we handle temporary user data is setting the enabled attribute to False until they get activated using a key provided during registration. In other words, our extension is a 'delayed user-create API for admins' with some extra functionality like password reset. What do you think about this approach? How do you plan to store this temporal data? It would be great if
Re: [openstack-dev] [gantt] ad-hoc IRC meeting Wed, 1500UTC
Le 20/01/2015 17:53, Dugger, Donald D a écrit : We’ll try and have an IRC meeting tomorrow so finalize the review for: Remove direct nova DB/API access by Scheduler Filters - https://review.opernstack.org/138444/ We’ll start out on #openstack-nova and then create a new channel if needed (#openstack-gantt has a nice ring to it J 1500UTC, really ? Was thinking we agreed 1600UTC :-) Please clarify but +1 for #openstack-gantt, I will no longer feel myself alone. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] 10Gbe performance issue.
If you can get 9Gbps with multiple connections I'm guessing it's because of latency and the buffer size of your sockets. If you change the sending and receiving window size you should be able to fully saturate the link with one connection (though there are several reasons for not doing that). On Tue, Jan 20, 2015 at 8:14 AM, Piotr Korthals piotr.korth...@intel.com wrote: Hi, I am facing issue with performance of 10 Gigabit Ethernet. Environment 2 hosts each: - 2 * Intel(R) Xeon(R) CPU E5-2690 v2 - Intel 82599ES 10Gb Ethernet - 128GB RAM System: - Centos 6.5 delivered by fuel 6.0 iperf during test of network performance over single stream report 2,5-3Gbps (when using 4+ connection, cumulative transfer can hit over 9Gbps) For comparison, same test was run on official Centos 6.5 with result at minimum 9,3 Gbps In both cases default MTU 1500 was set. From my analyses it looks like something is limiting i/o performance per stream. Are you aware of this issue, and can you comment on it? This is critical for our deployment. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] ad-hoc IRC meeting Wed, 1600UTC
Sorry guys, my time issues strike again. Yes, this will be at 1600 UTC (8AM PST). -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Dugger, Donald D [mailto:donald.d.dug...@intel.com] Sent: Tuesday, January 20, 2015 9:54 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Ed Leafe; Murray, Paul (HP Cloud) Subject: [openstack-dev] [gantt] ad-hoc IRC meeting Wed, 1500UTC We'll try and have an IRC meeting tomorrow so finalize the review for: Remove direct nova DB/API access by Scheduler Filters - https://review.opernstack.org/138444/ We'll start out on #openstack-nova and then create a new channel if needed (#openstack-gantt has a nice ring to it :) -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Thanks, Matt On Mon, Jan 19, 2015 at 3:45 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 16/01/15 18:55, Matthew Farina wrote: Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don't have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren't available as debian or ubuntu packages. You are mistaken here. It's actually the other way around. Fedora and Debian packagers used to do heroic work with previous releases to unbundle the static files from Horizon and link to the system-wide JavaScript libraries installed from packages, because their packaging policies require that. The introduction of XStatic was supposed to merely simplify and formalize that process, but now it turns out that it is redundant, and we can cut a corner and save the packagers having to create all those dummy XStatic shims. -- Radomir Dopieralski __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Question on functional tests
I don't believe we have any unit tests that create namespaces or veth pairs. This sounds like it belongs with functional tests. On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique numan.siddi...@enovance.com wrote: Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function ( OpenSwanProcess. _get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [adv-services] Question on functional tests
FYI, numan created a bug [1] about being able to run functional test job in neutron-vpnaas CI I've proposed a patch [2] which simply add neutron-dsvm-functional job in check and gate queue of neutron-vpnaas. Unfortunately, as discussed with marun on IRC, this won't be enough, since this job depends on hook scripts hosted in the neutron repository [3]. This issue will impact all advanced services which want to run functional test. I will try to investigate this deeper, but any though on this issue would be appreciated [1]https://bugs.launchpad.net/openstack-ci/+bug/1412770 [2]https://review.openstack.org/#/c/148616/ [3] https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/neutron-functional.yaml On Tue, Jan 20, 2015 at 9:02 PM, Kevin Benton blak...@gmail.com wrote: I don't believe we have any unit tests that create namespaces or veth pairs. This sounds like it belongs with functional tests. On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique numan.siddi...@enovance.com wrote: Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function ( OpenSwanProcess. _get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On Wed Jan 21 2015 at 7:00:12 AM Matthew Farina m...@mattfarina.com wrote: Radomir, maybe you can help me better understand where this would go. I have a few questions. First, can you point me to a time when horizon used system packages successfully for JavaScript libraries? When I looked through the Debian and Ubuntu packages I couldn't find the libraries horizon is using. I'm curious to see this in action. I'm not a user of these packaging systems, but I found this, which I believe shows the javascript system packages used: https://packages.debian.org/sid/openstack-dashboard Front-end systems almost never use system packagers like this. Can you point me to applications like horizon that use system packages this way? If Horizon is going to go it virtually alone in this space, what will that mean for our level of work and ability to have updates? Horizon is not a typical web front end system, it's part of OpenStack, and thus has to abide by OpenStack packaging conventions. Those dictate that we must have Horizon packaged by system packagers for deployment. Richard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Question on functional tests
My question is whether the tests proposed should be unit tests or functional tests. They only test one method, and it's not a complete piece of functionality - like creating a VPN connection. If that one system call is mocked, these could all be treated as unit tests. So I'm wondering if there is an advantage in actually testing the system call (getaddrinfo), as part of this work? Thoughts? PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Tue, Jan 20, 2015 at 3:02 PM, Kevin Benton blak...@gmail.com wrote: I don't believe we have any unit tests that create namespaces or veth pairs. This sounds like it belongs with functional tests. On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique numan.siddi...@enovance.com wrote: Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function ( OpenSwanProcess. _get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] iptables routes are not being injected to router namespace
On 01/20/2015 09:20 AM, Xavier León wrote: Hi all, we've been doing some tests with openstack kilo and found out a problem: iptables routes are not being injected to the router namespace. Scenario: - a private network NOT connected to the outside world. - a router with only one interface connected to the private network. - a vm instance connected to the private network as well. From inside the instance, we try to get some information from the metadata service with curl: $ curl http://169.254.169.254 curl: (7) couldn't connect to host With the same set up in juno, there was no such problem and metadata information is shown. The request is not filtered at the instance and hits the router namespace (checked with tcpdump). However, when looking from the controller at the iptables rules at the router, they appear empty. stack@devstack: ~$ sudo ip netns exec qrouter-d4ec737a-c5fb-4f5b-8bd0-1b5353bbade3 iptables-save snip # Generated by iptables-save v1.4.21 on Tue Jan 20 14:05:48 2015 *filter :INPUT ACCEPT [5:914] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [10:868] COMMIT Are you sure the l3-agent is running? You should have seen wrapped rules from it in most of these tables, for example: # Generated by iptables-save v1.4.21 on Tue Jan 20 16:29:19 2015 *filter :INPUT ACCEPT [34:10882] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1:84] :neutron-filter-top - [0:0] :neutron-l3-agent-FORWARD - [0:0] :neutron-l3-agent-INPUT - [0:0] :neutron-l3-agent-OUTPUT - [0:0] :neutron-l3-agent-local - [0:0] [...] I would check the log files for any errors. -Brian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Health Monitor association with pool
On Tue, Jan 20, 2015 at 12:49 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:
Hmm that is for lbaas v2 docs which shouldn't be in the docs yet because
it is not ready. We will need to file a bug with the docs team to get
the v1 docs back in until v2 is ready to be used (which should be
relatively soon). Thanks for letting us know!
Hi all,
I've fixed the logged bug:
https://bugs.launchpad.net/openstack-manuals/+bug/1412944
Longer explanation, the referenced link [1] is to a source document that is
going to openstack-attic as soon as the infra team does their scheduled
gerrit downtime. [2] Also, since our build jobs don't delete old files, I
had to manually delete the outdated docs. Once this spec is complete this
particular issue won't happen any more. [3]
Thanks,
Anne
1.
http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html
2. https://review.openstack.org/#/c/145289/
3.
http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html
Thanks,
Brandon
On Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:
Hi,
The openstack documentation for LBaaS Neutron v2 APIs does not clearly
define way to associate a HealthMonitor with a pool.
* Will it be done via pool update - put method at
/v2.0/pools/{pool_id}.
* Or it will be done via post method at
/v2.0/lb/pools/{pool_id}/health_monitors
Any other link detailing LBaaS v2 APIs will be great help.
Thanks in advance.
Regards
Shreshtha Joshi
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Anne Gentle
annegen...@justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today
On 01/20/2015 01:30 PM, Ian Cordasco wrote: On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org wrote: Hi everyone, Given that the agenda docket is pretty slim this week, I'd like to skip this cross-project meeting and have the next one on Jan 27. sigmavirus24 posted the Cross-project DevRef akin to Nova's item but I'd prefer if we discussed it on the mailing-list first (not certain it requires everyone's attention just yet, and could just be proposed as a spec). Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey all, First, let me provide some context. The week before last, an update to sqlalchemy-migrate broke glance’s gate. While helping us fix the problem, Matt Riedemann noticed that the project doesn’t have a Developer Reference document. The document helps new developers determine what system packages they need to build a development environment for the project. We discussed the idea of putting one together for glance at the team meeting last week. While discussing it, we realized a lot of the steps are similar to Nova’s and it might benefit OpenStack as a whole to have one common DevRef that links off to individual ones for further configuration. The list of common steps could be maintained in one place (rather than synchronized between projects) and then individual extensions would be maintained with in each project or wiki. Before we started duplicating content in our own document, we wanted to present the idea to the cross-project team and the community as a whole. Feedback is greatly appreciated, Ian I think a common shared developer reference is a great idea, Ian. ++ -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [trove] Confused about nova_proxy_admin_* settings
I've been looking at how the 3 nova_proxy_admin_* settings are used. I'm coming to the conclusion that I'm confused: E.g I note that a standard devstack (stable/juno branch) with trove enabled sets these as follows: nova_proxy_admin_pass = nova_proxy_admin_tenant_name = trove nova_proxy_admin_user = radmin However there is no 'radmin' user (or role) created in keystone, so the settings above cannot possibly work (if they were needed/used). Some experimentation involving removing these three settings from all of the trove config files seems to support the idea that they are in fact not needed, which has me somewhat puzzled. If someone could shed some light here that would be awesome! Thanks Mark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][python-clients] More freedom for all python clients
On Wed, Jan 14, 2015, at 04:50 AM, Sean Dague wrote: On 01/14/2015 03:55 AM, Flavio Percoco wrote: On 13/01/15 14:31 -0500, Sean Dague wrote: On 01/13/2015 02:10 PM, Jay Pipes wrote: On 01/13/2015 12:39 PM, Zane Bitter wrote: On 13/01/15 10:01, Jeremy Stanley wrote: On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote: Why doesn't rally just remove itself from projects.txt, then there would be no restrictions on what it adds. I second this recommendation. If Rally wants to depend on things which are not part of OpenStack and not required to run or test OpenStack in an official capacity (and since it's not an official OpenStack project it's entirely within its rights to want to do that), then forcing it to comply with the list of requirements for official OpenStack projects is an unnecessarily restrictive choice. FWIW I don't really agree with this advice. The purpose of openstack/requirements is to ensure that it's possible to create a distribution of OpenStack without conflicting version requirements, not to force every project to use every dependency listed. As such, some co-ordination around client libraries for related projects seems like it ought to be an uncontroversial addition. (Obviously it's easy to imagine potential additions that would legitimately be highly controversial, but IMHO this isn't one of them.) Saying that we require people to use our tools to get into the club but that our tools are not going to accommodate them in any way until they are in sounds a bit too close to Go away to my ears. +1 I think as we grow global-requirements probably needs to be broken up into functional lists. What's allowed in base-iass, what's allowed in application services, what's allowed in docs, etc, etc. The complexity of keeping the g-r list actually working goes up sort of n^2 as the size of it, because pip doesn't have a real solver. This is a barely functional set of plate spinning so just add everything misses the point that the breaks get more and more difficult to unwind. If someone is up for stepping up and contributing to breaking up into domains, please do. But I think while this remains a global list we really do need to be a bit careful here. Do we really need a per-domain g-r? With the upcoming changes in the openstack governance model, I believe this won't scale even if we break it into per-domain basis. Some questions that need answeres are: - Who's going to review the per domain g-r ? If it's a centralized team, then it won't definitely scale. If it's the domain team then, what's the real point of having these requirements? - How are we going to support the creation and maintnance of these g-r in the gate? Are they actually worth it? While I understand why we have g-r, I really don't think it'll scale for a broader community as we're envisioning it. With that in mind, I'd probably recommend to have 1 requirements group for the base-caas integrated gate and let other projects and groups have their own requirements. That is, non base-caas projects should get the versions of their common requirements from g-r so that they won't conflict if they're installed alongside with any of the base-caas projects. But other than those base requirements, I'd let non base-caas projects have what they need (which is pretty much what heat's team has done with the contrib packages, AFAICT). I know this opens the doors for version conflicts between the requirements of non base-caas projects but I think this is a more welcoming (and non-blocking) way to do things until we've a better one. Hope the above makes some sense I blame the lack of coffee if it doesn't, Flavio We have the base infrastructure of that in devstack today with a SOFT requirements update - https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704 If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft in your devstack run, we will leave extra dependencies untouched. Probably a few more bits required to make it really easy to expose, but that direction is also feasable. The reason I brought up domains though is that some groups really want the facility to have common requirements lists across a domain. Like the OpenStack Docs team. They've currently inserted a ton of stuff in g-r that really shouldn't be there because they have a lot of git trees, and the synchronization is a nice feature. However, if there were domain specific lists, that would be fine. A collection of projects that want to coordinate could all agree on a domain specific set of lists, and off we go. Maybe that list wouldn't even need to be contained in the main repo, it could be in a sub repo so have different approvers. This ml thread came up in the TC meeting today and I am responding here to catch the thread up with the meeting.
Re: [openstack-dev] [Cinder] Cutoff deadlines for cinder drivers
Mike, Thanks for the diligent efforts to get the word out! Jay On Jan 20, 2015 12:30 PM, Mike Perez thin...@gmail.com wrote: On 13:53 Tue 20 Jan , Erlon Cruz wrote: Thanks Deepak! Mike is also sending the announce to the vendors in the mail accounts listed in the CI Status page[1]. [1] https://wiki.openstack.org/wiki/Cinder/third-party-ci-status I've actually gone through each volume driver file and emailed whoever mostly appeared in git blame, as well as whoever appeared recently in commits with an obvious company email address. This has been cross checked with the proposed maintainers file [1]. -- Mike Perez [1] - https://review.openstack.org/#/c/116887/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)
On Wed, Jan 21, 2015 at 11:20:12AM +0900, Ken'ichi Ohmichi wrote: Hi David, As we told today, I tried Neutron service client migration to tempest-lib. but I found some blocking thing for it and I'd like to share it. I thought that the base service_client module and neutron service client are migrated to tempest-lib without other service clients as the first step. For doing that, we need to remove all CONF values from the base service_client module and neutron service client. We can remove all CONF values from neutron one but cannot do from the base service client before removing all CONF values from the other service clients due to: https://github.com/openstack/tempest/blob/master/tempest/common/service_client.py#L31 So we need to remove all CONF values from all service clients before neutron service client migration. The first thing that I feel we should be migrating before we start handling the service clients is the auth/credential code in tempest/auth.py. Right now the way tempest-lib is handling the auth layer is by passing in an auth provider as an arg, which is fine but the only examples of a working auth provider is in the tempest tree, not in the library. This isn't really useful for external consumers of tempest-lib. Before we start working on migrating other service clients I'd like to have the auth provider layer (and anything that requires) migrated into tempest-lib. I don't see much value in having other service clients migrated if this isn't sorted first. -Matt Treinish 2015-01-14 10:45 GMT+09:00 Kenichi Oomichi oomi...@mxs.nes.nec.co.jp: Hi David, -Original Message- From: David Kranz [mailto:dkr...@redhat.com] Sent: Wednesday, January 14, 2015 4:25 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC) On 01/08/2015 05:34 AM, Ken'ichi Ohmichi wrote: Hi, Unfortunately, I cannot join tomorrow meeting. So I'd like to share the progress of tempest-lib RestClient dev before the meeting. As Paris summit consensus, we have a plan to move RestClient from tempest to tempest-lib for moving API tests to each project in the future. And we are cleaning the code of RestClient up in tempest now. The progress will be complete with some patches[1]. After merging them, I will move the code to tempest-lib. This dev requires many patches/reviews, and many people have already worked well. Thank you very much for helping this dev, and I appreciate continuous effort. [1]: https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:rest-client,n,z Thanks Ken Ohmichi Ken, I have a question about this. The end goal is to move the service clients and so they must also be free of CONF references. But your current changes create a ServiceClient that still uses CONF in its constructor rather than taking the arguments. So I'm not sure what ServiceClient is adding. I also think whatever class the service clients are inheriting cannot contain CONF values? I was assuming the final arrangement would be something like, using neutron as an example: tempest_lib.RestClient(all needed args) tempest_lib.NeutronClient(all needed args to super) tempest.NeutronClient(pass CONF values to super) and where the tempest_lib neutron client would be used by neutron tests either through inheritance or delegation. Is that different than your vision? Yeah, that is the same as my vision about service clients. At this time, I just move CONF values to service clients just for RestClient. But maybe we will change tempest/clients.py to the following for passing CONF values: - self.network_client = NetworkClientJSON(self.auth_provider) + self.network_client = NetworkClientJSON(self.auth_provider, + CONF.network.catalog_type, + CONF.network.region or CONF.identity.region, + endpoint_type=CONF.network.endpoint_type, + build_interval=CONF.network.build_interval, + build_timeout=CONF.network.build_timeout, + disable_ssl_certificate_validation=CONF.identity.disable_ssl_certificate_validation, + ca_certs=CONF.identity.ca_certificates_file, + trace_requests=CONF.debug.trace_requests) That is the next step for moving service clients to tempest-lib. Thanks Ken'ichi Ohmichi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)
Hi David, As we told today, I tried Neutron service client migration to tempest-lib. but I found some blocking thing for it and I'd like to share it. I thought that the base service_client module and neutron service client are migrated to tempest-lib without other service clients as the first step. For doing that, we need to remove all CONF values from the base service_client module and neutron service client. We can remove all CONF values from neutron one but cannot do from the base service client before removing all CONF values from the other service clients due to: https://github.com/openstack/tempest/blob/master/tempest/common/service_client.py#L31 So we need to remove all CONF values from all service clients before neutron service client migration. Thanks Ken Ohmichi -- 2015-01-14 10:45 GMT+09:00 Kenichi Oomichi oomi...@mxs.nes.nec.co.jp: Hi David, -Original Message- From: David Kranz [mailto:dkr...@redhat.com] Sent: Wednesday, January 14, 2015 4:25 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC) On 01/08/2015 05:34 AM, Ken'ichi Ohmichi wrote: Hi, Unfortunately, I cannot join tomorrow meeting. So I'd like to share the progress of tempest-lib RestClient dev before the meeting. As Paris summit consensus, we have a plan to move RestClient from tempest to tempest-lib for moving API tests to each project in the future. And we are cleaning the code of RestClient up in tempest now. The progress will be complete with some patches[1]. After merging them, I will move the code to tempest-lib. This dev requires many patches/reviews, and many people have already worked well. Thank you very much for helping this dev, and I appreciate continuous effort. [1]: https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:rest-client,n,z Thanks Ken Ohmichi Ken, I have a question about this. The end goal is to move the service clients and so they must also be free of CONF references. But your current changes create a ServiceClient that still uses CONF in its constructor rather than taking the arguments. So I'm not sure what ServiceClient is adding. I also think whatever class the service clients are inheriting cannot contain CONF values? I was assuming the final arrangement would be something like, using neutron as an example: tempest_lib.RestClient(all needed args) tempest_lib.NeutronClient(all needed args to super) tempest.NeutronClient(pass CONF values to super) and where the tempest_lib neutron client would be used by neutron tests either through inheritance or delegation. Is that different than your vision? Yeah, that is the same as my vision about service clients. At this time, I just move CONF values to service clients just for RestClient. But maybe we will change tempest/clients.py to the following for passing CONF values: - self.network_client = NetworkClientJSON(self.auth_provider) + self.network_client = NetworkClientJSON(self.auth_provider, + CONF.network.catalog_type, + CONF.network.region or CONF.identity.region, + endpoint_type=CONF.network.endpoint_type, + build_interval=CONF.network.build_interval, + build_timeout=CONF.network.build_timeout, + disable_ssl_certificate_validation=CONF.identity.disable_ssl_certificate_validation, + ca_certs=CONF.identity.ca_certificates_file, + trace_requests=CONF.debug.trace_requests) That is the next step for moving service clients to tempest-lib. Thanks Ken'ichi Ohmichi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today
On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org wrote: Hi everyone, Given that the agenda docket is pretty slim this week, I'd like to skip this cross-project meeting and have the next one on Jan 27. sigmavirus24 posted the Cross-project DevRef akin to Nova's item but I'd prefer if we discussed it on the mailing-list first (not certain it requires everyone's attention just yet, and could just be proposed as a spec). Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey all, First, let me provide some context. The week before last, an update to sqlalchemy-migrate broke glance’s gate. While helping us fix the problem, Matt Riedemann noticed that the project doesn’t have a Developer Reference document. The document helps new developers determine what system packages they need to build a development environment for the project. We discussed the idea of putting one together for glance at the team meeting last week. While discussing it, we realized a lot of the steps are similar to Nova’s and it might benefit OpenStack as a whole to have one common DevRef that links off to individual ones for further configuration. The list of common steps could be maintained in one place (rather than synchronized between projects) and then individual extensions would be maintained with in each project or wiki. Before we started duplicating content in our own document, we wanted to present the idea to the cross-project team and the community as a whole. Feedback is greatly appreciated, Ian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Question on functional tests
Is the test asserting things about interactions with the system, or does it just happen to use a system call as a side effect of one of the setups? On Tue, Jan 20, 2015 at 1:24 PM, Paul Michali p...@michali.net wrote: My question is whether the tests proposed should be unit tests or functional tests. They only test one method, and it's not a complete piece of functionality - like creating a VPN connection. If that one system call is mocked, these could all be treated as unit tests. So I'm wondering if there is an advantage in actually testing the system call (getaddrinfo), as part of this work? Thoughts? PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Tue, Jan 20, 2015 at 3:02 PM, Kevin Benton blak...@gmail.com wrote: I don't believe we have any unit tests that create namespaces or veth pairs. This sounds like it belongs with functional tests. On Tue, Jan 20, 2015 at 10:20 AM, Numan Siddique numan.siddi...@enovance.com wrote: Hello, I am working on a bug [1] on neutron vpnaas and submitted the patch here [2]. The test code to test the fix does the following - creates a namespace - creates a veth pair and add one interface into the namespace - configures the interface with an ip address and - adds a default gateway - and of course tests the code. This test code only tests a specific function ( OpenSwanProcess. _get_nexthop()) Reviewers of this patch are not clear if this should be part of functional tests or unit tests. Can unit tests create linux namespaces, interfaces etc or it falls under functional tests? Please let me know your thoughts on this. [1] - https://bugs.launchpad.net/neutron/+bug/1405413 [2] - https://review.openstack.org/#/c/145005/5 Regards Numan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][python-clients] More freedom for all python clients
On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote: ... This ml thread came up in the TC meeting today and I am responding here to catch the thread up with the meeting. The soft update option is the suggested fix for non openstack projects that want to have most of their requirements managed by global requirements. For the project structure reform opening things up we should consider loosening the criteria to get on the list and make it primarily based on technical criteria such as py3k support, license compatibility, upstream support/activity, and so on (basically the current criteria with less of a focus on where the project comes from if it is otherwise healthy). Then individual projects would choose the subset they need to depend on. This model should be viable with different domains as well if we go that route. The following is not from the TC meeting but addressing other portions of this conversation: At least one concern with this option is that as the number of total requirements goes up is the difficulty in debugging installation conflicts becomes more difficult too. I have suggested that we could write tools to help with this. Install bisection based on pip logs for example, but these tools are still theoretical so I may be overestimating their usefulness. To address the community scaling aspect I think you push a lot of work back on deployers/users if we don't curate requirements for anything that ends up tagged as production ready (or whatever the equivalent tag becomes). Essentially we are saying this doesn't scale for us so now you deal with the fallout. Have fun, which isn't very friendly to people consuming the software. We already have an absurd number of requirements and management of them has appeared to scale. I don't foresee my workload going up if we open up the list as suggested. Perhaps I missed something, but the initial request wasn't about random packages, it was about other stackforge clients - these are things in the ecosystem! I'm glad we have technical solutions, but it just seems odd to me that adding them would ever have been controversial. On the pip solver side, joe gordon was working on a thing to install a fixed set of packages by bypassing the pip resolver... not sure how thats progressing. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today
+2 This topic had come up in Cinder I believe as well. Having a common devref for common content would be good and would make it easier to keep the documentation current. Jay On Jan 20, 2015 4:05 PM, Jay Pipes jaypi...@gmail.com wrote: On 01/20/2015 01:30 PM, Ian Cordasco wrote: On Jan 20, 2015, at 05:23, Thierry Carrez thie...@openstack.org wrote: Hi everyone, Given that the agenda docket is pretty slim this week, I'd like to skip this cross-project meeting and have the next one on Jan 27. sigmavirus24 posted the Cross-project DevRef akin to Nova's item but I'd prefer if we discussed it on the mailing-list first (not certain it requires everyone's attention just yet, and could just be proposed as a spec). Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey all, First, let me provide some context. The week before last, an update to sqlalchemy-migrate broke glance’s gate. While helping us fix the problem, Matt Riedemann noticed that the project doesn’t have a Developer Reference document. The document helps new developers determine what system packages they need to build a development environment for the project. We discussed the idea of putting one together for glance at the team meeting last week. While discussing it, we realized a lot of the steps are similar to Nova’s and it might benefit OpenStack as a whole to have one common DevRef that links off to individual ones for further configuration. The list of common steps could be maintained in one place (rather than synchronized between projects) and then individual extensions would be maintained with in each project or wiki. Before we started duplicating content in our own document, we wanted to present the idea to the cross-project team and the community as a whole. Feedback is greatly appreciated, Ian I think a common shared developer reference is a great idea, Ian. ++ -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Announcing Magnum's First Release
On Tue, Jan 20, 2015 at 11:48 PM, Adrian Otto adrian.o...@rackspace.com wrote: Hello, The Magnum community is pleased to announce the first release of Magnum available now for download from: https://github.com/stackforge/magnum/releases/tag/m1 Congratulations to you and everyone else that made this possible! Regards, Eric Windisch __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] some questions about neutron
hi，all： I have some questions about neutron: 1、how many compute nodes can be supported by one neutron-server ? 2、If one neutron-server can't support two many nodes , for example 1000 servers， can two neutron-servers work together in active-active mode ? Thans a lot ! gentle wu china mobile __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Telco][NFV] Use case documentation and review
Hi all, Based on the discussion last week during our first use case deep dive I have created etherpads for each use case and linked them from the wiki in the hope that this might provide a better mechanism for recording feedback in lieu of moving to a e.g. gerrit for these: https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases I also added links to the orchestration and service chaining etherpads under a work in progress heading. We can discuss how to proceed from here in the meeting tomorrow. Thanks, Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
