Re: [openstack-dev] [tc] Question about electorate for project without gerrit contribution

[Tony Breeds]

On Tue, Mar 15, 2016 at 09:41:41PM +, Hayes, Graham wrote:
> I do not see the time frame for defining an electorate there.
> 
> PTL seats are completely renewed every 6 months. A separate election is 
> run for
> each project team. These elections are collectively held 5 weeks prior 
> to each
> design summit, with nominations due 6 weeks prior to the summit and 
> elections
> held open for no less than five business days.
> 
> The way the rules are currently worded if the extra ATC patch merged
> before the deadline for PTL nomination anyone in that patch would be 
> able to run.
> 
> Where do we define the cut off date for electorate definition?

[1] roughly defines it as "committed a change to a repository of a project over
the last two 6-month release cycles"

For the sake of generating the full APC roles we (the election officials) define
the exact range and communicate that[2].  At approximately the same time the
governance repo is tagged and used for reference[3].  There are no extra-ATCs
for Packaging-deb[4].

That is how we define the electorate, changing that mid-election is not an 
option.

Yours Tony.
[1] 
http://governance.openstack.org/reference/charter.html#voters-for-ptl-seats-apc
[2] https://wiki.openstack.org/wiki/PTL_Elections_March_2016#Electorate
[3] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=march-2016-elections
[4] 
https://github.com/openstack/governance/blob/march-2016-elections/reference/projects.yaml#L3147-L3282


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] lvm2 and docker issue

[Steven Dake (stdake)]

Ccing mailing list for eveyrone's advantage.

From: "Serguei Bezverkhi (sbezverk)" 
>
Date: Tuesday, March 15, 2016 at 8:26 PM
To: Steven Dake >
Subject: lvm2 and docker issue

Hi Steven,

I have run few tests and so far with --ipc=host it looks better, at least I do 
not see that "stuck" issue when lvcreate is executed.

docker inspect 417f53c7ac84 | grep -i IPC
"IpcMode": "host",

Now, how do I specify this option when starting kolla containers?

This one I run manually with this command:

docker run --privileged -t -i --ipc=host --net=host --cap-add=ALL -v /dev:/dev 
-v /run:/run -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v 
/sys/kernel/config:/configfs -v /lib/modules:/lib/modules -v 
/var/lib/cinder:/var/lib/cinder -v /etc/iscsi:/etc/iscsi f4118e59a77a

Thank you

Serguei
You have to extend the kolla_docker module.  An example is here:
https://github.com/openstack/kolla/blob/master/ansible/library/kolla_docker.py#L597

Search the file for the word host - you will probably need stuff wherever that 
is except with pid duplicated with ipc.  I recommend a patch prior to your 
current patch to introduce the feature to kolla_docker.

Regards
-steve


[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_07.png?ct=1423747865775]

Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527


Cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.



__
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][taas] [ux] Proposal of Dashboard for TaaS

[Tripp, Travis S]

Hello Everybody,

The #openstack-ux project specifically has been setup to help with user 
experience designs.

We use a tool called invision [0] for visual design commenting and 
interactions. In addition,
The UX repo has been setup to help facilitate this process and Piet (the PTL) 
is looking
Into OpenSource opportunities. [1]

[0] https://openstack.invisionapp.com/d/main#/projects
[1]

>From Piet:
MOCK REVIEW TOOLS
There has been some discussion around replacing Invision because of the
speed, not being open source, etc.  I was hoping you could take a look at
a couple of alternatives.

To set expectations, it will need to be an open source project and be
hosted by either the OpenStack Infrastructure project or a specific
company.

Phabricator Pholio
http://phacility.com/phabricator/pholio/

Review board
https://www.reviewboard.org/



Thanks,
Travis




On 3/15/16, 9:30 PM, "Soichi Shigeta"  wrote:

>
>  Hi,
>
>  Please find attached file.
>Yet another design of the Network Topology Tab.
>
># I couldn't upload pdf files to the Wiki.
>  When I tried, a message ".pdf file is not permitted"
>  was shown.
>
>Regards,
>Soichi
>
>>
>>   Hi Anil, and folks,
>>
>> Thank you for your comments.
>>
>>> Thanks Soichi and Kaz for your work on implementing Horizon
>>> (dashboard) support for TaaS. The proposal (with screen shots)
>>> discussed in our recent IRC meeting look very nice. Here are some
>>> additional suggestions for improvement.
>>>
>>>
>>>
>>> 1.   General
>>>
>>> a.   When a port is being selected (for a tap-service instance or
>>> a tap-flow) it would be nice to also provide some extra information
>>> associated with that port, such as the VM it belongs to and the IP
>>> address.  This will look very similar to what is being done today when
>>> associating a floating IP with a VM vNIC. The extra context will allow
>>> users to identify their source and destination end-points with more
>>> ease. If a VM is not currently associated with a port then the extra
>>> information is not necessary.
>>
>> I agree with you.
>> It is difficult for users to select an appropriate port
>> by seeing only uuid.
>>
>> I didn't explain in the submitted document, in the current
>> implementation, not only uuid but also name is also shown
>> if a port is given a name.
>>
>> I agree to show IP address.
>> i.e., name, uuid, and IP address are shown for each port.
>> Please refer p.1 of the attached file.
>>
>> On the other hand, in terms of modification cost, I'd like
>> to disagree to show associated VM.
>> Because Neutron doesn't know association between a port and
>> a VM, we need to send a query to Nova.
>> Of course, I agree to implement this if requested from field.
>>
>>
>>> b.  When selecting the traffic monitoring direction, it would be
>>> nice to provide two check boxes, one for 'ingress' and the other for
>>> 'egress'. A user wishing to monitor a port in both directions can
>>> select both check boxes. I feel this looks better than having an
>>> option  called 'both'.
>>
>> In terms of consistency with the option in CLI, I prefer to
>> chose one of the both/ingress/egress from pull down menu.
>>
>> To avoid confusions, it had better to say something like
>> "ingress (to instance)" and "egress (from instance)".
>>
>>
>>> 2.   Using the Tap Services Tab
>>>
>>> a.   Allow tap-flow-create and tap-flow-delete operations to also
>>> be carried out from here. This will let users who prefer working in
>>> this fashion get everything done from the same place.
>>
>> I will plan to add "tap-flow-create" and "tap-flow-delete" button
>> on the tap-service tab.
>>
>> But, I'm afraid that a lot of ports will be listed as candidates
>> when a user starts tap-flow-create from here.
>> Because no instance (VM) is selected here, we can not filter to
>> list.
>>
>>
>>> b.  Provide a way to list tap flows currently associated with a
>>> tap service.
>>
>> Excuse me, I didn't mention about it on the submitted document.
>> This is done on the overview of a tap-service.
>> Please refer p.2 of the attached file.
>>
>>
>>> c.   Allow multiple tap-flows to be created at the same time. Let
>>> the user pick multiple source ports (and traffic monitoring
>>> directions) and have all of them attached to a designated tap-service.
>>
>> I'd like to consider this in the future.
>> Because it seems taking larger man-hour cost to realize.
>> (consideration with man-hour we have)
>> Additionally, I think we need to take care of error cases
>> such as a part of tap-flow creation failed.
>>
>>
>>> 3.   Using the Network Topology Tab
>>>
>>> a.   Allow tap-create and tap-delete operations to be also carried
>>> out from here. This will allow users who prefer working in this
>>> fashion get everything done from the same place. 

Re: [openstack-dev] [swift3][swift] What happens in swift3?

[Kota TSUYUZAKI]

Tim is sill working for making sure how the sigv4 patch works[1]. The couple of 
main reasons for the slow review is, right now, no way to make sure the sigv4 
in functests for jenkins job and no docs
about what's changed, what's constraint, what's we should change our config in 
those patches. In my opinion, the authentication is the most sensitive one of 
all modules because it can break everything
easily and I am still worried about the patch may break the exinsting 
environment for a bunch of users in all over the world using sigv2.

Regards,
Kota


1: https://bugs.launchpad.net/swift3/+bug/1557260
2: https://review.openstack.org/#/c/272516

(2016/03/14 19:01), Andrey Pavlov wrote:
> Hello,
> 
> I found that new Amazon tool for S3 started to use another way to sign 
> requests.
> I made changes and submitted my review [1] seven months ago.
> 
> This functionality is needed for ec2api project [2].
> It is needed for using new aws cli tool.
> 
> I asked to review my changes directly to Kota via email.
> My colleague asked him on previous summit about it.
> All dependent reviews (in keystone) already merged four months ago.
> On all comments were answered in the review.
> I tried to raise this question at swift3 meeting.
> 
> But still there is no answer.
> 
> Can anyone answer - Can it really be reviewed and merged?
> 
> [1] https://review.openstack.org/#/c/211933/
> [2] https://review.openstack.org/#/c/198571/
> 


-- 
--
Kota Tsuyuzaki(露﨑　浩太)  
NTT Software Innovation Center
Cloud Solution Project
Phone  0422-59-2837
Fax0422-59-2965
---



__
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] rabbitmq / ipv6 issue

[Emilien Macchi]

I did some testing again and I'm still running in curl issues:
http://paste.openstack.org/show/BU7UY0mUrxoMUGDhXgWs/

I'll continue investigation tomorrow.

On Tue, Mar 15, 2016 at 8:00 PM, Emilien Macchi  wrote:
> Both Pull-requests got merged upstream (kudos to Puppetlabs).
>
> I rebased https://review.openstack.org/#/c/289445/ on master and
> abandoned the pin. Let's see how CI works now.
> If it still does not work, feel free to restore the pin and rebase
> again on the pin, so we can make progress.
>
> On Tue, Mar 15, 2016 at 6:21 PM, Emilien Macchi  wrote:
>> So this is an attempt to fix everything in Puppet modules:
>>
>> * https://github.com/puppetlabs/puppetlabs-stdlib/pull/577
>> * https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/443
>>
>> If we have the patches like this, there will be no need to patch TripleO.
>>
>> Please review the patches if needed,
>> Thanks
>>
>> On Tue, Mar 15, 2016 at 1:57 PM, Emilien Macchi  wrote:
>>> So from now, we pin [5] puppetlabs-rabbitmq to the commit before [3]
>>> and I rebased Attila's patch to test CI again.
>>> This pin is a workaround, in the meantime we are working on a fix in
>>> puppetlabs-rabbitmq.
>>>
>>> [5] https://review.openstack.org/293074
>>>
>>> I also reported the issue in TripleO Launchpad:
>>> https://bugs.launchpad.net/tripleo/+bug/1557680
>>>
>>> Also a quick note:
>>> Puppet OpenStack CI did not detect this failure because we don't
>>> deploy puppetlabs-rabbitmq from master but from the latest release
>>> (tag).
>>>
>>> On Tue, Mar 15, 2016 at 1:17 PM, Emilien Macchi  wrote:
 TL;DR;This e-mail tracks down the work done to make RabbitMQ working
 on IPv6 deployments.
 It's currently broken and we might need to patch different Puppet
 modules to make it work.

 Long story:

 Attila Darazs is currently working on [1] to get IPv6 tested by
 TripleO CI but is stuck because a RabbitMQ issue in Puppet catalog
 [2], reported by Dan Sneddon.
 [1] https://review.openstack.org/#/c/289445
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1317693

 [2] is caused by a patch in puppetlabs-rabbitmq [3], that change the
 way we validate RabbitMQ is working from testing localhost to testing
 the actual binding IP.
 [3] 
 https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/dac8de9d95c5771b7ef7596b73a59d4108138e3a

 The problem is that when testing the actual IPv6, it curls fails for
 some different reasons explained on [4] by Sofer.
 [4] https://review.openstack.org/#/c/292664/

 So we need to investigate puppetlabs-rabbitmq and puppet-staging to
 see if whether or not we need to change something there.
 For now, I don't think we need to patch anything in TripleO Heat
 Templates, but we'll see after the investigation.

 I'm currently working on this task, but any help is welcome,
 --
 Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today with new meeting time and new irc
channel.

The meeting is being held Wednesday UTC1300 and irc channel
#openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)

[Hong Hui Xiao]

Hi all.

I did some investigation recently. And I think we can start some
discussion now.

All below thinking is based on the current implementation of neutron. With
routed network, a subnet will be considered as a L2 domain. Things might
change.

I think routed network in OVN can implement in this way:
User creates provider network. For example:
neutron net-create provider-101 --shared \
--provider:physical_network providernet \
--provider:network_type vlan \
--provider:segmentation_id 101

These attributes "--provider:physical_network" will be recorded in the
external_ids of Logical_Switch in OVN_Northbound.


To Russell:
I will expect OVN to do the following things.
1) The OVN_Southbound will have the latest information of
"ovn-bridge-mappings" of each Chassis.
2) After creating a new network with "provider:physical_network" set, the
OVN will update Logical_Switch in OVN_Northbound.
The Logical_Switch will have new key:value pair in external_ids.
neutron:available_hosts="compute-host1,compute-host2"
3) When a compute host join/leave the OpenStack topology, or a compute
host just updates its ovn-bridge-mappings, OVN should updated
Logical_Switch with related physical_network. This is a bottom-up change,
which is similar to the port status change.
4) networking-ovn should be able to catch the update of Logical_Switch in
2) & 3) and update the SegmentHostMapping, which will be introduced in
[2].

I think 1) 2) & 3) need additional work in OVN code. And 4) need code
change in networking-ovn.


To Carl:
At the same time, the plugin(ml2 or networking-ovn) will provide a "new"
interface. The "new" interface might be the same with [1].
Neutron will use this interface select routed hosts for a network.

Any thoughts?

[1] neutron.plugins.ml2.plugin.Ml2Plugin.filter_hosts_with_network_access 
@  https://review.openstack.org/#/c/205631/33
[2] https://review.openstack.org/#/c/285548/1

Thanks

HongHui Xiao(肖宏辉) PMP®
OpenStack Network development, Beijing, China

Email: xiaoh...@cn.ibm.com 
Tel: 86-10-82453130

__
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] [zaqar] PTL candidacy

[Fei Long Wang]

Hi all,

I've had the pleasure of serving the Zaqar community as PTL for the
Mitaka cycle, and I'd like to continue for Newton cycle, if
you'll have me.

For Newton release, things I'd like to do:

1. Real-world deployment
   Puppet Zaqar is ready. Ansible Zaqar role is on the way. So we need 
to get

the ansible work done ASAP,  and then interlock and provide more support for
potential cloud providers who have shown interest for Zaqar.

2. Notification service
   We got notification service alive since Liberty and fixed several 
bugs in

Mitaka. But we do still have things to do to make it fully functioning.
Such as subscription confirm and more drivers, etc.

2. Docs
   The config reference doc has been done in Mitaka which is an fantastic
milestone. And in Newton, I would like to complete API reference document
and admin guide for Zaqar.

4. Collaboration with other OpenStack projects
   We did a great job in Mitaka for the integration with Aodh, Mistral and
Tripleo. And I believe there are some other projects could be benefited by
Zaqar. For example, the notification middleware of Swift, Zaqar's websocket
transport for Searchlight/Horizon etc.

5. Encourage diversity in our Community
   We got some new members joined the team in Mitaka. And one of them 
has been

nominated as core reviewer who grew very fast. It's really awesome. In
Newton, I would like to encourage more people/organizations to join Zaqar
community.

It's a fantastic experience working with this amazing team and I know 
without
the dedication and hard work of everyone who has contributed to Zaqar we 
can't

make those success stories of Mitaka happen. I would be pleased to serve
as PTL for another cycle and I'd appreciate your vote.

Thanks for your consideration!

Election patch is here: https://review.openstack.org/#/c/293196 



--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

__
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] [glance] Bug when running Tempest on IPv6 network

[Emilien Macchi]

On Tue, Mar 15, 2016 at 9:28 PM, Nikhil Komawar  wrote:
> Hi Emilien ,
>
> Thanks for bringing this up! It appears that you've hit one of those
> weird ones that have a workaround in Glance. This is what you are
> looking for:
> https://github.com/openstack/glance/blob/master/glance/cmd/__init__.py#L32
>
> Hope it helps.

This patch should help: https://review.openstack.org/293195

>
> On 3/15/16 9:06 PM, Emilien Macchi wrote:
>> Puppet OpenStack team is currently working on deploying the our CI on
>> IPv6 networks.
>> Tempest fails on Glance, please look
>> https://bugs.launchpad.net/glance/+bug/1557814
>>
>> Please let me know any feedback on this,
>>
>> Thanks!
>
> --
>
> Thanks,
> Nikhil
>



-- 
Emilien Macchi

__
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] [glance] Bug when running Tempest on IPv6 network

[Nikhil Komawar]

Hi Emilien ,

Thanks for bringing this up! It appears that you've hit one of those
weird ones that have a workaround in Glance. This is what you are
looking for:
https://github.com/openstack/glance/blob/master/glance/cmd/__init__.py#L32

Hope it helps.

On 3/15/16 9:06 PM, Emilien Macchi wrote:
> Puppet OpenStack team is currently working on deploying the our CI on
> IPv6 networks.
> Tempest fails on Glance, please look
> https://bugs.launchpad.net/glance/+bug/1557814
>
> Please let me know any feedback on this,
>
> Thanks!

-- 

Thanks,
Nikhil


__
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] [magnum] Discussion of supporting single/multiple OS distro

[Kai Qiang Wu]

Hi  Stdake,

There is a patch about Atomic 23 support in Magnum.  And atomic 23 uses
kubernetes 1.0.6, and docker 1.9.1.
>From Steve Gordon, I learnt they did have a two-weekly release. To me it
seems each atomic 23 release not much difference, (minor change)
The major rebases/updates may still have to wait for e.g. Fedora Atomic 24.

So maybe we not need to test every Atomic 23 two-weekly.
Pick one or update old, when we find it is integrated with new kubernetes
or docker, etcd etc. If other small changes(not include security), seems
not need to update so frequently, it can save some efforts.


What do you think ?

Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   16/03/2016 03:23 am
Subject:Re: [openstack-dev] [magnum] Discussion of supporting
single/multiple OS distro



WFM as long as we stick to the spirit of the proposal and don't end up in a
situation where there is only one distribution.  Others in the thread had
indicated there would be only one distribution in tree, which I'd find
disturbing for reasons already described on this thread.

While we are about it, we should move to the latest version of atomic and
chase atomic every two weeks on their release.  Thoughts?

Regards
-steve


From: Hongbin Lu 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Monday, March 14, 2016 at 8:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [magnum] Discussion of supporting
single/multiple OS distro



From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: March-14-16 4:49 PM
To: OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [magnum] Discussion of supporting
single/multiple OS distro

Steve,

I think you may have misunderstood our intent here. We are not
seeking to lock in to a single OS vendor. Each COE driver can
have a different OS. We can have multiple drivers per COE. The
point is that drivers should be simple, and therefore should
support one Bay node OS each. That would mean taking what we
have today in our Kubernetes Bay type implementation and
breaking it down into two drivers: one for CoreOS and another
for Fedora/Atomic. New drivers would start out in a contrib
directory where complete functional testing would not be
required. In order to graduate one out of contrib and into the
realm of support of the Magnum dev team, it would need to have
a full set of tests, and someone actively maintaining it.
  OK. It sounds like the proposal allows more than one OS to be
  in-tree, as long as the second OS goes through an incubation process.
  If that is what you mean, it sounds reasonable to me.

Multi-personality driers would be relatively complex. That
approach would slow down COE specific feature development, and
complicate maintenance that is needed as new versions of the
dependency chain are bundled in (docker, k8s, etcd, etc.). We
have all agreed that having integration points that allow for
alternate OS selection is still our direction. This follows the
pattern that we set previously when deciding what networking
options to support. We will have one that’s included as a
default, and a way to plug in alternates.

Here is what I expect to see when COE drivers are implemented:

Docker Swarm:
Default driver Fedora/Atomic
Alternate driver: TBD

Kubernetes:
Default driver Fedora/Atomic
Alternate driver: CoreOS

Apache Mesos/Marathon:
Default driver: Ubuntu
Alternate driver: TBD

We can allow an arbitrary number of alternates. Those TBD items
can be initially added to the contrib directory, and with the
right level of community support can be advanced to defaults if
shown to work better, be more straightforward to maintain, be
more secure, or 

Re: [openstack-dev] [magnum-ui] Proposed Core addition, and removal notice

[Shuu Mutou]

Hi peers, 

Thank you for the appointment to core!!
I'm honored to working with my peers.
I'll do my best as core and i18n liaison.

Since I received previous mail after going home, 
I'm sorry for absence in last meeting.

Best regards, 

Shu Muto


__
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] [glance] Bug when running Tempest on IPv6 network

[Emilien Macchi]

Puppet OpenStack team is currently working on deploying the our CI on
IPv6 networks.
Tempest fails on Glance, please look
https://bugs.launchpad.net/glance/+bug/1557814

Please let me know any feedback on this,

Thanks!
-- 
Emilien Macchi

__
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] [Third-Party][CI] Modify CI accouts in CI group

[Anita Kuno]

On 03/15/2016 07:58 PM, Watanabe, Isao wrote:
> Hello, Anita
> 
> Thank you for your help.

You're welcome.

> 
> About the CC: syntax, it is the same as you assumed in last mail, that I am 
> using it.
> Sorry if I have confused you.

No confusion, I just wanted to ensure you understood the function, and
you do.

> 
> And also thank you for telling me about the gerrit usage.

You're welcome.

Thanks,
Anita.

> 
> Best regards,
> Watanabe.isao
> 
> 
>> -Original Message-
>> From: Anita Kuno [mailto:ante...@anteaya.info]
>> Sent: Wednesday, March 16, 2016 2:10 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Third-Party][CI] Modify CI accouts
>> in CI group
>>
>> On 03/14/2016 10:23 PM, Watanabe, Isao wrote:
>>> To: Anita
>>> Cc: Third-Party Coordinators
>>
>> Just so you know, putting cc: in the body of an email as content doesn't 
>> email
>> specific people. I assume you are using this syntax to state that while you
>> are addressing me directly you also include other third-party coordinators
>> as well.
>>
>>>
>>> Thank you for the help.
>>> I have created the missed account.
>>> Could you please help me to submit the account again?
 [1]Add account
 Name: Fujitsu ISM CI
 Mail: fj-lsoft-is...@dl.jp.fujitsu.com
