Re: [openstack-dev] [eventlet][requirements] Issue with eventlet = 0.17.2 and ssl
Hi, Assuming https support is a key requirement for OpenStack then a pin seems appropriate here? (is that assumption valid)? -stephen -- Stephen Mulcahy Systems/Software Engineer HP Cloud Postal Address: Hewlett Packard Galway Ltd, Ballybrit Business Park, Galway Registered Office: Hewlett Packard Galway Ltd, 63-74 Sir John Rogerson's Quay, Dublin 2 Registered Number: 361933 -Original Message- From: McLaren, Stuart Sent: 05 May 2015 10:31 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [eventlet][requirements] Issue with eventlet = 0.17.2 and ssl All, When using a version of python which has the new SSLContext (ie python 3, 2.7.9 and at least some 2.7.8 versions) this issue: https://github.com/eventlet/eventlet/issues/226 (where the combination of a newer python with https/eventlet and requests doesn't handle SSL certs propertly) seems to prevent running OpenStack with https using later 2.x python versions. Has anyone else hit this? There is a fix now on eventlet's master branch, but it hasn't been released yet. Since versions of eventlet prior to 0.17.3 aren't python 3 compatible [1] I'm guessing that we need to wait for a new eventlet to be released and can't update global-requirements to pin to an older version as a workaround? Thanks. -Stuart [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/061091.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 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] [heat]: stack stays interminably under the status create in progress
Hello there, I started a project where I need to deploy stacks and orchastrate them using heat (autoscaling and so on..). I just started playing with heat and the creation of my first stack is never complete. It stays in the status create in progress. My log files don't say much. For my template i'm using a veery simple one to launch a small instance. Any ideas what that might be? In advance, thank you for your response. sara, __ 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] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Doug __ 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] IPv4 transition/interoperation with IPv6
Hi Mike, Currently dual stack is supported. Can you be specific on what interoperation/transition techniques you are interested in? We’ve been thinking about NAT64 (stateless or stateful). thanks, Robert On 5/4/15, 9:56 PM, Mike Spreitzer mspre...@us.ibm.commailto:mspre...@us.ibm.com wrote: Does Neutron support any of the 4/6 interoperation/transition techniques? I wear an operator's hat nowadays, and want to make IPv6 as useful and easy to use as possible for my tenants. I think the interoperation/transition techniques will play a big role in this. Thanks, Mike __ 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] Speed Up RabbitMQ Recovering
Thank you Andrew. Sorry for misspell your name in the previous email.
on 2015/05/05 14:25, Andrew Beekhof wrote:
On 5 May 2015, at 2:31 pm, Zhou Zheng Sheng / 周征晟 zhengsh...@awcloud.com
wrote:
Thank you Bogdan for clearing the pacemaker promotion process for me.
on 2015/05/05 10:32, Andrew Beekhof wrote:
On 29 Apr 2015, at 5:38 pm, Zhou Zheng Sheng / 周征晟
zhengsh...@awcloud.com wrote:
[snip]
Batch is a pacemaker concept I found when I was reading its
documentation and code. There is a batch-limit: 30 in the output of
pcs property list --all. The pacemaker official documentation
explanation is that it's The number of jobs that the TE is allowed to
execute in parallel. From my understanding, pacemaker maintains cluster
states, and when we start/stop/promote/demote a resource, it triggers a
state transition. Pacemaker puts as many as possible transition jobs
into a batch, and process them in parallel.
Technically it calculates an ordered graph of actions that need to be
performed for a set of related resources.
You can see an example of the kinds of graphs it produces at:
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-config-testing-changes.html
There is a more complex one which includes promotion and demotion on the
next page.
The number of actions that can run at any one time is therefor limited by
- the value of batch-limit (the total number of in-flight actions)
- the number of resources that do not have ordering constraints between
them (eg. rsc{1,2,3} in the above example)
So in the above example, if batch-limit = 3, the monitor_0 actions will
still all execute in parallel.
If batch-limit == 2, one of them will be deferred until the others complete.
Processing of the graph stops the moment any action returns a value that
was not expected.
If that happens, we wait for currently in-flight actions to complete,
re-calculate a new graph based on the new information and start again.
So can I infer the following statement? In a big cluster with many
resources, chances are some resource agent actions return unexpected
values,
The size of the cluster shouldn’t increase the chance of this happening
unless you’ve set the timeouts too aggressively.
If there are many types of resource agents, and anyone of them is not
well written, it might cause trouble, right?
and if any of the in-flight action timeout is long, it would
block pacemaker from re-calculating a new transition graph?
Yes, but its actually an argument for making the timeouts longer, not shorter.
Setting the timeouts too aggressively actually increases downtime because of
all the extra delays and recovery it induces.
So set them to be long enough that there is unquestionably a problem if you
hit them.
But we absolutely recognise that starting/stopping a database can take a very
long time comparatively and that it shouldn’t block recovery of other
unrelated services.
I would expect to see this land in Pacemaker 1.1.14
It will be great to see this in Pacemaker 1.1.14. From my experience
using Pacemaker, I think customized resource agents are possibly the
weakest part. This feature should improve the handling for resource
action timeouts.
I see the
current batch-limit is 30 and I tried to increase it to 100, but did not
help.
Correct. It only puts an upper limit on the number of in-flight actions,
actions still need to wait for all their dependants to complete before
executing.
I'm sure that the cloned MySQL Galera resource is not related to
master-slave RabbitMQ resource. I don't find any dependency, order or
rule connecting them in the cluster deployed by Fuel [1].
In general it should not have needed to wait, but if you send me a crm_report
covering the period you’re talking about I’ll be able to comment specifically
about the behaviour you saw.
You are very nice, thank you. I uploaded the file generated by
crm_report to google drive.
https://drive.google.com/file/d/0B_vDkYRYHPSIZ29NdzV3NXotYU0/view?usp=sharing
Is there anything I can do to make sure all the resource actions return
expected values in a full reassembling?
In general, if we say ‘start’, do your best to start or return ‘0’ if you
already were started.
Likewise for stop.
Otherwise its really specific to your agent.
For example an IP resource just needs to add itself to an interface - it cant
do much differently, if it times out then the system much be very very busy.
The only other thing I would say is:
- avoid blocking calls where possible
- have empathy for the machine (do as little as is needed)
+1 for the empathy :)
Is it because node-1 and node-2
happen to boot faster than node-3 and form a cluster, when node-3 joins,
it triggers new state transition? Or may because some resources are
already started, so pacemaker needs to stop them firstly?
We only stop them if they shouldn’t yet be running (ie. a colocation or
ordering dependancy
Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?
On Mon, May 04, 2015 at 07:22:24PM +, Nikhil Komawar wrote: This is a really nice idea. Idea is indeed nice, but I have to fully agree with all of what Theirry says. I feel the same, that we can offload some I personally don't feel it's about offloading to some hypothetical person who'll magically understand (_and_ keep up) the detailed technical context across the projects to produce such a high-quality developer-oriented newsletter. Taking the venerable LWN as example, those who write most of the articles are folks who're technically very involved (not at a hand-wavy level, giving some directions) in Kernel and related projects. The thorough research completely shines through. It's more than a full-time job given the number of OpenStack projects, and assuming the the cadence of such a newsletter is once a month. of the work from the liaisons and reduce the number of syncs that need to happen. This can be a good source of asynchronous communication however, I still feel that we need to keep a good balance of both. Also, I like the proposed scope of the newsletter. [. . .] -- /kashyap __ 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] [Rally] Improve review process
Hi, Rally Team. I have created Rally Gerrit dashboard that organized patches in groups: Critical for next release, Waiting for final approve, Bug fixes, Proposed specs, Important patches, Ready for review, Has -1 but passed tests. Please use link http://goo.gl/iRxA5t for you comfortable. Patch is here https://review.openstack.org/#/c/179610/ It was made by gerrit-dash-creator. First group are the patches that are needed to merge to the nearest release. Content of the next three groups is obvious from the titles. Important patches - its just patches chosen(starred) by Boris Pavlovic or Mikhail Dubov. Ready for review - patches that are waiting for attention. And the last section - its patches with -1 mark but they passed CI. Roman Vasilets, Mirantis Inc. Intern Software Engineer __ 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] Nominate Julia Aranovich for fuel-web core
+1 On Tue, May 5, 2015 at 1:06 PM, Evgeniy L e...@mirantis.com wrote: +1 On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com: +1, indeed Julia's reviews are very thorough. P. On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote: Hi, I'd like to nominate Julia Aranovich http://stackalytics.com/report/users/jkirnosova for fuel-web https://github.com/stackforge/fuel-web core team. Julia's reviews are always thorough and have decent quality. She is one of the top contributors and reviewers in fuel-web repo (mostly for JS/UI stuff). Please vote by replying with +1/-1. -- Vitaly Kramskikh, Fuel UI Tech Lead, 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 __ 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] Juno Multinode installation error
Hi,
A better place to ask this question would be ask.openstack.org .
Cheers,
Ajaya
On Tue, May 5, 2015 at 4:56 PM, Abhishek Talwar abhishek.tal...@tcs.com
wrote:
Hi Folks,
I am trying to setup a multinode OpenStack. When I boot an instance it is
successfully created but it is going in ERROR state. I have checked the
logs in /var/log/nova/nova-scheduler.log and it gives an Operational error
“database is locked”. Moreover when I check the database there are no
tables getting created in the Nova database, while Neutron and others have
there tables.
The logs are following :
2015-05-05 14:35:13.158 18551 TRACE nova.openstack.common.periodic_task
OperationalError: (OperationalError) database is locked u'UPDATE
reservations SET deleted_at=?, deleted=id, updated_at=updated_at WHERE
reservations.deleted = ? AND reservations.expire ?' ('2015-05-05
09:05:13.150105', 0, '2015-05-05 09:05:13.138314')
2015-05-05 14:35:13.158 18551 TRACE nova.openstack.common.periodic_task
2015-05-05 14:37:47.972 18551 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on controller:5672
2015-05-05 14:37:47.991 18551 INFO oslo.messaging._drivers.impl_rabbit [-]
Connected to AMQP server on controller:5672
2015-05-05 15:10:59.535 18551 INFO nova.openstack.common.service [-]
Caught SIGTERM, exiting
2015-05-05 15:11:01.506 19260 AUDIT nova.service [-] Starting scheduler
node (version 2014.2.2)
2015-05-05 15:11:03.691 19260 INFO oslo.messaging._drivers.impl_rabbit
[req-7b53c22a-2161-4f9f-9942-c39ad5b35ca0 ] Connecting to AMQP server on
controller:5672
2015-05-05 15:11:03.747 19260 INFO oslo.messaging._drivers.impl_rabbit
[req-7b53c22a-2161-4f9f-9942-c39ad5b35ca0 ] Connected to AMQP server on
controller:5672
2015-05-05 15:21:55.601 19260 INFO nova.openstack.common.service [-]
Caught SIGTERM, exiting
2015-05-05 15:21:56.568 19542 AUDIT nova.service [-] Starting scheduler
node (version 2014.2.2)
2015-05-05 15:21:57.504 19542 INFO oslo.messaging._drivers.impl_rabbit
[req-ee9a2d39-678d-48c2-b490-2894cb6370b5 ] Connecting to AMQP server on
controller:5672
2015-05-05 15:21:57.514 19542 INFO oslo.messaging._drivers.impl_rabbit
[req-ee9a2d39-678d-48c2-b490-2894cb6370b5 ] Connected to AMQP server on
controller:5672
2015-05-05 15:32:39.316 19542 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on controller:5672
2015-05-05 15:32:39.343 19542 INFO oslo.messaging._drivers.impl_rabbit [-]
Connected to AMQP server on controller:5672
2015-05-05 15:38:21.280 19542 INFO nova.openstack.common.service [-]
Caught SIGTERM, exiting
2015-05-05 15:38:22.434 19954 AUDIT nova.service [-] Starting scheduler
node (version 2014.2.2)
2015-05-05 15:38:23.173 19954 INFO oslo.messaging._drivers.impl_rabbit
[req-b65ec7c6-6bbd-4e13-9694-da927c9cf337 ] Connecting to AMQP server on
controller:5672
2015-05-05 15:38:23.248 19954 INFO oslo.messaging._drivers.impl_rabbit
[req-b65ec7c6-6bbd-4e13-9694-da927c9cf337 ] Connected to AMQP server on
controller:5672
2015-05-05 15:39:46.468 19954 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on controller:5672
2015-05-05 15:39:46.484 19954 INFO oslo.messaging._drivers.impl_rabbit [-]
Connected to AMQP server on controller:5672
The configuration for nova.conf is :
[DEFAULT]
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
force_dhcp_release=True
libvirt_use_virtio_for_bridges=True
verbose=True
ec2_private_dns_show_ip=True
api_paste_config=/etc/nova/api-paste.ini
enabled_apis=ec2,osapi_compute,metadata
scheduler_default_filters=AllHostsFilter
verbose = True
connection = mysql://nova:NOVA_DBPASS@controller/nova
rpc_backend = rabbit
rabbit_host = controller
rabbit_password = RABBIT_PASS
auth_strategy = keystone
my_ip = 10.10.10.10
vncserver_listen = 10.10.10.10
vncserver_proxyclient_address = 10.10.10.10
network_api_class = nova.network.neutronv2.api.API
security_group_api = neutron
linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver = nova.virt.firewall.NoopFirewallDriver
[keystone_authtoken]
auth_uri = http://controller:5000/v2.0
identity_uri = http://controller:35357
admin_tenant_name = service
admin_user = nova
admin_password = NOVA_PASS
[glance]
host = controller
[neutron]
url = http://controller:9696
auth_strategy = keystone
admin_auth_url = http://controller:35357/v2.0
admin_tenant_name = service
admin_username = neutron
admin_password = NEUTRON_PASS
The configuration for neutron is:
[DEFAULT]
verbose = True
lock_path = $state_path/lock
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
auth_strategy = keystone
# Driver to use for scheduling a loadbalancer pool to an lbaas agent
# loadbalancer_pool_scheduler_driver =
neutron.services.loadbalancer.agent_scheduler.ChanceScheduler
Re: [openstack-dev] [Rally] Improve review process
Hi Roman, a truly great job. Very impressive and useful. Thanks a lot! Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 3:11 PM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Rally Team. I have created Rally Gerrit dashboard that organized patches in groups: Critical for next release, Waiting for final approve, Bug fixes, Proposed specs, Important patches, Ready for review, Has -1 but passed tests. Please use link http://goo.gl/iRxA5t for you comfortable. Patch is here https://review.openstack.org/#/c/179610/ It was made by gerrit-dash-creator. First group are the patches that are needed to merge to the nearest release. Content of the next three groups is obvious from the titles. Important patches - its just patches chosen(starred) by Boris Pavlovic or Mikhail Dubov. Ready for review - patches that are waiting for attention. And the last section - its patches with -1 mark but they passed CI. Roman Vasilets, Mirantis Inc. Intern Software Engineer __ 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] [TripleO] Core reviewer update proposal
On 05/05/15 14:57, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! __ 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] [opentack-dev][meetings] Proposing changes in Rally meetings
Hi everyone, this is to inform you that we have registered a second Rally meeting devoted to Rally releases: https://wiki.openstack.org/wiki/Meetings#Rally_meeting This new meeting is going to be held on Wednesdays at 14:00 UTC and will be held for the first time tomorrow. The main Rally meeting time has not changed and is still on Tuesdays at 17:00 UTC. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Mon, Apr 20, 2015 at 12:56 PM, Sergey Skripnick sskripn...@mirantis.com wrote: - We should start making agenda for each meeting and publish it to Rally wiki +1 - We should do 2 meeting per week: We can do both things in one meeting. __ 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] [Fuel] Nominate Julia Aranovich for fuel-web core
Thanks for voting. If nobody has objections by tomorrow, Julia will get +2 rights for fuel-web. 2015-05-05 15:30 GMT+03:00 Dmitry Pyzhov dpyz...@mirantis.com: +1 On Tue, May 5, 2015 at 1:06 PM, Evgeniy L e...@mirantis.com wrote: +1 On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com: +1, indeed Julia's reviews are very thorough. P. On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote: Hi, I'd like to nominate Julia Aranovich http://stackalytics.com/report/users/jkirnosova for fuel-web https://github.com/stackforge/fuel-web core team. Julia's reviews are always thorough and have decent quality. She is one of the top contributors and reviewers in fuel-web repo (mostly for JS/UI stuff). Please vote by replying with +1/-1. -- Vitaly Kramskikh, Fuel UI Tech Lead, 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 __ 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 -- Vitaly Kramskikh, Fuel UI Tech Lead, 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
Re: [openstack-dev] [keystone] On dynamic policy, role hierarchies/groups/sets etc.
On 05/05/2015 07:05 AM, Henry Nash wrote: We’ve been discussing changes to these areas for a while - and although I think there is general agreement among the keystone cores that we need to change *something*, we’ve been struggling to get agreement on exactly how.. So to try and ground the discussion that will (I am sure) occur in Vancouver, here’s an attempt to take a step back, look at what we have now, as well as where, perhaps, we want to get to. This is a great summary. Thanks Henry. The core functionality all this is related to is that of how does keystone policy allow the checking of whether a given API call to an OpenStack service should be allowed to take place or not. Within OpenStack this is a two step process for an API caller….1) Get yourself a token by authentication and getting authorised for a particular scope (e.g. a given project), and then 2) Use that token as part of your API call to the service you are interested in. Assuming you do, indeed, have the rights to execute this API, somehow steps 1) and 2) give the policy engine enough info to say yes or no. So first, how does this work today and (conceptually) how should we describe that? Well first of all, in fact, strictly we don’t control access at the raw API level. In fact, each service defines a series “capabilities” (which usually, but not always, map one-to-one with an API call). These capabilities represent the finest grained access control we support via the policy engine. Now, in theory, the most transparent way we could have implemented steps 1) and 2) above would have been to say that users should be assigned capabilities to projects….and then those capabilities would be placed in the token….allowing the policy engine to check if they match what is needed for a given capability to be executed. We didn’t do that since, a) this would probably end up being very laborious for the administrator (there would be lots of capabilities any given user would need), and b) the tokens would get very big storing all those capabilities. Instead, it was recognised that, usually, there are sets of these capabilities that nearly always go together - so instead let’s allow the creation of such sets….and we’ll assign those to users instead. So far, so good. What is perhaps unusual is how this was implemented. These capability sets are, today, called Roles…but rather than having a role definition that describes the capabilities represented by that role….instead roles are just labels - which can be assigned to users/projects and get placed in a tokens. The expansion to capabilities happens through the definition of a json policy file (one for each service) which must be processed by the policy engine in order to work out what whether the roles in a token and the role-capability mapping means that a given API can go ahead. This implementation leads to a number issues (these have all been raised by others, just pulling them together here): i) The role-capability mapping is rather static. Until recently it had to be stored in service-specific files pushed out to the service nodes out-of-band. Keystone does now provide some REST APIs to store and retrieve whole policy files, but these are a) course-grained and b) not really used by services anyway yet. ii) As more and more clouds become multi-customer (i.e. a cloud provider hosting multiple companies on a single OpenStack installation), cloud providers will want to allow those customers to administer “their bit of the cloud”. Keystone uses the Domains concept to allow a cloud provider to create a namespace for a customer to create their own projects, users and groups….and there is a version of the keystone policy file that allows a cloud provider to effectively delegate management of these items to an administrator of that customer (sometimes called a domain administrator). However, Roles are not part of that namespace - they exists in a global namespace (within a keystone installation). Diverse customers may have different interpretations of what a “VM admin” or a “net admin” should be allowed to do for their bit of the cloud - but right now that differentiation is hard to provide. We have no support for roles or policy that are domain specific. iii) Although as stated in ii) above, you can write a policy file that differentiates between various levels of admin, or fine-tunes access to certain capabilities, the reality is that doing this is pretty un-intuative. The structure of a policy.json file that tries to do this is, indeed, complex (see Keystone’s as an example: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json). Adding more capability to this will likely only make the situation worse. We have a number of specs taking shape to try and address the above (a number of them competing), so I wanted to propose with a set of guidelines for these: a) Making the policy centrally
Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?
Hiya, On 6/05/2015 2:53, James Bottomley wrote: On Tue, 2015-05-05 at 10:45 +0200, Thierry Carrez wrote: Joe Gordon wrote: [...] To tackle this I would like to propose the idea of a periodic developer oriented newsletter, and if we agree to go forward with this, hopefully the foundation can help us find someone to write newsletter. I've been discussing the idea of a LWN for OpenStack for some time, originally with Mark McLoughlin. For those who don't know it, LWN (lwn.net) is a source of quality tech reporting on Linux in general (and the kernel in particular). It's written by developers and tech reporters and funded by subscribers. An LWN-like OpenStack development newsletter would provide general status, dive into specific features, report on specific talks/conferences, summarize threads etc. It would be tremendously useful to the development community. The issue is, who can write such content ? It is a full-time job to produce authored content, you can't just copy (or link to) content produced elsewhere. It takes a very special kind of individual to write such content: the person has to be highly technical, able to tackle any topic, and totally connected with the OpenStack development community. That person has to be cross-project and ideally have already-built legitimacy. Here, you're being overly restrictive. Lwn.net isn't staffed by top level kernel maintainers (although it does solicit the occasional article from them). It's staffed by people who gained credibility via their insightful reporting rather than by their contributions. I see no reason why the same model wouldn't work for OpenStack. There is one technical difference: in the kernel, you can get all the information from the linux-kernel (and other mailing list) firehose if you're skilled enough to extract it. With OpenStack, openstack-dev isn't enough so you have to do other stuff as well, but that's more or less equivalent to additional research. It's basically the kind of profile every OpenStack company is struggling and fighting to hire. And that rare person should not really want to spend that much time developing (or become CTO of a startup) but prefer to write technical articles about what happens in OpenStack development. I'm not sure such a person exists. And a newsletter actually takes more than one such person, because it's a lot of work (even if not weekly). That's a bit pessimistic: followed to it's logical conclusion it would say that lwn.net can't exist either ... which is a bit of a contradiction. So as much as I'd like this to happen, I'm not convinced it's worth getting excited unless we have clear indication that we would have people willing and able to pull it off. The matter of who pays the bill is secondary -- I just don't think the profile exists. For the matter, I tried to push such an idea in the past and couldn't find anyone to fit the rare profile I think is needed to succeed. All the people I could think of had other more interesting things to do. I don't think things changed -- but I'd love to be proven wrong. Um, I assume you've thought of this already, but have you tried asking lwn.net? As you say above, they already fit the profile. Whether they have the bandwidth is another matter, but I believe their Chief Editor (Jon Corbet) may welcome a broadening of the funding base, particularly if the OpenStack foundation were offering seed funding for the endeavour. +2 I think asking LWN if they have the bandwidth and interest to do this would be ideal - they've credibility in the Free/Open Source space and a proven track record. Nice people too. More broadly I think these sorts of links could help OpenStack grow generally - no one would claim the Linux kernel development process to have been perfect, but it is at least of comparable complexity, breadth of development community and mix of personal and commercial interests. Cheers, Hugh __ 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] Which error code should we return when OverQuota
From API-WG guideline, exceed quota should be 403 https://github.com/openstack/api-wg/blob/master/guidelines/http.rst 2015-05-06 3:30 GMT+08:00 Chen CH Ji jiche...@cn.ibm.com: In doing patch [1], A suggestion is submitted that we should return 400 (bad Request) instead of 403 (Forbidden) I take a look at [2], seems 400 is not a good candidate because *'**The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. * *'* may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ 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] [Rally] Improve review process
Nice! On May 5, 2015, at 8:11 PM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Rally Team. I have created Rally Gerrit dashboard that organized patches in groups: Critical for next release, Waiting for final approve, Bug fixes, Proposed specs, Important patches, Ready for review, Has -1 but passed tests. Please use link http://goo.gl/iRxA5t http://goo.gl/iRxA5t for you comfortable. Patch is here https://review.openstack.org/#/c/179610/ https://review.openstack.org/#/c/179610/ It was made by gerrit-dash-creator. First group are the patches that are needed to merge to the nearest release. Content of the next three groups is obvious from the titles. Important patches - its just patches chosen(starred) by Boris Pavlovic or Mikhail Dubov. Ready for review - patches that are waiting for attention. And the last section - its patches with -1 mark but they passed CI. Roman Vasilets, Mirantis Inc. Intern Software Engineer __ 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] [opentack-dev][meetings] Proposing changes in Rally meetings
On Tue, May 05, 2015 at 06:22:47PM +0300, Mikhail Dubov wrote: Hi Rally team, as mentioned in another message from me in this list, we have decided to use the meeting time on Wednesdays at 14:00 UTC for our *usual weekly meeting in #openstack-meeting*. This meeting time and channel will clash with the docs meeting every second week. Check May 13th (UTC) at: https://www.google.com/calendar/embed?src=bj05mroquq28jhud58esggqmh4%40group.calendar.google.comctz=Iceland/Reykjavik It looks like #openstack-meeting-4 is free at that time. As for the release meeting, we wil hold it just before the main meeting, weekly on Wednesdays at 13:30 UTC in *#openstack-rally*. Do you want this listed as a meeting on https://wiki.openstack.org/wiki/Meetings and in thr iCal above? Tony. pgpAebHcGqYdO.pgp Description: PGP signature __ 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] [puppet] Re: Puppet-OpenStack API providers - Follow up
Hi, To summarize from latest 2 discussions about this matter. Workflow to find credentials details: 1. From environment (ENV[token] or ENV[project] in short) 2. From a RC file located by convention in current user homedir: ~/openstackrc 3. From an openstack configuration file such as keystone.conf, glance.conf, etc. Just to avoid confusion, any user/tenant and password or token details could be used but they have to come from above list. The change, impacting openstacklib and the current reviews depending on it, is therefore to remove any other way besides above list of passing the credentials. And more specifically remove passing authenticattion dynamically to the provider because of the many reasons evoked. Also note that 3. would need to be added afterward as this represent a factorization work away from the providers. Regards, Gilles __ 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] [puppet] puppet support for openstack rolling upgrade
Hi, I understand openstack puppet support fresh installation. I'd like to know openstack puppet support rolling upgrade. 1. DB Rolling upgrade 2. openstack configuration upgrade. 3. software package upgrade. 4. service rolling upgrade Thanks -Ruijing __ 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] [TaskFlow]Create Tables for SQLAlchemy backend issue
Hi there,
I'm trying to use mysql to store lobbooks and atom etc.
Here is the code:
backend = backends.fetch({
'connection': 'mysql://test:test@192.168.1.10/test',
'user': test,
'password': test,
})
book, flow_detail = pu.temporary_flow_detail(backend=backend)
And I got below errors:
taskflow.exceptions.StorageFailure: Failed saving logbook
'e34f21c0-72cf-48be-ad96-766befa55ab3'
ProgrammingError: (ProgrammingError) (1146, Table 'flow.logbooks' doesn't
exist) 'SELECT logbooks.created_at, logbooks.updated_at, logbooks.meta,
logbooks.name, logbooks.uuid \nFROM logbooks \nWHERE logbooks.uuid = %s'
('e34f21c0-72cf-48be-ad96-766befa55ab3',)
After checked http://docs.openstack.org/developer/taskflow/persistence.html
, there are 3 tables to be created.
So we need to create these tables manually right? Or is there any API for
the tables initiation?
Thanks.
__
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] How should edge services APIs integrate into Neutron?
Hi Paul, Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion. Please let me know about the IRC channels which we will be following for this discussion. Currently, I am following below BP’s for this work. https://blueprints.launchpad.net/neutron/+spec/edge-vpn https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case. https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining Thanks Vikram From: Paul Michali [mailto:p...@michali.net] Sent: 06 May 2015 01:38 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron? There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this... Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted? I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API. The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today. If there are examples already of how to extend an existing API extension that would help in understanding how to do this. I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension. I'm assuming that the python-neutronclient would also need to be updated. So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time. Thanks in advance, Paul Michali (pc_m) __ 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] [TaskFlow]Create Tables for SQLAlchemy backend issue
Good question!
U have to call into the following:
http://docs.openstack.org/developer/taskflow/persistence.html#taskflow.persistence.base.Connection.upgrade
This is getting renamed (hopefully to a more obvious name) in the
following review: https://review.openstack.org/#/c/180351/ (others got
confused by this one also).
https://blueprints.launchpad.net/taskflow/+spec/storage-initialize-instead-of-upgrade
Hope that helps,
-Josh
jeffty wrote:
Hi there,
I’m trying to use mysql to store lobbooks and atom etc.
Here is the code:
backend = backends.fetch({
'connection': 'mysql://test:test@192.168.1.10/test',
'user': test,
'password': test,
})
book, flow_detail = pu.temporary_flow_detail(backend=backend)
And I got below errors:
taskflow.exceptions.StorageFailure: Failed saving logbook
'e34f21c0-72cf-48be-ad96-766befa55ab3'
ProgrammingError: (ProgrammingError) (1146, Table 'flow.logbooks'
doesn't exist) 'SELECT logbooks.created_at, logbooks.updated_at,
logbooks.meta, logbooks.name, logbooks.uuid \nFROM logbooks \nWHERE
logbooks.uuid = %s' ('e34f21c0-72cf-48be-ad96-766befa55ab3',)
After checked
http://docs.openstack.org/developer/taskflow/persistence.html , there
are 3 tables to be created.
So we need to create these tables manually right? Or is there any API
for the tables initiation?
Thanks.
__
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] [Fuel] Swagger documentation
Hello, I prepared a small PoC of Swagger [1] as a proposal to [2]. If you want to test it out, checkout that commit into your repo, start Nailgun locally and point your browser to [3]. Basically you just need to put Swagger-UI [4] somewhere and point your browser to /dist/index.html there, filling in the URL. OPTIONS handler with appropriate CORS settings is required on API side if Swagger UI's host is somewhere else than the API. I've turned this on when the settings.DEVELOPMENT variable in API is set to True. As a demo I modified documentation of LogEntryCollectionHandler. Basically we should fix our docstrings to comply with [5] and extend cleanup my docutils parsing logic in swagger.py. The plus side is that our Sphinx documentation will get better too. Please test it and give feedback. P. [1] https://review.openstack.org/#/c/179051/ [2] https://bugs.launchpad.net/fuel/+bug/1449030 [3] http://172.18.163.4/swagger-ui/dist/index.html?url=http://localhost:8000/api/v1/docs#!/default/get_logs [4] https://github.com/swagger-api/swagger-ui [5] http://pythonhosted.org/sphinxcontrib-httpdomain/ __ 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] subscribe
subscribe __ 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] Adding Joshua Harlow to oslo-core
Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature __ 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] [oslo] Adding Joshua Harlow to oslo-core
+1 from me!! -- dims On Tue, May 5, 2015 at 10:47 AM, Julien Danjou jul...@danjou.info wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [oslo] Adding Joshua Harlow to oslo-core
++! On Tue, May 5, 2015 at 8:02 AM Davanum Srinivas dava...@gmail.com wrote: +1 from me!! -- dims On Tue, May 5, 2015 at 10:47 AM, Julien Danjou jul...@danjou.info wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [tc] Who is allowed to vote for TC candidates
On 05/05/15 18:10, Adam Lawson wrote: I think the ATC thing came up as one avenue to explore when folks were trying to figure out ways to quantify Operator involvement for the purpose of identifying who are actively contributing to OpenStack versus those who are fans/users of OpenStack but don't have time right now to contribute more formally. ATC, BTC, CTC, DTC... there are several great ideas that were brought up as possibilities as well as some take-aways for further discussion at the Vancouver Summit and the talking points for the User Committee. I'm really crossing my fingers this translates into something noticeably unique starting with the next election. In my perfect world anyway. ; ) I am all for OTC (OpenStack / Operational Technical Contributor) :) -- Best Regards, Maish Saidel-Keesing __ 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] Who is allowed to vote for TC candidates
Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. On May 5, 2015 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Doug __ 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] [TripleO] Core reviewer update proposal
On 05/05/2015 07:57 AM, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 They've both been huge in the development of the THT templates and the puppet integration over the past few months. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! __ 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] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-05 07:01:48 -0700: Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. Early on in the thread I thought you wanted community members without ATC status to be able to vote for and run for the TC. Maybe I misunderstood what you were saying? Doug __ 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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On Tue, May 5, 2015 at 1:32 AM Matthias Runge mru...@redhat.com wrote: On 05/05/15 04:31, Ian Cordasco wrote: Even so, Horizon is deployed in many places, and given the reliability of system packages, it’s increasingly deployed from source. Ok, I'll bite. You surely have a source for your statement, or even better, a proof? In the interest of open data, I'll answer this, using basic data extracted from the Paris User Survey. For the sake of simplicity, I'm only going to focus on production deployments of openstack, and I'm going to make the assumption that if a tool is referenced, the official openstack version of it was used. Here's the link, if you'd like to follow along: http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 As of Paris, the following tools were used to deploy openstack-dashboard in production. I've called out which of these are actually a source install, and which of them are not. I've also skipped the two 1%'ers, because I don't know those tools well enough to figure out if they're source. ToolPercentageIs Source?Is Package?Puppet45%NoYesChef20%NoYesAnsible21%NoYes DevStack7%Yes NoPackStack8%NoYesSalt8%NoYesJuju7%NoYes As you can see, the majority of the tools that we publish install via packages. Note that this data _cannot_ be used to infer an argument as to whether source or packages are used more often, for the following reasons: 1. The actual percentages from the survey add up to 118%. 2. Install from Source did not appear to be an option. 3. We are unable to determine the size of the cloud, thus providing a 'weight' to each install method. 4. We do not know whether every one of these respondents actually install horizon. In short: We don't have data to support either side of this argument, though there is a strong case that packages are the de-facto install method. If I can editorialize for a second and read subtext into what Ian's saying: The real question seems to be whether packagers have a disproportionate amount of power to set development goals, tools, and policy. This is a common theme that I've encountered frequently, and it leads to no small amount of tension. This tension serves no-one, and really just causes all of us stress. How about we start a separate thread to discuss the roles of package maintainers in OpenStack? Michael __ 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] [heat]: stack stays interminably under the status create in progress
Hi Sara, first, what version of OpenStack are you using? Second, could you provide us with actual template that exhibits such behavior and the way it was launched (Dashboard or CLI, with which parameters and other arguments)? Would be much easier for us to reason about possible failure scenarios. Best regards, Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com On Tue, May 5, 2015 at 4:02 PM, ICHIBA Sara ichi.s...@gmail.com wrote: Hello there, I started a project where I need to deploy stacks and orchastrate them using heat (autoscaling and so on..). I just started playing with heat and the creation of my first stack is never complete. It stays in the status create in progress. My log files don't say much. For my template i'm using a veery simple one to launch a small instance. Any ideas what that might be? In advance, thank you for your response. sara, __ 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] [opentack-dev][meetings] Proposing changes in Rally meetings
Mike, Thank you for picking up dates. I am OK with them. Best regards, Boris Pavlovic On Tue, May 5, 2015 at 6:22 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi Rally team, as mentioned in another message from me in this list, we have decided to use the meeting time on Wednesdays at 14:00 UTC for our *usual weekly meeting in #openstack-meeting*. As for the release meeting, we wil hold it just before the main meeting, weekly on Wednesdays at 13:30 UTC in *#openstack-rally*. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 4:13 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, this is to inform you that we have registered a second Rally meeting devoted to Rally releases: https://wiki.openstack.org/wiki/Meetings#Rally_meeting This new meeting is going to be held on Wednesdays at 14:00 UTC and will be held for the first time tomorrow. The main Rally meeting time has not changed and is still on Tuesdays at 17:00 UTC. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Mon, Apr 20, 2015 at 12:56 PM, Sergey Skripnick sskripn...@mirantis.com wrote: - We should start making agenda for each meeting and publish it to Rally wiki +1 - We should do 2 meeting per week: We can do both things in one meeting. __ 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] [TripleO] Core reviewer update proposal
On 5.5.2015 13:57, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 __ 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] Who is allowed to vote for TC candidates
On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. It comes down to this. OpenStack developers have a way of doing things. Operators also have a way of doing things - which is quite different to the way OpenStack does things. If each of these groups continue down the paths they are currently going - never shall the twain meet. They need to come towards each other. The OpenStack community needs be more receptive to the way Operators need things done. Operators need to be more receptive to the way things are done in OpenStack. Yes we have made progress. Yes we will continue to make progress. But until the Operators/users (and you can interchange users with Operators throughout my whole email - I was lazy) are accepted to be part of the decision process in OpenStack (and I think that you can agree - that if that actually happens today - it is way after the fact - or extremely late in the process) then this disconnect is going to continue. There is a feeling (at least that is my perception) that code is developed in a vacuum today. Without actually going into the field and asking what is needed - what is being used - what could be made better - before deciding what to write and fix. If you build it they will come[2] was a great idea in Hollywood, but I am not sure it will work as well for us - for OpenStack. Any ideas on how this could be solved - would be highly appreciated. [1] https://etherpad.openstack.org/p/PHL-ops-meetup [2] http://en.wikipedia.org/wiki/Field_of_Dreams -- Best Regards, Maish Saidel-Keesing __ 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] [rally] Weekly meeting
+Rally team Just to make sure that everybody saw this. Best regards, Boris Pavlovic On Tue, May 5, 2015 at 6:19 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, sorry for the previous disinformative message. We have decided to move our weekly meeting to Wednesdays at 14:00 UTC (IRC, *#openstack-meeting*). As said before, all the relevant information including the meeting agenda can be found on the wiki page https://wiki.openstack.org/wiki/Meetings/Rally . Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 6:10 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Starting from today, we will be posting our meeting agenda at the corresponding wiki page https://wiki.openstack.org/wiki/Meetings/Rally . Fell free to comment on the agenda / to propose new topics. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, Apr 28, 2015 at 1:05 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Here is the agenda for today: 1. Rally QA week: tasks, assignees, progress 2. Upcoming Rally 0.0.4 release: progress on critical patches 3. Spec on refactoring scenario utils: review and discussion ( https://review.openstack.org/#/c/172831/) 4. Spec on in-tree functional tests: review and discussion ( https://review.openstack.org/#/c/166487/) 5. Free discussion The meeting is going to be chaired by Alexander Maretskiy. Fell free to comment on the agenda / to propose new topics. 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 __ 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] Who is allowed to vote for TC candidates
I think the ATC thing came up as one avenue to explore when folks were trying to figure out ways to quantify Operator involvement for the purpose of identifying who are actively contributing to OpenStack versus those who are fans/users of OpenStack but don't have time right now to contribute more formally. ATC, BTC, CTC, DTC... there are several great ideas that were brought up as possibilities as well as some take-aways for further discussion at the Vancouver Summit and the talking points for the User Committee. I'm really crossing my fingers this translates into something noticeably unique starting with the next election. In my perfect world anyway. ; ) *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Tue, May 5, 2015 at 7:59 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Adam Lawson's message of 2015-05-05 07:01:48 -0700: Doug, it isn't about me or about trying to add more to the pool of one type of contributor from a different pool of individuals with a different skillset or about attempting to make shortcuts to leadership as you so delicately put it. Frankly I think you're missing the point. When there is a technical body governing everything of a technical nature within OpenStack and it consists of members from one slice of the overall community and candidates speak of engaging the operator community more than it has in the past as part of the reason folks should vote for them, I think the candidates are on point and we have an opportunity in front of us. Has nothing to do with broadening the pool of one specific type of contributor but about taking advantage of those who are already contributing in a different way. That's a strength in our community and when the tc appears to be moving towards technical leadership that paints with broader multi-discipline strokes, I'm completely on board with that. Early on in the thread I thought you wanted community members without ATC status to be able to vote for and run for the TC. Maybe I misunderstood what you were saying? Doug __ 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] [TripleO] Core reviewer update proposal
On 05/05/15 12:57, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 to both Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! __ 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] [TripleO] Core reviewer update proposal
On Tuesday 05 of May 2015 07:57:46 James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | | | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) || | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! Petr Blaho __ 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] [oslo] Adding Joshua Harlow to oslo-core
+1! finally!=) Best regards, Boris Pavlovic On Tue, May 5, 2015 at 5:57 PM, Davanum Srinivas dava...@gmail.com wrote: +1 from me!! -- dims On Tue, May 5, 2015 at 10:47 AM, Julien Danjou jul...@danjou.info wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [rally] Weekly meeting
Hi everyone, sorry for the previous disinformative message. We have decided to move our weekly meeting to Wednesdays at 14:00 UTC (IRC, *#openstack-meeting*). As said before, all the relevant information including the meeting agenda can be found on the wiki page https://wiki.openstack.org/wiki/Meetings/Rally. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 6:10 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Starting from today, we will be posting our meeting agenda at the corresponding wiki page https://wiki.openstack.org/wiki/Meetings/Rally. Fell free to comment on the agenda / to propose new topics. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, Apr 28, 2015 at 1:05 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Here is the agenda for today: 1. Rally QA week: tasks, assignees, progress 2. Upcoming Rally 0.0.4 release: progress on critical patches 3. Spec on refactoring scenario utils: review and discussion ( https://review.openstack.org/#/c/172831/) 4. Spec on in-tree functional tests: review and discussion ( https://review.openstack.org/#/c/166487/) 5. Free discussion The meeting is going to be chaired by Alexander Maretskiy. Fell free to comment on the agenda / to propose new topics. 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
[openstack-dev] [Security] CORS Documentation
Hey everyone! I'm currently managing an OpenStack specification to introduce CORS support to Liberty. The specification is here for your review: https://review.openstack.org/#/c/179866/1 Seeing as activating CORS has security implications, I strongly feel that the documentation should reflect this, and at Anne Gentle's suggestion I'd like some suggestions on where this might live. It will definitely live in the Cloud Admin guide - are there any other places where I should make a point to highlight these issues? Michael __ 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] [rally] Weekly meeting
Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Starting from today, we will be posting our meeting agenda at the corresponding wiki page https://wiki.openstack.org/wiki/Meetings/Rally. Fell free to comment on the agenda / to propose new topics. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, Apr 28, 2015 at 1:05 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Here is the agenda for today: 1. Rally QA week: tasks, assignees, progress 2. Upcoming Rally 0.0.4 release: progress on critical patches 3. Spec on refactoring scenario utils: review and discussion ( https://review.openstack.org/#/c/172831/) 4. Spec on in-tree functional tests: review and discussion ( https://review.openstack.org/#/c/166487/) 5. Free discussion The meeting is going to be chaired by Alexander Maretskiy. Fell free to comment on the agenda / to propose new topics. 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] [Rally] Improve review process
Roman, Well done! This really simplifies life! Best regards, Boris Pavlovic On Tue, May 5, 2015 at 4:07 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi Roman, a truly great job. Very impressive and useful. Thanks a lot! Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 3:11 PM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Rally Team. I have created Rally Gerrit dashboard that organized patches in groups: Critical for next release, Waiting for final approve, Bug fixes, Proposed specs, Important patches, Ready for review, Has -1 but passed tests. Please use link http://goo.gl/iRxA5t for you comfortable. Patch is here https://review.openstack.org/#/c/179610/ It was made by gerrit-dash-creator. First group are the patches that are needed to merge to the nearest release. Content of the next three groups is obvious from the titles. Important patches - its just patches chosen(starred) by Boris Pavlovic or Mikhail Dubov. Ready for review - patches that are waiting for attention. And the last section - its patches with -1 mark but they passed CI. Roman Vasilets, Mirantis Inc. Intern Software Engineer __ 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] [opentack-dev][meetings] Proposing changes in Rally meetings
Hi Rally team, as mentioned in another message from me in this list, we have decided to use the meeting time on Wednesdays at 14:00 UTC for our *usual weekly meeting in #openstack-meeting*. As for the release meeting, we wil hold it just before the main meeting, weekly on Wednesdays at 13:30 UTC in *#openstack-rally*. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 4:13 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, this is to inform you that we have registered a second Rally meeting devoted to Rally releases: https://wiki.openstack.org/wiki/Meetings#Rally_meeting This new meeting is going to be held on Wednesdays at 14:00 UTC and will be held for the first time tomorrow. The main Rally meeting time has not changed and is still on Tuesdays at 17:00 UTC. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Mon, Apr 20, 2015 at 12:56 PM, Sergey Skripnick sskripn...@mirantis.com wrote: - We should start making agenda for each meeting and publish it to Rally wiki +1 - We should do 2 meeting per week: We can do both things in one meeting. __ 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] Weekly subteam status report
Hi, 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, 2 May, 17:01 UTC) Open: 148 (+3) 7 new (+3), 42 in progress (+1), 0 critical, 7 high (-2) and 10 (-1) incomplete Drivers == iLO (wanyen) -- 3rd-party CI testing: https://etherpad.openstack.org/p/IloDriverGateTesting The subteams are taking a breather, so we'll resume the posting of weekly status reports sometime after the May summit. Until then, Happy OpenStackin'. --ruby [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] [neutron][api] Extensions out, Micro-versions in
so... as an operator looking at #3, If I need to support lbaas, I'm getting pushed to run more and more services, like octavia, plus a neutron-lbaas service, plus neutron? This seems like an operator scalability issue... What benifit does splitting out the advanced services into their own services have? Thanks, Kevin From: Salvatore Orlando [sorla...@nicira.com] Sent: Tuesday, May 05, 2015 3:13 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in There have now been a few iterations on the specification for Neutron micro-versioning [1]. It seems that no-one in the community opposes introducing versioning. In particular API micro-versioning as implemented by Nova and Ironic seems a decent way to evolve the API incrementally. What the developer community seems not yet convinced about is moving away from extensions. It seems everybody realises the flaws of evolving the API through extensions, but there are understandable concerns regarding impact on plugins/drivers as well as the ability to differentiate, which is something quite dear to several neutron teams. I tried to consider all those concerns and feedback received; hopefully everything has been captured in a satisfactory way in the latest revision of [1]. With this ML post I also seek feedback from the API-wg concerning the current proposal, whose salient points can be summarised as follows: #1 extensions are not part anymore of the neutron API. Evolution of the API will now be handled through versioning. Once microversions are introduced: - current extensions will be progressively moved into the Neutron unified API - no more extension will be accepted as part of the Neutron API #2 Introduction of features for addressing diversity in Neutron plugins It is possible that the combination of neutron plugins chosen by the operator won't be able to support the whole Neutron API. For this reason a concept of feature is included. What features are provided depends on the plugins loaded. The list of features is hardcoded as strictly dependent on the Neutron API version implemented by the server. The specification also mandates a minimum set of features every neutron deployment must provide (those would be the minimum set of features needed for integrating Neutron with Nova). #3 Advanced services are still extensions This a temporary measure, as APIs for load balancing, VPN, and Edge Firewall are still served through neutron WSGI. As in the future this API will live independently it does not make sense to version them with Neutron APIs. #4 Experimenting in the API One thing that has plagued Neutron in the past is the impossibility of getting people to reach any sort of agreement over the shape of certain APIs. With the proposed plan we encourage developers to submit experimental APIs. Experimental APIs are unversioned and no guarantee is made regarding deprecation or backward compatibility. Also they're optional, as a deployer can turn them off. While there are caveats, like forever-experimental APIs, this will enable developer to address user feedback during the APIs' experimental phase. The Neutron community and the API-wg can provide plenty of useful feeback, but ultimately is user feedback which determines whether an API proved successful or not. Please note that the current proposal goes in a direction different from that approved in Nova when it comes to experimental APIs [3] #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support - they do not redefine resources defined by the Neutron API. - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpgw=738site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By vendor here we refer either to a cloud provider or a company providing Neutron integration for their products. __ OpenStack Development Mailing List
Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
Patch #153236 is introducing pluggable IPAM in the db base plugin class, and default to it at the same time, I believe. If the consensus is to default to IPAM driver then in order to satisfy grenade requirements those migrations scripts should be run. There should actually be a single script to be run in a one-off fashion. Even better is treated as a DB migration. However, the plan for Kilo was to not turn on pluggable IPAM for default. Now that we are targeting Liberty, we should have this discussion again, and not take for granted that we should default to pluggable IPAM just because a few months ago we assumed it would be default by Liberty. I suggest to not enable it by default, and then consider in L-3 whether we should do this switch. For the time being, would it be possible to amend patch #153236 to not run pluggable IPAM by default. I appreciate this would have some impact on unit tests as well, which should be run both for pluggable and traditional IPAM. Salvatore On 4 May 2015 at 20:11, Pavel Bondar pbon...@infoblox.com wrote: Hi, During fixing failures in db_base_plugin_v2.py with new IPAM[1] I faced to check-grenade-dsvm-neutron failures[2]. check-grenade-dsvm-neutron installs stable/kilo, creates networks/subnets and upgrades to patched master. So it validates that migrations passes fine and installation is works fine after it. This is where failure occurs. Earlier there was an agreement about using pluggable IPAM only for greenhouse installation, so migrate script from built-in IPAM to pluggable IPAM was postponed. And check-grenade-dsvm-neutron validates greyhouse scenario. So do we want to update this agreement and implement migration scripts from built-in IPAM to pluggable IPAM now? Details about failures. Subnets created before patch was applied does not have correspondent IPAM subnet, so observed a lot of failures like this in [2]: Subnet 2c702e2a-f8c2-4ea9-a25d-924e32ef5503 could not be found Currently config option in patch is modified to use pluggable_ipam by default (to catch all possible UT/tempest failures). But before the merge patch will be switched back to non-ipam implementation by default. I would prefer to implement migrate script as a separate review, since [1] is already quite big and hard for review. [1] https://review.openstack.org/#/c/153236 [2] http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz - Pavel Bondar __ 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] [TripleO] Core reviewer update proposal
On Tue, May 05, 2015 at 07:57:46AM -0400, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Thanks for the nomination! :) Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. Absolutely, provided there are no objections I'll be very happy to serve, and I expect to at least maintain my current level of activity for the forseeable future. 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
[openstack-dev] [Nova][Ironic] Large number of ironic driver bugs in nova
Hi, I noticed last night that there are 23 bugs currently filed in nova tagged as ironic related. Whilst some of those are scheduler issues, a lot of them seem like things in the ironic driver itself. Does the ironic team have someone assigned to work on these bugs and generally keep an eye on their driver in nova? How do we get these bugs resolved? Thanks, Michael -- Rackspace Australia __ 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][api] Extensions out, Micro-versions in
There have now been a few iterations on the specification for Neutron micro-versioning [1]. It seems that no-one in the community opposes introducing versioning. In particular API micro-versioning as implemented by Nova and Ironic seems a decent way to evolve the API incrementally. What the developer community seems not yet convinced about is moving away from extensions. It seems everybody realises the flaws of evolving the API through extensions, but there are understandable concerns regarding impact on plugins/drivers as well as the ability to differentiate, which is something quite dear to several neutron teams. I tried to consider all those concerns and feedback received; hopefully everything has been captured in a satisfactory way in the latest revision of [1]. With this ML post I also seek feedback from the API-wg concerning the current proposal, whose salient points can be summarised as follows: #1 extensions are not part anymore of the neutron API. Evolution of the API will now be handled through versioning. Once microversions are introduced: - current extensions will be progressively moved into the Neutron unified API - no more extension will be accepted as part of the Neutron API #2 Introduction of features for addressing diversity in Neutron plugins It is possible that the combination of neutron plugins chosen by the operator won't be able to support the whole Neutron API. For this reason a concept of feature is included. What features are provided depends on the plugins loaded. The list of features is hardcoded as strictly dependent on the Neutron API version implemented by the server. The specification also mandates a minimum set of features every neutron deployment must provide (those would be the minimum set of features needed for integrating Neutron with Nova). #3 Advanced services are still extensions This a temporary measure, as APIs for load balancing, VPN, and Edge Firewall are still served through neutron WSGI. As in the future this API will live independently it does not make sense to version them with Neutron APIs. #4 Experimenting in the API One thing that has plagued Neutron in the past is the impossibility of getting people to reach any sort of agreement over the shape of certain APIs. With the proposed plan we encourage developers to submit experimental APIs. Experimental APIs are unversioned and no guarantee is made regarding deprecation or backward compatibility. Also they're optional, as a deployer can turn them off. While there are caveats, like forever-experimental APIs, this will enable developer to address user feedback during the APIs' experimental phase. The Neutron community and the API-wg can provide plenty of useful feeback, but ultimately is user feedback which determines whether an API proved successful or not. Please note that the current proposal goes in a direction different from that approved in Nova when it comes to experimental APIs [3] #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support - they do not redefine resources defined by the Neutron API. - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpgw=738site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By vendor here we refer either to a cloud provider or a company providing Neutron integration for their products. __ 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] [puppet][operators] How to specify Keystone v3 credentials?
On 05/04/2015 10:37 PM, Rich Megginson wrote: I'm starting to think about some sort of credentials vault. You store credentials in it and you tell your resource to use that specific credentials. You then no longer need to pass around 6-7 variables/parameters. I'm sure Adam Young has some ideas about this . . poof, and the devil appears. OK, the Keystone setup info is three distinct things: 1. You you are (username and password) 2. Where you start the process (auth_url) 3. Scope. (project) Both 1 and 3 are further namespace scoped by domain; Passwords are Bad. BADBADBAD. In Liberty, we have a work in progress to do tokenless operations using X509 based certificates. https://review.openstack.org/#/c/156870/ Ideally we would do something like this. For those of you that hate X509 (I know you are out there seething) we don't have a naked SSH Key based way to authenticate to Keystone. Sorry. We also Have Kerberos. I don't think I would want to put all of these in a vault. I could, however, see standardizing a config file setup for the clients where OS_AUTH_URL is defined at /etc/openrc.conf and the other values at ~/.openrc. One nice thing to add there would be the auth plugin used, and that would allow for Kerberos, X509, Password, or whatever. the cli could then take --conf= as an override. We might need to work on the file names. __ 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] [api] API reference - follow-up questions
Hi all, For Liberty I am working on a specification to update the way we deliver application developer information. [1] I'm incorporating Tom's suggestion to automate API reference information. [2] In revising the API reference specification I wanted to ask a few more questions to shape the spec further. * Should we do a proof of concept for say, Compute, then have the other projects follow? Identity v3 has the most calls in the core with 74, but Compute v2 plus extensions has over 120 calls. Alternatively, we could also limit the scope to greater than 50% reported on User Survey [2]. * Is there any way to know what versions of an API a user answering the survey is running or do we have to scope to both versions for some of these services? Identity Compute Block Storage Image Networking * Do we continue to enable the project teams to indicate where they want to maintain REST API information? Or does this spec require particulars down to the folder name in the repo due to automation efforts? Feel free to reply here or in the spec itself. Thanks, Anne 1. https://review.openstack.org/#/c/177934/1 2. http://lists.openstack.org/pipermail/openstack-docs/2015-April/006502.html 3. http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 -- 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] [TripleO] Core reviewer update proposal
Excerpts from James Slagle's message of 2015-05-05 11:57:46 +: TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. +1 __ 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] [oslo] Adding Joshua Harlow to oslo-core
Excerpts from Julien Danjou's message of 2015-05-05 16:47:23 +0200: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! +1 - overdue __ 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 communication: periodic developer newsletter?
On Tue, 2015-05-05 at 10:45 +0200, Thierry Carrez wrote: Joe Gordon wrote: [...] To tackle this I would like to propose the idea of a periodic developer oriented newsletter, and if we agree to go forward with this, hopefully the foundation can help us find someone to write newsletter. I've been discussing the idea of a LWN for OpenStack for some time, originally with Mark McLoughlin. For those who don't know it, LWN (lwn.net) is a source of quality tech reporting on Linux in general (and the kernel in particular). It's written by developers and tech reporters and funded by subscribers. An LWN-like OpenStack development newsletter would provide general status, dive into specific features, report on specific talks/conferences, summarize threads etc. It would be tremendously useful to the development community. The issue is, who can write such content ? It is a full-time job to produce authored content, you can't just copy (or link to) content produced elsewhere. It takes a very special kind of individual to write such content: the person has to be highly technical, able to tackle any topic, and totally connected with the OpenStack development community. That person has to be cross-project and ideally have already-built legitimacy. Here, you're being overly restrictive. Lwn.net isn't staffed by top level kernel maintainers (although it does solicit the occasional article from them). It's staffed by people who gained credibility via their insightful reporting rather than by their contributions. I see no reason why the same model wouldn't work for OpenStack. There is one technical difference: in the kernel, you can get all the information from the linux-kernel (and other mailing list) firehose if you're skilled enough to extract it. With OpenStack, openstack-dev isn't enough so you have to do other stuff as well, but that's more or less equivalent to additional research. It's basically the kind of profile every OpenStack company is struggling and fighting to hire. And that rare person should not really want to spend that much time developing (or become CTO of a startup) but prefer to write technical articles about what happens in OpenStack development. I'm not sure such a person exists. And a newsletter actually takes more than one such person, because it's a lot of work (even if not weekly). That's a bit pessimistic: followed to it's logical conclusion it would say that lwn.net can't exist either ... which is a bit of a contradiction. So as much as I'd like this to happen, I'm not convinced it's worth getting excited unless we have clear indication that we would have people willing and able to pull it off. The matter of who pays the bill is secondary -- I just don't think the profile exists. For the matter, I tried to push such an idea in the past and couldn't find anyone to fit the rare profile I think is needed to succeed. All the people I could think of had other more interesting things to do. I don't think things changed -- but I'd love to be proven wrong. Um, I assume you've thought of this already, but have you tried asking lwn.net? As you say above, they already fit the profile. Whether they have the bandwidth is another matter, but I believe their Chief Editor (Jon Corbet) may welcome a broadening of the funding base, particularly if the OpenStack foundation were offering seed funding for the endeavour. James __ 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] [oslo] Adding Joshua Harlow to oslo-core
Joshua is a really cool guy, or so I hear... for real. +1 Julien Danjou mailto:jul...@danjou.info May 5, 2015 at 7:47 AM Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! __ 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] [oslo] Adding Joshua Harlow to oslo-core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 +1 from me as well! On 05/05/2015 09:47 AM, Julien Danjou wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! __ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVSP2fAAoJEDehGd0Fy7uqEggH/3VMflb10XVGXFQb/061yrmo B1boYZdeqVeBOlURSgsSouKJwY8OahMygu18GhedLXHaefYUlMgZRW/nSeGoS8/7 fPWc1E4ebn/xupXPtSDo41CT8VswpeDZKod1DV74mTapMVQPzlslwnEmOwaik44h uuAwNEaMOPrelpHhv2qbINanOZco431BPmWqbPEEoRrOEkBJi0j7ikY36gHGL1Ny UTvtUW0rXDGOEswVi6/F9S6hZLYtvsyTFs+4ZspwQeHgQ+oTNdtFuw9w25oYhxLl lTJAKO29b7tcbZ3NHTJRBY1tldx3GVP9DkPAPWmXbZElwLvdfWMTKeLSrPbIdds= =aXKU -END PGP SIGNATURE- __ 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] Who is allowed to vote for TC candidates
Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. -- 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] [tc] Who is allowed to vote for TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. Is the feedback being taken into account during planning for liberty? Has someone correlated the feedback with the proposed specs and summit sessions? This is normally something I would expect the PTLs to be involved with for individual projects, although it might help to have a single document listing desired actionable changes from those separate etherpads, and someone involved in the meeting is probably better able to do that -- it can be difficult to look at meeting logs after the fact and extract a summary if you weren't in the room when the meeting occurred. Are there summaries of the consensus from the meetings? Looking through a few of the etherpads: https://etherpad.openstack.org/p/PHL-ops-burning-issues The first few items in the burning issues session look immediately actionable, some of them (such as nova-net/neutron migration and ceilometer performance improvements) are already under way as long-term changes, but some of them
Re: [openstack-dev] [QA][Glance][Heat][Cinder] Removing the CLI tests from Tempest
Hi guys. Probably we have missed this activity, so I start working on it. These are first commits: https://review.openstack.org/#/c/180215/ Regards, Sergey. On 30 April 2015 at 19:55, Matthew Treinish mtrein...@kortar.org wrote: On Thu, Apr 30, 2015 at 05:44:40PM +0100, Louis Taylor wrote: On Thu, Apr 30, 2015 at 12:28:15PM -0400, Matthew Treinish wrote: We're now at the end of the cycle and there are 3 clients that still have CLI tests in tempest. I have pushed the patch up to remove all these tests here: https://review.openstack.org/#/c/178757/ Hi Matt, This is being worked on in glance (infra patch adding test job: https://review.openstack.org/#/c/178285/). It will likely be finished before you remove the tests from tempest, so your current plan for removal sounds okay for us. Oh, cool I didn't realize that was in progress for glance already. Thanks for driving it forward. I guess it's probably worth pointing out that John Griffith has similar patches in progress starting the process on cinderclient too: https://review.openstack.org/175521 and https://review.openstack.org/175512 Thanks, Matt Treinish __ 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] [TripleO] Core reviewer update proposal
Excerpts from James Slagle's message of 2015-05-05 04:57:46 -0700: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! +1 to all the things __ 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] Who is allowed to vote for TC candidates
Thiery - Most operators are busy fighting operational battles, scale out etc. It is often an all-hands-on-the-deck job. I don’t think we should just measure by contributors getting work done. The work is often silent, and lags behind the dev cycle. Subbu On May 4, 2015, at 9:25 AM, Thierry Carrez thie...@openstack.org wrote: But in the end, it all boils down to contributors that get the work done and therefore make it going in one direction or another. __ 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] [TripleO] Core reviewer update proposal
Definite +1 to both On 05/05/2015 06:57 AM, James Slagle wrote: Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! __ 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] [oslo] Adding Joshua Harlow to oslo-core
Hi, Great idea! Joshua did a lot for Oslo, I want him in the oslo-core team! Victor Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! __ 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][octavia] what are the main differences between the two
You’re definitely stuck on lbaas v1 until you upgrade to Kilo, but… But, it would be possible to write an lbaasv1 driver for octavia, though octavia likely won’t be mature enough to be useful for that until the end of Liberty or so. Also, though “vendor” is a bad word in openstack (and that’s ok), there are a few vendor offerings, some of which will make v1 more usable and/or extend it with other features. Can you describe what you’re trying to do, and we can make some suggestions? Worst case, we’re always looking to hear more use cases as we build things. Thanks, doug On May 4, 2015, at 10:14 PM, Daniel Comnea comnea.d...@gmail.com wrote: Thanks a bunch Doug, very clear helpful info. so with that said those who run IceHouse or Juno are (more or less :) ) dead in the water as the only option is v1 ...hmm Dani On Mon, May 4, 2015 at 10:21 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: lbaas v1: This is the original Neutron LBaaS, and what you see in Horizon or in the neutron CLI as “lb-*”. It has an haproxy backend, and a few vendors supporting it. Feature-wise, it’s basically a byte pump. lbaas v2: This is the “new” Neutron LBaaS, and is in the neutron CLI as “lbaas-*” (it’s not yet in Horizon.) It first shipped in Kilo. It re-organizes the objects, and adds TLS termination support, and has L7 plus other new goodies planned in Liberty. It similarly has an haproxy reference backend with a few vendors supporting it. octavia: Think of this as a service vm framework that is specific to lbaas, to implement lbaas via nova VMs instead of “lbaas agents. It is expected to be the reference backend implementation for neutron lbaasv2 in liberty. It could also be used as its own front-end, and/or given drivers to be a load balancing framework completely outside neutron/nova, though that is not the present direction of development. Thanks, doug On May 4, 2015, at 1:57 PM, Daniel Comnea comnea.d...@gmail.com mailto:comnea.d...@gmail.com wrote: Hi all, I'm trying to gather more info about the differences between Neutron LBaaS v1 Neutron LBaaS v2 Octavia I know Octavia is still not marked production but on the other hand i keep hearing inside my organization that Neutron LBaaS is missing few critical pieces so i'd very much appreciate if anyone can provide detailed info about the differences above. Thanks, Dani __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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] [tc] Who is allowed to vote for TC candidates
Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ 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] Who is allowed to vote for TC candidates
On 05/05/15 19:14, Sylvain Bauza wrote: Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. Completely Agree!! At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? It should go both ways. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ 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, Maish Saidel-Keesing __ 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] Who is allowed to vote for TC candidates
I think that this will be my last say on this matter, because it seems to be getting out of hand. Us vs. them. Dev vs. Ops. It could be perceived that I am trying to wage a 'war' on the OpenStack development process, on the Developers, but that is not the case. But I do think there are valid points from both sides that need to be addressed. There are two sides of this story and in the end I do think that OpenStack as a community does need to accommodate and cater to the needs of of the colors of the rainbow. I hope that this discussion does open some doors, opens some minds and creates acceptance for those who are not like us. Believe me I have been dealing with this all my life. I would like to thank you all for your contribution and thoughts in this thread, I hope it was useful for you all as it was for me. -- Best Regards, Maish Saidel-Keesing On 05/04/15 20:11, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. You're describing these relationships in a much more hierarchical manner than I think reflects their reality. Decisions about the future of OpenStack are made by the people who show up and contribute. We try to identify common goals and priorities, and where there's little overlap we support each other in ways that we perceive improve the project. That process uses input from many sources, including product managers from contributing companies and operator/user feedback. As Thierry pointed out, there's no community group dictating what anyone works on or what the priorities are. Again, I'm curious about the specific issues driving this discussion. Are there bugs or blueprints that you feel need more attention? Doug __ 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] [puppet] Weekly meeting #34
On 05/04/2015 08:40 AM, Emilien Macchi wrote: Hi, Tomorrow is our weekly meeting. Please look at the agenda [1]. Feel free to bring new topics and reviews/bugs if needed. Also, if you had any action, make sure you can give a status during the meeting or in the etherpad directly. See you tomorrow, We did our meeting, you can read the notes: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-05-05-15.00.html Thanks, [1] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150505 __ 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 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] [Rally] Improve review process
+1 - Original Message - From: Boris Pavlovic bpavlo...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, May 5, 2015 6:09:43 PM Subject: Re: [openstack-dev] [Rally] Improve review process Roman, Well done! This really simplifies life! Best regards, Boris Pavlovic On Tue, May 5, 2015 at 4:07 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi Roman, a truly great job. Very impressive and useful. Thanks a lot! Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 3:11 PM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Rally Team. I have created Rally Gerrit dashboard that organized patches in groups: Critical for next release, Waiting for final approve, Bug fixes, Proposed specs, Important patches, Ready for review, Has -1 but passed tests. Please use link http://goo.gl/iRxA5t for you comfortable. Patch is here https://review.openstack.org/#/c/179610/ It was made by gerrit-dash-creator. First group are the patches that are needed to merge to the nearest release. Content of the next three groups is obvious from the titles. Important patches - its just patches chosen(starred) by Boris Pavlovic or Mikhail Dubov. Ready for review - patches that are waiting for attention. And the last section - its patches with -1 mark but they passed CI. Roman Vasilets, Mirantis Inc. Intern Software Engineer __ 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] [TripleO] Core reviewer update proposal
Hi James, I have been moved away from tripleo, so it would make sense to remove me from the cd-admins and core reviewer of tripleo. Thanks, Thanks, Jon-Paul Sullivan ☺ Cloud Services - @hpcloud Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as HP CONFIDENTIAL. -Original Message- From: James Slagle [mailto:james.sla...@gmail.com] Sent: 05 May 2015 12:58 To: OpenStack Development Mailing List Subject: [openstack-dev] [TripleO] Core reviewer update proposal Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! -- -- James Slagle -- __ 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] Let us make the DVR job voting at the gate.
Hi Folks, The DVR single node job has been in the check queue for more than a cycle and it is pretty stable now and seems to closely follow the neutron-full job. So this would be the right time to make this job voting. https://review.openstack.org/#/c/180230/ In the mean-time we also have an experimental multi-node job for the DVR and we are working on stabilizing the job in upstream and once stabilized we can make that job ( check/voting). Meanwhile we will also be working on updating the developer guide for people to learn more on the DVR. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.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] [tc] Who is allowed to vote for TC candidates
Le 05/05/2015 18:41, Maish Saidel-Keesing a écrit : On 05/05/15 19:14, Sylvain Bauza wrote: Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. Completely Agree!! At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? It should go both ways. As I said, I don't understand why you consider that devs are not production aware ? I can't speak for everyone but I certainly trust that most of the developers are part of a company which either is a software vendor (and consequently has customer requests) or is directly running a production cloud. Some of us have also stories where they were previously Ops but then moved to a developing position just because they began to contribute to OpenStack directly, as I mentioned. -Sylvain In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ 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] [tc] Who is allowed to vote for TC candidates
On Tue, May 5, 2015 at 11:41 AM, Maish Saidel-Keesing mais...@maishsk.com wrote: And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? Many do. Don't forget that the two original projects that formed OpenStack were both from active deployments, one of which is still around and very active in the community in many ways. Most of the top contributors in terms of commits and code are from companies that are either operators themselves or directly support operators as a paid service. That said, there are also conflicting priorities as some companies and operators are focused on serving different markets and user bases. It seems like much of the division on priorities and implementation of operator-requested needs may be due to the perceptions caused by differing priorities? dt -- Dean Troyer dtro...@gmail.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] [Neutron] reminder: service chaining feature development meeting at 10am pacific time today May 5th
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ 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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
http://programmers.stackexchange.com/questions/45033/can-i-minify-javascript-that-requires-copyright-notice Thanks, Kevin From: Matthias Runge [mru...@redhat.com] Sent: Monday, May 04, 2015 11:17 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes REJECTED) On 05/05/15 05:29, Robert Collins wrote: Probably, but it's legally wrong (ie: worst case, you can be sued) to leave a package which is in direct violation of the license of things it contains. So,we shouldn't use angular at all then, because as a js framework its distributed to users when they use the website, but the license file isn't included in that distribution. Would be good to get a legal position on this. If we're not allowed to use angular (and anybody else), I wonder how anyone could use it (following above logic) Angular.js is licensed under MIT License [1],[2]: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. question is, if our use of angular is a substantial portion if this software. Matthias [1] https://angularjs.org/ [2] https://github.com/angular/angular.js/blob/master/LICENSE __ 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] [rally] Weekly meeting
Thank you for moving it to a more reasonable time for me. - Original Message - From: Boris Pavlovic bo...@pavlovic.me To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, carlos torres carlos.tor...@rackspace.com, yfr...@redhat.com, yingjun li yingjun...@kylin-cloud.com, Aleksandr Maretskiy amarets...@mirantis.com, Andrey Kurilin akuri...@mirantis.com, Mikhail Dubov msdu...@gmail.com, Oleg Anufriev oanufr...@mirantis.com, Roman Vasilets rvasil...@mirantis.com, Sergey Skripnick sskripn...@mirantis.com Sent: Tuesday, May 5, 2015 6:28:52 PM Subject: Re: [openstack-dev] [rally] Weekly meeting +Rally team Just to make sure that everybody saw this. Best regards, Boris Pavlovic On Tue, May 5, 2015 at 6:19 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, sorry for the previous disinformative message. We have decided to move our weekly meeting to Wednesdays at 14:00 UTC (IRC, *#openstack-meeting*). As said before, all the relevant information including the meeting agenda can be found on the wiki page https://wiki.openstack.org/wiki/Meetings/Rally . Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, May 5, 2015 at 6:10 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Starting from today, we will be posting our meeting agenda at the corresponding wiki page https://wiki.openstack.org/wiki/Meetings/Rally . Fell free to comment on the agenda / to propose new topics. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Tue, Apr 28, 2015 at 1:05 PM, Mikhail Dubov mdu...@mirantis.com wrote: Hi everyone, let me remind you that today there is the weekly Rally meeting at 17:00 UTC (IRC, *#openstack-meeting*). Here is the agenda for today: 1. Rally QA week: tasks, assignees, progress 2. Upcoming Rally 0.0.4 release: progress on critical patches 3. Spec on refactoring scenario utils: review and discussion ( https://review.openstack.org/#/c/172831/) 4. Spec on in-tree functional tests: review and discussion ( https://review.openstack.org/#/c/166487/) 5. Free discussion The meeting is going to be chaired by Alexander Maretskiy. Fell free to comment on the agenda / to propose new topics. 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 __ 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] Who is allowed to vote for TC candidates
On 05/05/15 19:00, Thierry Carrez wrote: Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Quite the contrary - I do not live in a Ops vs. Dev world. What I am trying to do here is help both sides understand each other. Because there should be no us vs. them thing here. It should be an us thing. But an ALL of us thing. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. +1 here! -- Best Regards, Maish Saidel-Keesing __ 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] Who is allowed to vote for TC candidates
On 05/05/15 19:22, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. And I sincerely hope that they continue. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. If that process could be a transparent and published - I am sure that will beneficial for everyone Is the feedback being taken into account during planning for liberty? Has someone correlated the feedback with the proposed specs and summit sessions? This is normally something I would expect the PTLs to be involved with for individual projects, although it might help to have a single document listing desired actionable changes from those separate etherpads, and someone involved in the meeting is probably better able to do that -- it can be difficult to look at meeting logs after the fact and extract a summary if you weren't in the room when the meeting occurred. Are there summaries of the consensus from the meetings? Looking through a few of the etherpads: https://etherpad.openstack.org/p/PHL-ops-burning-issues The first few items in the burning issues session look immediately actionable, some of them (such as nova-net/neutron migration and
Re: [openstack-dev] [all] Replace mysql-python with mysqlclient
On 04/30/2015 05:00 PM, Victor Stinner wrote: Hi, I propose to replace mysql-python with mysqlclient in OpenStack applications to get Python 3 support, bug fixes and some new features (support MariaDB's libmysqlclient.so, support microsecond in TIME column). In fact, when looking at the python-mysqldb package description in Debian, I can see: Mysqlclient is an interface to the popular MySQL database server for Python. . This is a fork of MySQLdb. It add Python 3.3 support and merges some pull requests. Then I saw this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096 The package is currently only in Debian experimental, but I am betting that soon, the new python-mysqldb package will be uploaded to Sid, and it's very likely that Ubuntu will follow (and sync the package from Debian). As a consequence, I think it'd be much better that OpenStack follows that and use the same thing as distributions. I of course don't know what Fedora will do, but maybe they may follow the trend... Also, I've been using that fork without realizing it, and as much as I can tell, OpenStack continues to work... Cheers, Thomas Goirand (zigo) __ 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] [TripleO] Core reviewer update proposal
Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core. Giulio has been an active member of our community for a while. He worked on the HA implementation in the elements and recently has been making a lot of valuable contributions and reviews related to puppet in the manifests, heat templates, ceph, and HA. Steve Hardy has been instrumental in providing a lot of Heat domain knowledge to TripleO and his reviews and guidance have been very beneficial to a lot of the template refactoring. He's also been reviewing and contributing in other TripleO projects besides just the templates, and has shown a solid understanding of TripleO overall. 180 day stats: | gfidente | 2080 42 166 0 079.8% | 16 ( 7.7%) | | shardy | 2060 27 179 0 086.9% | 16 ( 7.8%) | TripleO cores, please respond with +1/-1 votes and any comments/objections within 1 week. Giulio and Steve, also please do let me know if you'd like to serve on the TripleO core team if there are no objections. I'd also like to give a heads-up to the following folks whose review activity is very low for the last 90 days: | tomas-8c8 ** | 80 0 0 8 2 100.0% |0 ( 0.0%) | |lsmola ** | 60 0 0 6 5 100.0% |0 ( 0.0%) | | cmsj ** | 60 2 0 4 266.7% |0 ( 0.0%) | | jprovazn **| 10 1 0 0 0 0.0% |0 ( 0.0%) | | jonpaul-sullivan **| no activity Helping out with reviewing contributions is one of the best ways we can make good forward progress in TripleO. All of the above folks are valued reviewers and we'd love to see you review more submissions. If you feel that your focus has shifted away from TripleO and you'd no longer like to serve on the core team, please let me know. I also plan to remove Alexis Lee from core, who previously has expressed that he'd be stepping away from TripleO for a while. Alexis, thank you for reviews and contributions! -- -- James Slagle -- __ 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 communication: periodic developer newsletter?
James Bottomley mailto:james.bottom...@hansenpartnership.com May 5, 2015 at 9:53 AM On Tue, 2015-05-05 at 10:45 +0200, Thierry Carrez wrote: Joe Gordon wrote: [...] To tackle this I would like to propose the idea of a periodic developer oriented newsletter, and if we agree to go forward with this, hopefully the foundation can help us find someone to write newsletter. I've been discussing the idea of a LWN for OpenStack for some time, originally with Mark McLoughlin. For those who don't know it, LWN (lwn.net) is a source of quality tech reporting on Linux in general (and the kernel in particular). It's written by developers and tech reporters and funded by subscribers. An LWN-like OpenStack development newsletter would provide general status, dive into specific features, report on specific talks/conferences, summarize threads etc. It would be tremendously useful to the development community. The issue is, who can write such content ? It is a full-time job to produce authored content, you can't just copy (or link to) content produced elsewhere. It takes a very special kind of individual to write such content: the person has to be highly technical, able to tackle any topic, and totally connected with the OpenStack development community. That person has to be cross-project and ideally have already-built legitimacy. Here, you're being overly restrictive. Lwn.net isn't staffed by top level kernel maintainers (although it does solicit the occasional article from them). It's staffed by people who gained credibility via their insightful reporting rather than by their contributions. I see no reason why the same model wouldn't work for OpenStack. There is one technical difference: in the kernel, you can get all the information from the linux-kernel (and other mailing list) firehose if you're skilled enough to extract it. With OpenStack, openstack-dev isn't enough so you have to do other stuff as well, but that's more or less equivalent to additional research. It's basically the kind of profile every OpenStack company is struggling and fighting to hire. And that rare person should not really want to spend that much time developing (or become CTO of a startup) but prefer to write technical articles about what happens in OpenStack development. I'm not sure such a person exists. And a newsletter actually takes more than one such person, because it's a lot of work (even if not weekly). That's a bit pessimistic: followed to it's logical conclusion it would say that lwn.net can't exist either ... which is a bit of a contradiction. So as much as I'd like this to happen, I'm not convinced it's worth getting excited unless we have clear indication that we would have people willing and able to pull it off. The matter of who pays the bill is secondary -- I just don't think the profile exists. For the matter, I tried to push such an idea in the past and couldn't find anyone to fit the rare profile I think is needed to succeed. All the people I could think of had other more interesting things to do. I don't think things changed -- but I'd love to be proven wrong. Um, I assume you've thought of this already, but have you tried asking lwn.net? As you say above, they already fit the profile. Whether they have the bandwidth is another matter, but I believe their Chief Editor (Jon Corbet) may welcome a broadening of the funding base, particularly if the OpenStack foundation were offering seed funding for the endeavour. +1 to that, although lwn.net is partially subscriber only (yes I'm a subscriber); so if say we had a 'openstack section' there (just like there is a kernel section, or a security section, or a distributions section...) how would that work? It'd be neat to have what we do on lwn.net vs having a openstack clone/similar thing to lwn.net (because IMHO we already make ourselves 'special' enough...). -Josh James __ 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 Thierry Carrez mailto:thie...@openstack.org May 5, 2015 at 1:45 AM I've been discussing the idea of a LWN for OpenStack for some time, originally with Mark McLoughlin. For those who don't know it, LWN (lwn.net) is a source of quality tech reporting on Linux in general (and the kernel in particular). It's written by developers and tech reporters and funded by subscribers. An LWN-like OpenStack development newsletter would provide general status, dive into specific features, report on specific talks/conferences, summarize threads etc. It would be tremendously useful to the development community. The issue is, who can write such content ? It is a full-time job to produce authored content, you can't just copy (or link to) content produced elsewhere. It takes a very special kind of individual to write such
Re: [openstack-dev] [Neutron] reminder: service chaining feature development meeting at 10am pacific time today May 5th
Hi Cathy, Is there a meeting recording or the minutes available for the folks who missed it ? - Sridhar On Tue, May 5, 2015 at 9:57 AM, Cathy Zhang cathy.h.zh...@huawei.com wrote: Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up a“goto meeting” for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ 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] [puppet] Re: Puppet-OpenStack API providers - Follow up
I'm cross-posting to the dev list since this conversation should be happening there and is related to another thread there. I'm going to top-post a summary and then respond inline. The summary so far is that puppet-openstacklib provides a way to pass in credentials to an API-driven puppet type via an auth parameter[1] included in the types like so[2]. The benefit of this is that a user could create additional API resources, such as keystone_user, by passing in credentials directly to the type (presumably via hiera) without having to read credentials out of keystone.conf. The desire for something like this was outlined in the initial aviator blueprint[3] (the openstackclient blueprint[4] changed some of the design parameters, but not that one). self.instances and self.prefetch are class methods provided by puppet that types and providers typically override. These methods are unable to read type parameters, as far as I can tell, because they do not have a specific instance from which to look up those parameters. In our implementation, self.instances exists so that the command `puppet resource keystone_user` works and returns a list of keystone_users, and we don't use self.prefetch. So, the way the providers are intended to work right now is: when creating a single resource, to run a custom 'instances' object method to list resources and check for existence, which can use username/password credentials passed in to the resource OR use username/password credentials set as environment variables OR fall back to reading admin_token credentials from keystone.conf, as it always did; when run in `puppet resource` mode, it runs self.instances which can only use credentials set as environment variables or read credentials from keystone.conf since it has no way to accept an auth parameter. There are a couple of problems with this approach, one outlined by Gilles below and another that I'm just noticing. On Mon, May 4, 2015 at 8:34 PM, Gilles Dubreuil gil.dubre...@gmail.com wrote: Hi Colleen, The issue is about having to deal with 2 different code paths because authentication could be optionally passed to a resource instance where it can't when dealing with self.instances. Its creates many complications down the road. I initially expressed that from a technical OO point of view, although as you said it doesn't really matter. So, let's look at those examples: https://review.openstack.org/#/c/178385/3/lib/puppet/provider/keystone.rb https://review.openstack.org/#/c/178456/6/lib/puppet/provider/keystone_endpoint/openstack.rb Providers should not have to go through that. That is indeed pretty awful, I had no idea this would get so complicated when I initially wrote this. I'm also noticing what looks like a major flaw in that the object instances method seems almost entirely useless. A resource looks up the full list of resources but only ever stores one[5]. So the goal of replacing self.prefetch with an object method that had access to the auth params is just not accomplished at all. This is why I think avoiding passing authentication details in some case (instance) should be avoided. The authentication is provided by another layer, basically the environment, whether that comes from. Given the added complexity that you pointed out and the fact that the motivation behind some of that complexity is moot, I'm inclined to agree. We could avoid this complexity and be be able to take advantage of self.prefetch (which should speed up performance) if we did away with the auth parameter and the methods needed to accommodate that parameter. The modules do not use that auth parameter themselves, it's intended as an add-on if users wanted to include extra keystone_user, etc, resources in their profiles and didn't want to worry about running it on the keystone node. I rather doubt anyone is actually using that yet, and I'm curious if anyone has a desire to keep it around. So if the providers could both read a config file (keystone.conf, glance-api.conf, etc) and read environment variables for authentication, would that be desireable? The auth param can accept a path to an openrc file, but if we just assumed a certain path we could have the provider check that for credentials as well. puppet-openstack_extras happens to place it in /root/openrc[6]. Don't get me wrong the new openstacklib is great but the authentication being different between class and instances. Again, the authentication should be the same for the a whole provider, unconditionally. Otherwise, sure it works, I don't know how to put it, honestly, it breaks the spirit of the providers. Richm, imcsk8, and I have discussed around that issue (keystone v2/v3 support) and decided to talk to you before pushing anything, but we do think this boulder to be removed. By doing so we'll be able to move faster. Thanks for doing so. I'm glad we could have this discussion. I'm in time zone UTC+10 - Will try tomorrow morning for me, arvo for
Re: [openstack-dev] [puppet] Re: Puppet-OpenStack API providers - Follow up
On 05/05/2015 12:20 PM, Colleen Murphy wrote: I'm cross-posting to the dev list since this conversation should be happening there and is related to another thread there. Ok. I'm not replying puppet-openstack. I'm going to top-post a summary and then respond inline. The summary so far is that puppet-openstacklib provides a way to pass in credentials to an API-driven puppet type via an auth parameter[1] included in the types like so[2]. The benefit of this is that a user could create additional API resources, such as keystone_user, by passing in credentials directly to the type (presumably via hiera) without having to read credentials out of keystone.conf. The desire for something like this was outlined in the initial aviator blueprint[3] (the openstackclient blueprint[4] changed some of the design parameters, but not that one). self.instances and self.prefetch are class methods provided by puppet that types and providers typically override. These methods are unable to read type parameters, as far as I can tell, because they do not have a specific instance from which to look up those parameters. In our implementation, self.instances exists so that the command `puppet resource keystone_user` works and returns a list of keystone_users, and we don't use self.prefetch. So, the way the providers are intended to work right now is: when creating a single resource, to run a custom 'instances' object method to list resources and check for existence, which can use username/password credentials passed in to the resource OR use username/password credentials set as environment variables OR fall back to reading admin_token credentials from keystone.conf, as it always did; when run in `puppet resource` mode, it runs self.instances which can only use credentials set as environment variables or read credentials from keystone.conf since it has no way to accept an auth parameter. There are a couple of problems with this approach, one outlined by Gilles below and another that I'm just noticing. On Mon, May 4, 2015 at 8:34 PM, Gilles Dubreuil gil.dubre...@gmail.com mailto:gil.dubre...@gmail.com wrote: Hi Colleen, The issue is about having to deal with 2 different code paths because authentication could be optionally passed to a resource instance where it can't when dealing with self.instances. Its creates many complications down the road. I initially expressed that from a technical OO point of view, although as you said it doesn't really matter. So, let's look at those examples: https://review.openstack.org/#/c/178385/3/lib/puppet/provider/keystone.rb https://review.openstack.org/#/c/178456/6/lib/puppet/provider/keystone_endpoint/openstack.rb Providers should not have to go through that. That is indeed pretty awful, I had no idea this would get so complicated when I initially wrote this. I don't believe the final implementation will be that bad. I don't think we have to support v2 any more. We will just assume we always have enough information to use v3 auth and v3 api. Based on our discussions here and on IRC, this is possible and is desireable. I'm also noticing what looks like a major flaw in that the object instances method seems almost entirely useless. A resource looks up the full list of resources but only ever stores one[5]. So the goal of replacing self.prefetch with an object method that had access to the auth params is just not accomplished at all. This is why I think avoiding passing authentication details in some case (instance) should be avoided. The authentication is provided by another layer, basically the environment, whether that comes from. Given the added complexity that you pointed out and the fact that the motivation behind some of that complexity is moot, I'm inclined to agree. We could avoid this complexity and be be able to take advantage of self.prefetch (which should speed up performance) if we did away with the auth parameter and the methods needed to accommodate that parameter. The modules do not use that auth parameter themselves, it's intended as an add-on if users wanted to include extra keystone_user, etc, resources in their profiles and didn't want to worry about running it on the keystone node. I rather doubt anyone is actually using that yet, and I'm curious if anyone has a desire to keep it around. I cannot figure out a use case for having per-resource authentication parameters. It seems that the likely use case would be for per-run auth parameters, set via env. or config file. However, in openstack.rb self.request - what if self.request were changed to do the same thing as the instance request method? So if the providers could both read a config file (keystone.conf, glance-api.conf, etc) and read environment variables for authentication, would that be desireable? Yes. The auth param can accept a path to an openrc file, but if we just
Re: [openstack-dev] [all] Replace mysql-python with mysqlclient
On 5/5/15 1:11 PM, Thomas Goirand wrote: On 04/30/2015 05:00 PM, Victor Stinner wrote: Hi, I propose to replace mysql-python with mysqlclient in OpenStack applications to get Python 3 support, bug fixes and some new features (support MariaDB's libmysqlclient.so, support microsecond in TIME column). In fact, when looking at the python-mysqldb package description in Debian, I can see: Mysqlclient is an interface to the popular MySQL database server for Python. . This is a fork of MySQLdb. It add Python 3.3 support and merges some pull requests. Then I saw this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096 Wow, the thread decides to go forward with the move based on incorrect information. MySQL-Python's last release was on Jan 2, 2014, *not* in 2010. They are looking at the entirely wrong repository. Andy Dustman is a real person who is easily locatable on many services including Twitter, Linkedin, Github, etc. Any chance that anyone has tried to get a comment from him on this, given that with the Django recommendation and the distro package moves, his package is about to be more or less wiped out of most major distributions?It just would be good style IMHO. __ 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] [nova] Which error code should we return when OverQuota
In doing patch [1], A suggestion is submitted that we should return 400 (bad Request) instead of 403 (Forbidden) I take a look at [2], seems 400 is not a good candidate because 'The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. ' may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC__ 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] Which error code should we return when OverQuota
On Tue, 2015-05-05 at 21:30 +0200, Chen CH Ji wrote: In doing patch [1], A suggestion is submitted that we should return 400 (bad Request) instead of 403 (Forbidden) I take a look at [2], seems 400 is not a good candidate because 'The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. ' may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Looking through the HTTP spec you reference in [2], there isn't really a good match. You're right that 400 doesn't really make sense, but I don't really think that 409 is a good fit either. The only ones that would make sense to me would be 413 (Request Entity Too Large) and 403, the definition of which is wide enough to encompass the over-quota condition; and of those, 403 makes the most sense. (Note that I believe we use 413 for rate limiting, because of the Retry-After header…) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ 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] Who is allowed to vote for TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-05-05 19:52:24 +0300: On 05/05/15 19:22, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300: On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. Unfortunately I wasn't able to attend, either, but I've heard the same general sentiments of the results. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. +1 for writing things down I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. I don't expect them to file blueprints for new features, because the contributor responsible for the implementation needs to document their plans. I absolutely *do* expect Operators to file bugs, though, just as they would with any other software package they use. And I sincerely hope that they continue. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. OK, so we're finally getting to the real issues! :-) What is your expectation for timing? Having a meetup to collect feedback like this mid-cycle is unlikely to affect the current release in significant ways. For example, bugs may be prioritized differently, and I know some were, but we're not likely to stop work on features already in progress to work on something new or start any large new initiatives at that point in the cycle. If that process could be a transparent and published - I am sure that will beneficial for everyone Most of the contributor teams meet weekly on IRC, and discuss priorities in the meeting, here on the mailing list, on the bug reports, on reviews, etc. -- the usual places. On top of that, the PTLs and release management team work hard to publish information about the status of blueprints over the course of the cycle. Is the problem that you don't know where we're publishing the information already, or is it in a form that's not easy to understand, or is there something else about the current process that makes what is already being written unsuitable for your needs? Is the feedback being taken into account during planning for liberty?
Re: [openstack-dev] [puppet][operators] How to specify Keystone v3 credentials?
On 2015-05-05 1:25 AM, Monty Taylor wrote:
On 05/04/2015 08:47 PM, Emilien Macchi wrote:
On 05/04/2015 10:37 PM, Rich Megginson wrote:
On 05/04/2015 07:52 PM, Mathieu Gagné wrote:
On 2015-05-04 9:15 PM, Rich Megginson wrote:
On 05/04/2015 06:03 PM, Mathieu Gagné wrote:
On 2015-05-04 7:35 PM, Rich Megginson wrote:
The way authentication works with the Icehouse branch is
that puppet-keystone reads the admin_token and
admin_endpoint from /etc/keystone/keystone.conf and
passes these to the keystone command via the
OS_SERVICE_TOKEN env. var. and the --os-endpoint
argument, respectively.
This will not work on a node where Keystone is not
installed (unless you copy /etc/keystone/keystone.conf to
all of your nodes).
I am assuming there are admins/operators that have
actually deployed OpenStack using puppet on nodes where
Keystone is not installed?
We are provisioning keystone resources from a privileged
keystone node which accepts the admin_token. All other
keystone servers has the admin_token_auth middleware
removed for obvious security reasons.
If so, how? How do you specify the authentication
credentials? Do you use environment variables? If so,
how are they specified?
When provisioning resources other than Keystones ones, we
use custom puppet resources and the credentials are passed
as env variables to the exec command. (they are mainly
based on exec resources)
I'm talking about the case where you are installing an
OpenStack service other than Keystone using puppet, and that
puppet code for that module needs to create some sort of
Keystone resource.
For example, install Glance on a node other than the Keystone
node. puppet-glance is going to call class
glance::keystone::auth, which will call
keystone::resource::service_identity, which will call
keystone_user { $name }. The openstack provider used by
keystone_user is going to need Keystone admin credentials in
order to create the user.
We fixed that part by not provisioning Keystone resources
from Glance nodes but from Keystone nodes instead.
We do not allow our users to create users/groups/projects, only
a user with the admin role can do it. So why would you want to
store/use admin credentials on an unprivileged nodes such as
Glance? IMO, the glance user shouldn't be able to
create/edit/delete users/projects/endpoints, that's the
keystone nodes' job.
Ok. You don't need the Keystone superuser admin credentials on
the Glance node.
Is the puppet-glance code completely separable so that you can
call only glance::keystone::auth (or other classes that use
Keystone resources) from the Keystone node, and all of the other
puppet-glance code on the Glance node? Does the same apply to
all of the other puppet modules?
If you do not wish to explicitly define Keystone resources for
Glance on Keystone nodes but instead let Glance nodes manage
their own resources, you could always use exported resources.
You let Glance nodes export their keystone resources and then
you ask Keystone nodes to realize them where admin credentials
are available. (I know some people don't really like exported
resources for various reasons)
I'm not familiar with exported resources. Is this a viable
option that has less impact than just requiring Keystone
resources to be realized on the Keystone node?
I'm not in favor of having exported resources because it requires
PuppetDB, and a lot of people try to avoid that. For now, we've
been able to setup all OpenStack without PuppetDB in TripleO and in
some other installers, we might want to keep this benefit.
+100
We're looking at using these puppet modules in a bit, but we're also a
few steps away from getting rid of our puppetmaster and moving to a
completely puppet apply based workflow. I would be double-plus
sad-panda if we were not able to use the openstack puppet modules to
do openstack because they'd been done in such as way as to require a
puppetmaster or puppetdb.
100% agree.
Even if you had a puppetmaster and puppetdb, you would still end up in
this eventual consistency dance of puppet runs.
--
Mathieu
__
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] os-ansible-deplpoyment has released Kilo
Hi Dani, To touch on the provisioining we presently have no plans to introduce baremetal provisioning via a PXE, Razor, djeep, etc… Our present thinking is to allow people to use whatever they want to provision the hosts and then come in with OSAD, post the OS deployment, to install OpenStack. As for the LXC containers they are used for infrastructure components within the cloud deployment. By default your instances are run under KVM which would allow you to sick to standard VM instances.If you didn’t want the separation and scalability that the LXC containers provide the infrastructure components, you could set the flag, “is_metal” to true within the `openstack_environment.yml` file which would install some or all of the various services, that we presently support, on the hosts specified within your Anisble inventory. I hope that helps / answers your questions, we are working on documentation to better spell out all of the things that you can do with the system, so watch for that soon. Also feel free to ping me @cloudnull or others within the #openstack-ansible channel or pop by one of our meetings [ https://wiki.openstack.org/wiki/Meetings/openstack-ansible ] there’s a bunch of us around that are more than happy to help / answer any more questions that you might have. — Kevin On May 4, 2015, at 15:49, Daniel Comnea comnea.d...@gmail.com wrote: Hey Kevin, Let me add more info: 1) trying to understand if there is any support for baremetal provisioning (e.g setup the UCS manager if using UCS blades etc, dump the OS on it). I don't care if is Ironic or PXE/ Kickstart or Foreman etc 2) deployments on baremetal without the use of LXC containers (stick with default VM instances) Dani On Mon, May 4, 2015 at 3:02 PM, Kevin Carter kevin.car...@rackspace.com wrote: Hey Dani, Are you looking for support for Ironic for baremetal provisioning or for deployments on baremetal without the use of LXC containers? — Kevin On May 3, 2015, at 06:45, Daniel Comnea comnea.d...@gmail.com wrote: Great job Kevin co !! Are there any plans in supporting configure the baremetal as well ? Dani On Thu, Apr 30, 2015 at 11:46 PM, Liu, Guang Jun (Gene) gene@alcatel-lucent.com wrote: cool! From: Kevin Carter [kevin.car...@rackspace.com] Sent: Thursday, April 30, 2015 4:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] os-ansible-deplpoyment has released Kilo Hello Stackers, The OpenStack Ansible Deployment (OSAD) project is happy to announce our stable Kilo release, version 11.0.0. The project has come a very long way from initial inception and taken a lot of work to excise our original vendor logic from the stack and transform it into a community-driven architecture and deployment process. If you haven’t yet looked at the `os-ansible-deployment` project on StackForge, we'd love for you to take a look now [ https://github.com/stackforge/os-ansible-deployment ]. We offer an OpenStack solution orchestrated by Ansible and powered by upstream OpenStack source. OSAD is a batteries included OpenStack deployment solution that delivers OpenStack as the developers intended it: no modifications to nor secret sauce in the services it deploys. This release includes 436 commits that brought the project from Rackspace Private Cloud technical debt to an OpenStack community deployment solution. I'd like to recognize the following people (from Git logs) for all of their hard work in making the OSAD project successful: Andy McCrae Matt Thompson Jesse Pretorius Hugh Saunders Darren Birkett Nolan Brubaker Christopher H. Laco Ian Cordasco Miguel Grinberg Matthew Kassawara Steve Lewis Matthew Oliver git-harry Justin Shepherd Dave Wilde Tom Cameron Charles Farquhar BjoernT Dolph Mathews Evan Callicoat Jacob Wagner James W Thorne Sudarshan Acharya Jesse P Julian Montez Sam Yaple paul Jeremy Stanley Jimmy McCrory Miguel Alex Cantu elextro While Rackspace remains the main proprietor of the project in terms of community members and contributions, we're looking forward to more community participation especially after our stable Kilo release with a community focus. Thank you to everyone that contributed on the project so far and we look forward to working with more of you as we march on. — Kevin Carter __ 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:
Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 5 May 2015 at 18:17, Matthias Runge mru...@redhat.com wrote: On 05/05/15 05:29, Robert Collins wrote: Probably, but it's legally wrong (ie: worst case, you can be sued) to leave a package which is in direct violation of the license of things it contains. So,we shouldn't use angular at all then, because as a js framework its distributed to users when they use the website, but the license file isn't included in that distribution. Would be good to get a legal position on this. If we're not allowed to use angular (and anybody else), I wonder how anyone could use it (following above logic) Lets take a sensible, pragmatic approach here. Firstly, upload a new tarball to pypi (a point release, not a postN release - for uninteresting reasons pbr 0.10 produced postN versions for local commits, and thus any postN version is not guaranteed to be unique). Secondly, reference that in a stable branch update to global-requirements and horizon. Thats easy enough. Thirdly, once our users have had time to update to the next point release of Horizon - say 3 months - delete the file thats missing its license statement from PyPI: upstream git has a LICENSE file, so we are clearly not representing them well by distributing a package without it. There's absolutely no reason to rush: if upstream were license pedants, they would not have chosen the license they did (because of its obvious incompatibility with js minification). The incompatibility that I refer to is potentially serious, since a license pedant can trivially take the position I put forward above, but since we can reasonably assume upstream want their code to be used, I think should be treated as a linter warning, not a fatal error, and we should take a gentle non-contentious approach to discussing it with them. angular-bootstrap only! has 190 committers, angular has 1200 committers:- any rectification, even a simple rider added to the repo, is likely to take time due to the lovely way copyright intertwines on these things. -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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 05/05/15 05:29, Robert Collins wrote: Probably, but it's legally wrong (ie: worst case, you can be sued) to leave a package which is in direct violation of the license of things it contains. So,we shouldn't use angular at all then, because as a js framework its distributed to users when they use the website, but the license file isn't included in that distribution. Would be good to get a legal position on this. If we're not allowed to use angular (and anybody else), I wonder how anyone could use it (following above logic) Angular.js is licensed under MIT License [1],[2]: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. question is, if our use of angular is a substantial portion if this software. Matthias [1] https://angularjs.org/ [2] https://github.com/angular/angular.js/blob/master/LICENSE __ 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] Speed Up RabbitMQ Recovering
On 5 May 2015, at 2:31 pm, Zhou Zheng Sheng / 周征晟 zhengsh...@awcloud.com
wrote:
Thank you Bogdan for clearing the pacemaker promotion process for me.
on 2015/05/05 10:32, Andrew Beekhof wrote:
On 29 Apr 2015, at 5:38 pm, Zhou Zheng Sheng / 周征晟 zhengsh...@awcloud.com
wrote:
[snip]
Batch is a pacemaker concept I found when I was reading its
documentation and code. There is a batch-limit: 30 in the output of
pcs property list --all. The pacemaker official documentation
explanation is that it's The number of jobs that the TE is allowed to
execute in parallel. From my understanding, pacemaker maintains cluster
states, and when we start/stop/promote/demote a resource, it triggers a
state transition. Pacemaker puts as many as possible transition jobs
into a batch, and process them in parallel.
Technically it calculates an ordered graph of actions that need to be
performed for a set of related resources.
You can see an example of the kinds of graphs it produces at:
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-config-testing-changes.html
There is a more complex one which includes promotion and demotion on the
next page.
The number of actions that can run at any one time is therefor limited by
- the value of batch-limit (the total number of in-flight actions)
- the number of resources that do not have ordering constraints between them
(eg. rsc{1,2,3} in the above example)
So in the above example, if batch-limit = 3, the monitor_0 actions will
still all execute in parallel.
If batch-limit == 2, one of them will be deferred until the others complete.
Processing of the graph stops the moment any action returns a value that was
not expected.
If that happens, we wait for currently in-flight actions to complete,
re-calculate a new graph based on the new information and start again.
So can I infer the following statement? In a big cluster with many
resources, chances are some resource agent actions return unexpected
values,
The size of the cluster shouldn’t increase the chance of this happening unless
you’ve set the timeouts too aggressively.
and if any of the in-flight action timeout is long, it would
block pacemaker from re-calculating a new transition graph?
Yes, but its actually an argument for making the timeouts longer, not shorter.
Setting the timeouts too aggressively actually increases downtime because of
all the extra delays and recovery it induces.
So set them to be long enough that there is unquestionably a problem if you hit
them.
But we absolutely recognise that starting/stopping a database can take a very
long time comparatively and that it shouldn’t block recovery of other unrelated
services.
I would expect to see this land in Pacemaker 1.1.14
I see the
current batch-limit is 30 and I tried to increase it to 100, but did not
help.
Correct. It only puts an upper limit on the number of in-flight actions,
actions still need to wait for all their dependants to complete before
executing.
I'm sure that the cloned MySQL Galera resource is not related to
master-slave RabbitMQ resource. I don't find any dependency, order or
rule connecting them in the cluster deployed by Fuel [1].
In general it should not have needed to wait, but if you send me a crm_report
covering the period you’re talking about I’ll be able to comment specifically
about the behaviour you saw.
Is there anything I can do to make sure all the resource actions return
expected values in a full reassembling?
In general, if we say ‘start’, do your best to start or return ‘0’ if you
already were started.
Likewise for stop.
Otherwise its really specific to your agent.
For example an IP resource just needs to add itself to an interface - it cant
do much differently, if it times out then the system much be very very busy.
The only other thing I would say is:
- avoid blocking calls where possible
- have empathy for the machine (do as little as is needed)
Is it because node-1 and node-2
happen to boot faster than node-3 and form a cluster, when node-3 joins,
it triggers new state transition? Or may because some resources are
already started, so pacemaker needs to stop them firstly?
We only stop them if they shouldn’t yet be running (ie. a colocation or
ordering dependancy is not yet started also).
Does setting
default-resource-stickiness to 1 help?
From 0 or INFINITY?
I also tried crm history XXX commands in a live and correct cluster,
I’m not familiar with that tool anymore.
but didn't find much information. I can see there are many log entries
like run_graph: Transition 7108 Next I'll inspect the pacemaker
log to see which resource action returns the unexpected value or which
thing triggers new state transition.
[1] http://paste.openstack.org/show/214919/
I’d not recommend mixing the two CLI tools.
The problem is that pacemaker can only promote a resource after it
detects the resource is
Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?
Joe Gordon wrote: [...] To tackle this I would like to propose the idea of a periodic developer oriented newsletter, and if we agree to go forward with this, hopefully the foundation can help us find someone to write newsletter. I've been discussing the idea of a LWN for OpenStack for some time, originally with Mark McLoughlin. For those who don't know it, LWN (lwn.net) is a source of quality tech reporting on Linux in general (and the kernel in particular). It's written by developers and tech reporters and funded by subscribers. An LWN-like OpenStack development newsletter would provide general status, dive into specific features, report on specific talks/conferences, summarize threads etc. It would be tremendously useful to the development community. The issue is, who can write such content ? It is a full-time job to produce authored content, you can't just copy (or link to) content produced elsewhere. It takes a very special kind of individual to write such content: the person has to be highly technical, able to tackle any topic, and totally connected with the OpenStack development community. That person has to be cross-project and ideally have already-built legitimacy. It's basically the kind of profile every OpenStack company is struggling and fighting to hire. And that rare person should not really want to spend that much time developing (or become CTO of a startup) but prefer to write technical articles about what happens in OpenStack development. I'm not sure such a person exists. And a newsletter actually takes more than one such person, because it's a lot of work (even if not weekly). So as much as I'd like this to happen, I'm not convinced it's worth getting excited unless we have clear indication that we would have people willing and able to pull it off. The matter of who pays the bill is secondary -- I just don't think the profile exists. For the matter, I tried to push such an idea in the past and couldn't find anyone to fit the rare profile I think is needed to succeed. All the people I could think of had other more interesting things to do. I don't think things changed -- but I'd love to be proven wrong. -- 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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 05/05/2015 04:31 AM, Ian Cordasco wrote: Please don’t put words in my mouth Thomas. You do this frequently. I don't think I have. Not here, not before. Please assume good faith on mailing lists, because it's hard to grasp the feeling on the other end. If you want to start an argue and feel like I've been bad with you, please do it privately, and I hope we'll get on together better. How about having a beer in Vancouver? :) given the reliability of system packages, it’s increasingly deployed from source. WTF?!? In what way are Python packages that I maintain for OpenStack not reliable? Could you care to explain? Are you a lawyer? Do you have a special connection with people from bootstrap and angular, and they told you so? Again with trying to put words in my mouth Thomas. I'm just pointing to the fact that you don't know, just like I don't either or anyone else, what the consequences can be to violate a license. This is unless you're a lawyer, or if you know upstream for Angular. I fail to see where I do put words into your mouth... I suppose if you used pip, you’d understand why the .post1 suffix is necessary I did use pip, but I still don't understand how adding .post1 provides more information. Probably I wont be the only one. Could you enlighten me? but you don’t care about anything other than how this affects your packages, do you? I do care that everything done within the OpenStack project is done respecting free software licenses. This is more than just packaging in Debian, this is also related to ethic. I'm pointing out the fact that there's a legal issue with the licensing and the distribution of a package. The plan described by Robert Collins is very accurate, and is just exactly what I thought should be done. Let's be constructive, have the issue fixed like Robert described, and avoid time loss (with nit-pickings), ok? On 05/05/2015 05:29 AM, Robert Collins wrote: So,we shouldn't use angular at all then, because as a js framework its distributed to users when they use the website, but the license file isn't included in that distribution. IANAL, but I don't think minified runtime use of a MIT-licensed Javascript has the same legal issues as shipping the source code. So far, I haven't seen a case where having a javascript running within your browser was considered as redistribution of the source code. On 05/05/2015 08:17 AM, Matthias Runge wrote: If we're not allowed to use angular (and anybody else), I wonder how anyone could use it (following above logic) Exactly my thoughts. Angular.js is licensed under MIT License [1],[2]: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. question is, if our use of angular is a substantial portion if this software. I'm convince it is. And I'm convince we *must* ship the above copyright notice and this permission notice in our source packages, as the license says. If you don't trust me, please do trust the Debian FTP masters who are doing this every day. Cheers, Thomas Goirand (zigo) __ 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] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 05/05/15 04:31, Ian Cordasco wrote: Even so, Horizon is deployed in many places, and given the reliability of system packages, it’s increasingly deployed from source. Ok, I'll bite. You surely have a source for your statement, or even better, a proof? This is wrong in so many ways. It's the same truth as someone could claim: neutron doesn't work, so don't use it. (just took neutron as example) If there is something wrong with system packages, please file bugs. Every distribution has a bug tracker. Matthias __ 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