>>
>> This account has been added to the Third-Party CI gerrit group.
>>
>>>
>>> About the disabled accounts.
>>> Thank you for the kindly inform about the gerrit account id.
>>> The following accounts are not going to be reused.
>>> - Fujitsu ETERNUS FC CI <==account has just been deleted
>>
>> Well actually we can never delete a gerrit account, we can't really delete
>> anything much in gerrit. That is sort of the point of using the tool. This
>> account has been deactivated. It does however still exist in an inactive
>> state.
>>
>>> - Fujitsu IRMC CI <==account not exists So, if there is any way to
>>> remove them, to keep  clear, feel free to delete them
>> at any time, please.
>>
>> I don't think it hurts anything to keep them listed in the Third-Party CI
>> gerrit group just in case something were to happen and they pop up again.
>> I'll leave them listed.
>>
>> Thank you for helping me to understand what you want and to get your accounts
>> in the gerrit group.
>>
>> Thank you,
>> Anita.
>>
>>
>>>
>>> Best regards,
>>> Watanabe.isao
>>>
>>>
>>>
 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Monday, March 14, 2016 11:57 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Third-Party][CI] Modify CI
 accouts in CI group

 On 03/14/2016 04:39 AM, Watanabe, Isao wrote:
> Hello, Third-Party Coordinators
> Cc：Ramy
>
> Could you please help me about the following CI accounts changes in CI
>> group?
>
> [1]Add account
> Name: Fujitsu ISM CI
> Mail: fj-lsoft-is...@dl.jp.fujitsu.com

 You need to create this account before it can be added to the
 Third-Party CI gerrit group. Gerrit doesn't know about this account yet.
 http://docs.openstack.org/infra/system-config/third_party.html#creati
 ng-
 a-service-account

>
> [2]Modify
> Name: Fujitsu ETERNUS CI
> OLD-Email: lsoft-eternu...@ml.css.fujitsu.com
> NEW-Email: fj-lsoft-eternu...@dl.jp.fujitsu.com

 If you created the gerrit account yourself, you can modify the email
>> yourself.
 In settings > Contact Information select the button Register New
 Email. Then add the new email of choice.

 If infra created the account for you, please follow the instructions
 here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount

 I have taken no action on this request, as I have none to take.

>
> [3] Modify
> OLD-Name: Fujitsu IRMC CI
> NEW-Name: Fujitsu iRMC CI
> OLD-Email: lsoft-irm...@ml.css.fujitsu.com
> NEW-Email: fj-lsoft-irm...@dl.jp.fujitsu.com

 I have added "Fujitsu iRMC CI" to the gerrit Third-Party CI gerrit group.

>
> [4] Modify
> Name: Fujitsu C-Fabric CI
> OLD-Email: lsoft-cfabri...@ml.css.fujitsu.com
> NEW-Email: fj-lsoft-cfabri...@dl.jp.fujitsu.com

 If you created the gerrit account yourself, you can modify the email
>> yourself.
 In settings > Contact Information select the button Register New
 Email. Then add the new email of choice.

 If infra created the account for you, please follow the instructions
 here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount

 I have taken no action on this request, as I have none to take.

>
> [5] Delete
> Name: Fujitsu ETERNUS FC CI
> Email: lsoft-openstac...@ml.css.fujitsu.com

 This account has been disabled by the infra team in gerrit. If you
 want it to be used again, you must contact a member of the infra team
 to have it set to active. The gerrit account id for this account is 19917.

 Thank you,
 

Re: [openstack-dev] [tripleo] rabbitmq / ipv6 issue

[Emilien Macchi]

Both Pull-requests got merged upstream (kudos to Puppetlabs).

I rebased https://review.openstack.org/#/c/289445/ on master and
abandoned the pin. Let's see how CI works now.
If it still does not work, feel free to restore the pin and rebase
again on the pin, so we can make progress.

On Tue, Mar 15, 2016 at 6:21 PM, Emilien Macchi  wrote:
> So this is an attempt to fix everything in Puppet modules:
>
> * https://github.com/puppetlabs/puppetlabs-stdlib/pull/577
> * https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/443
>
> If we have the patches like this, there will be no need to patch TripleO.
>
> Please review the patches if needed,
> Thanks
>
> On Tue, Mar 15, 2016 at 1:57 PM, Emilien Macchi  wrote:
>> So from now, we pin [5] puppetlabs-rabbitmq to the commit before [3]
>> and I rebased Attila's patch to test CI again.
>> This pin is a workaround, in the meantime we are working on a fix in
>> puppetlabs-rabbitmq.
>>
>> [5] https://review.openstack.org/293074
>>
>> I also reported the issue in TripleO Launchpad:
>> https://bugs.launchpad.net/tripleo/+bug/1557680
>>
>> Also a quick note:
>> Puppet OpenStack CI did not detect this failure because we don't
>> deploy puppetlabs-rabbitmq from master but from the latest release
>> (tag).
>>
>> On Tue, Mar 15, 2016 at 1:17 PM, Emilien Macchi  wrote:
>>> TL;DR;This e-mail tracks down the work done to make RabbitMQ working
>>> on IPv6 deployments.
>>> It's currently broken and we might need to patch different Puppet
>>> modules to make it work.
>>>
>>> Long story:
>>>
>>> Attila Darazs is currently working on [1] to get IPv6 tested by
>>> TripleO CI but is stuck because a RabbitMQ issue in Puppet catalog
>>> [2], reported by Dan Sneddon.
>>> [1] https://review.openstack.org/#/c/289445
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1317693
>>>
>>> [2] is caused by a patch in puppetlabs-rabbitmq [3], that change the
>>> way we validate RabbitMQ is working from testing localhost to testing
>>> the actual binding IP.
>>> [3] 
>>> https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/dac8de9d95c5771b7ef7596b73a59d4108138e3a
>>>
>>> The problem is that when testing the actual IPv6, it curls fails for
>>> some different reasons explained on [4] by Sofer.
>>> [4] https://review.openstack.org/#/c/292664/
>>>
>>> So we need to investigate puppetlabs-rabbitmq and puppet-staging to
>>> see if whether or not we need to change something there.
>>> For now, I don't think we need to patch anything in TripleO Heat
>>> Templates, but we'll see after the investigation.
>>>
>>> I'm currently working on this task, but any help is welcome,
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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] [Third-Party][CI] Modify CI accouts in CI group

[Watanabe, Isao]

Hello, Anita

Thank you for your help.

About the CC: syntax, it is the same as you assumed in last mail, that I am 
using it.
Sorry if I have confused you.

And also thank you for telling me about the gerrit usage.

Best regards,
Watanabe.isao


> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info]
> Sent: Wednesday, March 16, 2016 2:10 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Third-Party][CI] Modify CI accouts
> in CI group
> 
> On 03/14/2016 10:23 PM, Watanabe, Isao wrote:
> > To: Anita
> > Cc: Third-Party Coordinators
> 
> Just so you know, putting cc: in the body of an email as content doesn't email
> specific people. I assume you are using this syntax to state that while you
> are addressing me directly you also include other third-party coordinators
> as well.
> 
> >
> > Thank you for the help.
> > I have created the missed account.
> > Could you please help me to submit the account again?
> >> [1]Add account
> >> Name: Fujitsu ISM CI
> >> Mail: fj-lsoft-is...@dl.jp.fujitsu.com
> 
> This account has been added to the Third-Party CI gerrit group.
> 
> >
> > About the disabled accounts.
> > Thank you for the kindly inform about the gerrit account id.
> > The following accounts are not going to be reused.
> > - Fujitsu ETERNUS FC CI <==account has just been deleted
> 
> Well actually we can never delete a gerrit account, we can't really delete
> anything much in gerrit. That is sort of the point of using the tool. This
> account has been deactivated. It does however still exist in an inactive
> state.
> 
> > - Fujitsu IRMC CI <==account not exists So, if there is any way to
> > remove them, to keep  clear, feel free to delete them
> at any time, please.
> 
> I don't think it hurts anything to keep them listed in the Third-Party CI
> gerrit group just in case something were to happen and they pop up again.
> I'll leave them listed.
> 
> Thank you for helping me to understand what you want and to get your accounts
> in the gerrit group.
> 
> Thank you,
> Anita.
> 
> 
> >
> > Best regards,
> > Watanabe.isao
> >
> >
> >
> >> -Original Message-
> >> From: Anita Kuno [mailto:ante...@anteaya.info]
> >> Sent: Monday, March 14, 2016 11:57 PM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [Third-Party][CI] Modify CI
> >> accouts in CI group
> >>
> >> On 03/14/2016 04:39 AM, Watanabe, Isao wrote:
> >>> Hello, Third-Party Coordinators
> >>> Cc：Ramy
> >>>
> >>> Could you please help me about the following CI accounts changes in CI
> group?
> >>>
> >>> [1]Add account
> >>> Name: Fujitsu ISM CI
> >>> Mail: fj-lsoft-is...@dl.jp.fujitsu.com
> >>
> >> You need to create this account before it can be added to the
> >> Third-Party CI gerrit group. Gerrit doesn't know about this account yet.
> >> http://docs.openstack.org/infra/system-config/third_party.html#creati
> >> ng-
> >> a-service-account
> >>
> >>>
> >>> [2]Modify
> >>> Name: Fujitsu ETERNUS CI
> >>> OLD-Email: lsoft-eternu...@ml.css.fujitsu.com
> >>> NEW-Email: fj-lsoft-eternu...@dl.jp.fujitsu.com
> >>
> >> If you created the gerrit account yourself, you can modify the email
> yourself.
> >> In settings > Contact Information select the button Register New
> >> Email. Then add the new email of choice.
> >>
> >> If infra created the account for you, please follow the instructions
> >> here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount
> >>
> >> I have taken no action on this request, as I have none to take.
> >>
> >>>
> >>> [3] Modify
> >>> OLD-Name: Fujitsu IRMC CI
> >>> NEW-Name: Fujitsu iRMC CI
> >>> OLD-Email: lsoft-irm...@ml.css.fujitsu.com
> >>> NEW-Email: fj-lsoft-irm...@dl.jp.fujitsu.com
> >>
> >> I have added "Fujitsu iRMC CI" to the gerrit Third-Party CI gerrit group.
> >>
> >>>
> >>> [4] Modify
> >>> Name: Fujitsu C-Fabric CI
> >>> OLD-Email: lsoft-cfabri...@ml.css.fujitsu.com
> >>> NEW-Email: fj-lsoft-cfabri...@dl.jp.fujitsu.com
> >>
> >> If you created the gerrit account yourself, you can modify the email
> yourself.
> >> In settings > Contact Information select the button Register New
> >> Email. Then add the new email of choice.
> >>
> >> If infra created the account for you, please follow the instructions
> >> here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount
> >>
> >> I have taken no action on this request, as I have none to take.
> >>
> >>>
> >>> [5] Delete
> >>> Name: Fujitsu ETERNUS FC CI
> >>> Email: lsoft-openstac...@ml.css.fujitsu.com
> >>
> >> This account has been disabled by the infra team in gerrit. If you
> >> want it to be used again, you must contact a member of the infra team
> >> to have it set to active. The gerrit account id for this account is 19917.
> >>
> >> Thank you,
> >> Anita.
> >>
> >>>
> >>>
> >>> Best regards,
> >>> Watanabe.isao
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> __  OpenStack Development Mailing List (not for usage questions)
> 

[openstack-dev] [sahara] PTL non-candidacy

[Sergey Lukjanov]

Hi folks,

the PTL self-nomination period is opened and I want to note that I won’t be
running again as the Data Processing PTL. I’ve been the Sahara PTL from the
beginning of the project (oh, already more then 3 years) and I’m very proud
of the things we’ve achieved over this time. The project community grown
from a few people working not always in open source way to the successfully
incubated and then integrated OpenStack project.

The main reason I’m stepping down is that I have another inter-company
priorities and don’t have enough time to continue being the good PTL.
Another reason - I've started thinking that it’s a healthy flow to change
PTLs each cycle and I’m going to propose this approach on the upcoming
summit for Sahara community.

I’m not planning to fully leave project, I’d like to keep reviewing
(especially specs) and helping with release management, so, I’ll be around
and will help the next PTLs make a transitions where it’ll be needed.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] PTL for Newton and beyond

[Vilobh Meshram]

Thanks for all the hard work Dims!

On Wed, Mar 9, 2016 at 3:06 AM, Ivan Kolodyazhny  wrote:

> Thanks for your hard work, Dims!
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Fri, Mar 4, 2016 at 3:34 PM, Mehdi Abaakouk  wrote:
>
>> Hi,
>>
>> Thanks for all the great work you have done, I have appreciated your
>> leadership on Oslo,
>> and a special thanks to bring in new people in oslo.messaging ;)
>>
>>
>> Le 2016-03-03 11:32, Davanum Srinivas a écrit :
>>
>>> Team,
>>>
>>> It has been great working with you all as PTL for Oslo. Looks like the
>>> nominations open up next week for elections and am hoping more than
>>> one of you will step up for the next cycle(s). I can show you the
>>> ropes and help smoothen the transition process if you let me know
>>> about your interest in being the next PTL. With the move to more
>>> automated testing in our CI (periodic jobs running against oslo.*
>>> master) and the adoption of the release process (logging reviews in
>>> /releases repo) the load should be considerably less on you.
>>> especially proud of all the new people joining as both oslo cores and
>>> project cores and hitting the ground running. Big shout out to Doug
>>> Hellmann for his help and guidance when i transitioned into the PTL
>>> role.
>>>
>>> Main challenges will be to get back confidence of all the projects
>>> that use the oslo libraries, NOT be the first thing they look for when
>>> things break (Better backward compat, better test matrix) and
>>> evangelizing that Oslo is still the common play ground for *all*
>>> projects and not just the headache of some nut jobs who are willing to
>>> take up the impossible task of defining and nurturing these libraries.
>>> There's a lot of great work ahead of us and i am looking forward to
>>> continue to work with you all.
>>>
>>> Thanks,
>>> Dims
>>>
>>
>> --
>> Mehdi Abaakouk
>> mail: sil...@sileht.net
>> irc: sileht
>>
>>
>> __
>> 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] [tc] Question about electorate for project without gerrit contribution

[Thomas Goirand]

On 03/15/2016 11:18 PM, Emilien Macchi wrote:
> Whoever will be the PTL, my single hope is that one day people will
> deploy OpenStack in production by using packaging built in OpenStack
> Infra.

+1

Thanks for your support. I don't really care having a PTL badge either.
I care for this project to get going.

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] [tripleo] rabbitmq / ipv6 issue

[Emilien Macchi]

So this is an attempt to fix everything in Puppet modules:

* https://github.com/puppetlabs/puppetlabs-stdlib/pull/577
* https://github.com/puppetlabs/puppetlabs-rabbitmq/pull/443

If we have the patches like this, there will be no need to patch TripleO.

Please review the patches if needed,
Thanks

On Tue, Mar 15, 2016 at 1:57 PM, Emilien Macchi  wrote:
> So from now, we pin [5] puppetlabs-rabbitmq to the commit before [3]
> and I rebased Attila's patch to test CI again.
> This pin is a workaround, in the meantime we are working on a fix in
> puppetlabs-rabbitmq.
>
> [5] https://review.openstack.org/293074
>
> I also reported the issue in TripleO Launchpad:
> https://bugs.launchpad.net/tripleo/+bug/1557680
>
> Also a quick note:
> Puppet OpenStack CI did not detect this failure because we don't
> deploy puppetlabs-rabbitmq from master but from the latest release
> (tag).
>
> On Tue, Mar 15, 2016 at 1:17 PM, Emilien Macchi  wrote:
>> TL;DR;This e-mail tracks down the work done to make RabbitMQ working
>> on IPv6 deployments.
>> It's currently broken and we might need to patch different Puppet
>> modules to make it work.
>>
>> Long story:
>>
>> Attila Darazs is currently working on [1] to get IPv6 tested by
>> TripleO CI but is stuck because a RabbitMQ issue in Puppet catalog
>> [2], reported by Dan Sneddon.
>> [1] https://review.openstack.org/#/c/289445
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1317693
>>
>> [2] is caused by a patch in puppetlabs-rabbitmq [3], that change the
>> way we validate RabbitMQ is working from testing localhost to testing
>> the actual binding IP.
>> [3] 
>> https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/dac8de9d95c5771b7ef7596b73a59d4108138e3a
>>
>> The problem is that when testing the actual IPv6, it curls fails for
>> some different reasons explained on [4] by Sofer.
>> [4] https://review.openstack.org/#/c/292664/
>>
>> So we need to investigate puppetlabs-rabbitmq and puppet-staging to
>> see if whether or not we need to change something there.
>> For now, I don't think we need to patch anything in TripleO Heat
>> Templates, but we'll see after the investigation.
>>
>> I'm currently working on this task, but any help is welcome,
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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] Question about electorate for project without gerrit contribution

[Emilien Macchi]

On Tue, Mar 15, 2016 at 5:58 PM, Thomas Goirand  wrote:

[...]

> The Fuel team, many occasional Debian contributors, the Kolla team, the
> Puppet OpenStack team, and of course myself, all want this project to
> get started on good tracks. It will happen, because of this need. Please
> give it more time.

I confirm the desire of seeing upstream packaging moving to OpenStack,
and so far Thomas efforts have been heroic to build so much packages
in Debian, and try to move it in OpenStack Infrastructure.

In Puppet OpenStack CI, we have been using Canonical UCA packaging
that is not close to what provides OpenStackt trunk, and has lower
testing coverage. It's breaking our CI quite often, even if Ubuntu
folks are very responsive and helpful with us (kudos to jamespage &
coreycb); I hope one day we'll have packaging tested & hosted by
OpenStack Infra, for both Debian & Fedora worlds.

Whoever will be the PTL, my single hope is that one day people will
deploy OpenStack in production by using packaging built in OpenStack
Infra.
-- 
Emilien Macchi

__
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] Question about electorate for project without gerrit contribution

[Thomas Goirand]

On 03/15/2016 09:35 PM, Hayes, Graham wrote:
> On 15/03/2016 20:29, Thomas Goirand wrote:
> Does the current PTL not have the ability to propose extra-atc's for
> this reason?
> 
> Would a solution be for zigo to propose the people active in
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
> to the governance repo (including himself) and the TC approve it.
> 
> This would give an electorate, and give Zigo the right to run as PTL.

Just for the record, it's not only this repo, but all the 359
(currently, and counting...) Git repositories of:
http://anonscm.debian.org/cgit/openstack/

this one came out only because it's the only one I tried to push on
upstream infra. I didn't care pushing more packaging Git repositories
until we have a way to build packages, which is currently not the case.

BTW, I'd like to come back to the history of this project. A year ago, I
just wanted to start things on stackforge. Then, during the Vancouver
summit, I was pushed by many to enter the big tent. Which very painfully
happened, after a lot of convolutions: it was finally approved in the
middle of August, when I thought it would take a week or 2. This
postponed getting the deb-openstack-pkg-tools project-config patch
approved until nearly the Tokyo summit. Then the DIB patch to get a
Debian image is on its way to take more than 3 months, while it probably
doesn't need to take that much and be so perfect.

I understand that it took so long probably due to my own shortcomings,
and lack of follow-up on each of the above steps. I admit that I was a
bit lost, and didn't know what I could do.

The difficulties faced to bootstrap this project are very far from the
packaging skills that we want to deploy on OpenStack infra, which could
explain why I got lost and unfocused (dragged on doing the actual
packaging into the official Debian distro also).

It is my hope that this thread wont start another layer of bureaucratic
obstacles which I will have difficulties to deal with again.

The Fuel team, many occasional Debian contributors, the Kolla team, the
Puppet OpenStack team, and of course myself, all want this project to
get started on good tracks. It will happen, because of this need. Please
give it more time.

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] [tc] Question about electorate for project without gerrit contribution

[Hayes, Graham]

On 15/03/2016 21:09, Tony Breeds wrote:
> On Tue, Mar 15, 2016 at 08:35:23PM +, Hayes, Graham wrote:
>
>> Does the current PTL not have the ability to propose extra-atc's for
>> this reason?
>>
>> Would a solution be for zigo to propose the people active in
>> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
>> to the governance repo (including himself) and the TC approve it.
>
> What you say is essentially correct, but the time for such proposals has
> passed.  The electorate has been defined.
>
> Anita has provided links to the relevant documentation.
>
> Yours Tony.
>

I do not see the time frame for defining an electorate there.

PTL seats are completely renewed every 6 months. A separate election is 
run for
each project team. These elections are collectively held 5 weeks prior 
to each
design summit, with nominations due 6 weeks prior to the summit and 
elections
held open for no less than five business days.

The way the rules are currently worded if the extra ATC patch merged
before the deadline for PTL nomination anyone in that patch would be 
able to run.

Where do we define the cut off date for electorate definition?


- Graham

__
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] [kolla] [infra] Size of images built in the gate

[Steven Dake (stdake)]

Overlayfs is definitely faster, especially at deploy from a registry.

Regards,
-steve

From: Sam Yaple >
Reply-To: "s...@yaple.net" 
>, "OpenStack Development Mailing List 
(not for usage questions)" 
>
Date: Tuesday, March 15, 2016 at 9:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] [infra] Size of images built in the gate

Steve,

overlayfs does not reduce the disk usage at all

Paul, we can bump the size of the docker mountpoint up to ~20GB if you check 
all the gates for the appropriate space.

Sam Yaple

On Mon, Mar 14, 2016 at 7:20 PM, Steven Dake (stdake) 
> wrote:
Vikarm,

/var/lib/docker is a btrfs filesystem.  It would be nice to just use overlayfs 
as it doesn't take nearly as much disk space and is much faster then btrfs.  I 
use overlay daily and it works like a champ unless I want to rebuild, in which 
case I think a bug in the ovl yum plugin prevents rebuilding if an image 
already exists.

https://github.com/openstack/kolla/blob/master/tools/setup_RedHat.sh#L13

Regards,
-steve


From: "Vikram Hosakote (vhosakot)" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 14, 2016 at 11:51 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] [infra] Size of images built in the gate

/var/lib/docker/aufs  takes a lot of space if many containers are running and
writing data to their volumes.

If the gate VM's  /var/lib/docker  partition is small, you could move
/var/lib/docker  to a different partition that is big enough (like /home or 
/tmp)
and create a symbolic link to  /var/lib/docker.

mv  /var/lib/docker  /home/new_docker_path_with_more_space
ln -s  /home/new_docker_path_with_more_space  /var/lib/docker

Alternatively, you can use the -g option for the docker daemon to use a 
different
path instead of  /var/lib/docker  if it runs out of disk space.

DOCKER_OPTS="-g /home/new_docker_path_with_more_space"

Restart the docker daemon after making the above change.

https://github.com/docker/docker/issues/3127

Regards,
Vikram Hosakote
IRC: vhosakot

From: Paul Bourke >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 14, 2016 at 11:25 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] [infra] Size of images built in the gate

Hi all,

I'm currently working to add new gates for the oraclelinux image base
type (https://blueprints.launchpad.net/kolla/+spec/oraclelinux-gate) and
had a question on size available in the gate VMs.

Right now the binary build is running out of space in the gate, as it
exceeds the 10GB we're allocating for /var/lib/docker. For me, a current
local build using binary+oraclelinux is clocking in at 10.01GB, where as
the centos+binary is a little smaller at 8.89GB.

Is it written anywhere exactly what space is available in the gate VMs?
Sam mentioned briefly that different providers used in the gate give a
variety of disk sizes, so do we have an idea what we can reasonably bump
the docker partition to?

The above number indicates centos will likely soon run into the same
problem as we dockerise more of the big tent, so I think it's a good
idea to check this now before more gates start falling over.

Thanks,
-Paul

p.s. if people are interested here's lists sorted by name of the
oraclelinux and centos builds:

oraclelinux: http://paste.fedoraproject.org/339672/96915914
centos: http://paste.fedoraproject.org/339673/57969163

__
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] Question about electorate for project without gerrit contribution

[Tony Breeds]

On Tue, Mar 15, 2016 at 08:35:23PM +, Hayes, Graham wrote:

> Does the current PTL not have the ability to propose extra-atc's for
> this reason?
> 
> Would a solution be for zigo to propose the people active in
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
> to the governance repo (including himself) and the TC approve it.

What you say is essentially correct, but the time for such proposals has
passed.  The electorate has been defined.

Anita has provided links to the relevant documentation.

Yours Tony.


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] [all][oslo] config generator default overrides and namespaces

[Doug Hellmann]

Excerpts from Michael Krotscheck's message of 2016-03-14 14:31:37 +:
> On Mon, Mar 14, 2016 at 7:29 AM Markus Zoeller  wrote:
> 
> >
> > Thanks Doug and Robert for catching this and providing the fixes!
> >
> > Regarding potential backports: Do you have information if this is
> > something which came up in a specific version in "oslo.config"?
> >
> 
> Oslo config's default overrides were introduced in 3.7.0. Most of the
> patches that apply this for CORS have been introduced and landed in the
> last 2 weeks, and I haven't seen anyone else making use of it yet.
> 
> Long story short: It's a mitaka thing.

Yes, that's right. You don't need to backport any fixes related to this
problem, all of the work was done during Mitaka.

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] [tc] Question about electorate for project without gerrit contribution

[Tony Breeds]

On Tue, Mar 15, 2016 at 09:25:47PM +0100, Thomas Goirand wrote:
> On 03/15/2016 08:22 PM, Tony Breeds wrote:
> > However, at the risk of sounding like a humorless automaton, we have a valid
> > candidate.
> >  * Monty Taylor for Packaging-Deb PTL 
> > https://review.openstack.org/#/c/292690/
> 
> This started as a joke. Please don't pick-up the joke, and make it a
> serious proposal. This isn't funny anymore.

I did acknowledge that it is/was a joke.

> Obviously, Monty isn't interested (otherwise, he would have help with
> https://review.openstack.org/#/c/264726/, which he didn't despite his
> generous offer to do so in Tokyo but he had other priorities).
> 
> Also again, please have a look at the openstack-pkg-tools Git history here:
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
> 
> There's at least 3 commits a week on this repository.
> 
> Now, compare this to the single commit to add a .gitreview file from Monty:
> https://github.com/openstack/deb-openstack-pkg-tools/commits/debian/liberty
> 
> That's also a commit on the Liberty branch, and we've switched to
> debian/mitaka a long time ago.
> 
> > Also by the rules I feel like we have no choice but to reject
> >  * Adding Packaging-Deb/Thomas_Goirand.txt
> https://review.openstack.org/#/c/292885/
> 
> I know we have established governance rules. They exist for a reason.
> Though I hope everyone understand what happened after my explanation.
> 
> I believe what you wanted to write is:
> 
> "If we don't think first and follow the rules without even trying to
> understand, we *WOULD* reject. But we are humans with brains, not
> machines, therefore, it's ok"

Please do not put words in my mouth.  I wrote what I intended to say.

> Because *you do* have a choice, don't you?

I, as an election official, can not choose to make exceptions on a project by
project basis.  I am acting within my understood parameters.  The election
officials saw a problem and raised it with the TC/community.  If the
established process is allowed to play out I think the result will be
reasonable.

Yours Tony.


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] [nova] Wishlist bugs == (trivial) blueprint?

[Sean Dague]

On 03/15/2016 04:09 PM, melanie witt wrote:
> On Mar 15, 2016, at 10:59, Tim Bell  wrote:
> 
>> The risk I see is that we are missing input to the development process in 
>> view of the complexity of submitting those requirements. Clearly, setting 
>> the bar too low means that there is no clear requirement statement etc. 
>> However, I think the combination of tools and assumption of knowledge of the 
>> process means that we are missing the opportunity for good quality input.
>>
>> Many of these are low hanging fruit improvements which could be used to 
>> bring developers into the community if we can find a good way to get the 
>> input and match it with the resource to implement.
> 
> Agreed. I think Wishlist bugs have had value but I'll admit the value is 
> small compared to the total number of Wishlist bugs.
> 
> The thing I like about them is that they're easy for anyone to open and 
> people can pile on and say "me too" so we get some indication of how much 
> interest there is in a feature/idea (the launchpad bug heat increases). I 
> have seen this work well in a couple of cases where I don't think we could 
> have found out people were interested in something otherwise.
> 
> Digging up examples:
> 
> * Several novaclient users would like it if tenant ids were validated against 
> keystone [1] (Look how many duplicates and the bug heat!). It has since 
> evolved into a spec [2] and blueprint [3]. I didn't think this would be as 
> popular as it is, but I know it from the number of bugs people have opened 
> that I have marked as duplicates of a Wishlist bug.
> 
> * Several nova users are interested in the capability to detach the root 
> device volume of an instance, when in shutoff state [4]. This one, I had no 
> idea about until I saw the bug.
> 
> 
> I think the spec process is heavy for a person who just wants to communicate 
> a feature ask and it requires that other people be able to find that spec to 
> +1 it before it potentially goes into the abandoned state once spec freeze 
> happens. I can't imagine users finding a spec being that they're not 
> searchable. I feel like you have to "be in the know" to vote on a spec. With 
> the Wishlist bugs, users can search to find things they're interested in and 
> add comments. Triagers can see duplicates and mark them as such, which 
> bubbles up popular asks via bug heat. It's a lot of manual work, though.

I think this is the key issue.

It is so much manual and noise in most of the cases that it actually
slows down the fixing of real bugs. And burns out all the triagers.
Markus has been lasting in this role longer than most, so I want to
defer to his judgment about being able to stay in it and stay sane.

It's a trade off. Would you rather keep Wishlist mechanism and have ~30
extra bugs in every release, and have to hunt for a new bug lead twice
as often? That's my gut feel on the break down here.

To get the bug backlog under control, we have to make hard calls here.
This is one of them. Once we're working with < 400 open issues, deciding
to reopen the Wishlist mechanism is a thing we can and should revisit.

-Sean

-- 
Sean Dague
http://dague.net

__
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] Question about electorate for project without gerrit contribution

[Jeremy Stanley]

On 2016-03-15 21:25:47 +0100 (+0100), Thomas Goirand wrote:
[...]
> I know we have established governance rules. They exist for a reason.
> Though I hope everyone understand what happened after my explanation.
> 
> I believe what you wanted to write is:
> 
> "If we don't think first and follow the rules without even trying to
> understand, we *WOULD* reject. But we are humans with brains, not
> machines, therefore, it's ok"
> 
> Because *you do* have a choice, don't you?

Strict process for elections is crucial, to avoid any impression of
impropriety or vote fixing which could invalidate the results.
Election officials aren't really at liberty to loosely interpret the
process; as volunteers their task is to ensure the established
process is followed and applied accurately and consistently. This
process defines another elected body which can rule on inconclusive
cases: the Technical Committee.
-- 
Jeremy Stanley

__
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] [designate] PTL Candidacy

[Hayes, Graham]

Hi All!

I am proposing myself for PTL of the Designate project.

In the last 6 months we have had a smaller amount of changes into
the project, but this has not necessarily been a bad thing for us.

We have stabilized some of the changes that have been filtering through
over the last year or so, and have this cycle had a chance to evaluate
what we have completed, and what needs to change.

I think we now have a solid base to add new features for end users
(like ALIAS) and operators (MiniDNS simplification + possible replacement
in a sane language, IXFR).

As we progress we will need to get more integrated into the community,
like we have with Nova, Neutron and Designate integration that has merged
this cycle. We should build on this to add content to the shared Docs,
API reference site and other projects.

Next cycle we need to focus on 3 items:

1.  Docs. Docs. Docs.

 We have gotten better at writing docs, and the addition of reno has
 helped our release notes a lot, but there is always room for
 improvement. We need to ensure that we also remove old docs at the
 same time as writing new ones.

2.  Worker Model.

 Migration to the worker model improves a lot of our scaling story.
 It allows use to remove the extra code that went into MiniDNS and
 remove RPC from MiniDNS entirely.
 This in turn makes MiniDNS much more re implementable in a language
 that is more suited to parsing and building DNS packets.

3.  Horizon Updates (Read: replacement)

 Our horizon panels are ... dated, use the deprecated API, and lack
 most of the new features that we have added to designate. Part of
 our time in newton needs to be getting these panels updated, and
 availible to the community.

I see myself as a good person to lead these 3 priorities, and appreciate 
your
support for PTL.

Thanks,

Graham Hayes

Election Repo Commit - https://review.openstack.org/#/c/292385/

__
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] Question about electorate for project without gerrit contribution

[Anita Kuno]

On 03/15/2016 04:25 PM, Thomas Goirand wrote:
> On 03/15/2016 08:22 PM, Tony Breeds wrote:
>> However, at the risk of sounding like a humorless automaton, we have a valid
>> candidate.
>>  * Monty Taylor for Packaging-Deb PTL 
>> https://review.openstack.org/#/c/292690/
> 
> This started as a joke. Please don't pick-up the joke, and make it a
> serious proposal. This isn't funny anymore.
> 
> Obviously, Monty isn't interested (otherwise, he would have help with
> https://review.openstack.org/#/c/264726/, which he didn't despite his
> generous offer to do so in Tokyo but he had other priorities).
> 
> Also again, please have a look at the openstack-pkg-tools Git history here:
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
> 
> There's at least 3 commits a week on this repository.
> 
> Now, compare this to the single commit to add a .gitreview file from Monty:
> https://github.com/openstack/deb-openstack-pkg-tools/commits/debian/liberty
> 
> That's also a commit on the Liberty branch, and we've switched to
> debian/mitaka a long time ago.
> 
>> Also by the rules I feel like we have no choice but to reject
>>  * Adding Packaging-Deb/Thomas_Goirand.txt
> https://review.openstack.org/#/c/292885/
> 
> I know we have established governance rules. They exist for a reason.
> Though I hope everyone understand what happened after my explanation.
> 
> I believe what you wanted to write is:
> 
> "If we don't think first and follow the rules without even trying to
> understand, we *WOULD* reject. But we are humans with brains, not
> machines, therefore, it's ok"
> 
> Because *you do* have a choice, don't you?

ATC definition is in the bylaws: section 3:
http://www.openstack.org/legal/technical-committee-member-policy/

Eligibility for PTL and the electorate is covered in the charter:
http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n106

And this resolution:
http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

Election officials administer elections according to the rules as outlined.

Thanks,
Anita.

> 
> 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 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] Question about electorate for project without gerrit contribution

[Hayes, Graham]

On 15/03/2016 20:29, Thomas Goirand wrote:
> On 03/15/2016 08:22 PM, Tony Breeds wrote:
>> However, at the risk of sounding like a humorless automaton, we have a valid
>> candidate.
>>   * Monty Taylor for Packaging-Deb PTL 
>> https://review.openstack.org/#/c/292690/
>
> This started as a joke. Please don't pick-up the joke, and make it a
> serious proposal. This isn't funny anymore.
>
> Obviously, Monty isn't interested (otherwise, he would have help with
> https://review.openstack.org/#/c/264726/, which he didn't despite his
> generous offer to do so in Tokyo but he had other priorities).
>
> Also again, please have a look at the openstack-pkg-tools Git history here:
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
>
> There's at least 3 commits a week on this repository.
>
> Now, compare this to the single commit to add a .gitreview file from Monty:
> https://github.com/openstack/deb-openstack-pkg-tools/commits/debian/liberty
>
> That's also a commit on the Liberty branch, and we've switched to
> debian/mitaka a long time ago.
>
>> Also by the rules I feel like we have no choice but to reject
>>   * Adding Packaging-Deb/Thomas_Goirand.txt
> https://review.openstack.org/#/c/292885/
>
> I know we have established governance rules. They exist for a reason.
> Though I hope everyone understand what happened after my explanation.
>
> I believe what you wanted to write is:
>
> "If we don't think first and follow the rules without even trying to
> understand, we *WOULD* reject. But we are humans with brains, not
> machines, therefore, it's ok"
>
> Because *you do* have a choice, don't you?
>
> 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
>

Does the current PTL not have the ability to propose extra-atc's for
this reason?

Would a solution be for zigo to propose the people active in
http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/
to the governance repo (including himself) and the TC approve it.

This would give an electorate, and give Zigo the right to run as PTL.

I know the timescales would be short - but it might be workable.

- Graham

__
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] Question about electorate for project without gerrit contribution

[Thomas Goirand]

On 03/15/2016 08:22 PM, Tony Breeds wrote:
> However, at the risk of sounding like a humorless automaton, we have a valid
> candidate.
>  * Monty Taylor for Packaging-Deb PTL https://review.openstack.org/#/c/292690/

This started as a joke. Please don't pick-up the joke, and make it a
serious proposal. This isn't funny anymore.

Obviously, Monty isn't interested (otherwise, he would have help with
https://review.openstack.org/#/c/264726/, which he didn't despite his
generous offer to do so in Tokyo but he had other priorities).

Also again, please have a look at the openstack-pkg-tools Git history here:
http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/

There's at least 3 commits a week on this repository.

Now, compare this to the single commit to add a .gitreview file from Monty:
https://github.com/openstack/deb-openstack-pkg-tools/commits/debian/liberty

That's also a commit on the Liberty branch, and we've switched to
debian/mitaka a long time ago.

> Also by the rules I feel like we have no choice but to reject
>  * Adding Packaging-Deb/Thomas_Goirand.txt
https://review.openstack.org/#/c/292885/

I know we have established governance rules. They exist for a reason.
Though I hope everyone understand what happened after my explanation.

I believe what you wanted to write is:

"If we don't think first and follow the rules without even trying to
understand, we *WOULD* reject. But we are humans with brains, not
machines, therefore, it's ok"

Because *you do* have a choice, don't you?

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] [nova] Wishlist bugs == (trivial) blueprint?

[melanie witt]

On Mar 15, 2016, at 10:59, Tim Bell  wrote:

> The risk I see is that we are missing input to the development process in 
> view of the complexity of submitting those requirements. Clearly, setting the 
> bar too low means that there is no clear requirement statement etc. However, 
> I think the combination of tools and assumption of knowledge of the process 
> means that we are missing the opportunity for good quality input.
> 
> Many of these are low hanging fruit improvements which could be used to bring 
> developers into the community if we can find a good way to get the input and 
> match it with the resource to implement.

Agreed. I think Wishlist bugs have had value but I'll admit the value is small 
compared to the total number of Wishlist bugs.

The thing I like about them is that they're easy for anyone to open and people 
can pile on and say "me too" so we get some indication of how much interest 
there is in a feature/idea (the launchpad bug heat increases). I have seen this 
work well in a couple of cases where I don't think we could have found out 
people were interested in something otherwise.

Digging up examples:

* Several novaclient users would like it if tenant ids were validated against 
keystone [1] (Look how many duplicates and the bug heat!). It has since evolved 
into a spec [2] and blueprint [3]. I didn't think this would be as popular as 
it is, but I know it from the number of bugs people have opened that I have 
marked as duplicates of a Wishlist bug.

* Several nova users are interested in the capability to detach the root device 
volume of an instance, when in shutoff state [4]. This one, I had no idea about 
until I saw the bug.


I think the spec process is heavy for a person who just wants to communicate a 
feature ask and it requires that other people be able to find that spec to +1 
it before it potentially goes into the abandoned state once spec freeze 
happens. I can't imagine users finding a spec being that they're not 
searchable. I feel like you have to "be in the know" to vote on a spec. With 
the Wishlist bugs, users can search to find things they're interested in and 
add comments. Triagers can see duplicates and mark them as such, which bubbles 
up popular asks via bug heat. It's a lot of manual work, though.

-melanie


[1] https://bugs.launchpad.net/nova/+bug/1118066
[2] https://review.openstack.org/#/c/92507/
[3] https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone
[4] https://bugs.launchpad.net/nova/+bug/1396965


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] PTL candidacy

[Kenichi Oomichi]

Hi everyone,

I'd like to announce my candidacy for PTL of the Quality Assurance
team for the Newton release cycle. I have joined into the OpenStack
community since 2012 as a developer, and you can see my activities on
the following metric:

 * Review: http://stackalytics.com/?release=all_id=oomichi=marks
 * Commit: http://stackalytics.com/?release=all_id=oomichi=commits

I have concentrated on solving bugs on both QA and Nova sides in long
term, my contribution has created Nova V2.1 API as a result. The API
is necessary to solve both API inconsistencies and wrong behaviors of
the existing API without clients' pain. Now many projects start to use
its mechanism (API microversions) for solving these own issues.
In Mitaka cycle, we have implemented the testing framework for the API
microversions in Tempest to be used in all projects. The fact is my
pleasure because we can work together to solve the same issues between
whole OpenStack projects. That is a strong point of our OpenStack
community.

In Newton cycle, I'd like to finish service client development which
makes it easy to implement Tempest-like tests for non-core projects.
That will be helpful for OpenStack big-tent. We have already implemented
many clients as stable interfaces, but some clients still remain.
I believe we can finish that with folks in the cycle. On the other hand,
tempest-resources feature also is one of that I want to concentrate on
in the cycle. That will make Tempest easier to be used on production
environments. If implementing it, we can involve more users in our
upstream development and debugging. One more thing is OpenStack health
dashboard, that attracts people to QA project. We can see current test
situation easily from the dashboard. The dashboard is already great, but
there are still several ideas for improving. I want to see the improved
one in the cycle.

I don't want to enforce something on folks. The door of QA project
should be always open as previous PTLs did. New ideas are welcome for
improving test coverage and easy debugging, this is open source project.

I am glad that this chance is given to all developers, this community
is really open. Regardless of the election result, I will do my best
in this project.

Thanks
Ken'ichi Ohmichi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTL noncandidacy

[Cindy Lu]

Thank you so much David! You've done an *exceptional* job making Horizon
great! Look forward to continuing to work alongside you (your knowledge of
past/present/future is unmatched!).

Regards,
Cindy



From:   Zhenguo Niu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   03/14/2016 07:04 PM
Subject:Re: [openstack-dev] [horizon] PTL noncandidacy



David,

Thanks for your commitment and leadership, really appreciated all the help
from you!

On Tue, Mar 15, 2016 at 5:41 AM, Diana Whitten 
wrote:
  David,

  I don't envy the person who has to fill these shoes.  You've been
  amazing!

  - Diana

  On Mon, Mar 14, 2016 at 1:04 PM, Timur Sufiev 
  wrote:
   David,

   It's sad news for us, and a well-deserved vacation from bureaucratic
   hassles for you! Will try hard to not break Horizon in your absence.

   On Mon, 14 Mar 2016 at 22:46, Doug Fish  wrote:
 David, congratulations on a job well done!

 Doug

 On Mar 14, 2016, at 8:39 AM, Liz Blanchard 
 wrote:



   On Fri, Mar 11, 2016 at 12:19 PM, David Lyle 
   wrote:
After five cycles as PTL of Horizon, I've decided not to run
for the
Newton cycle.

   David,

   Thank you for everything you've done for Horizon, especially
   around helping push a focus on User Experience.

   Best,
   Liz


I am exceptionally proud of the things we've accomplished over
this
time. I'm amazed by how much our project's community has grown
and
evolved.

Looking at the community now, I believe we have a tremendous
group of
contributors for moving forward. There are several people
capable of
becoming great PTLs and overall the community will be healthier
with
some turnover in the PTL role. I feel honored to have had your
trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

David


__

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




--
Best Regards,
Zhenguo Niu
__
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] [nova] Wishlist bugs == (trivial) blueprint?

[Chen CH Ji]

 agree we can ask people to submit their requirement through backlog spec but not sure it might have too much process sometimes the bug opener is not a developer, it might be some operatoror openstack user, they just want to get it done but they don't know more detailso we can keep the wishlist and cleanup it and mark it invalid as you suggestedlike 6 month or 1 year, but mark the bug which may contains valid request Invalid like [1] right afterwe found it's not current supported seems too rush[1]https://bugs.launchpad.net/bugs/1556756-Matt Riedemann  wrote: -To: openstack-dev@lists.openstack.orgFrom: Matt Riedemann Date: 03/15/2016 02:50PMSubject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?On 3/15/2016 8:37 AM, Chris Dent wrote:> On Tue, 15 Mar 2016, Markus Zoeller wrote:>>> Long story short, I'm in favor of abandoning the use of "wishlist">> as an importance in bug reports to track requests for enhancements.>> While I'm very much in favor of limiting the amount of time issues> (of any sort) linger in launchpad[1] I worry that if we stop making> "wishlist" available as an option then people who are not well> informed about the complex system for achieving features in Nova> will have no medium to get their ideas into the system. We want> users to sometime be able to walk up, drop an idea and move on without> having to be responsible for actually doing that work. If we insist> that such ideas must go through the blueprint process then most> ideas will be left unstated.We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs:https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html>> What I think we need to do instead is fix this problem:>>> * we don't have a process to transform wishlist bugs to blueprints>> such that we do have a process of some kind where a wishlist idea> either gets an owner who starts the blueprint process (because it is> just that cool) or dies from lack of attention.>> It's clear, though, that we already have a huge debt in bug/issue> management so adding yet another task is hard to contemplate.>> I think we can address some of that by more quickly expiring bugs> that have had no recent activity or attention, on the assumption> that:>> * They will come back up again if they are good ideas or real bugs.> * Lack of attention is a truthy signal of either lack of resources or lack>    of importance.>> What needs to happen is that fewer things which are not actionable> or nobody is interested in show up when traversing the bugs looking> for something to work on.>> I'm happy to help some of this become true, in part because of [1]> below.>> [1] I've recently spent a bit of time chasing bugs tagged> "scheduler" and far too many of them are so old that it's impossible> to tell whether they matter any more, and many of them are confused> by patches and people who have gone in and out of existence. It's> challenging to tease out what can be done and the information has> very little archival value. It should go off the radar. Having a> bunch of stuff that looks like it needs to be done but never> actually is is stop energy and depressing. __> 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>We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that).-- Thanks,Matt Riedemann__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [magnum] Discussion of supporting single/multiple OS distro

[Steven Dake (stdake)]

WFM as long as we stick to the spirit of the proposal and don't end up in a 
situation where there is only one distribution.  Others in the thread had 
indicated there would be only one distribution in tree, which I'd find 
disturbing for reasons already described on this thread.

While we are about it, we should move to the latest version of atomic and chase 
atomic every two weeks on their release.  Thoughts?

Regards
-steve


From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 14, 2016 at 8:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro



From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: March-14-16 4:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro

Steve,

I think you may have misunderstood our intent here. We are not seeking to lock 
in to a single OS vendor. Each COE driver can have a different OS. We can have 
multiple drivers per COE. The point is that drivers should be simple, and 
therefore should support one Bay node OS each. That would mean taking what we 
have today in our Kubernetes Bay type implementation and breaking it down into 
two drivers: one for CoreOS and another for Fedora/Atomic. New drivers would 
start out in a contrib directory where complete functional testing would not be 
required. In order to graduate one out of contrib and into the realm of support 
of the Magnum dev team, it would need to have a full set of tests, and someone 
actively maintaining it.
OK. It sounds like the proposal allows more than one OS to be in-tree, as long 
as the second OS goes through an incubation process. If that is what you mean, 
it sounds reasonable to me.

Multi-personality driers would be relatively complex. That approach would slow 
down COE specific feature development, and complicate maintenance that is 
needed as new versions of the dependency chain are bundled in (docker, k8s, 
etcd, etc.). We have all agreed that having integration points that allow for 
alternate OS selection is still our direction. This follows the pattern that we 
set previously when deciding what networking options to support. We will have 
one that’s included as a default, and a way to plug in alternates.

Here is what I expect to see when COE drivers are implemented:

Docker Swarm:
Default driver Fedora/Atomic
Alternate driver: TBD

Kubernetes:
Default driver Fedora/Atomic
Alternate driver: CoreOS

Apache Mesos/Marathon:
Default driver: Ubuntu
Alternate driver: TBD

We can allow an arbitrary number of alternates. Those TBD items can be 
initially added to the contrib directory, and with the right level of community 
support can be advanced to defaults if shown to work better, be more 
straightforward to maintain, be more secure, or whatever criteria is important 
to us when presented with the choice. Such criteria will be subject to 
community consensus. This should allow for free experimentation with alternates 
to allow for innovation. See how this is not locking in a single OS vendor?

Adrian

On Mar 14, 2016, at 12:41 PM, Steven Dake (stdake) 
> wrote:

Hongbin,

When we are at a disagreement in the Kolla core team, we have the Kolla core 
reviewers vote on the matter. This is typical standard OpenStack best practice.

I think the vote would be something like
"Implement one OS/COE/network/storage prototype, or implement many."

I don't have a horse in this race, but I think it would be seriously damaging 
to Magnum to lock in to a single vendor.

Regards
-steve


From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, March 7, 2016 at 10:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro



From: Corey O'Brien [mailto:coreypobr...@gmail.com]
Sent: March-07-16 8:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro

Hongbin, I think the offer to support different OS options is a perfect example 
both of what we want and what we don't want. We definitely want to allow for 
someone like yourself to maintain templates for whatever OS they want and to 
have that option be easily integrated in to a 

Re: [openstack-dev] [tc] Question about electorate for project without gerrit contribution

[Tony Breeds]

On Tue, Mar 15, 2016 at 06:28:14PM +0100, Thierry Carrez wrote:

> The second issue is that we don't have any way to run an election on the
> project, since we don't have a way to determine "contributors" (or rather,
> the only voter and potential candidate under those rules would be Monty).
> You can't even apply to be the PTL :) That is obviously an exceptional case
> and if I read Tristan's answer correctly, it will naturally end up in the
> process where the TC ends up picking the PTL. It feels natural if you're the
> only candidate that we would pick you, but that will likely have to wait
> until the end of the election period.

I don't think we have the luxury of waiting.  There needs to be a small
amount of corrective action taken now.

As pointed out elsewhere in this thread the TC has the ability to appoint a PTL
should a project end up leaderless should that happen.

However, at the risk of sounding like a humorless automaton, we have a valid
candidate.
 * Monty Taylor for Packaging-Deb PTL https://review.openstack.org/#/c/292690/

In the interests of transparency I'll say this here.  Monty if you do *NOT*
have a genuine desire to lead the packaging-deb team please abandon that review
ASAP.

Also by the rules I feel like we have no choice but to reject
 * Adding Packaging-Deb/Thomas_Goirand.txt 
https://review.openstack.org/#/c/292885/


Yours Tony.


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

[openstack-dev] [horizon] PTL candidacy

[Rob Cresswell (rcresswe)]

Hi folks,

I'm announcing my candidacy for PTL for Horizon for the Newton release cycle.

My main goals for the cycle are:

- Remove roadblocks from AngularJS development so that the code can
  mature. This means optimistically approving patches in the experimental
  disabled panels, so that it can be rapidly iterated. The Swift rewrite is a
  fantastic example of how focused reviews and dropping the demand for
  absolute perfection allow for a dramatically improved experience via
  AngularJS.

- Work on scale issues, and improve non-performant content. There are a number
  of panels in Horizon that are often unused (especially in the Admin
  dashboard). We need to apply the existing tools available to us such as
  pagination and filtering, as well as investigate other proposals.

- Improve bug management and project organisation. In the past few cycles, the
  bugs and blueprints on launchpad have been quickly growing while triage work
  dwindles. In Mitaka, we've run several bug days as well as holding a Horizon
  Drivers meeting every other week to analyse blueprints as a group. I'd like
  to continue the focus on bringing our tooling back to useable state, so that
  we correctly address current issues and customer needs.

Finally, I believe one of the most important parts of being a PTL is community
engagement, and will continue to build an active and positive developer
community.

Election repo patch: https://review.openstack.org/#/c/293083/

Thanks,
Rob
__
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] Getting rid of cluster status

[Andrew Woodward]

On Tue, Mar 15, 2016 at 4:04 AM Roman Prykhodchenko  wrote:

> Fuelers,
>
> I would like to continue the series of "Getting rid of …" emails. This
> time I’d like to talk about statuses of clusters.
>
> The issues with that attribute is that it is not actually related to real
> world very much and represents nothing. A few month ago I proposed to make
> it more real-world-like [1] by replacing a simple string by an aggregated
> value. However, after task based deployment was introduced even that
> approach lost its connection to the real world.
>
> My idea is to get rid of that attribute from a cluster and start working
> with status of every single node in it. Nevertheless, we only have tasks
> that are executed on nodes now, so we cannot apply the "status" term to
> them. What if we replace that with a sort of boolean value called
> maintenance_mode (or similar) that we will use to tell if the node is
> operational or not. After that we will be able to use an aggregated
> property for cluster and check, if there are any nodes that are under a
> progress of performing some tasks on them.
>

Yes, we still need an operations attribute, I'm not sure a bool is enough,
but you are quite correct, setting the status of the cluster after
operational == True based on the result of a specific node failing, is in
practice invalid.

At the same time, operational == True is not necessarily deployment
succeeded, its more along the line of deployment validated, which may be
further testing passing like ostf, or more manual in the operator wants to
do more testing their own prior to changing the state.

As we adventure in to the LCM flow, we actually need status of each
component in addition of the general status of the cluster to determine the
proper course of action the on the next operation.

For example nova-compute
if the cluster is not operational, then we can provision compute nodes, and
have them enabled, or active in the scheduler automatically. However if the
cluster is operational, a new compute node must be disabled, or otherwise
blocked from the default scheduler until the node has received validation.
In this case the interpretation of operational is quite simple

For example ceph
Here we care less about the status of the cluster (slightly, this example
ignores ceph's impact on nova-compute), and more about the status of the
service. In the case that we deploy ceph-osd's when their are not replica
factor osd hosts online (3) the we can provision the OSD's similar to
nova-compute,  in that we can bring them all online and active and data
could be placed to them immediately (more or less). but if the ceph status
is operational, then we have to take a different action, the OSD's have to
be brought in disabled, and gradually(probably by the operator) have their
data weight increased so they don't clog the network with data peering
which causes the clients may woes.


> Thoughts, ideas?
>
>
> References:
>
> 1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status
>
>
> - romcheg
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] UCA deployment landed and working

[Matthew Mosesohn]

Hi all,

Thanks to Alex Schultz, we landed the Ubuntu Cloud Archive as a
possible deployment source last week just in time for the feature
freeze exception. No sooner than landing it, we have a new task to
switch it to a separate Fuel release[1]. Patches are on review to fix
this now[2]. But now it seems that deployment should pass using Ubuntu
Cloud Archive with Fuel.

There were some packaging issues blocking deployment last week, but
now with openstackclient 2.2.0 in trusty-proposed/mitaka, it should
all be working. I want to thank Corey Bryant and James Page from the
UCA team for rebuilding client libraries so quickly.

I'm still running through testing cycles, and I'll report when we have
a passed BVT using UCA.

[1] https://bugs.launchpad.net/fuel/+bug/1556011
[2] https://review.openstack.org/293044 https://review.openstack.org/#/c/292340/

Best Regards,
MAtthew Mosesohn

__
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] Wishlist bugs == (trivial) blueprint?

[Tim Bell]

On 15/03/16 16:21, "Markus Zoeller"  wrote:

>Sean Dague  wrote on 03/15/2016 02:52:47 PM:
>
>> From: Sean Dague 
>> To: openstack-dev@lists.openstack.org
>> Date: 03/15/2016 02:53 PM
>> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
>blueprint?
>> 
>> On 03/15/2016 09:37 AM, Chris Dent wrote:
>> > On Tue, 15 Mar 2016, Markus Zoeller wrote:
>> > 
>> >> Long story short, I'm in favor of abandoning the use of "wishlist"
>> >> as an importance in bug reports to track requests for enhancements.
>> > 
>> > While I'm very much in favor of limiting the amount of time issues
>> > (of any sort) linger in launchpad[1] I worry that if we stop making
>> > "wishlist" available as an option then people who are not well
>> > informed about the complex system for achieving features in Nova
>> > will have no medium to get their ideas into the system. We want
>> > users to sometime be able to walk up, drop an idea and move on without
>> > having to be responsible for actually doing that work. If we insist
>> > that such ideas must go through the blueprint process then most
>> > ideas will be left unstated.
>> 
>> I believe that 0% of such drive by wishlist items ever get implemented.
>> I also think they mostly don't even get ACKed until 6 or 12 months after
>> submission. So It's not really a useful feedback channel.
>> 
>> So I'm pro just closing Wishlist items as Opinion and moving on.
>> Probably with some boiler plate around it about submission guidelines
>> for making a lightweight blueprint.
>
>A few more specific numbers which could help to make a decission.
>Open wishlist bug reports older than:
>>   now: 146
>>  6 months: 141
>> 12 months: 122
>
>Wishlist bug reports in progress: 9
>Wishlist bug reports implemented:
>46 (last 24 months)
>25 (last 18 months)
>19 (last 12 months)
> 5 (last  6 months)
>
>Based on that it seems to me that it is not a very successful 
>channel to get ideas implemented(!). The dropping is easy though.
>
>Based on that I'm very much in favor of the agressive choice to close 
>the remaining 146 wishlist bugs with a comment which explains how to
>go on from there (using backlog specs).


The bug process was very light weight for an operator who found something they 
would like enhanced. It could be done through the web and did not require 
git/gerrit knowledge. I went through the process for a change:

- Reported a bug for the need to add an L2 cache size option for QEMU 
(https://bugs.launchpad.net/nova/+bug/1509304) closed as invalid since this was 
a feature request
- When this was closed, I followed the process and submitted a spec 
(https://blueprints.launchpad.net/nova/+spec/qcow2-l2-cache-size-configuration)

It was not clear how to proceed from here for me. 

The risk I see is that we are missing input to the development process in view 
of the complexity of submitting those requirements. Clearly, setting the bar 
too low means that there is no clear requirement statement etc. However, I 
think the combination of tools and assumption of knowledge of the process means 
that we are missing the opportunity for good quality input.

Many of these are low hanging fruit improvements which could be used to bring 
developers into the community if we can find a good way to get the input and 
match it with the resource to implement.

Tim

>
>> > What I think we need to do instead is fix this problem:
>> > 
>> >> * we don't have a process to transform wishlist bugs to blueprints
>> > 
>> > such that we do have a process of some kind where a wishlist idea
>> > either gets an owner who starts the blueprint process (because it is
>> > just that cool) or dies from lack of attention.
>> > 
>> > It's clear, though, that we already have a huge debt in bug/issue
>> > management so adding yet another task is hard to contemplate.
>> > 
>> > I think we can address some of that by more quickly expiring bugs
>> > that have had no recent activity or attention, on the assumption
>> > that:
>> > 
>> > * They will come back up again if they are good ideas or real bugs.
>> > * Lack of attention is a truthy signal of either lack of resources or 
>lack
>> >   of importance.
>> > 
>> > What needs to happen is that fewer things which are not actionable
>> > or nobody is interested in show up when traversing the bugs looking
>> > for something to work on.
>> > 
>> > I'm happy to help some of this become true, in part because of [1]
>> > below.
>> > 
>> > [1] I've recently spent a bit of time chasing bugs tagged
>> > "scheduler" and far too many of them are so old that it's impossible
>> > to tell whether they matter any more, and many of them are confused
>> > by patches and people who have gone in and out of existence. It's
>> > challenging to tease out what can be done and the information has
>> > very little archival value. It should go off the radar. Having a
>> > bunch of stuff that looks like it needs to be done but 

[openstack-dev] [Rally] single router per tenant in network context

[Akshay Kumar Sanghai]

Hi,
I have a openstack setup with 1 controller node, 1 network node and 2
compute nodes. I want to perform scale testing of the setup in the
following manner:

- Create 10 tenants
- Create 1 router per tenant
- Create 100 neutron networks across 10 tenants attached to the router
- Create 500 VMs spread across 10 tenants attached to the networks

I used the boot_server scenario and defined the number of networks and
tenants in the network and users context respectively. But I want only one
router to be created per tenant. In the current case, one router is created
per network.

Do i have an option to accomplish this using the existing rally code? Or
should i go ahead and make some change in the network context for my use
case?

Thanks,
Akshay
__
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] rabbitmq / ipv6 issue

[Emilien Macchi]

So from now, we pin [5] puppetlabs-rabbitmq to the commit before [3]
and I rebased Attila's patch to test CI again.
This pin is a workaround, in the meantime we are working on a fix in
puppetlabs-rabbitmq.

[5] https://review.openstack.org/293074

I also reported the issue in TripleO Launchpad:
https://bugs.launchpad.net/tripleo/+bug/1557680

Also a quick note:
Puppet OpenStack CI did not detect this failure because we don't
deploy puppetlabs-rabbitmq from master but from the latest release
(tag).

On Tue, Mar 15, 2016 at 1:17 PM, Emilien Macchi  wrote:
> TL;DR;This e-mail tracks down the work done to make RabbitMQ working
> on IPv6 deployments.
> It's currently broken and we might need to patch different Puppet
> modules to make it work.
>
> Long story:
>
> Attila Darazs is currently working on [1] to get IPv6 tested by
> TripleO CI but is stuck because a RabbitMQ issue in Puppet catalog
> [2], reported by Dan Sneddon.
> [1] https://review.openstack.org/#/c/289445
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1317693
>
> [2] is caused by a patch in puppetlabs-rabbitmq [3], that change the
> way we validate RabbitMQ is working from testing localhost to testing
> the actual binding IP.
> [3] 
> https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/dac8de9d95c5771b7ef7596b73a59d4108138e3a
>
> The problem is that when testing the actual IPv6, it curls fails for
> some different reasons explained on [4] by Sofer.
> [4] https://review.openstack.org/#/c/292664/
>
> So we need to investigate puppetlabs-rabbitmq and puppet-staging to
> see if whether or not we need to change something there.
> For now, I don't think we need to patch anything in TripleO Heat
> Templates, but we'll see after the investigation.
>
> I'm currently working on this task, but any help is welcome,
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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][Neutron] neutron-lbaas agent service placement

[Ben Nemec]

On 03/14/2016 10:18 AM, Qasim Sarfraz wrote:
> Hi Triple-O folks,
> 
> I was planning to enable neutron-lbaas-agent on a overcloud deployment
> but couldn't find any useful documentation. Can someone please point me
> to the required documentation? Is there a heat/puppet workflow available
> for this service? 
> 
> Also I had following questions regarding neutron-lbaas service placement:
> 
>   * I am not able to find a network node or neutron node role in tripleo
> templates [1] consequently the service will be placed on
> controllers. Correct? 

Yeah, there's work under way to allow custom placement of services, but
for the moment it would probably need to run on the controllers.

>   * Is it possible to run multiple instances of this service and use
> HAproxy to provide VIP to the services?

Assuming the service supports this, it should be doable.

>   * Is it possible to run the service on the compute nodes? If yes is
> there a installation workflow for this.

It's possible, but to my knowledge there isn't any existing support for
LBaaS in TripleO.  To enable it, you would need to:

-Add it to the TripleO loadbalancer puppet manifest:
https://github.com/openstack/puppet-tripleo/blob/master/manifests/loadbalancer.pp
-Add the necessary hieradata to enable it in tripleo-heat-templates.

This is assuming there is existing puppet support for it.  If not, there
would be some additional steps to get that into the puppet modules we use.

-Ben

__
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] Plans on networking modularisation

[Ryan Moe]

Hi Aleksey,



> What is the status of making networking part replaceable? As I know, [0]
> is in progress. Are there any other activities in progress (about API,
> serialization for orchestrator, network verification)? Do we have specs on
> review (I know about this one: [1]) ?
>
>
AFAIK there are no other activities in progress right now.


> As I know, [0] is about separate storage service for networking related
> information (from what I've seen), not about moving all network-related
> code. Please correct me if it's not true.
>

You are correct. The intent was to end up with a separate network storage
service and network manager as a client of this service (where appropriate).


>
> AFAIC, [0] can be combined with moving of network part into extension
> (API, serialization). So, extension could use this storage. Network
> verification (net-checker) depends on networking data and it uses the same
> RPC so it can be more difficult to move its setup and results acquisition
> from Nailgun into extension.
> I'm for networking as extension as it was done for "volume manager"
> already.
>
>
I agree that moving network manager into an extension would be good. I
think we'll need some discussion around that though. NetworkManager does a
lot and some of it can be pushed off to a separate service but some will
always be tied to Nailgun. I'm not sure how or if that will impact moving
it into an extension.


> Please expand this a bit: "Reuse Neutron API with additional
> plugins/extensions to provide for us a way to also store bonds/nics related
> information."
> As I understand, it's rather specific stuff and will cover very small part
> of the whole task. And as 2.1 is in progress already, 2.3 seems to be
> rejected..?
>
>
I originally created a simple PoC (2.1) just to test out the idea. The
Nailgun side of this work done since doesn't have any dependency on that
PoC. We can freely change directions. Neutron handles a lot of what Nailgun
cares about (networks, subnets, IP allocation, etc.) so I'm currently
investigating it as an option.


> I'd like to participate in design discussions. Please add me into meetings.
>

I will make sure you're included. Your input would be greatly appreciated.

Thanks,
Ryan
__
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] [packstack] Update packstack core list

[Ivan Chavero]

- Original Message -
> From: "Javier Pena" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, March 8, 2016 4:41:41 AM
> Subject: Re: [openstack-dev] [packstack] Update packstack core list
> 
> > Hi,
> > 
> > [post originally sent on RDO-list but I've been told I should use this
> > channel]
> > 
> > I've looked at packstack core-list [1] and I suggest we revisit to keep
> > only active contributors [2] in the core members list.
> > 
> > The list seems super big comparing to who is actually active on the
> > project; in a meritocracy world it would make sense to revisit that list.
> > 
> > Thanks,
> > 
> > [1] https://review.openstack.org/#/admin/groups/124,members
> > [2] http://stackalytics.com/report/contribution/packstack/90
> > 
> 
> I agree with Emilien. Looking at the active contributors, my proposal for the
> core list would be:
> 
> - Martin Mágr
> - Iván Chavero
> - Javier Peña
> - Alan Pevec
> 
> I have a doubt about Lukas, he's contributed an awful lot to Packstack, just
> not over the last 90 days. Lukas, will you be contributing in the future? If
> so, I'd include him in the proposal as well.
> 
> 
> Thoughts?

Sorry for the late response, this mail got buried in the mix of filters.

I agree, the core members list is to big. +1 for Javier's proposal

Cheers,
Ivan

__
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] Question about electorate for project without gerrit contribution

[Thierry Carrez]

Thomas Goirand wrote:

so it's not completely
crazy to kick it back to non-official status (especially now that it
doesn't trigger any repository rename).


Please don't. It took over 5 months to get it, and to be allowed to
create the initial Git repository under the OpenStack namespace, with
others replying to the project-config code review that we should be
waiting on the TC's decision first. I don't want to have this happen
again, that'd be really too much of a loss of time.

It's taking a (really too) long time to be setup properly with the
Debian image and build infrastructure. I'm aware of it, and I hope we
can fix this during the Newton cycle. Though a lot of teams are waiting
on this project. Puppet OpenStack wants to gate on what we'll be
producing, and so is Fuel. The plan is that MOS guys will also do more
work over there using Gerrit, if we have something usable.

Please allow us to make it happen.


We have two separate issues here. The first one is that we added a 
requirement that official project teams need to be active for some time 
before they are considered for addition. We rejected a number of 
projects (including Kosmos and the Juju charms) based on that new 
requirement. The packaging-deb team was approved before that new 
requirement was added, but that doesn't mean it can just ignore it (as 
otherwise that would be unfair to the teams we rejected).


You make a good point that the team is active but that activity can't 
translate to commits yet -- if anyone proposes the removal of 
packaging-deb due to failing to meet the activity requirement, I expect 
we'll come back to that discussion. But nobody did yet, so it's not an 
immediate issue.



I hope that everyone understands the situation, and I hope that the
proposal to have Monty hijacking the project will remain a joke.

Oh, and if it wasn't clear: I'm again proposing myself as a PTL for the
project, since I don't think anyone else will want to stand.


The second issue is that we don't have any way to run an election on the 
project, since we don't have a way to determine "contributors" (or 
rather, the only voter and potential candidate under those rules would 
be Monty). You can't even apply to be the PTL :) That is obviously an 
exceptional case and if I read Tristan's answer correctly, it will 
naturally end up in the process where the TC ends up picking the PTL. It 
feels natural if you're the only candidate that we would pick you, but 
that will likely have to wait until the end of the election period.


--
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

[openstack-dev] [tripleo] rabbitmq / ipv6 issue

[Emilien Macchi]

TL;DR;This e-mail tracks down the work done to make RabbitMQ working
on IPv6 deployments.
It's currently broken and we might need to patch different Puppet
modules to make it work.

Long story:

Attila Darazs is currently working on [1] to get IPv6 tested by
TripleO CI but is stuck because a RabbitMQ issue in Puppet catalog
[2], reported by Dan Sneddon.
[1] https://review.openstack.org/#/c/289445
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1317693

[2] is caused by a patch in puppetlabs-rabbitmq [3], that change the
way we validate RabbitMQ is working from testing localhost to testing
the actual binding IP.
[3] 
https://github.com/puppetlabs/puppetlabs-rabbitmq/commit/dac8de9d95c5771b7ef7596b73a59d4108138e3a

The problem is that when testing the actual IPv6, it curls fails for
some different reasons explained on [4] by Sofer.
[4] https://review.openstack.org/#/c/292664/

So we need to investigate puppetlabs-rabbitmq and puppet-staging to
see if whether or not we need to change something there.
For now, I don't think we need to patch anything in TripleO Heat
Templates, but we'll see after the investigation.

I'm currently working on this task, but any help is welcome,
-- 
Emilien Macchi

__
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] [Third-Party][CI] Modify CI accouts in CI group

[Anita Kuno]

On 03/14/2016 10:23 PM, Watanabe, Isao wrote:
> To: Anita
> Cc: Third-Party Coordinators

Just so you know, putting cc: in the body of an email as content doesn't
email specific people. I assume you are using this syntax to state that
while you are addressing me directly you also include other third-party
coordinators as well.

> 
> Thank you for the help.
> I have created the missed account.
> Could you please help me to submit the account again?
>> [1]Add account
>> Name: Fujitsu ISM CI
>> Mail: fj-lsoft-is...@dl.jp.fujitsu.com

This account has been added to the Third-Party CI gerrit group.

> 
> About the disabled accounts.
> Thank you for the kindly inform about the gerrit account id.
> The following accounts are not going to be reused.
> - Fujitsu ETERNUS FC CI <==account has just been deleted

Well actually we can never delete a gerrit account, we can't really
delete anything much in gerrit. That is sort of the point of using the
tool. This account has been deactivated. It does however still exist in
an inactive state.

> - Fujitsu IRMC CI <==account not exists
> So, if there is any way to remove them, to keep  clear, 
> feel free to delete them at any time, please.

I don't think it hurts anything to keep them listed in the Third-Party
CI gerrit group just in case something were to happen and they pop up
again. I'll leave them listed.

Thank you for helping me to understand what you want and to get your
accounts in the gerrit group.

Thank you,
Anita.


> 
> Best regards,
> Watanabe.isao
> 
> 
> 
>> -Original Message-
>> From: Anita Kuno [mailto:ante...@anteaya.info]
>> Sent: Monday, March 14, 2016 11:57 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Third-Party][CI] Modify CI accouts
>> in CI group
>>
>> On 03/14/2016 04:39 AM, Watanabe, Isao wrote:
>>> Hello, Third-Party Coordinators
>>> Cc：Ramy
>>>
>>> Could you please help me about the following CI accounts changes in CI 
>>> group?
>>>
>>> [1]Add account
>>> Name: Fujitsu ISM CI
>>> Mail: fj-lsoft-is...@dl.jp.fujitsu.com
>>
>> You need to create this account before it can be added to the Third-Party
>> CI gerrit group. Gerrit doesn't know about this account yet.
>> http://docs.openstack.org/infra/system-config/third_party.html#creating-
>> a-service-account
>>
>>>
>>> [2]Modify
>>> Name: Fujitsu ETERNUS CI
>>> OLD-Email: lsoft-eternu...@ml.css.fujitsu.com
>>> NEW-Email: fj-lsoft-eternu...@dl.jp.fujitsu.com
>>
>> If you created the gerrit account yourself, you can modify the email 
>> yourself.
>> In settings > Contact Information select the button Register New Email. Then
>> add the new email of choice.
>>
>> If infra created the account for you, please follow the instructions
>> here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount
>>
>> I have taken no action on this request, as I have none to take.
>>
>>>
>>> [3] Modify
>>> OLD-Name: Fujitsu IRMC CI
>>> NEW-Name: Fujitsu iRMC CI
>>> OLD-Email: lsoft-irm...@ml.css.fujitsu.com
>>> NEW-Email: fj-lsoft-irm...@dl.jp.fujitsu.com
>>
>> I have added "Fujitsu iRMC CI" to the gerrit Third-Party CI gerrit group.
>>
>>>
>>> [4] Modify
>>> Name: Fujitsu C-Fabric CI
>>> OLD-Email: lsoft-cfabri...@ml.css.fujitsu.com
>>> NEW-Email: fj-lsoft-cfabri...@dl.jp.fujitsu.com
>>
>> If you created the gerrit account yourself, you can modify the email 
>> yourself.
>> In settings > Contact Information select the button Register New Email. Then
>> add the new email of choice.
>>
>> If infra created the account for you, please follow the instructions
>> here: https://wiki.openstack.org/wiki/OldtoNewGerritCIAccount
>>
>> I have taken no action on this request, as I have none to take.
>>
>>>
>>> [5] Delete
>>> Name: Fujitsu ETERNUS FC CI
>>> Email: lsoft-openstac...@ml.css.fujitsu.com
>>
>> This account has been disabled by the infra team in gerrit. If you want it
>> to be used again, you must contact a member of the infra team to have it set
>> to active. The gerrit account id for this account is 19917.
>>
>> Thank you,
>> Anita.
>>
>>>
>>>
>>> Best regards,
>>> Watanabe.isao
>>>
>>>
>>>
>>>
>>> __
>>>  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] [kolla] [infra] Size of images built in the gate

[Sam Yaple]

Steve,

overlayfs does not reduce the disk usage at all

Paul, we can bump the size of the docker mountpoint up to ~20GB if you
check all the gates for the appropriate space.

Sam Yaple

On Mon, Mar 14, 2016 at 7:20 PM, Steven Dake (stdake) 
wrote:

> Vikarm,
>
> /var/lib/docker is a btrfs filesystem.  It would be nice to just use
> overlayfs as it doesn't take nearly as much disk space and is much faster
> then btrfs.  I use overlay daily and it works like a champ unless I want to
> rebuild, in which case I think a bug in the ovl yum plugin prevents
> rebuilding if an image already exists.
>
> https://github.com/openstack/kolla/blob/master/tools/setup_RedHat.sh#L13
>
> Regards,
> -steve
>
>
> From: "Vikram Hosakote (vhosakot)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, March 14, 2016 at 11:51 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] [infra] Size of images built in the
> gate
>
> /var/lib/docker/aufs  takes a lot of space if many containers are running
> and
> writing data to their volumes.
>
> If the gate VM’s  /var/lib/docker  partition is small, you could move
> /var/lib/docker  to a different partition that is big enough (like /home
> or /tmp)
> and create a symbolic link to  /var/lib/docker.
>
> mv  /var/lib/docker  /home/new_docker_path_with_more_space
> ln -s  /home/new_docker_path_with_more_space  /var/lib/docker
>
> Alternatively, you can use the -g option for the docker daemon to use a
> different
> path instead of  /var/lib/docker  if it runs out of disk space.
>
> DOCKER_OPTS="-g /home/new_docker_path_with_more_space"
>
> Restart the docker daemon after making the above change.
>
> https://github.com/docker/docker/issues/3127
>
> Regards,
> Vikram Hosakote
> IRC: vhosakot
>
> From: Paul Bourke 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, March 14, 2016 at 11:25 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [kolla] [infra] Size of images built in the gate
>
> Hi all,
>
> I'm currently working to add new gates for the oraclelinux image base
> type (https://blueprints.launchpad.net/kolla/+spec/oraclelinux-gate) and
> had a question on size available in the gate VMs.
>
> Right now the binary build is running out of space in the gate, as it
> exceeds the 10GB we're allocating for /var/lib/docker. For me, a current
> local build using binary+oraclelinux is clocking in at 10.01GB, where as
> the centos+binary is a little smaller at 8.89GB.
>
> Is it written anywhere exactly what space is available in the gate VMs?
> Sam mentioned briefly that different providers used in the gate give a
> variety of disk sizes, so do we have an idea what we can reasonably bump
> the docker partition to?
>
> The above number indicates centos will likely soon run into the same
> problem as we dockerise more of the big tent, so I think it's a good
> idea to check this now before more gates start falling over.
>
> Thanks,
> -Paul
>
> p.s. if people are interested here's lists sorted by name of the
> oraclelinux and centos builds:
>
> oraclelinux: http://paste.fedoraproject.org/339672/96915914
> centos: http://paste.fedoraproject.org/339673/57969163
>
> __
> 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] [nova] Wishlist bugs == (trivial) blueprint?

[Chris Dent]

On Tue, 15 Mar 2016, Markus Zoeller wrote:

Chris Dent  wrote on 03/15/2016 03:23:42 PM:

My take is that if we do have that level of friction then influence, in
its many forms, will solely be mediated by the vendors that consume the
upstream OpenStack community, or people who have the wherewithal to
become embedded in the community. Is that fully healthy?


I don't understand this, could you rephrase it please?


Just for an example:

Say I'm a hobbyist in the basement who has just installed openstack
using whatever combination of packages, puppet, chef, ansible,
trunk, sheer grit, whatever on my spare hardware because I want to
know how it all works. After some effort I get it working, start
using it, and find some issues. Those issues come in two forms:

* What would be described by reasonable folk as a bug ("I do some api
  request and get a 500, really I should get a 4xx"). I report that
  to launchpad with a replication scenario, eventually somebody comes
  along, sees an actionable bug and fixes it, thanks me for the
  clear MTC.

* I get used to using things and realize that for a particular use
  case it would be useful to be able to express it more clearly. I
  report that to launchpad with a description of the idea and how it
  fits in to the world. It gets closed as wishlist with a bump to
  the backlog specs. I'm just a guy in the basement, I can't be
  bothered with going to the trouble of making a commit, I guess my
  ideas aren't that important.

Meanwhile, fortune 500 company chrisshoe, inc.[2] has contracted with
Hbirahat, the new consolidated enterprise OpenStack company, for a few
millions dollars worth of help on their new private cloud. While
working on that the professionals involved have realized they need a
particular feature. Hbirahat has a lot of people involved in
OpenStack[1], so no problem, we'll just get one of the cores in the
related project to write a spec, massage it through.

Turns out that idea from chrisshoe, inc. was in the same area as the one
that me in the basement had, except mine was several months earlier. And
while the chrisshoe solution is oriented towards easing private clouds
for enterprises, mine was for easing experimental clouds for people in
the basement. I could have spent the day not just writing up the backlog
spec, but also first of all figuring out _how_ to write a backlog spec.
Instead I just went about my original goal because meh.

You could argue that I (in the basement) just didn't care enough
and if I did I would have scratched my itch. That would be entirely
fair in many open source projects and may even be in this one. But
there's an extent to which the leverage that a monied corporation
can exercise in the OpenStack environment is a bit ... disconcerting.

It makes it seem like that for individual contributors we may want
to grease the pathways of contribution to compensate for the
advantages that the corporate behemoths have. I, unfortunately, don't
have any immediate ideas on how that might be done in the face our
pre-existing situation.

[1] All of them, pretty much, because of the industry consolidation.
[2] Makers of comfy shoes for comfy folk.
--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] RC1 candidate

[Armando M.]

Neutrinos,

I believe we reached the point [1] where RC1 can be cut [2]. If I made an
error of judgement, or any other catastrophic failure arises, please report
a bug, and tag it as mitaka-rc-potential [3]. Please, sign off on
postmortem [4], so that we can finalize the specs status for Mitaka and
open up to Newton.

Please, consider this the last warning to ensure that everything is in the
right order so that you can feel proud of what you and your teammates have
accomplished this release!

Cheers,
Armando

[1] https://launchpad.net/neutron/+milestone/mitaka-rc1
[2] https://review.openstack.org/#/c/292445/
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=mitaka-rc-potential
[4] https://review.openstack.org/#/c/286413/
[5] https://review.openstack.org/#/c/283383/
__
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] [FFE] FF exception request for SR-IOV

[Aleksandr Didenko]

Hi,

feature has been merged. QA is in progress.

Thanks,
Alex

On Fri, Mar 4, 2016 at 1:15 AM, Dmitry Borodaenko 
wrote:

> Granted, merge deadline March 16, feature to be marked experimental
> until QA has signed off that it's fully tested and stable.
>
> --
> Dmitry Borodaenko
>
>
> On Wed, Mar 02, 2016 at 01:40:26PM +0200, Aleksey Kasatkin wrote:
> > > And we need to write a new patch for:
> >
> https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov
> >
> > It is on review now: https://review.openstack.org/286704
> >
> > Complete list of patches on review:
> >
> https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov
> >
> >
> >
> > Aleksey Kasatkin
> >
> >
> > On Tue, Mar 1, 2016 at 6:27 PM, Aleksandr Didenko  >
> > wrote:
> >
> > > Hi,
> > >
> > > I'd like to to request a feature freeze exception for "Support for
> SR-IOV
> > > for improved networking performance" feature [0].
> > >
> > > Part of this feature is already merged [1]. We have the following
> patches
> > > in work / on review:
> > >
> > > https://review.openstack.org/280782
> > > https://review.openstack.org/284603
> > > https://review.openstack.org/286633
> > >
> > > And we need to write a new patch for:
> > >
> https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov
> > >
> > > We need 2 weeks at most after FF to accomplish this.
> > > Risk of not delivering it after 2 weeks is very low.
> > >
> > > Regards,
> > > Alex
> > >
> > > [0] https://blueprints.launchpad.net/fuel/+spec/support-sriov
> > > [1]
> > >
> https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-sriov
> > >
> > >
> > >
> __
> > > 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] [tc] Question about electorate for project without gerrit contribution

[Tristan Cacqueray]

On 03/15/2016 01:45 PM, Thomas Goirand wrote:
> On 03/11/2016 12:45 AM, Jeremy Stanley wrote:
>> On 2016-03-10 22:05:00 + (+), Tristan Cacqueray wrote:
>>> Projects such as Openstack UX, Packaging Deb and i18n do not have active
>>> contributions we can collect from git repos listed as project
>>> deliverables. For these projects, how can the election officials
>>> validate PTL candidacy and what would be the electorate roll in case of
>>> an election ?
>>
>> The electorate rolls for project-teams without any
>> deliverables/repos end up being limited to the "extra-atc" entries
>> for them. For example, the I18N team has done an excellent job of
>> providing a curated list of active translators, rendered at:
>>
>> http://governance.openstack.org/reference/projects/i18n.html#extra-atcs
>>
>> I guess for teams with no deliverables *and* no extra ATCs, they
>> probably also don't need a PTL?
>>
>> Packaging-Deb is the only one I see in an especially strange state
>> at the moment: it has one existing repo (the rest are phantoms which
>> were never created) with two Gerrit changes, both owned by the
>> team's sole code contributor (based on our traditional process of
>> enumerating Gerrit change owners)... Congratulations, Monty, on your
>> new de facto PTL-ship!
>>
>> https://review.openstack.org/#/q/status:merged+project:openstack/deb-openstack-pkg-tools
>>
>> Obviously, we'll need the TC to step in on unusual corner cases with
>> inactive/newly-minted teams, such as this one.
> 
> Hi there!
> 
> First, I'm surprised that nobody got in touch with me directly about
> this first, before this thread happens. But never mind, I'll explain
> what happened here.
> 
> tl;dr:
> The project can still be considered at the same state as it was 6 months
> ago. Ie: it's not started yet on OpenStack infra, but alive and working
> outside of it. The reason is simple: we still don't have a Debian image
> to work with within OpenStack infra, and even less the necessary tooling
> to build packages. I hope this will change in Newton, so please leave
> the project as it is.
> 

Thomas, if the TC and Monty agrees to give "Packaging Deb" project
another cycle to bootstrap, then what you proposed sounds fair and we
should keep the project as it is.

Note that we need an explicit approval since the current state basically
prevent the next PTL to be elected by the community.

Regards,
-Tristan






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] [puppet] weekly meeting #74 (take care of DST)

[Emilien Macchi]

We did our meeting, and you can read the notes here:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-03-15-15.01.html

See you next week!

On Mon, Mar 14, 2016 at 10:00 AM, Emilien Macchi <emil...@redhat.com> wrote:
> Hi,
>
> We'll have our weekly meeting tomorrow at 3pm UTC on
> #openstack-meeting4.
>
> Note: DST happened for some countries, so take care of that.
> Example, I'm in Canada/Quebec, the meeting was for me at 10am,
> tomorrow it will be 11am.
>
> https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack
>
> As usual, free free to bring topics in this etherpad:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160315
>
> We'll also have open discussion for bugs & reviews, so anyone is welcome
> to join.
>
> See you there,
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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] Wishlist bugs == (trivial) blueprint?

[Markus Zoeller]

Chris Dent  wrote on 03/15/2016 03:23:42 PM:

> From: Chris Dent 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 03/15/2016 03:24 PM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> On Tue, 15 Mar 2016, Matt Riedemann wrote:
> 
> > We do have a way for people to drop off RFEs/ideas for features 
without 
> > actually providing design details, which is the backlog specs:
> >
> > 
https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
> 
> In what universe is writing a backlog spec walking up and dropping
> an idea?
> 
> It's not necessarily a bad thing to have that level of friction, but
> it is something we should be aware of.

Having 2 channels to communicate an idea, both with different levels
of friction, the easier one will be used. And that's the bug list.
Instantly closing new "wishlist" bugs in the future leaves one channel
open. The friction of that channel is fine IMO.

> My take is that if we do have that level of friction then influence, in
> its many forms, will solely be mediated by the vendors that consume the
> upstream OpenStack community, or people who have the wherewithal to
> become embedded in the community. Is that fully healthy?

I don't understand this, could you rephrase it please?

> [...]
> 
> -- 
> Chris Dent   (�s°□°)�s�喋擤ォ�
http://anticdent.org/
> freenode: cdent tw: 
> 
@anticdent__
> 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

Regards, Markus Zoeller (markus_z)

__
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] [Ceilometer] Doubt about data recollection

[gordon chung]

On 15/03/2016 11:01 AM, Alberto Gutiérrez Torre wrote:
> What we would like to have is access to the data available in Ceilometer
> API but by local access. For instance, CPU metrics produced at a given
> node will be consumed in that same node. Probably we will not need all
> the available data we're yet finding which variables are of our
> interest. To start with, CPU usage and memory usage are mandatory.
>
> I believe that what we are searching is to access directly to compute
> agent data. Is this possible, for example, subscribing to  the RabbitMQ
> queue where the data is being published by the agent? Is there any other
> way to do so?

that's exactly one way to do it. the (compute) polling agents build a 
set of metrics for each poll and publishes them to message queue. the 
default consumer of these messages is the notification agent which 
processes the data further (if necessary) and redirects it to a storage 
or alternative target.

you can configure your compute agent publish to multiple queues by 
setting notification_topic = notifications, . or you can 
just disable notification agent and all other non compute agent services 
if all you want is the data

alternatively, you can use all the services and have the notification 
agent publish the data to a specific target. to do this, you'll need to 
edit pipeline.yaml file to send just compute agent metrics to where you 
want.

cheers,

-- 
gord

__
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] network_metadata hash keys on astute.yaml

[Sergey Vasilenko]

Keys should be immutable.

If keys are not immutable -- it can lead to the situation, when
network_metadata/nodes contains two records for same nodes (with same UID),
but with different information.

/sv
__
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] [keystone] PTL candidacy

[Steve Martinelli]

Hey everyone,

I'd like to continue to serve as the Keystone PTL for the Newton release. I
found serving as PTL for the Mitaka release to be an extremely rewarding
experience where I learned a lot about myself and the project. I’d like to
continue what I’ve learned and serve as PTL again. I am also fortunate
enough to work for an employer where I can dedicate 100% of my time to
upstream contributions. With all that said, I believe I'm even more
prepared to go at it again!

We met a lot of goals from my original mission statement [0] and snuck in a
few other features that were not listed, you can read the Mitaka recap here
[1]. We completed 16 blueprints; ended Mitaka with a very low bug count
(down from over 300 to 107); and nominated two new core members. I'm very
proud of the work the entire team did during the Mitaka development cycle.
I know it's been said many times before but this is a really special team
and I'm lucky to be a part of it.

For the Newton development cycle I'd like to continue down the path of
making Keystone more enterprise ready by advocating for solid, well-defined
and realistic use cases for features that actually help end users. This
includes support for Multi-Factor Authentication.

Within Keystone I think it's critical that we finally deliver on our
promise of a functional tests for our advanced features such as federated
identify, notifications and multiple backends (LDAP and SQL).

Lastly, we have clear cross-project deficiencies that need to be addressed.
Creating a new standardized Service Catalog to improve interoperability,
and changing our Policy and Authorization for a better user experience are
critical.  These are huge cross-project efforts that will need a lot of
time and dedicated resources.

I think we're getting closer to all of these goals with each passing
release and would like to continue to take us there. Our core team is
fantastic and experienced, I like to think I bring organization, structure
and direction to the team. I’d like to continue to play to my strengths and
accomplish the goals I have stated above.

This can also be viewed in the election repo [2]

[0]
https://review.openstack.org/#/c/222766/1/candidates/mitaka/Keystone/Steve_Martinelli.txt

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089387.html
[2] https://review.openstack.org/#/c/292982/

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead
__
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] Rewriting nailgun agent on Python proposal

[Sylwester Brzeczkowski]

+1 to drop nailgun-agent and replace it with python script with ohai call
or ironic-inspector!

On Tue, Mar 15, 2016 at 1:07 PM, Alexander Saprykin 
wrote:

> Dear all,
>
> Thank you for the opinions about this problem.
>
> I would agree with Roman, that it is always better to reuse solutions than
> re-inventing the wheel. We should investigate possibility of using
> ironic-inspector and integrating it into fuel.
>
> Best regards,
> Alexander Saprykin
>
> 2016-03-15 13:03 GMT+01:00 Sergii Golovatiuk :
>
>> My strong +1 to drop off nailgun-agent completely in favour of
>> ironic-inspector. Even taking into consideration we'lll need to
>> extend  ironic-inspector for fuel needs.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko 
>> wrote:
>>
>>> My opition on this is that we have too many re-invented wheels in Fuel
>>> and it’s better think about replacing them with something we can re-use
>>> than re-inventing them one more time.
>>>
>>> Let’s take a look at Ironic and try to figure out how we can use its
>>> features for the same purpose.
>>>
>>>
>>> - romcheg
>>> > 15 бер. 2016 р. о 10:38 Neil Jerram 
>>> написав(ла):
>>> >
>>> > On 15/03/16 07:11, Vladimir Kozhukalov wrote:
>>> >> Alexander,
>>> >>
>>> >> We have many other places where use Ruby (astute, puppet custom types,
>>> >> etc.). I don't think it is a good reason to re-write something just
>>> >> because it is written in Ruby. You are right about tests, about
>>> plugins,
>>> >> but let's look around. Ironic community has already invented discovery
>>> >> component (btw written in python) and I can't see any reason why we
>>> >> should continue putting efforts in nailgun agent and not try to switch
>>> >> to ironic-inspector.
>>> >
>>> > +1 in general terms.  It's strange to me that there are so many
>>> > OpenStack deployment systems that each do each piece of the puzzle in
>>> > their own way (Fuel, Foreman, MAAS/Juju etc.) - and which also means
>>> > that I need substantial separate learning in order to use all these
>>> > systems.  It would be great to see some consolidation.
>>> >
>>> > Regards,
>>> >   Neil
>>> >
>>> >
>>> >
>>> __
>>> > 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
>
>


-- 
*Sylwester Brzeczkowski*
Python Software Engineer
Product Development-Core : Product Engineering
__
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] [keystone] mitaka release recap

[Steve Martinelli]

Before beginning, I'd like to thank all members of the Keystone community.
The Mitaka release would not be possible without the many dedicated
contributors to the Keystone project. This was a great development cycle
and I’m very happy with the finished product. Here’s the Keystone Mitaka
release at a glance.

*Features*
In total, we completed 16 blueprints/specs in the Mitaka release. We bumped
2 to the Newton release. Some of the more interesting features are:
  - Time-based one-time password (TOTP)
  - Implied roles
  - Domain specific roles
  - Shadow users
  - Bootstrap via keystone-manage
For a comprehensive list of complete features and additional information
please refer to our specs page.
Source: http://specs.openstack.org/openstack/keystone-specs/

*Community*
We added 2 new core members to the team, Dave Chen and Samuel de Medeiros
Queiroz. I’d like to once again thank them for their support during the
development cycle.
Source:
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085170.html

*Bugs*
We started to perform weekly bug squashes and triages. We _actually_ did
them, consistently too. I’m very happy to say that Keystone’s bug count is
the lowest it has been in a long time, with 107 open bugs to date. A far
cry from the 300 when Mitaka started. This is a small victory that we can
be proud of that gives us a sense of completion.
Source: http://status.openstack.org/bugday/ and
https://bugs.launchpad.net/keystone

*Consolidation*
A large factor that made the above possible is the removal or deprecation
of certain features. This includes, but is not limited to:
  - LDAP write support for users and groups -- deprecated
  - PKI tokens -- deprecated
  - Using LDAP as a store for projects and roles -- removed
Source:
http://lists.openstack.org/pipermail/openstack-operators/2015-November/009019.html


*Libraries*
We made great strides in the adoption of keystoneauth. Both novaclient and
neutronclient are now using our new keystoneauth library, with many other
projects working on patches to do the same.
Source: https://review.openstack.org/#/c/236325/ and
https://review.openstack.org/#/c/256056/

*Release notes*
A comprehensive list of release notes can be viewed here:
http://docs.openstack.org/releasenotes/keystone/unreleased.html or here
http://docs.openstack.org/releasenotes/keystone/mitaka.html (depending on
when you view them)

To everyone who participated in contributing to Keystone during the Mitaka
release, I cannot thank you enough for your time and effort.

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead
__
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] Wishlist bugs == (trivial) blueprint?

[Markus Zoeller]

Sean Dague  wrote on 03/15/2016 02:52:47 PM:

> From: Sean Dague 
> To: openstack-dev@lists.openstack.org
> Date: 03/15/2016 02:53 PM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> On 03/15/2016 09:37 AM, Chris Dent wrote:
> > On Tue, 15 Mar 2016, Markus Zoeller wrote:
> > 
> >> Long story short, I'm in favor of abandoning the use of "wishlist"
> >> as an importance in bug reports to track requests for enhancements.
> > 
> > While I'm very much in favor of limiting the amount of time issues
> > (of any sort) linger in launchpad[1] I worry that if we stop making
> > "wishlist" available as an option then people who are not well
> > informed about the complex system for achieving features in Nova
> > will have no medium to get their ideas into the system. We want
> > users to sometime be able to walk up, drop an idea and move on without
> > having to be responsible for actually doing that work. If we insist
> > that such ideas must go through the blueprint process then most
> > ideas will be left unstated.
> 
> I believe that 0% of such drive by wishlist items ever get implemented.
> I also think they mostly don't even get ACKed until 6 or 12 months after
> submission. So It's not really a useful feedback channel.
> 
> So I'm pro just closing Wishlist items as Opinion and moving on.
> Probably with some boiler plate around it about submission guidelines
> for making a lightweight blueprint.

A few more specific numbers which could help to make a decission.
Open wishlist bug reports older than:
>   now: 146
>  6 months: 141
> 12 months: 122

Wishlist bug reports in progress: 9
Wishlist bug reports implemented:
46 (last 24 months)
25 (last 18 months)
19 (last 12 months)
 5 (last  6 months)

Based on that it seems to me that it is not a very successful 
channel to get ideas implemented(!). The dropping is easy though.

Based on that I'm very much in favor of the agressive choice to close 
the remaining 146 wishlist bugs with a comment which explains how to
go on from there (using backlog specs).

> > What I think we need to do instead is fix this problem:
> > 
> >> * we don't have a process to transform wishlist bugs to blueprints
> > 
> > such that we do have a process of some kind where a wishlist idea
> > either gets an owner who starts the blueprint process (because it is
> > just that cool) or dies from lack of attention.
> > 
> > It's clear, though, that we already have a huge debt in bug/issue
> > management so adding yet another task is hard to contemplate.
> > 
> > I think we can address some of that by more quickly expiring bugs
> > that have had no recent activity or attention, on the assumption
> > that:
> > 
> > * They will come back up again if they are good ideas or real bugs.
> > * Lack of attention is a truthy signal of either lack of resources or 
lack
> >   of importance.
> > 
> > What needs to happen is that fewer things which are not actionable
> > or nobody is interested in show up when traversing the bugs looking
> > for something to work on.
> > 
> > I'm happy to help some of this become true, in part because of [1]
> > below.
> > 
> > [1] I've recently spent a bit of time chasing bugs tagged
> > "scheduler" and far too many of them are so old that it's impossible
> > to tell whether they matter any more, and many of them are confused
> > by patches and people who have gone in and out of existence. It's
> > challenging to tease out what can be done and the information has
> > very little archival value. It should go off the radar. Having a
> > bunch of stuff that looks like it needs to be done but never
> > actually is is stop energy and depressing.
> 
> Agreed. At 1000 open artifacts (many of them bad), you can't keep enough
> context in your head at once to know things are really issues or not,
> and once they get old enough they are lost to the mists of time. Having
> a smaller high quality bug list would make it more of a todo list, which
> would be nice for both experienced folks in the project, and new people
> looking to contribute something off the bat.
> 
>-Sean

True, that's a goal we should aim for. The old bug reports bind
unnecessarily resources. 

Regards, Markus Zoeller (markus_z)


__
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] Wishlist bugs == (trivial) blueprint?

[Markus Zoeller]

Chris Dent  wrote on 03/15/2016 02:37:45 PM:

> From: Chris Dent 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 03/15/2016 02:38 PM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> On Tue, 15 Mar 2016, Markus Zoeller wrote:
> 
> > Long story short, I'm in favor of abandoning the use of "wishlist"
> > as an importance in bug reports to track requests for enhancements.
> 
> While I'm very much in favor of limiting the amount of time issues
> (of any sort) linger in launchpad[1] I worry that if we stop making
> "wishlist" available as an option then people who are not well
> informed about the complex system for achieving features in Nova
> will have no medium to get their ideas into the system. We want
> users to sometime be able to walk up, drop an idea and move on without
> having to be responsible for actually doing that work. If we insist
> that such ideas must go through the blueprint process then most
> ideas will be left unstated.
> 
> What I think we need to do instead is fix this problem:
> 
> > * we don't have a process to transform wishlist bugs to blueprints
> 
> such that we do have a process of some kind where a wishlist idea
> either gets an owner who starts the blueprint process (because it is
> just that cool) or dies from lack of attention.
> 
> It's clear, though, that we already have a huge debt in bug/issue
> management so adding yet another task is hard to contemplate.
> 
> I think we can address some of that by more quickly expiring bugs
> that have had no recent activity or attention, on the assumption
> that:
> 
> * They will come back up again if they are good ideas or real bugs.
> * Lack of attention is a truthy signal of either lack of resources or 
lack
>of importance.
> 
> What needs to happen is that fewer things which are not actionable
> or nobody is interested in show up when traversing the bugs looking
> for something to work on.

Regarding the expiration of bug reports, I have [1] in the pipeline
which had a proposal there at the end. It's something I'd like to
discuss at the summit. Right now I'm focusing on the "wishlist" ones.

> [...]

References:
[1] https://review.openstack.org/#/c/266453/2/doc/source/bug_process.rst

Regards, Markus Zoeller (markus_z)


__
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] network_metadata hash keys on astute.yaml

[Aleksey Kasatkin]

Hi,

I'm agree with Alex, keys should remain immutable. 'node-{uid}' is Okay, we
have a method for this in Nailgun already. It should be a very simple fix
in Nailgun.

Thanks,


Aleksey Kasatkin


On Tue, Mar 15, 2016 at 3:19 PM, Kyrylo Galanov 
wrote:

> Hi,
>
> I would like to remind that we are close to code freeze and bug is still
> there. Moreover, new bug reports continue to be submitted [3].
> Please, do not ignore the discussion.
>
> [3] https://bugs.launchpad.net/fuel/+bug/1557417
>
> On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko  > wrote:
>
>> Hi,
>>
>> some additional info on the problem: if I create some Hiera override for
>> the nodes list and use node key which is hostname bond, then after node
>> rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
>> override will create a "ghost" node in the list and will not change
>> settings I wanted to change. So node keys in that hash should remain
>> immutable.
>>
>> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
>> was working before (and does not require new patches like [0]) and we're
>> too late in the release cycle to change keys to '{uid}'.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/284046/
>>
>> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
>> wrote:
>>
>>> Hi,
>>>
>>> Currently nailgun and puppet process network_metadata hash slightly
>>> different.
>>> Nailgun uses short hostname as a hash key for each node, while library
>>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>>> deployment failure.
>>>
>>> During code review[0] it turned out that there are two points of view,
>>> which approach is correct [1].
>>> Both are one-line fixes, however it have been lasting too long with no
>>> result.
>>>
>>> I would like to start a discussion with a hope to close the issue
>>> shortly.
>>>
>>> Best regards.
>>> Kyrylo
>>>
>>> [0] https://review.openstack.org/#/c/284046/
>>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>>
>>>
>>> __
>>> 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-dev] [telemetry] PTL Candidacy

[Julien Danjou]

Hi there,

The Telemetry project had a tremendous run so far, and I'm willing to help it
continue on that trajectory. We have an awesome community, and we had the
chance to be led by great leaders so far, which directed the team and projects
in an open and enthusiast manner.

Our previous PTL helped the community to grow in a fabulous way over the last 2
cycles, and I'm glad to be able to follow his footsteps. As you may know, I've
already been Ceilometer PTL during the Havana and Icehouse cycles, and it'd be
with a great pleasure that I would take up the torch again. I'll continue to
manage the project in a transparent way and do everything I can to grow our
community and make people feel welcome.

Looking forward to Newton, I hope we'll be able to continue improving our
deliverables. Some items I'd like to target are:

- Continue splitting Ceilometer into smaller parts. Aodh has been a success,
  it's time to create another one.

- Continue code refactoring and technical debt addressing. We're probably one
  of the most aggressive and efficient project on that, but that gives us an
  amazing outlook.

- Reduce Ceilometer hard-coupling to OpenStack projects.
  We applied this strategy from scratch to Gnocchi, and to some extent to Aodh,
  with great success. Let's continue that.

Candidacy review: https://review.openstack.org/#/c/292935/

Cheers,
-- 
Julien Danjou
# Free Software hacker
# https://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] [Ceilometer] Doubt about data recollection

[Alberto Gutiérrez Torre]

Hello Gordon,

Thanks for your reply.

What we would like to have is access to the data available in Ceilometer
API but by local access. For instance, CPU metrics produced at a given
node will be consumed in that same node. Probably we will not need all
the available data we're yet finding which variables are of our
interest. To start with, CPU usage and memory usage are mandatory.

I believe that what we are searching is to access directly to compute
agent data. Is this possible, for example, subscribing to  the RabbitMQ
queue where the data is being published by the agent? Is there any other
way to do so?

Thanks for your support.

Best regards,
Alberto.

On 15/03/16 15:39, gordon chung wrote:
>
> On 07/03/2016 11:47 AM, Alberto Gutiérrez Torre wrote:
>> Hello,
>>
>> Istarted working with OpenStack's ceilometer recently and I have some
>> questions that I can not resolve with the documentation I have found.
>>
>> I would like to have the telemetry of a node inside the node itself (for
>> example, a virtual machine that resides in that node and processes the
>> local information in some way) without passing through the global scope
>> (Ceilometer API with the default settings). Is it possible? I have read
>> about agent plugins and it may be a way to approach to the solution
>> (http://docs.openstack.org/developer/ceilometer/contributing/plugins.html).
> sorry, missed this while we were busy with release. can you clarify what 
> data you want? we currently have different agents that gather metrics in 
> various ways.
>
> polling agents - periodic querying of various apis
>   - compute/ipmi agents - exist on host and query for host and guest 
> level metrics
>   - central agent - exist usually on controller node and query service 
> apis
>
> notification agents - listens to service queues for any messages published.
>
> cheers,
>


WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

__
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] [Glance][Artifacts] Current status of Glance artifacts

[Mikhail Fedosin]

Hi! Thank you for your interest in Glare. I'm leading this project and I'll
try to answer your questions :)

Glare is a new service under Glance repo which previously was called Glance
v3, now it's experimental Glare v0.1 api. It has a devstack support, so you
can deploy it with setting ENABLED_SERVICES=g-glare in your localrc file.
At the moment only Murano uses v0.1 as an optional backend for its
packages, but in common case it's not recommended for real deployments.

While we were working on the service we got a lot of advice and suggestions
from community and API-WG about how we can improve our api. We collected
them all and started implementing stable Glare api - v1 [1]. Currently
stable Glare is under active development, skeleton is almost here [2] and I
think we can organize public POC demo next week (it will be announced later
on Friday). More details and functionality will be presented on Newton
summit.

Our plan is stabilize Glare as much as possible and merge it in Newton.
Then in Ocata add Glare's v1 support in Nova and other services like Heat,
Sahara, App Catalog, Tacker, Murano, Mistral and so on.

If you have any other questions you can ask here or visit our weekly irc
meeting on Monday at 1730 UTC in #openstack-meeting-alt [3].

Best regards,
Mikhail Fedosin

[1] https://review.openstack.org/#/c/283136/
[2] https://review.openstack.org/#/c/292327/
[3]
https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda

On Tue, Mar 15, 2016 at 3:12 AM, Ramakrishna, Deepti <
deepti.ramakris...@intel.com> wrote:

> Hi all,
>
> I have some questions around the current status of Artifacts (Glare) in
> Glance.
>
> 1. From briefly poking around, I found [1] to be the most current BP for
> implementing artifacts. I see few work items like declarative definitions
> of artifact types, adding database layer, plugins loader etc (I assume all
> the work items which makes this feature alive) have already been merged.
> But for other patches like [2] which is meant for adding Glare client has
> been on hold until there is a better understanding of Glare APIs. I also
> see from Mitaka mid-cycle meetup [3] that there were few artifact tasks
> which were missed out for Mitaka and some more Glare API discussions
> planned targeting Newton.
> Where can I find the *exact* list of work items and their ETAs?
>
> 2. Is it production ready? Is there any service using artifacts right now?
> I did see a response to this question here [4] where Alexander mentioned
> that "Murano stores its packages in Glance since the Liberty release. There
> is a plan to create a plugin for Heat packages, but the Heat team has
> decided to wait till the API is stable (this should happen during the
> Mitaka cycle)". How stable are these APIs now as we are approaching the end
> of Mitaka cycle?
>
> Sorry for being naïve since I am just a day old to Glare :)
>
> Thanks,
> Deepti
>
> [1] https://blueprints.launchpad.net/glance/+spec/artifact-repository
> [2] https://review.openstack.org/#/c/255220/
> [3] https://etherpad.openstack.org/p/glance-mitaka-virtual-mid-cycle
> [4]
> https://www.mirantis.com/blog/glance-api-v3-and-the-openstack-community-app-catalog/
>
> __
> 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] [Ceilometer] Doubt about data recollection

[gordon chung]

On 07/03/2016 11:47 AM, Alberto Gutiérrez Torre wrote:
> Hello,
>
> Istarted working with OpenStack's ceilometer recently and I have some
> questions that I can not resolve with the documentation I have found.
>
> I would like to have the telemetry of a node inside the node itself (for
> example, a virtual machine that resides in that node and processes the
> local information in some way) without passing through the global scope
> (Ceilometer API with the default settings). Is it possible? I have read
> about agent plugins and it may be a way to approach to the solution
> (http://docs.openstack.org/developer/ceilometer/contributing/plugins.html).

sorry, missed this while we were busy with release. can you clarify what 
data you want? we currently have different agents that gather metrics in 
various ways.

polling agents - periodic querying of various apis
- compute/ipmi agents - exist on host and query for host and guest 
level metrics
- central agent - exist usually on controller node and query service 
apis

notification agents - listens to service queues for any messages published.

cheers,

-- 
gord

__
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] Wishlist bugs == (trivial) blueprint?

[Chris Dent]

On Tue, 15 Mar 2016, Matt Riedemann wrote:

We do have a way for people to drop off RFEs/ideas for features without 
actually providing design details, which is the backlog specs:


https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html


In what universe is writing a backlog spec walking up and dropping
an idea?

It's not necessarily a bad thing to have that level of friction, but
it is something we should be aware of.

My take is that if we do have that level of friction then influence, in
its many forms, will solely be mediated by the vendors that consume the
upstream OpenStack community, or people who have the wherewithal to
become embedded in the community. Is that fully healthy?

Sean said:

I believe that 0% of such drive by wishlist items ever get implemented.
I also think they mostly don't even get ACKed until 6 or 12 months after
submission. So It's not really a useful feedback channel.


That's a shame.

[snip]

Matt said:
We need to shrink the nova bug backlog. I'd say any wishlist bugs that are 
open for over a year (maybe even 6 months) should be marked Invalid with a 
comment saying to file a blueprint or a backlog spec (with links on how to do 
that).


Sean said:

Agreed. At 1000 open artifacts (many of them bad), you can't keep
enough context in your head at once to know things are really issues
or not, and once they get old enough they are lost to the mists of
time. Having a smaller high quality bug list would make it more of a
todo list, which would be nice for both experienced folks in the
project, and new people looking to contribute something off the bat.


I think whatever timegap we use for expiring stuff it should _not_
be on anything resembling the length of a cycle. It should be a bit
shorter so as to keep the ebb and flow of the bug handling on its
own flow: something that anybody can do in the gaps of whatever else
they are doing without regard to the cycle's handling of features.

But yes, some kind of expiration of the backlog would be great. I'll
start doing what I can when I see it.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] Wishlist bugs == (trivial) blueprint?

[Sylvain Bauza]

Le 15/03/2016 14:48, Matt Riedemann a écrit :



On 3/15/2016 8:37 AM, Chris Dent wrote:

On Tue, 15 Mar 2016, Markus Zoeller wrote:


Long story short, I'm in favor of abandoning the use of "wishlist"
as an importance in bug reports to track requests for enhancements.


While I'm very much in favor of limiting the amount of time issues
(of any sort) linger in launchpad[1] I worry that if we stop making
"wishlist" available as an option then people who are not well
informed about the complex system for achieving features in Nova
will have no medium to get their ideas into the system. We want
users to sometime be able to walk up, drop an idea and move on without
having to be responsible for actually doing that work. If we insist
that such ideas must go through the blueprint process then most
ideas will be left unstated.


We do have a way for people to drop off RFEs/ideas for features 
without actually providing design details, which is the backlog specs:


https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html



I tend to agree, we could just put either opinion/wishlist or 
invalid/wishlist and gently ask the bug reporter to open at least a 
blueprint.


I'm not sure a backlog spec for a tiny RFE is worthwhile, because it 
would generate a lot of changes up to nova-specs tho, but in case we see 
some Launchpad blueprint needing a backlog spec, we could then invalid 
the blueprint and ask for a backlog spec instead.


-Sylvain



What I think we need to do instead is fix this problem:


* we don't have a process to transform wishlist bugs to blueprints


such that we do have a process of some kind where a wishlist idea
either gets an owner who starts the blueprint process (because it is
just that cool) or dies from lack of attention.

It's clear, though, that we already have a huge debt in bug/issue
management so adding yet another task is hard to contemplate.

I think we can address some of that by more quickly expiring bugs
that have had no recent activity or attention, on the assumption
that:

* They will come back up again if they are good ideas or real bugs.
* Lack of attention is a truthy signal of either lack of resources or 
lack

   of importance.

What needs to happen is that fewer things which are not actionable
or nobody is interested in show up when traversing the bugs looking
for something to work on.

I'm happy to help some of this become true, in part because of [1]
below.

[1] I've recently spent a bit of time chasing bugs tagged
"scheduler" and far too many of them are so old that it's impossible
to tell whether they matter any more, and many of them are confused
by patches and people who have gone in and out of existence. It's
challenging to tease out what can be done and the information has
very little archival value. It should go off the radar. Having a
bunch of stuff that looks like it needs to be done but never
actually is is stop energy and depressing.



__ 


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



We need to shrink the nova bug backlog. I'd say any wishlist bugs that 
are open for over a year (maybe even 6 months) should be marked 
Invalid with a comment saying to file a blueprint or a backlog spec 
(with links on how to do that).





__
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] [freezer] Freezer meeting on 17/04 is CANCELED

[Ramirez Garcia, Guillermo]

due to bank holiday in Ireland the freezer meeting for this week will be 
canceled. we’ll be back next week as usual.

Regards
Guillermo
__
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][novaclient]novaclient backward compatible changes

[Sean Dague]

On 03/15/2016 10:02 AM, Chen CH Ji wrote:
> From [1], some questions raised is whether and how we will guarantee the
> return value of novaclient? e.g some tools
> such as openstackclient utilize novaclient return value , we don't have
> microversion mechanism (and seems not helpful
> and too heavy) to do those kind of changes... so novaclient should make
> every changes backward compatible?
> 
> BTW: [1] seems not mandatory(better to have), so the question is related
> to the patch, just for general idea..
> 
> [1] https://review.openstack.org/#/c/291915/1

Yes, this is a library. Changing the return value on existing functions
isn't a thing you can do. If you want a different return, introduce a
new method which does that, and we can deprecate the old one out over time.

-Sean

-- 
Sean Dague
http://dague.net

__
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][novaclient]novaclient backward compatible changes

[Chen CH Ji]

 From [1], some questions raised is whether and how we will guarantee the return value of novaclient? e.g some toolssuch as openstackclient utilize novaclient return value , we don't have microversion mechanism (and seems not helpfuland too heavy) to do those kind of changes... so novaclient should make every changes backward compatible?BTW: [1] seems not mandatory(better to have), so the question is related to the patch, just for general idea..[1] https://review.openstack.org/#/c/291915/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] [Murano] [FFE] Support for Magnum Plugin

[Madhuri]

Thank you all for the acceptance.

Regards,
Madhuri

On Mon, Mar 14, 2016 at 10:09 PM, Serg Melikyan 
wrote:

> Granted
>
> On Mon, Mar 14, 2016 at 4:09 AM, Nikolay Starodubtsev <
> nstarodubt...@mirantis.com> wrote:
>
>> Hi,
>> I don't like when we need to break rules, but in this case I agree with
>> Kirill. As far as the plugin is not something which can broke general
>> murano functionality, I'm for FFE.
>>
>>
>>
>> Nikolay Starodubtsev
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>>
>> Skype: dark_harlequine1
>>
>> 2016-03-14 11:58 GMT+03:00 Kirill Zaitsev :
>>
>>> I’m going to advocate for this FFE. Even though it’s very late to ask
>>> for FFE, I believe, that this commit is very low-risk/high reward (the
>>> plugin is not enabled by default). I believe that code is in good shape (I
>>> remember +2 it at some point) and would very much like to see this in.
>>>
>>> Serg, do you have any objections?
>>>
>>> --
>>> Kirill Zaitsev
>>> Software Engineer
>>> Mirantis, Inc
>>>
>>> On 14 March 2016 at 11:55:46, Madhuri (madhuri.ra...@gmail.com) wrote:
>>>
>>> Hi All,
>>>
>>> I would like to request a feature freeze exception for "Magnum/Murano
>>> rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster.
>>> The patch is on review[2].
>>> I am looking for your decision about considering this change for a FFE.
>>>
>>> [1]
>>> https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization
>>> [2] https://review.openstack.org/#/c/269250/
>>>
>>> Regards,
>>> Madhuri
>>> __
>>>
>>> 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
>>
>>
>
>
> --
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
>
> __
> 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] [magnum-ui] Proposed Core addition, and removal notice

[Adrian Otto]

Hi,

Voting has concluded. Welcome, Shu Muto to the magnum-UI core team! I will 
announce your new status at today's team meeting.

Thanks,

Adrian

> On Mar 14, 2016, at 5:40 PM, Shuu Mutou  wrote:
> 
> Hi team, 
> 
> Thank you very much for vote to me.
> I'm looking forward to work more with our peers.
> However, when is the end of this vote?
> 
> Shu Muto
> 
> __
> 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] [nova] Wishlist bugs == (trivial) blueprint?

[Sean Dague]

On 03/15/2016 09:37 AM, Chris Dent wrote:
> On Tue, 15 Mar 2016, Markus Zoeller wrote:
> 
>> Long story short, I'm in favor of abandoning the use of "wishlist"
>> as an importance in bug reports to track requests for enhancements.
> 
> While I'm very much in favor of limiting the amount of time issues
> (of any sort) linger in launchpad[1] I worry that if we stop making
> "wishlist" available as an option then people who are not well
> informed about the complex system for achieving features in Nova
> will have no medium to get their ideas into the system. We want
> users to sometime be able to walk up, drop an idea and move on without
> having to be responsible for actually doing that work. If we insist
> that such ideas must go through the blueprint process then most
> ideas will be left unstated.

I believe that 0% of such drive by wishlist items ever get implemented.
I also think they mostly don't even get ACKed until 6 or 12 months after
submission. So It's not really a useful feedback channel.

So I'm pro just closing Wishlist items as Opinion and moving on.
Probably with some boiler plate around it about submission guidelines
for making a lightweight blueprint.

> What I think we need to do instead is fix this problem:
> 
>> * we don't have a process to transform wishlist bugs to blueprints
> 
> such that we do have a process of some kind where a wishlist idea
> either gets an owner who starts the blueprint process (because it is
> just that cool) or dies from lack of attention.
> 
> It's clear, though, that we already have a huge debt in bug/issue
> management so adding yet another task is hard to contemplate.
> 
> I think we can address some of that by more quickly expiring bugs
> that have had no recent activity or attention, on the assumption
> that:
> 
> * They will come back up again if they are good ideas or real bugs.
> * Lack of attention is a truthy signal of either lack of resources or lack
>   of importance.
> 
> What needs to happen is that fewer things which are not actionable
> or nobody is interested in show up when traversing the bugs looking
> for something to work on.
> 
> I'm happy to help some of this become true, in part because of [1]
> below.
> 
> [1] I've recently spent a bit of time chasing bugs tagged
> "scheduler" and far too many of them are so old that it's impossible
> to tell whether they matter any more, and many of them are confused
> by patches and people who have gone in and out of existence. It's
> challenging to tease out what can be done and the information has
> very little archival value. It should go off the radar. Having a
> bunch of stuff that looks like it needs to be done but never
> actually is is stop energy and depressing.

Agreed. At 1000 open artifacts (many of them bad), you can't keep enough
context in your head at once to know things are really issues or not,
and once they get old enough they are lost to the mists of time. Having
a smaller high quality bug list would make it more of a todo list, which
would be nice for both experienced folks in the project, and new people
looking to contribute something off the bat.

-Sean

-- 
Sean Dague
http://dague.net

__
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] propose ejuaso for core

[Jay Dobies]

On 03/14/2016 10:38 AM, Dan Prince wrote:

http://russellbryant.net/openstack-stats/tripleo-reviewers-180.txt

Our top reviewer over the last half a year ejuaso (goes by Ozz for
Osorio or jaosorior on IRC). His reviews seem consistent, he
consistently attends the meetings and he chimes in on lots of things.
I'd like to propose we add him to our core team (probably long overdue
now too).

If you agree please +1. If there is no negative feedback I'll add him
next Monday.


+1


Dan

__
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] Question about electorate for project without gerrit contribution

[Thomas Goirand]

On 03/11/2016 12:45 AM, Jeremy Stanley wrote:
> On 2016-03-10 22:05:00 + (+), Tristan Cacqueray wrote:
>> Projects such as Openstack UX, Packaging Deb and i18n do not have active
>> contributions we can collect from git repos listed as project
>> deliverables. For these projects, how can the election officials
>> validate PTL candidacy and what would be the electorate roll in case of
>> an election ?
> 
> The electorate rolls for project-teams without any
> deliverables/repos end up being limited to the "extra-atc" entries
> for them. For example, the I18N team has done an excellent job of
> providing a curated list of active translators, rendered at:
> 
> http://governance.openstack.org/reference/projects/i18n.html#extra-atcs
> 
> I guess for teams with no deliverables *and* no extra ATCs, they
> probably also don't need a PTL?
> 
> Packaging-Deb is the only one I see in an especially strange state
> at the moment: it has one existing repo (the rest are phantoms which
> were never created) with two Gerrit changes, both owned by the
> team's sole code contributor (based on our traditional process of
> enumerating Gerrit change owners)... Congratulations, Monty, on your
> new de facto PTL-ship!
> 
> https://review.openstack.org/#/q/status:merged+project:openstack/deb-openstack-pkg-tools
> 
> Obviously, we'll need the TC to step in on unusual corner cases with
> inactive/newly-minted teams, such as this one.

Hi there!

First, I'm surprised that nobody got in touch with me directly about
this first, before this thread happens. But never mind, I'll explain
what happened here.

tl;dr:
The project can still be considered at the same state as it was 6 months
ago. Ie: it's not started yet on OpenStack infra, but alive and working
outside of it. The reason is simple: we still don't have a Debian image
to work with within OpenStack infra, and even less the necessary tooling
to build packages. I hope this will change in Newton, so please leave
the project as it is.

Longer version:

To build packages on Debian, we need a Debian image to work with on
OpenStack infra. I've been told to do it on the Ubuntu image, but I
don't think that's viable, as I also run tempest on it to validate the
packaging, and that runs on top of Debian (I haven't tested it on
Ubuntu). I don't mind to *also* work on it on Ubuntu, but my priority
and motivation here is Debian mostly.

What's going on with the Debian image:
==
After Tokyo, I've been told by a few persons from infra, that I'd get
help. This help never came, so I started a CR to add the Debian image.
As I didn't know well enough the OpenStack infra and DIB, it wasn't done
well, and Igor Belikov took it over.

The review which is currently stuck is that one:
https://review.openstack.org/#/c/264726/

It was supposed to be waiting on that one:
https://review.openstack.org/#/c/211859/

It's been nearly 3 months now that we're still stuck there.

Though Greg appeared to be busy (personal reasons), and couldn't work on
#211859, recently, Igor Belikov (who kindly took over #264726 which I
couldn't do myself) wrote that, thanks to a commit from Monty in DIB, we
could get rid of the #211859 depends. I'm still waiting on Igor to
un-depend #211859, so we can get going. Hopefully, we'll get the Debian
image to work before the Austin summit.

The plan for the future:

Once we finally get a Debian image, then we'll be able to add jobs to
actually build packages. Most of the scripting is already written and
used in that Jenkins which we're using, so it shouldn't be too hard to
figure out. Once I get the idea on how to hook the build scripts, it
should be a lot more easy for me to write it. At least a lot more easy
than the DIB elements.

And then store the resulting artifacts somewhere on infra, so that other
packages can (build-)depends on them. There, I'll need also some help
from the infra team, to see how this can be done.

As you see, all of the issues aren't on the packaging itself, but just
on understanding how infra works, and how to be setup.

Where's the commits?

Because there's nothing to test the commits against (ie: packages aren't
even built in upstream infra), then it makes very little sense to push
changes to the OpenStack gerrit. Instead, all has been done as we used
to, within the git on alioth.debian.org. Once a commit is pushed, it
triggers a package build (in both Jessie and Trusty) in the Jenkins
servers sponsored by Mirantis, with the result published on IRC (in
#debian-openstack-commits on OFTC). That's exactly what we hoped to get
away from, though this continues to work, and that's the only thing
we've got. And there, I understand everything, and have root access on
the servers.

If you consider git commit statistics there, then it's FAR from being
zero commits. There's in fact commits every day on it. If we want to
gather stats there, then that's a very good starting point.

As 

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

[Matt Riedemann]

On 3/15/2016 8:37 AM, Chris Dent wrote:

On Tue, 15 Mar 2016, Markus Zoeller wrote:


Long story short, I'm in favor of abandoning the use of "wishlist"
as an importance in bug reports to track requests for enhancements.


While I'm very much in favor of limiting the amount of time issues
(of any sort) linger in launchpad[1] I worry that if we stop making
"wishlist" available as an option then people who are not well
informed about the complex system for achieving features in Nova
will have no medium to get their ideas into the system. We want
users to sometime be able to walk up, drop an idea and move on without
having to be responsible for actually doing that work. If we insist
that such ideas must go through the blueprint process then most
ideas will be left unstated.


We do have a way for people to drop off RFEs/ideas for features without 
actually providing design details, which is the backlog specs:


https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html



What I think we need to do instead is fix this problem:


* we don't have a process to transform wishlist bugs to blueprints


such that we do have a process of some kind where a wishlist idea
either gets an owner who starts the blueprint process (because it is
just that cool) or dies from lack of attention.

It's clear, though, that we already have a huge debt in bug/issue
management so adding yet another task is hard to contemplate.

I think we can address some of that by more quickly expiring bugs
that have had no recent activity or attention, on the assumption
that:

* They will come back up again if they are good ideas or real bugs.
* Lack of attention is a truthy signal of either lack of resources or lack
   of importance.

What needs to happen is that fewer things which are not actionable
or nobody is interested in show up when traversing the bugs looking
for something to work on.

I'm happy to help some of this become true, in part because of [1]
below.

[1] I've recently spent a bit of time chasing bugs tagged
"scheduler" and far too many of them are so old that it's impossible
to tell whether they matter any more, and many of them are confused
by patches and people who have gone in and out of existence. It's
challenging to tease out what can be done and the information has
very little archival value. It should go off the radar. Having a
bunch of stuff that looks like it needs to be done but never
actually is is stop energy and depressing.



__
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



We need to shrink the nova bug backlog. I'd say any wishlist bugs that 
are open for over a year (maybe even 6 months) should be marked Invalid 
with a comment saying to file a blueprint or a backlog spec (with links 
on how to do that).


--

Thanks,

Matt Riedemann


__
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] Wishlist bugs == (trivial) blueprint?

[Chris Dent]

On Tue, 15 Mar 2016, Markus Zoeller wrote:


Long story short, I'm in favor of abandoning the use of "wishlist"
as an importance in bug reports to track requests for enhancements.


While I'm very much in favor of limiting the amount of time issues
(of any sort) linger in launchpad[1] I worry that if we stop making
"wishlist" available as an option then people who are not well
informed about the complex system for achieving features in Nova
will have no medium to get their ideas into the system. We want
users to sometime be able to walk up, drop an idea and move on without
having to be responsible for actually doing that work. If we insist
that such ideas must go through the blueprint process then most
ideas will be left unstated.

What I think we need to do instead is fix this problem:


* we don't have a process to transform wishlist bugs to blueprints


such that we do have a process of some kind where a wishlist idea
either gets an owner who starts the blueprint process (because it is
just that cool) or dies from lack of attention.

It's clear, though, that we already have a huge debt in bug/issue
management so adding yet another task is hard to contemplate.

I think we can address some of that by more quickly expiring bugs
that have had no recent activity or attention, on the assumption
that:

* They will come back up again if they are good ideas or real bugs.
* Lack of attention is a truthy signal of either lack of resources or lack
  of importance.

What needs to happen is that fewer things which are not actionable
or nobody is interested in show up when traversing the bugs looking
for something to work on.

I'm happy to help some of this become true, in part because of [1]
below.

[1] I've recently spent a bit of time chasing bugs tagged
"scheduler" and far too many of them are so old that it's impossible
to tell whether they matter any more, and many of them are confused
by patches and people who have gone in and out of existence. It's
challenging to tease out what can be done and the information has
very little archival value. It should go off the radar. Having a
bunch of stuff that looks like it needs to be done but never
actually is is stop energy and depressing.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] network_metadata hash keys on astute.yaml

[Kyrylo Galanov]

Hi,

I would like to remind that we are close to code freeze and bug is still
there. Moreover, new bug reports continue to be submitted [3].
Please, do not ignore the discussion.

[3] https://bugs.launchpad.net/fuel/+bug/1557417

On Tue, Mar 15, 2016 at 10:18 PM, Aleksandr Didenko 
wrote:

> Hi,
>
> some additional info on the problem: if I create some Hiera override for
> the nodes list and use node key which is hostname bond, then after node
> rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
> override will create a "ghost" node in the list and will not change
> settings I wanted to change. So node keys in that hash should remain
> immutable.
>
> Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it
> was working before (and does not require new patches like [0]) and we're
> too late in the release cycle to change keys to '{uid}'.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/284046/
>
> On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
> wrote:
>
>> Hi,
>>
>> Currently nailgun and puppet process network_metadata hash slightly
>> different.
>> Nailgun uses short hostname as a hash key for each node, while library
>> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
>> deployment failure.
>>
>> During code review[0] it turned out that there are two points of view,
>> which approach is correct [1].
>> Both are one-line fixes, however it have been lasting too long with no
>> result.
>>
>> I would like to start a discussion with a hope to close the issue shortly.
>>
>> Best regards.
>> Kyrylo
>>
>> [0] https://review.openstack.org/#/c/284046/
>> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Single Sign On integration research

[Rodrigo Duarte]

Awesome blog posts, thanks for sharing - these setups can be tricky
sometimes.

On Tue, Mar 8, 2016 at 11:43 AM, Steve Martinelli 
wrote:

> Looks great! I only have one suggestion for the ECP blog. We actually have
> keystoneauth plugins for ECP [1]. Instead of issuing a request in your
> example, you may be able to just use the federated auth plugin.
>
> [1]
> https://github.com/openstack/keystoneauth/blob/35cad4a2ef00339eb31d80458bafaada41a5d8ce/keystoneauth1/extras/_saml2/v3/saml2.py
>
> stevemar
>
> [image: Inactive hide details for Adam Heczko ---2016/03/08 03:38:31
> PM---Good job Kseniya :) A.]Adam Heczko ---2016/03/08 03:38:31 PM---Good
> job Kseniya :) A.
>
> From: Adam Heczko 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 2016/03/08 03:38 PM
> Subject: Re: [openstack-dev] [keystone] Single Sign On integration
> research
> --
>
>
>
> Good job Kseniya :)
>
> A.
>
> On Tue, Mar 8, 2016 at 3:21 PM, Jay Pipes <*jaypi...@gmail.com*
> > wrote:
>
>Awesome blogs, Kseniya, thank you for sharing this! :)
>-jay
>
>On 03/08/2016 09:12 AM, Kseniya Tychkova wrote:
>Hi,
>as you may know currently Keystone supports Single Sign-On (SSO) and as
>I think it is one of the most interesting features in Keystone.
>I've done research on Single Sign-On in Keystone. Practically I just
>tried to set up Keystone in 2 different configuration.
>As a result of my research I have 2 blog posts and I would like to
>share
>links with you:
>
>*1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO
>profile)
><
>*http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html*
>
>>*:
><
>*http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html*
>
>>
>(
>*http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html*
>
>)
>Post describes how to step-by-step deploy Shibboleth Identity Provider
>with Keystone Service Provider.
>This configuration is interesting because you can easily replace
>Shibboleth Identity Provider
>with any other Identity Provider with SAML support.
>So it is, I think, most popular use case for SSO in Keystone.
>
>*2. How to setup Keystone with Shibboleth (ECP profile):
><
>
> *http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html*
>
> 
>>
>*(
>
>
> *http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html*
>
> 
>)
>Post describes how to deploy Keystone Identity Provider with Keystone
>Service Provider.
>It is Keystone-to-Keystone configuration and it uses ECP profile
>(Enhanced Client or Proxy) of SAML Protocol.
>A lot of information for this post I took from rodrigods blog
>(
>
> *http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo*
>
> 
>).
>
>I hope my posts will help you to deploy/configure SSO or at least will
>be interesting to take a look at SSO feature in Keystone.
>
>Kind regards, Kseniya
>
>
>
>__
>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*
>
>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>

[openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

[Markus Zoeller]

Long story short, I'm in favor of abandoning the use of "wishlist"
as an importance in bug reports to track requests for enhancements.

The reason I bring this up is [1] which I closed as invalid because
I saw it as a RFE. jichenjc disagreed with my approach there.
I'm asking here on the ML to check what the common understanding is.

My reasons to *not* use "wishlist" are:
* the absence of a feature is not a bug
* a bug report describes a faulty behavior of existing features
* we don't have a process to transform wishlist bugs to blueprints
* wishlist bugs could be used to sneak in features after the feature 
  freeze
* using a bug report bypasses the blueprint approval process
* using "wishlist" as an importance below "low" is a granularity which
  doesn't help 

We have ~160 bug reports which are set to "wishlist" and are in an
open state. 2/3 of them are older than 1 year and would need a new
assessment if they are still valid. As we have enough valid bugs open
I'm not sure which benefit we have to keep them open and who would do
the new assessment.

Alternative:
mriedem used a combination of "wishlist" + "opinion" (a closed state)
in [2], which does also make sense to me, as it is easy to query.
Not sure who would do that though.

References:
[1] https://bugs.launchpad.net/nova/+bug/1556756
[2] https://bugs.launchpad.net/nova/+bug/1552786

Regards, Markus Zoeller (markus_z)


__
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] [ceilometer] Why edited configuration get replaced after stack.sh

[Sean Dague]

Devstack assumes it owns everything on the system, and will overwrite
all configs all the time. This is to keep things repeatable.

There are 3 approaches you could to support your approach here. The
first one is have a custom branch of ceilometer which you then reference
in local.conf.

1)

enable_plugin ceilometer /path/to/your/repo yourbranch

Then just keep it synced over time.

2)

another option would be to build your own plugin which makes this
modification as part of it's normal run.

3)

Create a local.sh -
https://github.com/openstack-dev/devstack/blob/03cf3ce902daa5b53151cd2b8663f4e5533e3177/stack.sh#L1344-L1348

-Sean


On 03/15/2016 08:53 AM, Umar Yousaf wrote:
> Hello Rubab,
> 
> I already know these steps.But does this mean you have to update the
> previous all custom configurations again and again whenever you stack.sh???
> 
> Is there any way possible that these changes don't get updated because
> in a testing environment like mine I have to do it very often.
> 
> Regards,
> Umar
> On Tue, Mar 15, 2016 at 5:36 PM, Rubab Syed  > wrote:
> 
> Hi Umar,
> 
> As far as I know, you should follow these steps to make this work:
> 
> 1- Run stack.sh
> 2- Add rules to policy.json in /etc/ceilometer
> 3- Restart ceilometer service. Follow this link [1] to see how can
> you restart a particular service.
> 
> 
> [1] 
> http://stackoverflow.com/questions/23593508/restarting-a-service-in-openstack-installed-using-devstack
> 
> Hope this helps.
> 
> Rubab
> 
> On Tue, Mar 15, 2016 at 4:57 PM, Umar Yousaf  > wrote:
> 
> Hi,
> 
> I am pretty new to openstack and I have a very basic question to
> ask. I have a single node liberty edition of devstack up and
> running.
> 
> I order to get *ceilometer events* for instances running on demo
> tenant with admin token set I have heard about role based access
> control (rbac) following
> 
> http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/events-rbac.html,
> so I added those two rules in *policy.json
> * inside*/etc/ceilometer* and in order to test its affect I
> ./stack.sh but after that I could not find those two rules added
> by me. The file is updated again with its default values. 
> 
> Is there anyway that these changes remain intact after stack.sh
> too. Isn't it a very general thing that you have to update the
> configuration in order to override the default behavior and in
> testing environment such as mine you will be doing stack.sh very
> often so these changes must not be updated by the default ones
> again.
> 
> Regards,
> Umar
> 
> 
> __
> 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
> 


-- 
Sean Dague
http://dague.net

__
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] [ironic] [inspector] Rewriting nailgun agent on Python proposal

[Serge Kovaleff]

Dear All,

Let's compare functional abilities of both solutions.

Till the recent Mitaka release Ironic-inspector had only Introspection
ability.

Discovery part is proposed and implemented by Anton Arefiev. We should
align expectations and current and future functionality.

Adding Tags to attract the Inspector community.

Cheers,
Serge Kovaleff
http://www.mirantis.com
cell: +38 (063) 83-155-70

On Tue, Mar 15, 2016 at 2:07 PM, Alexander Saprykin 
wrote:

> Dear all,
>
> Thank you for the opinions about this problem.
>
> I would agree with Roman, that it is always better to reuse solutions than
> re-inventing the wheel. We should investigate possibility of using
> ironic-inspector and integrating it into fuel.
>
> Best regards,
> Alexander Saprykin
>
> 2016-03-15 13:03 GMT+01:00 Sergii Golovatiuk :
>
>> My strong +1 to drop off nailgun-agent completely in favour of
>> ironic-inspector. Even taking into consideration we'lll need to
>> extend  ironic-inspector for fuel needs.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko 
>> wrote:
>>
>>> My opition on this is that we have too many re-invented wheels in Fuel
>>> and it’s better think about replacing them with something we can re-use
>>> than re-inventing them one more time.
>>>
>>> Let’s take a look at Ironic and try to figure out how we can use its
>>> features for the same purpose.
>>>
>>>
>>> - romcheg
>>> > 15 бер. 2016 р. о 10:38 Neil Jerram 
>>> написав(ла):
>>> >
>>> > On 15/03/16 07:11, Vladimir Kozhukalov wrote:
>>> >> Alexander,
>>> >>
>>> >> We have many other places where use Ruby (astute, puppet custom types,
>>> >> etc.). I don't think it is a good reason to re-write something just
>>> >> because it is written in Ruby. You are right about tests, about
>>> plugins,
>>> >> but let's look around. Ironic community has already invented discovery
>>> >> component (btw written in python) and I can't see any reason why we
>>> >> should continue putting efforts in nailgun agent and not try to switch
>>> >> to ironic-inspector.
>>> >
>>> > +1 in general terms.  It's strange to me that there are so many
>>> > OpenStack deployment systems that each do each piece of the puzzle in
>>> > their own way (Fuel, Foreman, MAAS/Juju etc.) - and which also means
>>> > that I need substantial separate learning in order to use all these
>>> > systems.  It would be great to see some consolidation.
>>> >
>>> > Regards,
>>> >   Neil
>>> >
>>> >
>>> >
>>> __
>>> > 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] [ceilometer] Why edited configuration get replaced after stack.sh

[Umar Yousaf]

Hello Rubab,

I already know these steps.But does this mean you have to update the
previous all custom configurations again and again whenever you stack.sh???

Is there any way possible that these changes don't get updated because in a
testing environment like mine I have to do it very often.

Regards,
Umar
On Tue, Mar 15, 2016 at 5:36 PM, Rubab Syed  wrote:

> Hi Umar,
>
> As far as I know, you should follow these steps to make this work:
>
> 1- Run stack.sh
> 2- Add rules to policy.json in /etc/ceilometer
> 3- Restart ceilometer service. Follow this link [1] to see how can you
> restart a particular service.
>
> [1]
> http://stackoverflow.com/questions/23593508/restarting-a-service-in-openstack-installed-using-devstack
>
> Hope this helps.
>
> Rubab
>
> On Tue, Mar 15, 2016 at 4:57 PM, Umar Yousaf 
> wrote:
>
>> Hi,
>>
>> I am pretty new to openstack and I have a very basic question to ask. I
>> have a single node liberty edition of devstack up and running.
>>
>> I order to get *ceilometer events* for instances running on demo tenant
>> with admin token set I have heard about role based access control (rbac)
>> following
>> http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/events-rbac.html,
>> so I added those two rules in *policy.json * inside* /etc/ceilometer*
>> and in order to test its affect I ./stack.sh but after that I could not
>> find those two rules added by me. The file is updated again with its
>> default values.
>>
>> Is there anyway that these changes remain intact after stack.sh too.
>> Isn't it a very general thing that you have to update the configuration in
>> order to override the default behavior and in testing environment such as
>> mine you will be doing stack.sh very often so these changes must not be
>> updated by the default ones again.
>>
>> Regards,
>> Umar
>>
>> __
>> 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] [ceilometer] Why edited configuration get replaced after stack.sh

[Rubab Syed]

Hi Umar,

As far as I know, you should follow these steps to make this work:

1- Run stack.sh
2- Add rules to policy.json in /etc/ceilometer
3- Restart ceilometer service. Follow this link [1] to see how can you
restart a particular service.

[1]
http://stackoverflow.com/questions/23593508/restarting-a-service-in-openstack-installed-using-devstack

Hope this helps.

Rubab

On Tue, Mar 15, 2016 at 4:57 PM, Umar Yousaf  wrote:

> Hi,
>
> I am pretty new to openstack and I have a very basic question to ask. I
> have a single node liberty edition of devstack up and running.
>
> I order to get *ceilometer events* for instances running on demo tenant
> with admin token set I have heard about role based access control (rbac)
> following
> http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/events-rbac.html,
> so I added those two rules in *policy.json * inside* /etc/ceilometer* and
> in order to test its affect I ./stack.sh but after that I could not find
> those two rules added by me. The file is updated again with its default
> values.
>
> Is there anyway that these changes remain intact after stack.sh too. Isn't
> it a very general thing that you have to update the configuration in order
> to override the default behavior and in testing environment such as mine
> you will be doing stack.sh very often so these changes must not be updated
> by the default ones again.
>
> Regards,
> Umar
>
> __
> 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] [trove] PTL non-candidacy

[Amrith Kumar]

Craig,

You’ve done a ton for Trove (your first commit on the project that is visible 
in git is March 2012!) and it was the 25th commit in the project!

It has been a pleasure and a honor working with you, with Nikhil and Michael 
before that. I look forward to some good backyard-bbq, and maybe we can have 
some of that this Thursday when I’m in your stomping grounds.

Thanks,

-amrith

From: Craig Vyvial [mailto:cp16...@gmail.com]
Sent: Tuesday, March 15, 2016 12:22 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [trove] PTL non-candidacy

All,

I've decided to not run for Trove PTL for the upcoming Newton cycle.

I've enjoyed working with everyone in the Trove community. We've accomplished 
many features over the last cycle. I am positive with the roadmap we've talked 
about that Trove will continue to grow with the next leadership. I would like 
to thank the community of Trove as well as the rest of the OpenStack team for 
the opportunity to help and learn from everyone.

I look forward to working with the new leadership and excited to see what is in 
store for the future of Trove.

Thanks,
Craig Vyvial
__
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] Rewriting nailgun agent on Python proposal

[Alexander Saprykin]

Dear all,

Thank you for the opinions about this problem.

I would agree with Roman, that it is always better to reuse solutions than
re-inventing the wheel. We should investigate possibility of using
ironic-inspector and integrating it into fuel.

Best regards,
Alexander Saprykin

2016-03-15 13:03 GMT+01:00 Sergii Golovatiuk :

> My strong +1 to drop off nailgun-agent completely in favour of
> ironic-inspector. Even taking into consideration we'lll need to
> extend  ironic-inspector for fuel needs.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko 
> wrote:
>
>> My opition on this is that we have too many re-invented wheels in Fuel
>> and it’s better think about replacing them with something we can re-use
>> than re-inventing them one more time.
>>
>> Let’s take a look at Ironic and try to figure out how we can use its
>> features for the same purpose.
>>
>>
>> - romcheg
>> > 15 бер. 2016 р. о 10:38 Neil Jerram 
>> написав(ла):
>> >
>> > On 15/03/16 07:11, Vladimir Kozhukalov wrote:
>> >> Alexander,
>> >>
>> >> We have many other places where use Ruby (astute, puppet custom types,
>> >> etc.). I don't think it is a good reason to re-write something just
>> >> because it is written in Ruby. You are right about tests, about
>> plugins,
>> >> but let's look around. Ironic community has already invented discovery
>> >> component (btw written in python) and I can't see any reason why we
>> >> should continue putting efforts in nailgun agent and not try to switch
>> >> to ironic-inspector.
>> >
>> > +1 in general terms.  It's strange to me that there are so many
>> > OpenStack deployment systems that each do each piece of the puzzle in
>> > their own way (Fuel, Foreman, MAAS/Juju etc.) - and which also means
>> > that I need substantial separate learning in order to use all these
>> > systems.  It would be great to see some consolidation.
>> >
>> > Regards,
>> >   Neil
>> >
>> >
>> >
>> __
>> > 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] [Fuel] Rewriting nailgun agent on Python proposal

[Sergii Golovatiuk]

My strong +1 to drop off nailgun-agent completely in favour of
ironic-inspector. Even taking into consideration we'lll need to
extend  ironic-inspector for fuel needs.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko  wrote:

> My opition on this is that we have too many re-invented wheels in Fuel and
> it’s better think about replacing them with something we can re-use than
> re-inventing them one more time.
>
> Let’s take a look at Ironic and try to figure out how we can use its
> features for the same purpose.
>
>
> - romcheg
> > 15 бер. 2016 р. о 10:38 Neil Jerram 
> написав(ла):
> >
> > On 15/03/16 07:11, Vladimir Kozhukalov wrote:
> >> Alexander,
> >>
> >> We have many other places where use Ruby (astute, puppet custom types,
> >> etc.). I don't think it is a good reason to re-write something just
> >> because it is written in Ruby. You are right about tests, about plugins,
> >> but let's look around. Ironic community has already invented discovery
> >> component (btw written in python) and I can't see any reason why we
> >> should continue putting efforts in nailgun agent and not try to switch
> >> to ironic-inspector.
> >
> > +1 in general terms.  It's strange to me that there are so many
> > OpenStack deployment systems that each do each piece of the puzzle in
> > their own way (Fuel, Foreman, MAAS/Juju etc.) - and which also means
> > that I need substantial separate learning in order to use all these
> > systems.  It would be great to see some consolidation.
> >
> > Regards,
> >   Neil
> >
> >
> >
> __
> > 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-dev] [election][trove] Trove PTL Candidacy

[Amrith Kumar]

Greetings,

I am writing to submit my candidacy for election for Project Team Lead
for the Trove project for the Newton cycle.

I have been an active technical contributor to
the Trove project since just before the Icehouse release when Trove
was integrated into OpenStack. I have also contributed code[1] and
reviews[2] to some other OpenStack projects. I am one of the two
authors of the book on Trove[3], the other author is my colleague and
a fellow Trove contributor, Doug Shelley.

Over the past two years, Trove has come a very long way, adding
support for a dozen databases, and providing users the ability to
orchestrate complex topologies of these databases, and manage them
through their lifecycle. In the Mitaka release we have seen the
addition of a number of exciting and new capabilities for databases
like Cassandra, CouchDB, MariaDB, MongoDB, Percona XtraDB Cluster, and
Vertica.

Looking ahead to Newton and Ocata, I think the project has some
specific areas where focus is needed. These include:

   * paying down the technical debt both in shipping code and tests,

   * strenghtening the community and adding more contributors,
 reviewers and core reviewers,

   * addressing issues with the review backlog,

   * improve integrations with other projects (specifically Cinder,
 Manila, Ironic, Magnum and Sahara),

   * continuing to extend the capabilities of trove especially in the
 area of some specific requirements from large enterprises, and

   * making it easier to use Trove, to make guest images, and other
 commonly reported problems.

All of these are things that have come up from within the community
and I look forward to working to continue to make progress on these
efforts.

Thank you, and I would appreciate your vote in the election.

-amrith

--
Amrith Kumar
Email: amr...@tesora.com
IRC: amrith
GPG: 0x5e48849a9d21a29b

[1] http://stackalytics.com/?user_id=amrith=all=commits
[2] http://stackalytics.com/?user_id=amrith=all=marks
[3] http://www.apress.com/9781484212226





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

[openstack-dev] [ceilometer] Why edited configuration get replaced after stack.sh

[Umar Yousaf]

Hi,

I am pretty new to openstack and I have a very basic question to ask. I
have a single node liberty edition of devstack up and running.

I order to get *ceilometer events* for instances running on demo tenant
with admin token set I have heard about role based access control (rbac)
following
http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/events-rbac.html,
so I added those two rules in *policy.json * inside* /etc/ceilometer* and
in order to test its affect I ./stack.sh but after that I could not find
those two rules added by me. The file is updated again with its default
values.

Is there anyway that these changes remain intact after stack.sh too. Isn't
it a very general thing that you have to update the configuration in order
to override the default behavior and in testing environment such as mine
you will be doing stack.sh very often so these changes must not be updated
by the default ones again.

Regards,
Umar
__
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] fuel-web/docs to fuel-docs migration

[Aleksandra Fedorova]

Hi, everyone,

this week we plan to migrate the content of fuel-web/docs to fuel-docs
repo to setup one place for all Fuel documentation.

See related blueprint
https://blueprints.launchpad.net/fuel/+spec/fuel-docs-migration

There are two patches on review:

* https://review.openstack.org/#/c/292403/ - sync fuel-web/docs to fuel-docs
* https://review.openstack.org/#/c/292446/ - remove fuel-web/docs content

There is only one remaining non-merged patch in fuel-web/docs

  
https://review.openstack.org/#/q/project:openstack/fuel-web+file:docs+status:open

I suggest that we merge it right away, then declare fuel-web/docs
freeze and perform the migration.

All new changes to dev docs should then be sent to fuel-docs
repository, in devdocs subfolder.

-- 
Aleksandra Fedorova
Fuel CI Engineer
bookwar

__
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] [release][stable][oslo] oslo.messaging 4.5.1 release (mitaka)

[no-reply]

We are tickled pink to announce the release of:

oslo.messaging 4.5.1: Oslo Messaging API

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 4.5.0..4.5.1
--

f8cad0e Bump rabbit_transient_queues_ttl to 30 mins
da3cd9b Fix Notification listener blocking behavior
4ab9b02 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview | 1 +
oslo_messaging/_drivers/base.py| 2 ++
oslo_messaging/_drivers/impl_rabbit.py | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)




__
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] network_metadata hash keys on astute.yaml

[Aleksandr Didenko]

Hi,

some additional info on the problem: if I create some Hiera override for
the nodes list and use node key which is hostname bond, then after node
rename (rename during LCM or reset/rename/redeploy - doesn't matter) my
override will create a "ghost" node in the list and will not change
settings I wanted to change. So node keys in that hash should remain
immutable.

Let's fix LP#1538220 and keep 'node-{uid}' simply because that's how it was
working before (and does not require new patches like [0]) and we're too
late in the release cycle to change keys to '{uid}'.

Regards,
Alex

[0] https://review.openstack.org/#/c/284046/

On Tue, Mar 15, 2016 at 11:22 AM, Kyrylo Galanov 
wrote:

> Hi,
>
> Currently nailgun and puppet process network_metadata hash slightly
> different.
> Nailgun uses short hostname as a hash key for each node, while library
> code assumes that key is always 'node-{uid}'. Sometimes it can result in a
> deployment failure.
>
> During code review[0] it turned out that there are two points of view,
> which approach is correct [1].
> Both are one-line fixes, however it have been lasting too long with no
> result.
>
> I would like to start a discussion with a hope to close the issue shortly.
>
> Best regards.
> Kyrylo
>
> [0] https://review.openstack.org/#/c/284046/
> [1] https://bugs.launchpad.net/fuel/+bug/1538220
>
> __
> 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] [TripleO] PTL Candidacy

[Steven Hardy]

All, I've proposed my candidacy to the openstack/election repo [1] but
copying here for visibility.

I am announcing my candidacy for PTL for the TripleO team for the Newton
release cycle.

Over the last development cycle, I've been heavily involved with evolving the
TripleO release model to better enable consuming TripleO in the context of
OpenStack coordinated release.

We've had our share of challenges supporting the new stable/liberty branches,
such as CI capacity and an overload of backports, but I still think improving
the experience for both upstream users and downstream consumers of TripleO
remains one of the most important challenges we face, and I intend to commit
further time to this task in the Newton timeframe.

The other area I'd like to help improve is refining our template model to
better support integration with vendor drivers, and potentially giving more
operator choice in terms of the configuration management workflow.  We've
made slow progress on this during Mitaka, but I think improving composability
and enabling more operator choice remains very important, and I'd like to help
fix our branch model and free up capacity so we can make progress on this.

My view of the PTL role is that it's as much about release coordination as it
is about technical leadership, so I'd like to step up and offer to take on this
workload (with the help of our community!) for Newton.

Thanks for your consideration!

[1] https://review.openstack.org/#/c/292817/

__
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] rate-limit

[Andy Wang]

Hi Irena,
I have reported one bug in the system.
https://bugs.launchpad.net/neutron/+bug/1557457
I could not join the meeting, I will check the meeting minutes.
Thanks
Andy








At 2016-03-14 20:49:42, "Irena Berezovsky"  wrote:

Hi Andy,
(Adding neutron tag)

Please open an RFE bug under neutron and add qos tag. This will facilitate the 
discussion of the use case feasibility. 
Please join the QoS IRC meetings  https://wiki.openstack.org/wiki/Meetings/QoS.


BR,
Irena


On Mon, Mar 14, 2016 at 2:05 PM, Andy Wang  wrote:

Hi All,


I want to develop  feature rate-limit based on contrail-openstack context. 
My target is control rate of the sum of all the VMs int the one project or one 
tenant.
I want to do it using linux TC. Is it feasible ?
Is there one better idea for this ? Any suggestion is very appreciated.


Thanks
Andy Wang




 





 


__
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] Getting rid of cluster status

[Roman Prykhodchenko]

Fuelers,

I would like to continue the series of "Getting rid of …" emails. This time I’d 
like to talk about statuses of clusters.

The issues with that attribute is that it is not actually related to real world 
very much and represents nothing. A few month ago I proposed to make it more 
real-world-like [1] by replacing a simple string by an aggregated value. 
However, after task based deployment was introduced even that approach lost its 
connection to the real world.

My idea is to get rid of that attribute from a cluster and start working with 
status of every single node in it. Nevertheless, we only have tasks that are 
executed on nodes now, so we cannot apply the "status" term to them. What if we 
replace that with a sort of boolean value called maintenance_mode (or similar) 
that we will use to tell if the node is operational or not. After that we will 
be able to use an aggregated property for cluster and check, if there are any 
nodes that are under a progress of performing some tasks on them.

Thoughts, ideas?


References:

1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status


- romcheg


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev