Re: [OpenStack-Infra] OpenDev Independence and Governance

[Mohammed Naser]

On Fri, Dec 6, 2019 at 4:37 AM Thierry Carrez  wrote:
>
> Clark Boylan wrote:
> > [...]
> > The OpenDev project will be governed by two entities. The first is the 
> > service coordinator. Responsibilities for the service coordinator are 
> > essentially the same of the existing Infra team PTL. They coordinate work 
> > of contributors and act as a tie breaker when clear consensus isn't found.
> >
> > The service coordinator is elected every 6 months. The nominee pool and 
> > electorate are individuals that have contributed changes to OpenDev in the 
> > last 12 months.
> >
> > The second is an advisory board made up of representatives from OpenDev's 
> > user base of projects and organizations that contribute compute resources. 
> > This advisory board provides a formal location for both our users and 
> > contributing orgs to express their needs to the OpenDev project. This 
> > creates a clear contact point for  feedback on priorities and direction. 
> > Their input will help ensure that the OpenDev project is a good steward of 
> > the resources provided to it and that user needs are being addressed.
> >
> > Contributing orgs and user projects are not required to join the advisory 
> > board, but are encouraged to do so. Individuals on the  board would be 
> > selected by their own constituency as that constituency feels is 
> > appropriate.
> >
> > The advisory board will also serve as a point of contact for  the OpenDev 
> > project when making changes that may be disruptive. The intent is to create 
> > bidirectional communication between OpenDev and the advisory board.
> >
> > How does this look?
>
> Loving it.

LGTM too! :)

> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] OpenDev Independence and Governance

[Mohammed Naser]

On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez  wrote:
>
> Clark Boylan wrote:
> > [...]
> > In James Blair's winterscale email [0] he suggested that we create a 
> > governing council made up of the OpenDev PTL and
> > a representative from each of the OpenStack Foundation's official projects 
> > that currently consume OpenDev resources
> > (currently OpenStack itself, Airship, and Zuul). This suggestion creates 
> > two levels of governance for the OpenDev team.
> >
> > The first is the position of PTL for the OpenDev project. If we want to 
> > continue to manage this position as we've managed it
> > for the OpenStack Infra team, then we can have elections for the position 
> > every 6 months. The nominee pool and electorate
> > would be individuals that have contributed changes to OpenDev in the last 
> > 12 months.
>
> That sounds good. Only comment: "PTL" meaning "project team lead", it's
> a bit of an OpenStack-ism which might not make perfect sense in the
> Opendev context.
>
> > For the council, membership would be small, but I think demands on this 
> > group would also be minimal. Ideally the OpenDev team
> > would be left to figure out technical details for services and this council 
> > would be used as a check on service changes or
> > other behavioral updates that affect how OpenDev's users interact with the 
> > system. Since this group would be starting with
> > an even number of individuals we may need to determine tie breaker 
> > requirements upfront. Also, we may want to consider
> > if the "else" group of OpenDev users need a voice. Individuals representing 
> > constituent projects should be nominated by
> > their project leadership.
>
> I feel like this group should more of an advisory board (to get
> feedback) than a governance council (to vote on motions on a one project
> = one vote basis).
>
> If you go for a governance structure, it creates a number of issues
> imho, like tie breaking, or the fact that OpenStack's vote is arguably
> more important than StarlingX's (being a pilot project) or Kata's (only
> using very few of the Opendev services).
>
> Choosing an advisory board style, there is no formal vote, just official
> feedback on priorities and proposals, which can then be properly weighed
> by the OpenDev lead and contributors. You can integrate additional seats
> to represent "else" opendev users without having to over-think how their
> voice compares to an OSF project voice.
>
> I'm also wondering if the advisory board should not also include seats
> for the infrastructure donors... Since we should definitely be making
> sure Opendev goes in a direction that encourages them to continue
> investing in (or increase) the resources that they give us.

I wanted to bring this up but indeed, I think that as an infrastructure
donor, there is a significant investment from our side and knowing
where and how that's going is important

> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. https://vexxhost.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Adding submariner to opendev.org

[Mohammed Naser]

On Wed, Nov 20, 2019 at 5:25 AM Mike Kolesnik  wrote:
>
> Hi,
>
> We would like to add the submariner repositories currently hosted at [1] to 
> opendev.org.

That's great.  I've been a big fan of Submariner for quite sometime
and I'd love to help you out in bringing it into opendev.org

I would be happy to help you out in that effort over IRC if you'd like
(or perhaps some other method of communication if you'd like).

> The website itself doesn't have much information on how to go about it.
>
> Would it be possible?
> And if so, is there some guide to follow?
>
> [1] https://github.com/submariner-io/
>
> --
> Regards,
> Mike
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Infra Shanghai PTG Recap

[Mohammed Naser]

al open source hosting. If 
> it is then we can work with the OSF to see if using the paid hosting platform 
> for weblate is viable. If not we also have the option of possibly hosting our 
> own weblate.
>
> Finally there were discussions about Zuul specific topics. This email is 
> already quite long so I'll keep it scoped to the OpenDev/Infra topics. If 
> there is interest in a similar email re Zuul topics I can probably send one 
> out to the Zuul list.
>
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. https://vexxhost.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] CentOS 8 as a Python 3-only base image

[Mohammed Naser]

On Fri, Sep 27, 2019 at 7:11 AM Jeremy Stanley  wrote:
>
> On 2019-09-27 17:26:15 +1000 (+1000), Ian Wienand wrote:
> [...]
> > Installing pip and virtualenv from upstream sources has a long history
> > full of bugs and workarounds nobody wants to think about (if you do
> > want to think about it, you can start at [2]).
> [...]
> > I'm thinking that CentOS 8 is a good place to stop this.  We just
> > won't support, in dib, installing pip/virtualenv from source for
> > CentOS 8.  We hope for the best that the packaged versions of tools
> > are always working, but *if* we do require fixes to the system
> > packages, we will implement that inside jobs directly, rather than on
> > the base images.
> [...]
>
> This seems like a reasonable shift to me. I'd eventually love to see
> us stop preinstalling pip and virtualenv entirely, allowing jobs to
> take care of doing that at runtime if they need to use them.

+1 for this, it'll simplify building nodepool images a lot more

> --
> Jeremy Stanley
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] opensource infra: server sizes

[Mohammed Naser]

You can see them listed here:

https://docs.openstack.org/infra/system-config/contribute-cloud.html

On Mon, Aug 12, 2019 at 12:45 PM Shadi Akiki  wrote:
>
> Hello. I've been going through the opensource infrastructure configurations 
> at https://docs.openstack.org/infra/system-config/
> and linked from https://opensourceinfra.org/
>
> I don't see any information about server sizes.
> Is this something that is not interesting to share as part of the opensource 
> infrastructure initiative?
> --
> Shadi Akiki
> Founder & CEO, AutofitCloud
> https://autofitcloud.com/
> +1 813 579 4935
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Cross-community/generic mailing lists

[Mohammed Naser]

Resending because I’m silly and I didn’t hit reply all.

> On Dec 10, 2018, at 9:15 PM, Mohammed Naser  wrote:
> 
> 
>> On Dec 10, 2018, at 7:39 PM, Jonathan Bryce  wrote:
>> 
>> Hi everyone,
>> 
>> I was having a conversation with some people who are working across multiple 
>> communities involved in virtualization and container security and they were 
>> interested in having a higher level mailing list for open discussions. It 
>> doesn’t necessarily make sense to tie it to any particular project mailing 
>> list, and I was wondering how others on the OpenDev team felt about creating 
>> discussion lists along these lines on lists.opendev.org. This isn’t the 
>> first time we’ve seen this use case, and seems like it could be a nice 
>> service to a number of communities.
> 
> I think this is actually really useful.  At the Denver PTG (round 2), Clark 
> brought up the idea of having public clouds (as an example of an operator at 
> the time — this happened during the public cloud WG sessions) find a way to 
> discuss together with upstream regarding things which involve core 
> virtualization infrastructure.
> 
> One of the issues that were discussed at the time was the ability to bring 
> stable nested virtualization.  Kashyap at the time mentioned that he was also 
> happy to work together to help improve that.  At the time, we just had no 
> real place to house that discussion in but this seems *perfect* for OpenDev.
> 
>> Thoughts?
> 
> I’m for it.
> 
>> Jonathan
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Access to CI

[Mohammed Naser]

Hi everyone,

We’re in the processing of moving a lot of our internally used Ansible roles to 
ones which are public.  As a result, we’d like to also add testing coverage for 
them, however, there’s two issues that we’re seeing

We’d love to take advantage of the existing infrastructure for CI rather than 
use some other third party CI service for those roles.  Also, the Gerrit 
workflow is great and flows perfectly with everything that we do right now.  
However, having said that..

1) There seems to be some namespace issues which could block us (for example, 
openstack/ansible-role-container-registry seems to be fairly TripleO 
opinionated, even running TripleO jobs).  If we wanted to write a similar role, 
we’d probably have to put another name.. or $some_other_solution

2) If we don’t host the code in Gerrit and just use GitHub for now (until we 
can get namespaced projects in Gerrit with OpenDev), then are we allowed to use 
the current Zuul deployment and resources to run these jobs?  Is there any sort 
of infrastructure in place to get a ‘yes’ or ‘no’?

I know that the OpenDev effort is moving forward but it might be a little while 
before there’s something concrete and it’d be nice to be able to use some 
infrastructure in the meantime, without having to rely on other external 
services.

Thanks!
Mohammed
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?

[Mohammed Naser]

On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth  wrote:

> I have a request to do $SUBJECT in relation to a V2V workflow. The use
> case here is conversion of a VM/Physical which was previously powered
> off. We want to move its data, but we don't want to be powering on
> stuff which wasn't previously on.
>
> This would involve an api change, and a hopefully very small change in
> drivers to support it. Technically I don't see it as an issue.
>
> However, is it a change we'd be willing to accept? Is there any good
> reason not to do this? Are there any less esoteric workflows which
> might use this feature?
>

If you upload an image of said VM which you don't boot, you'd really be
accomplishing the same thing, no?

Unless you want to be in a state where you want the VM to be there but
sitting in SHUTOFF state


> Matt
> --
> Matthew Booth
> Red Hat OpenStack Engineer, Compute DFG
>
> Phone: +442070094448 (UK)
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?

[Mohammed Naser]

On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth  wrote:

> I have a request to do $SUBJECT in relation to a V2V workflow. The use
> case here is conversion of a VM/Physical which was previously powered
> off. We want to move its data, but we don't want to be powering on
> stuff which wasn't previously on.
>
> This would involve an api change, and a hopefully very small change in
> drivers to support it. Technically I don't see it as an issue.
>
> However, is it a change we'd be willing to accept? Is there any good
> reason not to do this? Are there any less esoteric workflows which
> might use this feature?
>

If you upload an image of said VM which you don't boot, you'd really be
accomplishing the same thing, no?

Unless you want to be in a state where you want the VM to be there but
sitting in SHUTOFF state


> Matt
> --
> Matthew Booth
> Red Hat OpenStack Engineer, Compute DFG
>
> Phone: +442070094448 (UK)
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Way to see VMs under all tenants by non-admin?

[Mohammed Naser]

Hi Ken:

https://github.com/openstack/nova/blob/juno-eol/nova/api/openstack/compute/servers.py#L588-L590

Good luck (with your upgrades ;))

Mohammed

On Mon, Nov 26, 2018 at 9:39 AM Ken D'Ambrosio  wrote:

> Hey, all.  I've had a request for a non-admin user to see all the VMs
> currently running, irrespective of project.  I've gone through the
> policy.json file (this is Juno) and enabled everything I could think of
> that seemed appropriate, to no avail.  Is there any way to do this
> without granting him flat-out admin?
>
> Thanks!
>
> -Ken
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [OpenStack][Glance]Getting instance snapshot result in size 0 byte

[Mohammed Naser]

Are they boot from volume instances?

On Fri, Nov 23, 2018 at 5:57 PM Soheil Pourbafrani 
wrote:

> Hi,
>
> I have many instances running on OpenStack and I wanted to export them. So
> I create a snapshot of an instance and it results in a new record in images
> in the format of Qcow2 and size of 0 bytes! It just created a volume
> snapshot of the instance, too.
>
> I tried with both command line and horizon but the same results!
>
> How can I export instances in the correct way?
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] openstack-annsible networking layout before running playbooks

[Mohammed Naser]

Hey there,

You can just have one br-mgmt and skip the second one and everything will
go over br-mgmt :)

Thanks,
Mohammed

On Thu, Nov 22, 2018 at 5:05 AM Jawad Ahmed  wrote:

> Hi all,
> I am deploying openstack-ansible in test environment where I need to use
> br-mgmt bridge for both storage and management traffic (same bridge for
> both) so that container interfaces eth1 and eth2 will connect to br-mgmt
> for mgmt and storage traffic at same time.Does it make sense if I ll setup
> provider networks openstack_user_config.yml as below?
>
>  tunnel_bridge: "br-vxlan" //separate bridge for vxlan though
>   management_bridge: "br-mgmt"
>
>   provider_networks:
> - network:
> container_bridge: "br-mgmt"
> container_type: "veth"
> container_interface: "eth1"
> ip_from_q: "container"
> type: "raw"
> group_binds:
>   - all_containers
>   - hosts
> is_container_address: true
> is_ssh_address: true
>
>
>  - network:
> container_bridge: "br-mgmt"
> container_type: "veth"
> container_interface: "eth2"
> ip_from_q: "storage"
> type: "raw"
> group_binds:
>   - glance_api
>   - cinder_api
>   - cinder_volume
>   - nova_compute
>
> Help would be appreciated.
>
> --
> Greetings,
> Jawad Ahmed
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] StarlingX gap analysis to converge with OpenStack master

[Mohammed Naser]

Thanks for doing this in the open and working with the upstream teams to
reduce divergence!

On Wed, Nov 21, 2018 at 1:17 PM Miguel Lavalle  wrote:

> Hi Stackers,
>
> One of the key goals of StarlingX during the current cycle is to converge
> with the OpenStack projects master branches. In order to accomplish this
> goal, the Technical Steering Committee put together a gap analysis that
> shows the specs and patches that need to merge in the different OpenStack
> projects by the end of Stein. The attached PDF document shows this
> analysis. Although other projects are involved, most of the work has to be
> done in Nova, Neutron and Horizon. Hopefully all the involved projects will
> help StarlingX achieve this important goal.
>
> It has to be noted that work is still on-going to refine this gap
> analysis, so there might be some updates to it in the near future.
>
> Best regards
>
> Miguel
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

[Mohammed Naser]

With my core hat, I would give it a +1.  At this point, it has no open
patches and the last one we merged was 7 months ago.

https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:open
https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:merged

I can't speak about it as an operator as we don't run anything that old.

On Mon, Nov 19, 2018 at 7:43 AM Emilien Macchi  wrote:

> +1 for me, I haven't seen much interest in keeping these branches for
> puppet modules.
> I also would like to hear from our users though.
>
> On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin 
> wrote:
>
>> Hello,
>>
>> We've been talking for a while about the deprecation and removal of the
>> stable/newton branches.
>> I think it's time now that we get rid of them, we have no open patches
>> and Newton is considered EOL.
>>
>> Could cores get back with a quick feedback and then the stable team can
>> get rid of those whenever they have time.
>>
>> Best regards
>> Tobias
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] (Juno - *sigh*) Want non-admin access to hypervisor:VM association.

[Mohammed Naser]

https://blueprints.launchpad.net/nova/+spec/openstack-api-hostid

This should take care of it, don't know if it exists in Juno though.

On Thu, Nov 15, 2018 at 1:49 PM Ken D'Ambrosio  wrote:

> Hey, all.  We've got a Juno cloud, and we'd like various end-users to be
> able to see which hypervisors their VMs spring up on.
> /etc/nova/policy.json seems to have some relevant info, but it's hard to
> tell what does what.   "compute_extension:hypervisors" looks like a
> possible candidate, but that's so vague that there's no telling what,
> exactly, is meant by "hypervisors".  So:
>
> * Given that I just want the hypervisor:VM association, any suggestions
> as to which rule(s) to modify?
> * Failing that, wondering if there's any for-real documentation on what
> the various options in policy.json *do*.  I've found many, many lists of
> what's in a generic policy.json, but nothing that went into detail about
> what does what.
>
> Thanks!
>
> -Ken
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Retire of openstack-ansible-os_monasca-ui

[Mohammed Naser]

+1

On Mon, Nov 12, 2018 at 2:14 PM Kaio Oliveira 
wrote:

> Hi everyone,
>
> As part of the process of retiring the os_monasca-ui role from the
> openstack-ansible project, I'm announcing here on the ML that this role
> will be retired, because there's no reason to maintain it anymore.
> This has been discussed with the previous and the current
> OpenStack-Ansible PTL.
>
> The monasca-ui will be dealt within os_horizon role on openstack-ansible.
>
> Best regards,
> Kaio
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [openstack-ansible] meeting cancelled

[Mohammed Naser]

Hi everyone,

Due to most of us being at the OpenStack Summit, we're cancelling the
meeting tomorrow.

Thanks everyone and see you in Berlin.

Regards,
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Mohammed Naser]

On Wed, Nov 7, 2018 at 2:07 PM Dr. Jens Harbott (frickler)
 wrote:
>
> 2018-11-07 12:47 GMT+00:00 Mohammed Naser :
> > On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
> >>
> >> Corey Bryant  writes:
> >>
> >> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> >> > wrote:
> >> >
> >> > I'd like to start moving forward with enabling py37 unit tests for a 
> >> > subset
> >> > of projects. Rather than putting too much load on infra by enabling 3 x 
> >> > py3
> >> > unit tests for every project, this would just focus on enablement of py37
> >> > unit tests for a subset of projects in the Stein cycle. And just to be
> >> > clear, I would not be disabling any unit tests (such as py35). I'd just 
> >> > be
> >> > enabling py37 unit tests.
> >> >
> >> > As some background, this ML thread originally led to updating the
> >> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
> >> > but has now led back to this ML thread for a +1 rather than updating the
> >> > governance goal.
> >> >
> >> > I'd like to get an official +1 here on the ML from parties such as the TC
> >> > and infra in particular but anyone else's input would be welcomed too.
> >> > Obviously individual projects would have the right to reject proposed
> >> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> >> > but they could individually vote that way.
> >> >
> >> > Thanks,
> >> > Corey
> >>
> >> This seems like a good way to start. It lets us make incremental
> >> progress while we take the time to think about the python version
> >> management question more broadly. We can come back to the other projects
> >> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.
> >
> > What's the impact on the number of consumption in upstream CI node usage?
>
> I think the relevant metric here will be nodes_used * time_used.
> nodes_used will increase by one, time_used for usual unit test jobs
> seems to be < 10 minutes, so I'd think that the total increase in CI
> usage should be neglegible compared to full tempest or similar jobs
> that take 1-2 hours.

Indeed it doesn't look too bad:

http://zuul.openstack.org/builds?job_name=openstack-tox-py35

It'll be good to try and aim to transition as quickly as possible to
avoid extra 'wasted' resources in the infrastructure side

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [python3] Enabling py37 unit tests

[Mohammed Naser]

On Wed, Nov 7, 2018 at 1:37 PM Doug Hellmann  wrote:
>
> Corey Bryant  writes:
>
> > On Wed, Oct 10, 2018 at 8:45 AM Corey Bryant 
> > wrote:
> >
> > I'd like to start moving forward with enabling py37 unit tests for a subset
> > of projects. Rather than putting too much load on infra by enabling 3 x py3
> > unit tests for every project, this would just focus on enablement of py37
> > unit tests for a subset of projects in the Stein cycle. And just to be
> > clear, I would not be disabling any unit tests (such as py35). I'd just be
> > enabling py37 unit tests.
> >
> > As some background, this ML thread originally led to updating the
> > python3-first governance goal (https://review.openstack.org/#/c/610708/)
> > but has now led back to this ML thread for a +1 rather than updating the
> > governance goal.
> >
> > I'd like to get an official +1 here on the ML from parties such as the TC
> > and infra in particular but anyone else's input would be welcomed too.
> > Obviously individual projects would have the right to reject proposed
> > changes that enable py37 unit tests. Hopefully they wouldn't, of course,
> > but they could individually vote that way.
> >
> > Thanks,
> > Corey
>
> This seems like a good way to start. It lets us make incremental
> progress while we take the time to think about the python version
> management question more broadly. We can come back to the other projects
> to add 3.7 jobs and remove 3.5 jobs when we have that plan worked out.

What's the impact on the number of consumption in upstream CI node usage?

> 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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

[Mohammed Naser]

On Mon, Nov 5, 2018 at 4:17 PM Matt Riedemann  wrote:
>
> On 11/4/2018 4:22 AM, Mohammed Naser wrote:
> > Just for information sake, a clean state cloud which had no reported issues
> > over maybe a period of 2-3 months already has 4 allocations which are
> > incorrect and 12 allocations pointing to the wrong resource provider, so I
> > think this comes does to committing to either "self-healing" to fix those
> > issues or not.
>
> Is this running Rocky or an older release?

In this case, this is inside a Queens cloud, I can run the same script
on a Rocky
cloud too.

> Have you dug into any of the operations around these instances to
> determine what might have gone wrong? For example, was a live migration
> performed recently on these instances and if so, did it fail? How about
> evacuations (rebuild from a down host).

To be honest, I have not, however, I suspect a lot of those happen from the
fact that it is possible that the service which makes the claim is not the
same one that deletes it

I'm not sure if this is something that's possible but say the compute2 makes
a claim for migrating to compute1 but something fails there, the revert happens
in compute1 but compute1 is already borked so it doesn't work

This isn't necessarily the exact case that's happening but it's a summary
of what I believe happens.

> By "4 allocations which are incorrect" I assume that means they are
> pointing at the correct compute node resource provider but the values
> for allocated VCPU, MEMORY_MB and DISK_GB is wrong? If so, how do the
> allocations align with old/new flavors used to resize the instance? Did
> the resize fail?

The allocated flavours usually are not wrong, they are simply associated
to the wrong resource provider (so it feels like failed migration or resize).

> Are there mixed compute versions at all, i.e. are you moving instances
> around during a rolling upgrade?

Nope

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



--
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

[Mohammed Naser]

Sent from my iPhone

> On Nov 5, 2018, at 10:19 AM, Thierry Carrez  wrote:
> 
> Monty Taylor wrote:
>> [...]
>> What if we added support for serving vendor data files from the root of a 
>> primary URL as-per RFC 5785. Specifically, support deployers adding a json 
>> file to .well-known/openstack/client that would contain what we currently 
>> store in the openstacksdk repo and were just discussing splitting out.
>> [...]
>> What do people think?
> 
> I love the idea of public clouds serving that file directly, and the user 
> experience you get from it. The only two drawbacks on top of my head would be:
> 
> - it's harder to discover available compliant openstack clouds from the 
> client.
> 
> - there is no vetting process, so there may be failures with weird clouds 
> serving half-baked files that people may blame the client tooling for.
> 
> I still think it's a good idea, as in theory it aligns the incentive of 
> maintaining the file with the most interested stakeholder. It just might need 
> some extra communication to work seamlessly.

I’m thinking out loud here but perhaps a simple linter that a cloud provider 
can run will help them make sure that everything is functional. 

> -- 
> 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 Development Mailing 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] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir

[Mohammed Naser]

On Sun, Nov 4, 2018 at 4:12 PM Monty Taylor  wrote:
>
> Heya,
>
> I've floated a half-baked version of this idea to a few people, but
> lemme try again with some new words.
>
> What if we added support for serving vendor data files from the root of
> a primary URL as-per RFC 5785. Specifically, support deployers adding a
> json file to .well-known/openstack/client that would contain what we
> currently store in the openstacksdk repo and were just discussing
> splitting out.
>
> Then, an end-user could put a url into the 'cloud' parameter.
>
> Using vexxhost as an example, if Mohammed served:
>
> {
>"name": "vexxhost",
>"profile": {
>  "auth_type": "v3password",
>  "auth": {
>"auth_url": "https://auth.vexxhost.net/v3;
>  },
>  "regions": [
>"ca-ymq-1",
>"sjc1"
>  ],
>  "identity_api_version": "3",
>  "image_format": "raw",
>  "requires_floating_ip": false
>}
> }
>
> from https://vexxhost.com/.well-known/openstack/client
>
> And then in my local config I did:
>
> import openstack
> conn = openstack.connect(
>  cloud='https://vexxhost.com',
>  username='my-awesome-user',
>  ...)
>
> The client could know to go fetch
> https://vexxhost.com/.well-known/openstack/client to use as the profile
> information needed for that cloud.

Mohammed likes this idea and would like to present this for you to hack on:
https://vexxhost.com/.well-known/openstack/client

> If I wanted to configure a clouds.yaml entry, it would look like:
>
> clouds:
>mordred-vexxhost:
>  profile: https://vexxhost.com
>  auth:
>username: my-awesome-user
>
> And I could just
>
> conn = openstack.connect(cloud='mordred-vexxhost')
>
> The most important part being that we define the well-known structure
> and interaction. Then we don't need the info in a git repo managed by
> the publiccloud-wg - each public cloud can manage it itself. But also -
> non-public clouds can take advantage of being able to define such
> information for their users too - and can hand a user a simple global
> entrypoint for discover. As they add regions - or if they decide to
> switch from global keystone to per-region keystone, they can just update
> their profile file and all will be good with the world.
>
> Of course, it's a convenience, so nothing forces anyone to deploy one.
>
> For backwards compat, as public clouds we have vendor profiles for start
> deploying a well-known profile, we can update the baked-in named profile
> in openstacksdk to simply reference the remote url and over time
> hopefully there will cease to be any information that's useful in the
> openstacksdk repo.
>
> What do people think?

I really like this idea, the only concern is fallbacks.  I can imagine
that in some
arbitrary world, things might get restructured in a web structure and that URL
magically disappears but shifting the responsibilities on the provider rather
than maintainers of this project is a much cleaner alternative, IMHO.

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [nova][cinder] Using externally stored keys for encryption

[Mohammed Naser]

Hi everyone:

I've been digging around the documentation of Nova, Cinder and the
encrypted disks feature and I've been a bit stumped on something which
I think is a very relevant use case that might not be possible (or it
is and I have totally missed it!)

It seems that both Cinder and Nova assume that secrets are always
stored within the Barbican deployment in the same cloud.  This makes a
lot of sense however in scenarios where the consumer of an OpenStack
cloud wants to operate it without trusting the cloud, they won't be
able to have encrypted volumes that make sense, an example:

- Create encrypted volume, keys are stored in Barbican
- Boot VM using said encrypted volume, Nova pulls keys from Barbican,
starts VM..

However, this means that the deployer can at anytime pull down the
keys and decrypt things locally to do $bad_things.  However, if we had
something like any of the following two ideas:

- Allow for "run-time" providing secret on boot (maybe something added
to the start/boot VM API?)
- Allow for pointing towards an external instance of Barbican

By using those 2, we allow OpenStack users to operate their VMs
securely and allowing them to have control over their keys.  If they
want to revoke all access, they can shutdown all the VMs and cut
access to their key storage management and not worry about someone
just pulling them down from the internal Barbican.

Hopefully I did a good job explaining this use case and I'm just
wondering if this is a thing that's possible at the moment or if we
perhaps need to look into it.

Thanks,
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

[Mohammed Naser]

that should
be there) or remove all self-healing stuff

Also, for the self healing work, if we take that route and implement it fully,
it might make placement split much easier, because we just switch over
and wait for the computes to automagically populate everything, but that's
the type of operation that happens once in the lifetime of a cloud.

Just for information sake, a clean state cloud which had no reported issues
over maybe a period of 2-3 months already has 4 allocations which are
incorrect and 12 allocations pointing to the wrong resource provider, so I
think this comes does to committing to either "self-healing" to fix those
issues or not.

> * I believe I made the point yesterday that we should probably not
> refresh by default, and let operators opt-in to that behavior if they
> really need it, i.e. they are frequently making changes to the
> environment, potentially by some external service (I could think of
> vCenter doing this to reflect changes from vCenter back into
> nova/placement), but I don't think that should be the assumed behavior
> by most and our defaults should reflect the "normal" use case.

I agree.  For 99% of the deployments out there, placement service will likely
not be touched by anyone except the services and at this stage, probably
just Nova talking to placement directly.

I really do agree on the statement that the "normal" use case is of a user
playing around with placement out-of-band is not common at all.

> * I think I've noted a few times now that we don't actually use the
> provider aggregates information (yet) in the compute service. Nova host
> aggregate membership is mirror to placement since Rocky [1] but that
> happens in the API, not the the compute. The only thing I can think of
> that relied on resource provider aggregate information in the compute is
> the shared storage providers concept, but that's not supported (yet)
> [2]. So do we need to keep retrieving aggregate information when nothing
> in compute uses it yet?

Is there anything stopping us here from polling that information during
the time when the VM is spawning?  It doesn't seem like something that the
compute node always needs to check..

> * Similarly, why do we need to get traits on each periodic? The only
> in-tree virt driver I'm aware of that *reports* traits is the libvirt
> driver for CPU features [3]. Otherwise I think the idea behind getting
> the latest traits is so the virt driver doesn't overwrite any traits set
> externally on the compute node root resource provider. I think that
> still stands and is probably OK, even though we have generations now
> which should keep us from overwriting if we don't have the latest
> traits, but I wanted to bring it up since it's related to the "why do we
> need provider aggregates in the compute?" question.

Forgive my ignorance on this subject, but would traits really be only set
when the service is first started (so that check can happens only once on
startup) and then the compute nodes never really ever consume that
information (but the scheduler does?).  Also, AFAIK I doubt virt drivers
actually report much change in traits (CPU flags changing in runtime?)

> * Regardless of what we do, I think we should probably *at least* make
> that refresh associations config allow 0 to disable it so CERN (and
> others) can avoid the need to continually forward-porting code to
> disable it.

+1

> [1]
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-mirror-host-aggregates.html
> [2] https://bugs.launchpad.net/nova/+bug/1784020
> [3]
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/report-cpu-features-as-traits.html
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova][placement] Placement requests and caching in the resource tracker

[Mohammed Naser]

nd our defaults should reflect the "normal" use case.
>
> * I think I've noted a few times now that we don't actually use the
> provider aggregates information (yet) in the compute service. Nova host
> aggregate membership is mirror to placement since Rocky [1] but that
> happens in the API, not the the compute. The only thing I can think of
> that relied on resource provider aggregate information in the compute is
> the shared storage providers concept, but that's not supported (yet)
> [2]. So do we need to keep retrieving aggregate information when nothing
> in compute uses it yet?
>
> * Similarly, why do we need to get traits on each periodic? The only
> in-tree virt driver I'm aware of that *reports* traits is the libvirt
> driver for CPU features [3]. Otherwise I think the idea behind getting
> the latest traits is so the virt driver doesn't overwrite any traits set
> externally on the compute node root resource provider. I think that
> still stands and is probably OK, even though we have generations now
> which should keep us from overwriting if we don't have the latest
> traits, but I wanted to bring it up since it's related to the "why do we
> need provider aggregates in the compute?" question.
>
> * Regardless of what we do, I think we should probably *at least* make
> that refresh associations config allow 0 to disable it so CERN (and
> others) can avoid the need to continually forward-porting code to
> disable it.
>
> [1]
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-mirror-host-aggregates.html
> [2] https://bugs.launchpad.net/nova/+bug/1784020
> [3]
> https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/report-cpu-features-as-traits.html
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] Storyboard python script

[Mohammed Naser]

I believe this project is a client for Storyboard, an OpenStack project and not 
the commercial product you’re mentioning

Sent from my iPhone

> On Oct 31, 2018, at 11:39 PM, Krishna Jain  wrote:
> 
> Hi,
> I’m an animator with some coding experience picking up Python. I came across 
> your python-storyboardclient library, which would be very helpful for 
> automating our pipeline in Toon Boom Storyboard Pro. I’d like to have Python 
> call some of the Javascript scripts I’ve written to extend SBPro. Or at least 
> make it possible to rewrite the scripts in Python if need be. Unfortunately, 
> when I try to install it, I get:
>  
> Command ""c:\program files\python37\python.exe" -u -c "import setuptools, 
> tokeni
> ze;__file__='C:\\Users\\kjain\\AppData\\Local\\Temp\\pip-install-gli0gz3z\\netif
> aces\\setup.py';f=getattr(tokenize, 'open', 
> open)(__file__);code=f.read().replac
> e('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install 
> --recor
> d C:\Users\kjain\AppData\Local\Temp\pip-record-1qhmhrv5\install-record.txt 
> --sin
> gle-version-externally-managed --compile" failed with error code 1 in 
> C:\Users\k
> jain\AppData\Local\Temp\pip-install-gli0gz3z\netifaces\
>  
> Do you know what might be going wrong here?
> Thanks!
> -Krishna Jain
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] No complains about rabbitmq SSL problems: could we have this in the logs?

[Mohammed Naser]

For what it’s worth: I ran into the same issue.  I think the problem lies a bit 
deeper because it’s a problem with kombu as when debugging I saw that Oslo 
messaging tried to connect and hung after. 

Sent from my iPhone

> On Oct 31, 2018, at 2:29 PM, Thomas Goirand  wrote:
> 
> Hi,
> 
> It took me a long long time to figure out that my SSL setup was wrong
> when trying to connect Heat to rabbitmq over SSL. Unfortunately, Oslo
> (or heat itself) never warn me that something was wrong, I just got
> nothing working, and no log at all.
> 
> I'm sure I wouldn't be the only one happy about having this type of
> problems being yelled out loud in the logs. Right now, it does work if I
> turn off SSL, though I'm still not sure what's wrong in my setup, and
> I'm given no clue if the issue is on rabbitmq-server or on the client
> side (ie: heat, in my current case).
> 
> Just a wishlist... :)
> 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] [Searchlight][release] Searchlight will release Stein-1

[Mohammed Naser]

Yay!

Congratulations on the first Stein release, well done with your work
in looking after Searchlight so far.
On Tue, Oct 30, 2018 at 6:37 AM Trinh Nguyen  wrote:
>
> Hi team,
>
> I'm doing a release for Searchlight projects (searchlight, searchlight-ui, 
> python-searchlightclient) [1]. Please help to review and make sure everything 
> is ok.
>
> [1] https://review.openstack.org/#/c/614066/
>
> Finally \m/ :D
>
> Bests,
>
> --
> Trinh Nguyen
> www.edlab.xyz
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [openstack-community] Sharing upstream contribution mentoring result with Korea user group

[Mohammed Naser]

In echoing the words of everyone, it takes a tremendous amount of effort and 
patience to lead this effort. 

THANK YOU!

Sent from my iPhone

> On Oct 30, 2018, at 6:14 PM, Doug Hellmann  wrote:
> 
> "Ian Y. Choi"  writes:
> 
>> Hello,
>> 
>> I got involved organizing & mentoring Korean people for OpenStack 
>> upstream contribution for about last two months,
>> and would like to share with community members.
>> 
>> Total nine mentees had started to learn OpenStack, contributed, and 
>> finally survived as volunteers for
>>  1) developing OpenStack mobile app for better mobile user interfaces 
>> and experiences
>> (inspired from https://github.com/stackerz/app which worked on Juno 
>> release), and
>>  2) translating OpenStack official project artifacts including documents,
>>  and Container Whitepaper ( 
>> https://www.openstack.org/containers/leveraging-containers-and-openstack/ ).
>> 
>> Korea user group organizers (Seongsoo Cho, Taehee Jang, Hocheol Shin, 
>> Sungjin Kang, and Andrew Yongjoon Kong)
>> all helped to organize total 8 offline meetups + one mini-hackathon and 
>> mentored to attendees.
>> 
>> The followings are brief summary:
>>  - "OpenStack Controller" Android app is available on Play Store
>>   : 
>> https://play.google.com/store/apps/details?id=openstack.contributhon.com.openstackcontroller
>>(GitHub: https://github.com/kosslab-kr/openstack-controller )
>> 
>>  - Most high-priority projects (although it is not during string freeze 
>> period) and documents are
>>100% translated into Korean: Horizon, OpenStack-Helm, I18n Guide, 
>> and Container Whitepaper.
>> 
>>  - Total 18,695 words were translated into Korean by four contributors
>>   (confirmed through Zanata API: 
>> https://translate.openstack.org/rest/stats/user/[Zanata 
>> ID]/2018-08-16..2018-10-25 ):
>> 
>> ++---+-+
>> | Zanata ID  | Name  | Number of words |
>> ++---+-+
>> | ardentpark | Soonyeul Park | 12517   |
>> ++---+-+
>> | bnitech| Dongbim Im| 693 |
>> ++---+-+
>> | csucom | Sungwook Choi | 4397|
>> ++---+-+
>> | jaeho93| Jaeho Cho | 1088|
>> ++---+-+
>> 
>>  - The list of projects translated into Korean are described as:
>> 
>> +-+-+
>> | Project | Number of words |
>> +-+-+
>> | api-site| 20  |
>> +-+-+
>> | cinder  | 405 |
>> +-+-+
>> | designate-dashboard | 4   |
>> +-+-+
>> | horizon | 3226|
>> +-+-+
>> | i18n| 434 |
>> +-+-+
>> | ironic  | 4   |
>> +-+-+
>> | Leveraging Containers and OpenStack | 5480|
>> +-+-+
>> | neutron-lbaas-dashboard | 5   |
>> +-+-+
>> | openstack-helm  | 8835|
>> +-+-+
>> | trove-dashboard | 89  |
>> +-+-+
>> | zun-ui  | 193 |
>> +-+-+
>> 
>> I would like to really appreciate all co-mentors and participants on 
>> such a big event for promoting OpenStack contribution.
>> The venue and food were supported by Korea Open Source Software 
>> Development Center ( https://kosslab.kr/ ).
>> 
>> 
>> With many thanks,
>> 
>> /Ian
>> 
>> ___
>> Community mailing list
>> commun...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/community
> 
> This is an excellent success story, Ian, thank you for sharing it and
> for leading the effort.
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 

Re: [openstack-dev] [tripleo][openstack-ansible][nova][placement] Owners needed for placement extraction upgrade deployment tooling

[Mohammed Naser]

Hi there:

We spoke about this today in the OpenStack Ansible meeting, we've come
up with the following steps:

1) Create a role for placement which will be called `os_placement`
located in `openstack/openstack-ansible-os_placement`
2) Integrate that role with the OSA master and stop using the built-in
placement service
3) Update the playbooks to handle upgrades and verify using our
periodic upgrade jobs

For #1, Guilherme from the OSA team will be taking care of creating
the role initially, I'm hoping that maybe we can get it done sometime
this week.  I think it'll probably take another week to integrate it
into the main repo.

The difficult task really comes in the upgrade jobs, I really hope
that we can get some help on this as this probably puts a bit of a
load already on Guilherme, so anyone up to look into that part when
the first 2 are completed? :)

Thanks,
Mohammed
On Thu, Oct 25, 2018 at 7:34 PM Matt Riedemann  wrote:
>
> Hello OSA/TripleO people,
>
> A plan/checklist was put in place at the Stein PTG for extracting
> placement from nova [1]. The first item in that list is done in grenade
> [2], which is the devstack-based upgrade project in the integrated gate.
> That should serve as a template for the necessary upgrade steps in
> deployment projects. The related devstack change for extracted placement
> on the master branch (Stein) is [3]. Note that change has some dependencies.
>
> The second point in the plan from the PTG was getting extracted
> placement upgrade tooling support in a deployment project, notably
> TripleO (and/or OpenStackAnsible).
>
> Given the grenade change is done and passing tests, TripleO/OSA should
> be able to start coding up and testing an upgrade step when going from
> Rocky to Stein. My question is who can we name as an owner in either
> project to start this work? Because we really need to be starting this
> as soon as possible to flush out any issues before they are too late to
> correct in Stein.
>
> So if we have volunteers or better yet potential patches that I'm just
> not aware of, please speak up here so we know who to contact about
> status updates and if there are any questions with the upgrade.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html
> [2] https://review.openstack.org/#/c/604454/
> [3] https://review.openstack.org/#/c/600162/
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack-operators] Fleio - OpenStack billing - ver. 1.1 released

[Mohammed Naser]

On Fri, Oct 19, 2018 at 7:45 PM Jay Pipes  wrote:
>
> Please do not use these mailing lists to advertise
> closed-source/proprietary software solutions.

+1

> Thank you,
> -jay
>
> On 10/19/2018 05:42 AM, Adrian Andreias wrote:
> > Hello,
> >
> > We've just released Fleio version 1.1.
> >
> > Fleio is a billing solution and control panel for OpenStack public
> > clouds and traditional web hosters.
> >
> > Fleio software automates the entire process for cloud users. New
> > customers can use Fleio to sign up for an account, pay invoices, add
> > credit to their account, as well as create and manage cloud resources
> > such as virtual machines, storage and networking.
> >
> > Full feature list:
> > https://fleio.com#features
> >
> > You can see an online demo:
> > https://fleio.com/demo
> >
> > And sign-up for a free trial:
> > https://fleio.com/signup
> >
> >
> >
> > Cheers!
> >
> > - Adrian Andreias
> > https://fleio.com
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [publiccloud-wg][sdk][osc][tc] Extracting vendor profiles from openstacksdk

[Mohammed Naser]

I'm in support, mainly for quite a few reasons:

- The vendor data should/might need to be be released often.  If a
provider makes a change, it'd be nice that you can pick it up without
changing everything else that sits in your system (and potentially
breaking other things)
- We can add some very sort of basic gating that at least make sure
the endpoints are responding
- If we want to add a new region, we really shouldn't have to go
through many hours of OpenStack SDK jobs to pick them up

I'm all for it!
On Mon, Oct 15, 2018 at 11:04 PM Monty Taylor  wrote:
>
> Heya,
>
> Tobias and I were chatting at OpenStack Days Nordic about the Public
> Cloud Working Group potentially taking over as custodians of the vendor
> profile information [0][1] we keep in openstacksdk (and previously in
> os-client-config)
>
> I think this is a fine idea, but we've got some dancing to do I think.
>
> A few years ago Dean and I talked about splitting the vendor data into
> its own repo. We decided not to at the time because it seemed like extra
> unnecessary complication. But I think we may have reached that time.
>
> We should split out a new repo to hold the vendor data json files. We
> can manage this repo pretty much how we manage the
> service-types-authority [2] data now. Also similar to that (and similar
> to tzdata) these are files that contain information that is true
> currently and is not release specific - so it should be possible to
> update to the latest vendor files without updating to the latest
> openstacksdk.
>
> If nobody objects, I'll start working through getting a couple of new
> repos created. I'm thinking openstack/vendor-profile-data, owned/managed
> by Public Cloud WG, with the json files, docs, json schema, etc, and a
> second one, openstack/os-vendor-profiles - owned/managed by the
> openstacksdk team that's just like os-service-types [3] and is a
> tiny/thin library that exposes the files to python (so there's something
> to depend on) and gets proposed patches from zuul when new content is
> landed in openstack/vendor-profile-data.
>
> How's that sound?
>
> Thanks!
> Monty
>
> [0]
> http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/config/vendors
> [1]
> https://docs.openstack.org/openstacksdk/latest/user/config/vendor-support.html
> [2] http://git.openstack.org/cgit/openstack/service-types-authority
> [3] http://git.openstack.org/cgit/openstack/os-service-types
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [openstack-ansible] dropping xenial jobs

[Mohammed Naser]

FYI: Thanks to Jesse, he has picked up this work and it's up here:

https://review.openstack.org/#/c/609329/6
On Wed, Oct 10, 2018 at 9:56 AM Jesse Pretorius
 wrote:
>
> On 10/10/18, 5:54 AM, "Mohammed Naser"  wrote:
>
> >So I’ve been thinking of dropping the Xenial jobs to reduce our overall 
> > impact in terms of gate usage in master because we don’t support it.
>
> I think we can start dropping it given our intended supported platform for 
> Stein is Bionic, not Xenial. We'll have to carry Xenial & Bionic for Rocky as 
> voting jobs. Anything ported back and found not to work for both can be fixed 
> through either another patch to master which is back ported, or a 
> re-implementation, as necessary.
>
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [tc][all] meetings outside IRC

[Mohammed Naser]

Hi everyone:

I was going over our governance documents, more specifically this section:

"All project meetings are held in public IRC channels and recorded."

Does this mean that all official projects are *required* to hold their
project meetings over IRC?  Is this a hard requirement or is this
something that we're a bit more 'lax about?  Do members of the
community feel like it would be easier to hold their meetings if we
allowed other avenues (assuming this isn't allowed?)

Looking forward to hearing everyone's comments.

Thanks
Mohammed

__
OpenStack Development Mailing 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] [tc][all] Discussing goals (upgrades) with community @ office hours

[Mohammed Naser]

Hi everyone!

It looks like we're not going to be able to have a TC meeting every 2
weeks as I had hoped for, the majority of the TC seems to want to meet
once every month.  However, I wanted to ask if the community would be
interested in taking one of the upcoming office hours to discuss the
current community goals, more specifically upgrades.

It's been brought to my attention by some community members that they
feel like we've been deciding goals too early without having enough
maturity in terms of implementation.  In addition, it seems like the
final implementation way is not fully baked in by the time we create
the goal.  This was brought up in the WSGI goal last time and it looks
like there is some oddities at the moment with "do we implement our
own stuff?" "do we use the new oslo library?" "is the library even
ready?"

I wanted to propose one of the upcoming office hours to perhaps invite
some of the community members (PTL, developers, anyone!) as well as
the TC with goal champions to perhaps discuss some of these goals to
help everyone get a clear view on what's going on.

Does this seem like it would be of interest to the community?  I am
currently trying to transform our office hours to be more of a space
where we have more of the community and less of discussion between us.

Regards,
Mohammed

__
OpenStack Development Mailing 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] [tc] biweekly vs monthly meetings

[Mohammed Naser]

Hi everyone:

We've discussed bringing back meetings back to the TC and there's
different opinions on having biweekly vs monthly meetings.  Therefore,
I have added a patch similar to Doug's that instead lists biweekly
meetings instead of monthly meetings.

I would really appreciate if other community members could step vote
on what they feel would be best.  The agenda of those meetings would
be published in advance, topics could be requested from
chair/vice-chairs in advance and the notes would be available for the
community to consume, which should be easier to parse.

Besides the community, I'd invite TC members to vote on the change
that they prefer! :)

- Weekly: https://review.openstack.org/#/c/609562/
- Monthly: https://review.openstack.org/#/c/608751/

Thank you!
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [openstack-ansible] dropping xenial jobs

[Mohammed Naser]

Hi everyone!

So I’ve been thinking of dropping the Xenial jobs to reduce our overall impact 
in terms of gate usage in master because we don’t support it. 

However, I was a bit torn on this because i realize that it’s possible for us 
to write things and backport them only to find out that they’d break under 
xenial which can be deployed with Rocky. 

Thoughts?  Ideas?  I was thinking maybe Lee an experimental job.. not really 
sure on specifics but I’d like to bring in more feedback. 

Thanks,
Mohammed
__
OpenStack Development Mailing 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] [openstack-ansible] blocked gates

[Mohammed Naser]

Hi everyone:

Our gates have unfortunately been blocked because of OpenSUSE failures
and Bionic timeouts, I have submitted a patch to set both to non
voting

Bionic: It seems to take a really long time for APT installs, I'm
investigating and thanks to fungi I hope to have an instance to get it
up and running soon.

OpenSUSE: Package conflicts, nicolasbock is looking into it

I have created a patch to disable both jobs, as well as two patches to
enable them so we can be ready to enable them once they're fixed.

remote:   https://review.openstack.org/608427 Set OpenSUSE and Bionic
jobs to non-voting
remote:   https://review.openstack.org/608428 Restore Bionic jobs to
voting
remote:   https://review.openstack.org/608429 Restore OpenSUSE jobs

Thanks everyone for your patience!

Mohammed

__
OpenStack Development Mailing 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] bringing back formal TC meetings

[Mohammed Naser]

On Oct 4 2018, at 1:40 pm, Doug Hellmann  wrote:
>
> During the TC office hours today [1] we discussed the question of
> resuming having formal meetings of the TC to ensure we are in compliance
> with the section of the bylaws that says "The Technical Committee shall
> meet at least quarterly." [2] As not all TC members were present today,
> we decide to move the discussion to the mailing list to ensure all
> members have input into the decision.
>
> A bit of background
> ---
>
> The TC used to hold formal weekly meetings with agendas, roll call,
> etc. We stopped doing that in an attempt to encourage more asynchronous
> communication and to include folks in all time zones. Those meetings
> were replaced with less formal "office hours" where TC members were
> encouraged to be present on IRC in case the community had questions or
> issues to raise in a synchronous forum.
>
> The bylaws section that describes the membership and some of the
> expectations for the Technical Committee specifically requires us to
> meet at least once quarter year. We have had meetings at the PTGs and
> summits, which while not recorded via a roll call were open and
> documented afterwards with summaries to this mailing list.
>
> With the change in event schedule, we will no longer have obvious
> opportunities to hold 4 in-person meetings each year. During the
> discussion today, we established the general consensus that our current
> informal office hours do not constitute a "meeting" in the sense that
> any of us understand this requirement. As a result, we need to consider
> changes to our current meeting policy to ensure we are in compliance
> with the foundation bylaws.
>
> Today's discussion
> --
>
> A few folks expressed concern that we work to ensure these meetings
> *not* be seen as a replacement for asynchronous communication, and that
> we continue to encourage ad hoc discussions to continue to happen on the
> mailing list or during office hours. I think we agreed we could do that
> by managing the agenda carefully (i.e., the chair or vice chair would
> need to add topics to the agenda, rather than allowing anyone to add
> anything as we have done in the past). We also talked about only
> allowing recurring topics on the agenda, but I would prefer that we not
> write too many hard rules at the outset.
>
> We discussed how frequently we should meet, and everyone seemed to agree
> that weekly was too often and quarterly was not often enough. I proposed
> monthly, and there was some general support for that. We also talked
> about whether to find a new meeting time or to use one of the office
> hour times.
>
> As things stand now, the proposal is to try to find a time a few hours
> earlier than office hours on the first Thursday of each month for the
> meetings. The earlier time is so that APAC participants (Ghanshyam, in
> particular) do not need to stay up until midnight or later to
> participate.
>
> Next steps
> --
>
> TC members, please reply to this thread and indicate if you would find
> meeting at 1300 UTC on the first Thursday of every month acceptable, and
> of course include any other comments you might have (including alternate
> times).
>

I think every 1 month is a bit too much. Especially if we're going to rotate to 
be able to accommodate those in APAC time zones, they might not be able to make 
a proper meeting in 2 months.
I don't think a very brief weekly one that's planned which we can skip is a 
huge burden on all of us, finding an hour of time isn't too unreasonable (and 
we mostly are already doing it during office hours anyways).
> Thanks,
> Doug
>
>
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-04.log.html#t2018-10-04T15:02:31
> [2] https://www.openstack.org/legal/technical-committee-member-policy/ (item 
> #4)
>
> __
> OpenStack Development Mailing 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] [placement] The "intended purpose" of traits

[Mohammed Naser]

On Fri, Sep 28, 2018 at 7:17 PM Chris Dent  wrote:
>
> On Fri, 28 Sep 2018, melanie witt wrote:
>
> > I'm concerned about a lot of repetition here and maintenance headache for
> > operators. That's where the thoughts about whether we should provide
> > something like a key-value construct to API callers where they can instead
> > say:
> >
> > * OWNER=CINDER
> > * RAID=10
> > * NUMA_CELL=0
> >
> > for each resource provider.
> >
> > If I'm off base with my example, please let me know. I'm not a placement
> > expert.
> >
> > Anyway, I hope that gives an idea of what I'm thinking about in this
> > discussion. I agree we need to pick a direction and go with it. I'm just
> > trying to look out for the experience operators are going to be using this
> > and maintaining it in their deployments.
>
> Despite saying "let's never do this" with regard to having formal
> support for key/values in placement, if we did choose to do it (if
> that's what we chose, I'd live with it), when would we do it? We
> have a very long backlog of features that are not yet done. I
> believe (I hope obviously) that we will be able to accelerate
> placement's velocity with it being extracted, but that won't be
> enough to suddenly be able to do quickly do all the things we have
> on the plate.
>
> Are we going to make people wait for some unknown amount of time,
> in the meantime? While there is a grammar that could do some of
> these things?
>
> Unless additional resources come on the scene I don't think is
> either feasible or reasonable for us to considering doing any model
> extending at this time (irrespective of the merit of the idea).
>
> In some kind of weird belief way I'd really prefer we keep the
> grammar placement exposes simple, because my experience with HTTP
> APIs strongly suggests that's very important, and that experience is
> effectively why I am here, but I have no interest in being a
> fundamentalist about it. We should argue about it strongly to make
> sure we get the right result, but it's not a huge deal either way.

Is there a spec up for this should anyone want to implement it?

> --
> Chris Dent   ٩◔̯◔۶   https://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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [all][tc][elections] Stein TC Election Results

[Mohammed Naser]

On Thu, Sep 27, 2018 at 7:57 PM Emmet Hikory  wrote:
>
> Please join me in congratulating the 6 newly elected members of the
> Technical Committee (TC):
>
>   - Doug Hellmann (dhellmann)
>   - Julia Kreger (TheJulia)
>   - Jeremy Stanley (fungi)

Welcome back!

>   - Jean-Philippe Evrard (evrardjp)
>   - Lance Bragstad (lbragstad)
>   - Ghanshyam Mann (gmann)

..and welcome to the TC :)

>
> Full Results:
> https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f773fda2d0695864
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.

A big thank you to our election team who oversees all of this as well :)

> Thank you to all who voted and who encouraged others to vote.  Voter turnout
> was significantly up from recent cycles.  We need to ensure your voices are
> heard.
>
> --
> Emmet HIKORY
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [cinder][puppet][kolla][helm][ansible] Change in Cinder backup driver naming

[Mohammed Naser]

Thanks for the email Sean.

https://review.openstack.org/605846 Fix Cinder backup to use full paths

I think this should cover us, please let me know if we did things right.

FYI: the docs all still seem to point at the old paths..

https://docs.openstack.org/cinder/latest/configuration/block-storage/backup-drivers.html
On Thu, Sep 27, 2018 at 2:33 PM Sean McGinnis  wrote:
>
> This probably applies to all deployment tools, so hopefully this reaches the
> right folks.
>
> In Havana, Cinder deprecated the use of specifying the module for configuring
> backup drivers. Patch https://review.openstack.org/#/c/595372/ finally removed
> the backwards compatibility handling for configs that still used the old way.
>
> Looking through a quick search, it appears there may be some tools that are
> still defaulting to setting the backup driver name using the patch. If your
> project does not specify the full driver class path, please update these to do
> so now.
>
> Any questions, please reach out here or in the #openstack-cinder channel.
>
> Thanks!
> Sean
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack] [Openstack-Ansible] Unable to install Openstack Queens using Ansible

[Mohammed Naser]

Hi,

4GB of memory is not enough for a deployment unfortunately.  

You’ll have to bump it up. 

Thanks
Mohammed

Sent from my iPhone

> On Sep 18, 2018, at 7:04 AM, Budai Laszlo  wrote:
> 
> Hi,
> 
> run dmesg on your deployment host. It should print which process has been 
> evicted by the OOM killer.
> We had similar issues with our deployment host. We had to increase its memory 
> to 9G to have openstack-ansiblle working properly.
> You should also monitor the memory usage of your processes on the 
> controller/deployment host.
> 
> good luck,
> Laszlo
> 
>> On 18.09.2018 13:43, Anirudh Gupta wrote:
>> Hi Team,
>> I am installing Open Stack Queens using the Openstack Ansible and facing 
>> some issues
>> *System Configuration*
>> *Controller/Deployment Host*
>> RAM - 12 GB
>> Hard disk - 100 GB
>> Linux - Ubuntu 16.04
>> Kernel Version - 4.4.0-135-generic
>> *Compute*
>> RAM - 4 GB
>> Hard disk - 100 GB
>> Linux - Ubuntu 16.04
>> Kernel Version - 4.4.0-135-generic
>> *Issue Observed:*
>> When we run the below playbook
>> openstack-ansible setup-openstack.yml
>> *Error Observed:*
>> After running for some duration, it throws the error of "Out of Memory 
>> Killing mysqld"
>> In the "top" command, we see only haproxy processes and the system gets so 
>> slow that we are not even able to login into the system.
>> Can you please help me in resolving the issue.
>> Regards
>> Anirudh Gupta
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Mohammed Naser]

Hi,

On that note, is there any way to get an 'invite' onto those channels?

Any information about the foundation side of things about the
'official' channels?

Thanks,
Mohammed
On Mon, Sep 17, 2018 at 3:28 PM Samuel Cassiba  wrote:
>
> On Mon, Sep 17, 2018 at 6:58 AM Sylvain Bauza  wrote:
> >
> >
> >
> > Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley  a écrit :
> >>
> >> On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
> >> [...]
> >> > - What is the problem joining Wechat will solve (keeping in mind the
> >> > language barrier)?
> >>
> >> As I understand it, the suggestion is that mere presence of project
> >> leadership in venues where this emerging subset of our community
> >> gathers would provide a strong signal that we support them and care
> >> about their experience with the software.
> >>
> >> > - Isn't this problem already solved for other languages with
> >> > existing initiatives like local ambassadors and i18n team? Why
> >> > aren't these relevant?
> >> [...]
> >>
> >> It seems like there are at least couple of factors at play here:
> >> first the significant number of users and contributors within
> >> mainland China compared to other regions (analysis suggests there
> >> were nearly as many contributors to the Rocky release from China as
> >> the USA), but second there may be facets of Chinese culture which
> >> make this sort of demonstrative presence a much stronger signal than
> >> it would be in other cultures.
> >>
> >> > - Pardon my ignorance here, what is the problem with email? (I
> >> > understand some chat systems might be blocked, I thought emails
> >> > would be fine, and the lowest common denominator).
> >>
> >> Someone in the TC room (forgive me, I don't recall who now, maybe
> >> Rico?) asserted that Chinese contributors generally only read the
> >> first message in any given thread (perhaps just looking for possible
> >> announcements?) and that if they _do_ attempt to read through some
> >> of the longer threads they don't participate in them because the
> >> discussion is presumed to be over and decisions final by the time
> >> they "reach the end" (I guess not realizing that it's perfectly fine
> >> to reply to a month-old discussion and try to help alter course on
> >> things if you have an actual concern?).
> >>
> >
> > While I understand the technical issues that could be due using IRC in 
> > China, I still don't get why opening the gates and saying WeChat being yet 
> > another official channel would prevent our community from fragmenting.
> >
> > Truly the usage of IRC is certainly questionable, but if we have multiple 
> > ways to discuss, I just doubt we could prevent us to silo ourselves between 
> > our personal usages.
> > Either we consider the new channels as being only for southbound 
> > communication, or we envisage the possibility, as a community, to migrate 
> > from IRC to elsewhere (I'm particulary not fan of the latter so I would 
> > challenge this but I can understand the reasons)
> >
> > -Sylvain
> >
>
> Objectively, I don't see a way to endorse something other than IRC
> without some form of collective presence on more than just Wechat to
> keep the message intact. IRC is the official messaging platform, for
> whatever that's worth these days. However, at present, it makes less
> and less sense to explicitly eschew other outlets in favor. From a
> Chef OpenStack perspective, the common medium is, perhaps not
> unsurprising, code review. Everything else evolved over time to be
> southbound paths to the code, including most of the conversation
> taking place there as opposed to IRC.
>
> The continuation of this thread only confirms that there is already
> fragmentation in the community, and that people on each side of the
> void genuinely want to close that gap. At this point, the thing to do
> is prevent further fragmentation of the intent. It is, however, far
> easier to bikeshed over which platform of choice.
>
> At present, it seems a collective presence is forming ad hoc,
> regardless of any such resolution. With some additional coordination
> and planning, I think that there could be something that could scale
> beyond one or two outlets.
>
> Best,
> Samuel
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Mohammed Naser]

Sign me up too :)

Sent from my iPhone

> On Sep 16, 2018, at 6:06 PM, Zhipeng Huang  wrote:
> 
> Great to see the momentum going ! :) 
> 
> Another problem is that many people doesn't follow upstream so they are 
> oblivious about the new features and cool things had been done in every 
> cycle, and then all these types of half ass openstack trashing blog post got 
> shared in wechat moments dissing how openstack 2015 didn't help to solve 
> their 2018 problems
> 
> Glad to have Alex and Matt sign up on the Nova side :)
> 
>> On Mon, Sep 17, 2018, 4:57 AM Alex Xu  wrote:
>> I'm happy to be the translator or forwarder for the nova issue if you guys 
>> need(although, the nova team isn't happy with me now, also  i see it is not 
>> to my personal. I guess they won't be make me hard for other work I do.). I 
>> can see there are a lot of Chinese operators/users complain some issues, but 
>> they never send their feedback to the mail-list, this may due to the 
>> language, or people don't know the OpenSource culture in the China.(To be 
>> host, the OpenStack is first project, let a lot of developers to understand 
>> what is OpenSource, and how it is works. In the before, since the linux 
>> kernel is hard, really only few people in the China experience OpenSource).
>> 
>> 
>> 
>> 
>> Matt Riedemann  于2018年9月16日周日 下午11:34写道：
>>> On 9/15/2018 9:50 PM, Fred Li wrote:
>>> > As a non-native English speaker, it is nice-to-have that some TC or BoD 
>>> > can stay in the local social media, like wechat group in China. But it 
>>> > is also very difficult for non-native Chinese speakers to stay find 
>>> > useful information in ton of Chinese chats.
>>> > My thoughts (even I am not a TC candidate) on this is,
>>> > 1. it is kind of you to stay in the local group.
>>> > 2. if we know that you are in, we will say English if we want you to 
>>> > notice.
>>> > 3. since there is local OpenStack operation manager, hope he/she can 
>>> > identify some information and help to translate, or remind them to 
>>> > translate.
>>> > 
>>> > My one cent.
>>> 
>>> Is there a generic openstack group on wechat? Does one have to be 
>>> invited to it? Is there a specific openstack/nova group on wechat? I'm 
>>> on wechat anyway so I don't mind being in those groups if someone wants 
>>> to reach out.
>>> 
>>> -- 
>>> 
>>> Thanks,
>>> 
>>> Matt
>>> 
>>> __
>>> OpenStack Development Mailing 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] [election][tc] Opinion about 'PTL' tooling

[Mohammed Naser]

I think something we should take into consideration is *what* you consider 
health because the way we’ve gone about it over health checks is not something 
that can become a toolkit because it was more of question asking, etc

Sent from my iPhone

> On Sep 10, 2018, at 6:29 AM, Rico Lin  wrote:
> 
> 
> 
>> On Mon, Sep 10, 2018 at 5:31 AM Doug Hellmann  wrote:
>> Excerpts from jean-phili...@evrard.me's message of 2018-09-10 13:15:02 +0200:
>> > Hello everyone,
>> > 
>> > In my candidacy [1], I mentioned that the TC should provide more tools to 
>> > help the PTLs at their duties, for example to track community health.
>> > 
>> > I have questions for the TC candidates:
>> > - What is your opinion about said toolkit? Do you see a purpose for it?
>> > - Do you think said toolkit should fall under the TC umbrella?
>> > 
>> > After my discussion with Rico Lin (PTL of the Heat project, and TC 
>> > candidate) yesterday, I am personally convinced that it would be a good 
>> > idea, and that we should have those tools: As a PTL (but also any person 
>> > interested to see health of projects) I wanted it and I am not alone. PTLs 
>> > are focusing on their duties and, as a day is only composed of so few 
>> > hours, it is possible they won't have the focus to work on said tools to 
>> > track, in the longer term, the community.
>> > 
>> > For me, tracking community health (and therefore a toolkit for the 
>> > PTLs/community) is something TC should cover for good governance, and I am 
>> > not aware of any tooling extracting metrics that can be easily visible and 
>> > used by anyone. If each project started to have their own implementation 
>> > of tools, it would be opposite to one of my other goals, which is the 
>> > simplification of OpenStack.
>> > 
>> > Thanks for reading me, and do not hesitate to ask me questions on the 
>> > mailing lists, or in real life during the PTG!
>> > 
>> > Regards,
>> > Jean-Philippe Evrard (evrardjp)
>> > 
>> > [1]: 
>> > https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me
>> > 
>> 
>> We've had several different sets of scripts at different times to
>> extract review statistics from gerrit. Is that the sort of thing you
>> mean?
>> 
>> What information would you find useful?
> 
> First of all, I know I'm awake because jet lag, but it's surprise to see you 
> all are too! Are you guys really in Denver!? or just some cardboard cut-out I 
> saw!
> 
> Okay, let's back to the mail.
> As a PTL (not like a good one, but try to do what I can and learn from 
> others), I do see the benifit to have tool kit
> to properly alarm (or show to) PTL about how people been in projects. As 
> checking the health of projects been a big task for TCs for last cycle, I 
> believe this might be something we can further discussion in that TCs task.
> 
> Right now we're asking TCs to asisit team to get a health report. But if we 
> can provide a list of tools that mgith help PTLs (or cores) to generate some 
> information to see the health situation. so PTLs can see how's things going 
> after they adjust their strategies. For toolkits, I believe there're already 
> something we can collect for PTLs? So we can use what already there and make 
> sure we don't over taken everyone's time for this task.
> I aware there are challenges when we talk about how to make nwe-join people 
> feel good and how can we help PTLs (with experiences or not) to adjust their 
> way or to get better communications cross projects so PTLs will get a chances 
> to share and learn from others if they see any improvement also applied to 
> their team as well.
> 
> 
> Also I agree with Doug that it's improtant to bring this idea on table and 
> discuss about what exactly information we want to get from data. And what 
> information TCs feel helpful to track health condition.
> 
> 
> Now this bring me some idea of suggestion for all that I think it's time to 
> renew some documentation in 
> https://docs.openstack.org/project-team-guide/ptl.html 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] ptg schedule

[Mohammed Naser]

Hi team:

I've come up with a schedule which includes the general events
happening at the PTG which would be interesting for the OSA team and
contributors.

https://calendar.google.com/calendar?cid=dmV4eGhvc3QuY29tXzgwNmJyb2hpZnNoaGdmY2kzcWdqdDk3aTJzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

Please let me know if you have any difficulty accessing that link.
Also, it seems like a very loaded schedule however we're likely going
to have extra time here and there so it's very tentative :)

Thanks and look forward to seeing everyone!

Regards,
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [openstack-ansible] no meeting this week

[Mohammed Naser]

Hi team:

We won't be conducting a meeting this week because of the PTG,
however, we'll be making an effort to try and allow/bring remote
access to those not at the PTG over this week.

Thanks everyone.

Regards,
Mohammed

__
OpenStack Development Mailing 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-operators] [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[Mohammed Naser]

t; consensus that just removing the default-to-empty-sqlite behavior is the
> right thing to do. Placement won't magically find nova.conf if it exists
> and jump into its database, and it also won't do the silly thing of
> starting up with an empty database if the very important config step is
> missed in the process of deploying placement itself. Operators will have
> to deploy the new package and do the database surgery (which we will
> provide instructions and a script for) as part of that process, but
> there's really no other sane alternative without changing the current
> agreed-to plan regarding the split.
>
> Is everyone okay with the above summary of the outcome?

I've dropped my -1 from this given the discussion

https://review.openstack.org/#/c/600157/

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[Mohammed Naser]

t; consensus that just removing the default-to-empty-sqlite behavior is the
> right thing to do. Placement won't magically find nova.conf if it exists
> and jump into its database, and it also won't do the silly thing of
> starting up with an empty database if the very important config step is
> missed in the process of deploying placement itself. Operators will have
> to deploy the new package and do the database surgery (which we will
> provide instructions and a script for) as part of that process, but
> there's really no other sane alternative without changing the current
> agreed-to plan regarding the split.
>
> Is everyone okay with the above summary of the outcome?

I've dropped my -1 from this given the discussion

https://review.openstack.org/#/c/600157/

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack-operators] [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 12:41 PM Dan Smith  wrote:
>
> > I think there was a period in time where the nova_api database was created
> > where entires would try to get pulled out from the original nova database 
> > and
> > then checking nova_api if it doesn't exist afterwards (or vice versa).  One
> > of the cases that this was done to deal with was for things like instance 
> > types
> > or flavours.
> >
> > I don't know the exact details but I know that older instance types exist in
> > the nova db and the newer ones are sitting in nova_api.  Something along
> > those lines?
>
> Yep, we've moved entire databases before in nova with minimal disruption
> to the users. Not just flavors, but several pieces of data came out of
> the "main" database and into the api database transparently. It's
> doable, but with placement being split to a separate
> project/repo/whatever, there's not really any option for being graceful
> about it in this case.
>
> > At this point, I'm thinking turn off placement, setup the new one, do
> > the migration
> > of the placement-specific tables (this can be a straightforward documented 
> > task
> > OR it would be awesome if it was a placement command (something along
> > the lines of `placement-manage db import_from_nova`) which would import all
> > the right things
> >
> > The idea of having a command would be *extremely* useful for deployment 
> > tools
> > in automating the process and it also allows the placement team to 
> > selectively
> > decide what they want to onboard?
>
> Well, it's pretty cut-and-dried as all the tables in nova-api are either
> for nova or placement, so there's not much confusion about what belongs.
>
> I'm not sure that doing this import in python is really the most
> efficient way. I agree a placement-manage command would be ideal from an
> "easy button" point of view, but I think a couple lines of bash that
> call mysqldump are likely to vastly outperform us doing it natively in
> python. We could script exec()s of those commands from python, but.. I
> think I'd rather just see that as a shell script that people can easily
> alter/test on their own.
>
> Just curious, but in your case would the service catalog entry change at
> all? If you stand up the new placement in the exact same spot, it
> shouldn't, but I imagine some people will have the catalog entry change
> slightly (even if just because of a VIP or port change). Am I
> remembering correctly that the catalog can get cached in various places
> such that much of nova would need a restart to notice?

We already have placement in the catalog and it's behind a load balancer
so changing the backends resolves things right away, so we likely won't
be needing any restarts (and I don't think OSA will either because it uses
the same model).

> --Dan



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 12:41 PM Dan Smith  wrote:
>
> > I think there was a period in time where the nova_api database was created
> > where entires would try to get pulled out from the original nova database 
> > and
> > then checking nova_api if it doesn't exist afterwards (or vice versa).  One
> > of the cases that this was done to deal with was for things like instance 
> > types
> > or flavours.
> >
> > I don't know the exact details but I know that older instance types exist in
> > the nova db and the newer ones are sitting in nova_api.  Something along
> > those lines?
>
> Yep, we've moved entire databases before in nova with minimal disruption
> to the users. Not just flavors, but several pieces of data came out of
> the "main" database and into the api database transparently. It's
> doable, but with placement being split to a separate
> project/repo/whatever, there's not really any option for being graceful
> about it in this case.
>
> > At this point, I'm thinking turn off placement, setup the new one, do
> > the migration
> > of the placement-specific tables (this can be a straightforward documented 
> > task
> > OR it would be awesome if it was a placement command (something along
> > the lines of `placement-manage db import_from_nova`) which would import all
> > the right things
> >
> > The idea of having a command would be *extremely* useful for deployment 
> > tools
> > in automating the process and it also allows the placement team to 
> > selectively
> > decide what they want to onboard?
>
> Well, it's pretty cut-and-dried as all the tables in nova-api are either
> for nova or placement, so there's not much confusion about what belongs.
>
> I'm not sure that doing this import in python is really the most
> efficient way. I agree a placement-manage command would be ideal from an
> "easy button" point of view, but I think a couple lines of bash that
> call mysqldump are likely to vastly outperform us doing it natively in
> python. We could script exec()s of those commands from python, but.. I
> think I'd rather just see that as a shell script that people can easily
> alter/test on their own.
>
> Just curious, but in your case would the service catalog entry change at
> all? If you stand up the new placement in the exact same spot, it
> shouldn't, but I imagine some people will have the catalog entry change
> slightly (even if just because of a VIP or port change). Am I
> remembering correctly that the catalog can get cached in various places
> such that much of nova would need a restart to notice?

We already have placement in the catalog and it's behind a load balancer
so changing the backends resolves things right away, so we likely won't
be needing any restarts (and I don't think OSA will either because it uses
the same model).

> --Dan



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack-operators] [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann  wrote:
>
> On 9/5/2018 8:47 AM, Mohammed Naser wrote:
> > Could placement not do what happened for a while when the nova_api
> > database was created?
>
> Can you be more specific? I'm having a brain fart here and not
> remembering what you are referring to with respect to the nova_api DB.

I think there was a period in time where the nova_api database was created
where entires would try to get pulled out from the original nova database and
then checking nova_api if it doesn't exist afterwards (or vice versa).  One
of the cases that this was done to deal with was for things like instance types
or flavours.

I don't know the exact details but I know that older instance types exist in
the nova db and the newer ones are sitting in nova_api.  Something along
those lines?

> >
> > I say this because I know that moving the database is a huge task for
> > us, considering how big it can be in certain cases for us, and it
> > means control plane outage too
>
> I'm pretty sure you were in the room in YVR when we talked about how
> operators were going to do the database migration and were mostly OK
> with what was discussed, which was a lot will just copy and take the
> downtime (I think CERN said around 10 minutes for them, but they aren't
> a public cloud either), but others might do something more sophisticated
> and nova shouldn't try to pick the best fit for all.

If we're provided the list of tables used by placement, we could considerably
make the downtime smaller because we don't have to pull in the other huge
tables like instances/build requests/etc

What happens if things like server deletes happen while the placement service
is down?

> I'm definitely interested in what you do plan to do for the database
> migration to minimize downtime.

At this point, I'm thinking turn off placement, setup the new one, do
the migration
of the placement-specific tables (this can be a straightforward documented task
OR it would be awesome if it was a placement command (something along
the lines of `placement-manage db import_from_nova`) which would import all
the right things

The idea of having a command would be *extremely* useful for deployment tools
in automating the process and it also allows the placement team to selectively
decide what they want to onboard?

Just throwing ideas here.

> +openstack-operators ML since this is an operators discussion now.
>
> --
>
> Thanks,
>
> Matt



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann  wrote:
>
> On 9/5/2018 8:47 AM, Mohammed Naser wrote:
> > Could placement not do what happened for a while when the nova_api
> > database was created?
>
> Can you be more specific? I'm having a brain fart here and not
> remembering what you are referring to with respect to the nova_api DB.

I think there was a period in time where the nova_api database was created
where entires would try to get pulled out from the original nova database and
then checking nova_api if it doesn't exist afterwards (or vice versa).  One
of the cases that this was done to deal with was for things like instance types
or flavours.

I don't know the exact details but I know that older instance types exist in
the nova db and the newer ones are sitting in nova_api.  Something along
those lines?

> >
> > I say this because I know that moving the database is a huge task for
> > us, considering how big it can be in certain cases for us, and it
> > means control plane outage too
>
> I'm pretty sure you were in the room in YVR when we talked about how
> operators were going to do the database migration and were mostly OK
> with what was discussed, which was a lot will just copy and take the
> downtime (I think CERN said around 10 minutes for them, but they aren't
> a public cloud either), but others might do something more sophisticated
> and nova shouldn't try to pick the best fit for all.

If we're provided the list of tables used by placement, we could considerably
make the downtime smaller because we don't have to pull in the other huge
tables like instances/build requests/etc

What happens if things like server deletes happen while the placement service
is down?

> I'm definitely interested in what you do plan to do for the database
> migration to minimize downtime.

At this point, I'm thinking turn off placement, setup the new one, do
the migration
of the placement-specific tables (this can be a straightforward documented task
OR it would be awesome if it was a placement command (something along
the lines of `placement-manage db import_from_nova`) which would import all
the right things

The idea of having a command would be *extremely* useful for deployment tools
in automating the process and it also allows the placement team to selectively
decide what they want to onboard?

Just throwing ideas here.

> +openstack-operators ML since this is an operators discussion now.
>
> --
>
> Thanks,
>
> Matt



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

[Mohammed Naser]

Hi Andy:

I made a metal note of replying to this but I never got a chance to :(

It was great working with you, you're always welcome back anytime! :)

Thanks,
Mohammed


On Mon, Sep 3, 2018 at 3:32 AM Hugh Saunders  wrote:
>
> Thanks for all your hard work on OSA Andy :)
>
> On Thu, 30 Aug 2018 at 18:41 Andy McCrae  wrote:
>>
>> Now that Rocky is all but ready it seems like a good time! Since changing 
>> roles I've not been able to keep up enough focus on reviews and other 
>> obligations - so I think it's time to step aside as a core reviewer.
>>
>> I want to say thanks to everybody in the community, I'm really proud to see 
>> the work we've done and how the OSA team has grown. I've learned a tonne 
>> from all of you - it's definitely been a great experience.
>>
>> Thanks,
>> Andy
>> __
>> OpenStack Development Mailing 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



--
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

Could placement not do what happened for a while when the nova_api
database was created?

I say this because I know that moving the database is a huge task for
us, considering how big it can be in certain cases for us, and it
means control plane outage too
On Wed, Sep 5, 2018 at 9:39 AM Dan Smith  wrote:
>
> >> Yes, we should definitely trim the placement DB migrations to only
> >> things relevant to placement. And we can use this opportunity to get
> >> rid of cruft too and squash all of the placement migrations together
> >> to start at migration 1 for the placement repo. If anyone can think
> >> of a problem with doing that, please shout it out.
>
> I agree, FWIW.
>
> > Umm, nova-manage db sync creates entries in a sqlalchemy-migrate
> > versions table, something like that, to track per database what the
> > latest migration sync version has been.
> >
> > Based on that, and the fact I thought our DB extraction policy was to
> > mostly tell operators to copy the nova_api database and throw it
> > elsewhere in a placement database, then the migrate versions table is
> > going to be saying you're at 061 and you can't start new migrations
> > from 1 at that point, unless you wipe out that versions table after
> > you copy the API DB.
>
> They can do this, sure. However, either we'll need migrations to delete
> all the nova-api-related tables, or they will need to trim them
> manually. If we do the former, then everyone who ever installs placement
> from scratch will go through the early history of nova-api only to have
> that removed. Or we trim those off the front, but we have to keep the
> collapsing migrations until we compact again, etc.
>
> The thing I'm more worried about is operators being surprised by this
> change (since it's happening suddenly in the middle of a release),
> noticing some split, and then realizing that if they just point the
> placement db connection at nova_api everything seems to work. That's
> going to go really bad when things start to diverge.
>
> > I could be wrong, but just copying the database, squashing/trimming
> > the migration scripts and resetting the version to 1, and assuming
> > things are going to be hunky dory doesn't sound like it will work to
> > me.
>
> Why not?
>
> I think the safest/cleanest thing to do here is renumber placement-related
> migrations from 1, and provide a script or procedure to dump just the
> placement-related tables from the nova_api database to the new one (not
> including the sqlalchemy-migrate versions table).
>
> --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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [election] [tc] thank you

[Mohammed Naser]

Émilien:

I think you’re one of the role models of our community.  Your leadership has 
helped make it easier for me to become more involved from leading a project to 
joining the TC. 

Thank you again!

Regards,
Mohammed 

Sent from my iPhone

> On Sep 4, 2018, at 10:11 PM, Emilien Macchi  wrote:
> 
> After 2 years at the TC, I feel lucky enough to have been part of this group 
> where I hope that my modest contributions helped to make OpenStack a bit 
> better.
> I've learnt so many things and worked with a talented group where it's not 
> easy every day, but we have made and will continue to progress in the future.
> I personally feel like some rotation needs to happen, therefore I won't run 
> the current election.
> 
> I don't plan to leave or anything, I just wanted to say "merci" to the 
> community who gave me a chance to be part of this team.
> -- 
> 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 Development Mailing 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] Viewing VM's hypervisors as a non-admin user?

[Mohammed Naser]

hostId in the API exposes that without telling you the exact host
On Tue, Sep 4, 2018 at 4:49 PM Bernd Bausch  wrote:
>
> It’s probably this policy rule:
>
> "os_compute_api:os-extended-server-attributes": "rule:admin_api"
>
>
> See also 
> http://git.openstack.org/cgit/openstack/nova/tree/nova/policies/extended_server_attributes.py
>
> Bernd
>
> On Sep 5, 2018, at 4:20, Ken D'Ambrosio  wrote:
>
> Hey, all.  We've got a Juno cloud, and it would be really handy for some of 
> our engineers if they could see which VMs wound up on which hypervisors.  I'm 
> unsure how to make that happen; I'm afraid the documentation on the options 
> of the policy.json file is a bit opaque.  How would I go about making this 
> happen, assuming it's even possible?
>
> Thanks!
>
> -Ken
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

Forgive me for barging into this, but just with my deployer and PTL of
a deployment project hat on..

As part of the split, wouldn't we *not* need to make a devstack change
if this is done correctly because placement will become a nova
dependency, which is pulled out of Git and when using Zuul, will test
the specific commit in question.  From devstack's POV, deploying the
way things are shouldn't change (except for when we decide to deploy
placement separately).. but I believe in the process, both should
technically work? (and if devstack breaks, then maybe we'll be
breaking downstream users?)

Thanks,
Mohammed
On Tue, Aug 28, 2018 at 11:47 AM Matt Riedemann  wrote:
>
> On 8/28/2018 6:20 AM, Chris Dent wrote:
> > On Mon, 27 Aug 2018, melanie witt wrote:
> >
> >> I think we should use the openstack review system (gerrit) for moving
> >> the code. We're moving a critical piece of nova to its own repo and I
> >> think it's worth having the review and history contained in the
> >> openstack review system.
> >
> > This seems a reasonable enough strategy, in broad strokes. I want to
> > be sure that we're all actually in agreement on the details, as
> > we've had a few false starts and I think some of the details are
> > getting confused in the shuffle and the general busy-ness in progress.
> >
> > Is anyone aware of anyone who hasn't commented yet that should? If
> > you are, please poke them so we don't surprise them.
> >
> >> Using smaller changes that make it easy to see import vs content
> >> changes might make review faster than fewer, larger changes.
> >
> > I _think_ we ought to be able to use the existing commits from the
> > runs-throughs-to-passing-tests already done, but if we use the
> > strategy described below it doesn't really matter: the TDD approach
> > (after fixing paths and test config) is pretty fast.
> >
> >> The most important bit of all of this is making sure we don't break
> >> anything in the process for operators and users consuming nova and
> >> placement, and ensure the upgrade path from rocky => stein is tested
> >> in grenade.
> >
> > This is one of the areas where pretty active support from all of
> > nova will be required: getting zuul, upgrade paths, and the like
> > clearly defined and executed.
> >
> >> The steps I think we should take are:
> >>
> >> 1. We copy the placement code into the openstack/placement repo and
> >> have it passing all of its own unit and functional tests.
> >
> > To break that down to more detail, how does this look?
> > (note the ALL CAPS where more than acknowledgement is requested)
> >
> > 1.1 Run the git filter-branch on a copy of nova
> >  1.1.1 Add missing files to the file list:
> >1.1.1.1 .gitignore
> >1.1.1.2 # ANYTHING ELSE?
>
> Unless I were to actually run the git filter-branch tooling to see what
> is excluded from the new repo, I can't really say what is missing at
> this time. I assume it would be clear during review - which is why I'm
> asking that we do this stuff in gerrit where we do reviews.
>
> > 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
> >  (ed's repo should be fine)
> > 1.3 Do the repo creation bits described in
> >  https://docs.openstack.org/infra/manual/creators.html
> >  to seed openstack/placement
> >  1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
> >  func and unit # INPUT DESIRED HERE
>
> Agree. As I said to gibi elsewhere in this thread, I would hold off on
> adding a tempest-full job to the repo until we're at the end.
>
> > 1.4 Once the repo exists with some content, incrementally bring it to
> >  working
> >  1.4.1 Update tox.ini to be placement oriented
> >  1.4.2 Update setup.cfg to be placement oriented
> >  1.4.3 Correct .stesr.conf
> >  1.4.4 Move base of placement to "right" place
> >  1.4.5 Move unit and functionals to right place
> >  1.4.6 Do automated path fixings
> >  1.4.7 Set up translation domain and i18n.py corectly
> >  1.4.8 Trim placement/conf to just the conf settings required
> >(api, base, database, keystone, paths, placement)
> >  1.4.9 Remove database files that are not relevant (the db api is
> >not used by placement)
> >  1.4.10 Fix the Database Fixture to be just one database
> >  1.4.11 Disable migrations that can't work (because of
> > dependencies on nova code, 014 and 030 are examples)
> > # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL
> >  1.4.12 Incrementally get tests working
> >  1.4.13 Fix pep8
> > 1.5 Make zuul pep, unit and functional voting
> > 1.6 Create tools for db table sync/create
> > 1.7 Concurrently go to step 2, where the harder magic happens.
> > 1.8 Find and remove dead code (there will be some).
> > 1.9 Tune up and confirm docs
> > 1.10 Grep for remaining "nova" (as string and spirit) and fix
> >
> >
> > Item 1.4.12 may deserve some discussion. When I've done 

Re: [openstack-dev] [TripleO][kolla-ansible][DevStack][Tempest][openstack-ansible] Collaborate towards creating a unified ansible tempest role in openstack-ansible project

[Mohammed Naser]

Hi Chandan,

This is great, I added some more OSA-side comments, I'd love for us to
find sometime to sit down to discuss this at the PTG.

Thanks,
Mohammed

On Mon, Aug 27, 2018 at 12:39 PM, Jesse Pretorius
 wrote:
>>On 8/27/18, 7:33 AM, "Chandan kumar"  wrote:
>
>>I have summarized the problem statement and requirements on this etherpad 
>> [3].
>>Feel free to add your requirements and questions for the same on the
>>etherpad so that we can shape the unified ansible role in a better
>>way.
>
>>Links:
>>1. 
>> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133119.html
>>2. https://github.com/openstack/openstack-ansible-os_tempest
>>3. https://etherpad.openstack.org/p/ansible-tempest-role
>
> Thanks for compiling this Chandan. I've added the really base requirements 
> from an OSA standpoint that come to mind and a question that's been hanging 
> in the recesses of my mind for a while.
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [magnum] K8s Conformance Testing

[Mohammed Naser]

Hi Chris,

This is an awesome effort. We can provide nested virt resources which are 
leveraged by Kata at the moment. 

Thanks!
Mohammed

Sent from my iPhone

> On Aug 21, 2018, at 6:38 PM, Chris Hoge  wrote:
> 
> As discussed at the Vancouver SIG-K8s and Copenhagen SIG-OpenStack sessions,
> we're moving forward with obtaining Kubernetes Conformance certification for
> Magnum. While conformance test jobs aren't reliably running in the gate yet,
> the requirements of the program make sumbitting results manually on an
> infrequent basis something that we can work with while we wait for more
> stable nested virtualization resources. The OpenStack Foundation has signed
> the license agreement, and Feilong Wang is preparing an initial conformance
> run to submit for certification.
> 
> My thanks to the Magnum team for their impressive work on building out an
> API for deploying Kubernetes on OpenStack clusters.
> 
> [1] https://www.cncf.io/certification/software-conformance/
> 
> __
> OpenStack Development Mailing 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-Infra] Continued discussion of Winterscale naming

[Mohammed Naser]

It's a +1 for me, I really like the name.

On Tue, Aug 21, 2018 at 2:33 PM, Jeremy Stanley  wrote:
> The Infra team has been brainstorming and collecting feedback in
> https://etherpad.openstack.org/p/infra-services-naming as to what
> actual name/domain the Winterscale effort will use. If you've not
> been following along, the earlier discussions can be found in the
> following mailing list threads:
>
> http://lists.openstack.org/pipermail/openstack-infra/2018-May/005957.html
> http://lists.openstack.org/pipermail/openstack-infra/2018-July/006010.html
>
> So far the "short list" at the bottom of the pad seems to contain
> only one entry: OpenDev.
>
> The OpenStack Foundation has offered to let us take control of
> opendev.org for this purpose if we would like. They have it mainly
> as a defensive registration to protect the OpenDev Conference brand,
> but use a separate opendevconf.org domain for that at present. The
> opendev.org domain is just sitting parked on the same nameservers as
> openstack.org right now, not in use for anything. The brand itself
> has a positive connotation in the community so far, and the OpenDev
> Conferences share a lot of similar goals (bringing communities of
> people together to collaborate openly on design and development
> activities) so this even provides some useful synergy around the
> name and possible promotional tie-ins with the events if we like.
>
> I know lots of us are eager to move forward on the rebranding, so I
> wanted to wake this discussion back up and try to see if we can
> drive it to a conclusion. As we continue to take on hosting for
> additional large projects, having somewhere for them to send the
> contributors and users in their community which has a distinct
> identity unclouded by OpenStack itself will help make our services
> much more welcoming. If you don't particularly like the OpenDev idea
> or have alternatives you think might achieve greater consensus
> within our team and present a better image to our extended
> community, present and future, please update the above mentioned pad
> or follow up to this mailing list thread. Thanks!
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack-operators] [openstack-dev] [puppet] migrating to storyboard

[Mohammed Naser]

It's a +1 from me.  I don't think there is anything linked specifically to it.

On Wed, Aug 15, 2018 at 11:22 AM, Emilien Macchi  wrote:
> On Tue, Aug 14, 2018 at 6:33 PM Tobias Urdin  wrote:
>>
>> Please let me know what you think about moving to Storyboard?
>
> Go for it. AFIK we don't have specific blockers to make that migration
> happening.
>
> 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
>



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [puppet] migrating to storyboard

[Mohammed Naser]

It's a +1 from me.  I don't think there is anything linked specifically to it.

On Wed, Aug 15, 2018 at 11:22 AM, Emilien Macchi  wrote:
> On Tue, Aug 14, 2018 at 6:33 PM Tobias Urdin  wrote:
>>
>> Please let me know what you think about moving to Storyboard?
>
> Go for it. AFIK we don't have specific blockers to make that migration
> happening.
>
> 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
>



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do

[Mohammed Naser]

ras/tree/roles/validate-tempest
> [2] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest/
> [3] 
> http://git.openstack.org/cgit/openstack/kolla-ansible/tree/ansible/roles/tempest
> [4] http://git.openstack.org/cgit/openstack/ansible-role-tripleo-tempest
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack] [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Mohammed Naser]

Hi Victoria,

Thank you so much for all your wonderful work especially around Outreachy! :)

Sincerely,
Mohammed

On Tue, Aug 7, 2018 at 7:47 PM, Victoria Martínez de la Cruz
 wrote:
> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this effort
> for several rounds now and I believe is a good moment for somebody else to
> take the lead. You all know how important is Outreachy to me and I'm
> grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Mohammed Naser]

Hi Victoria,

Thank you so much for all your wonderful work especially around Outreachy! :)

Sincerely,
Mohammed

On Tue, Aug 7, 2018 at 7:47 PM, Victoria Martínez de la Cruz
 wrote:
> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this effort
> for several rounds now and I believe is a good moment for somebody else to
> take the lead. You all know how important is Outreachy to me and I'm
> grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
>
> __
> OpenStack Development Mailing 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] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Mohammed Naser]

On Mon, Jul 30, 2018 at 11:59 AM, Jesse Pretorius
 wrote:
>>On 7/30/18, 9:19 AM, "jean-phili...@evrard.me"  
>>wrote:
>>
>>I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
>> OpenStack-Ansible.
>>The BBC team [1] has been very active recently across the board, but 
>> worked heavily in our ops repo, making sure the experience is complete for 
>> operators.
>
> I most certainly welcome this. Jonathan (and his team) are insightful and 
> provide very valuable operator input and they're always ready to help when 
> they can. +2 from me
>
>
I echo those thoughts, +2. :)
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [puppet] non-candidacy for stein

[Mohammed Naser]

Hi everyone,

Unfortunately, I've gotten busy with a few other projects over time
and I won't be able to run PTL for the upcoming Stein cycle.

I'd like to personally thank all of the current Puppet team due to
their help in on-boarding and helping me take on one of my first
leadership experiences inside OpenStack, I'm extremely grateful for
all of it.

I'll continue to be able to do reviews however!

Thank you,
Mohammed

__
OpenStack Development Mailing 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] [openstack-ansible] Candidacy for OpenStack Ansible

[Mohammed Naser]

Hi everyone:

I would like to submit my candidacy to become PTL for the OpenStack Ansible
project for the upcoming Stein cycle.

I have been personally involved in the deployment of OpenStack for many years
now, using all sorts of different deployment tools.  Ansible seems like a
great choice for deployment OpenStack and I've been using OpenStack Ansible
for quite a while now.

As PTL, I hope that I can work with the team to focus on the following:

# CI
- Improve stability of CI for both roles and integrated repo. by using more
  mirrors.
- Start leveraging the integrated repo playbooks inside the role test jobs in
  order to avoid the duplication and test the OpenStack Ansible path
- Once jobs are stable, add integrated jobs to all roles in order to be sure
  that we don't break the integrated repo with role changes.

# Deployment
- Continue to work and finalize the addition of distro installation for all
  distributions.
- Aim to start integrating the `systemd` roles and look into seeing the
  possibility of enabling nspawn and avoiding lxc on CentOS.

There's much more to be done, but those are some of the aspects that would
help in the stability of this project which is what I feel we need to focus
a bit more on.   As a deployment project with a limited scope of the operating
systems needing to exist, there doesn't seem to be much we can come up with
and taking a cycle just to catch up on all the debt, improve stability and
make the maintenance of the project easier is extremely useful.

I hope to work with the team for the upcoming cycle.

Regards,
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [tc] Technical Committee update for week of 23 July

[Mohammed Naser]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

Doug (who usually sends these out!) is out so we've come up with
the idea of a vice-chair, which I'll be fulfilling.  More information
in the change listed below.

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- Remove Stable branch maintenance as a project team
https://review.openstack.org/584206
- Add ansible-role-tripleo-cookiecutter to governance
https://review.openstack.org/#/c/581428/

Reference/charter changes:

- Clarify new project requirements for community engagement
https://review.openstack.org/#/c/567944/
- add vice chair role to the tc charter https://review.openstack.org/#/c/583947/
- designate Mohammed Naser as vice chair
https://review.openstack.org/#/c/583948/

Other approved changes:

- ansible-role-tripleo-zaqar had a typo which was fixed up
https://review.openstack.org/#/c/583636/
- added validation for repo names (because of the above!)
https://review.openstack.org/#/c/583637/
- tooling improvements in this stack: https://review.openstack.org/#/c/583953/

Office hour logs:

Due to (what) seems to be a lack of consumption of the office hours
logs, we're not longer logging
the start and end.  However, we welcome community feedback if this was
something that was consumed.

== Ongoing Discussions ==

Sean McGinnis (smcginnis) has proposed the pre-upgrade checks as the
Stein goal, the document is
currently being worked on with reviews already in, please chime in:

- https://review.openstack.org/#/c/585491/

== TC member actions/focus/discussions for the coming week(s) ==

It looks like it's been a quiet past few days.  However, there is a
lot of discussion around how
to properly decide to on-board an OpenStack project in a very specific
and clear process rather
than an arbitrary one at the moment.

We also should continue to discuss on subjects for the upcoming PTG:

- https://etherpad.openstack.org/p/tc-stein-ptg

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.

__
OpenStack Development Mailing 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] [tc] Fast-track: Remove Stable branch maintenance as a project team

[Mohammed Naser]

Hi everyone:

This email is just to notify everyone on the TC and the community that
the change to remove the stable branch maintenance as a project
team[1] has been fast-tracked[2].

The change should be approved on 2018-07-28 however it is beneficial
to remove the stable branch team (which has been moved into a SIG) in
order for `tonyb` to be able to act as an election official.

There seems to be no opposing votes however a revert is always
available if any members of the TC are opposed to the change[3].

Thanks to Tony for all of his help in the elections.

Regards,
Mohammed

[1]: https://review.openstack.org/#/c/584206/
[2]: 
https://governance.openstack.org/tc/reference/house-rules.html#other-project-team-updates
[3]: 
https://governance.openstack.org/tc/reference/house-rules.html#rolling-back-fast-tracked-changes

__
OpenStack Development Mailing 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] Fatal error during container create (ansible-openstack on bionic)

[Mohammed Naser]

Hi there,

Bionic isn't current supported and we're working on adding support for
it in the Rocky cycle!  We recommend you deploy on Xenial.

Thanks,
Mohammed

On Wed, Jul 11, 2018 at 11:44 AM, Ruth Ivimey-Cook  wrote:
> I am getting a fatal error in lxc_create when running openstack-ansible
> playbooks/setup-hosts.yml and hoping someone can push me in the right
> direction. Logs below...
>
> I am interpreting the fatal error as some sort of missing config, which is
> why I included the warnings that happened earlier in the above. Is that
> right? Is there any way I can isolate where exactly in the ansible setup
> this happens?
>
> The only significant changes I've made to the ansible setup are
>
> - comment out `linux-image-extra-{{ ansible_kernel }}` package from the
> ubuntu config as it no longer exists.
> - create /etc/ansible/.../*ubuntu-18.04.yml files by copying the equivalent
> ubuntu-16.04.yml file, where no 18.04 version was already present.
>
>> ~/openstack-ansible$ sudo openstack-ansible playbooks/setup-hosts.yml
>>
>> Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e
>> @/etc/openstack_deploy/user_variables.yml "
>>
>>  [WARNING]: Unable to parse /etc/openstack_deploy/inventory.ini as an
>> inventory source
>
>> [DEPRECATION WARNING]: 'include' for playbook includes. You should use
>> 'import_playbook' instead. This
>>
>> feature will be removed in version 2.8. Deprecation warnings can be
>> disabled by setting
>>
>> deprecation_warnings=False in ansible.cfg.
>>
>>  [WARNING]: Could not match supplied host pattern, ignoring:
>> all_lxc_containers
>>
>>  [WARNING]: Could not match supplied host pattern, ignoring:
>> all_nspawn_containers
>>
>> PLAY [Install Ansible prerequisites]
>> *
>>
>> TASK [Ensure python is installed]
>> 
>>
>> ok: [aio1]
>
>
> ... lots of stuff that works...
>
>> TASK [Create the new LXC service log directory]
>> **
>>
>> ok: [aio1]
>>
>> TASK [Create the LXC service log aggregation link]
>> ***
>>
>> ok: [aio1]
>>
>> TASK [apt_package_pinning : Add apt pin preferences]
>> *
>>
>> TASK [lxc_hosts : Check for the presence of a public key file on the
>> deployment host] 
>>
>> ok: [aio1 -> localhost]
>>
>> TASK [lxc_hosts : Fail if a ssh public key is not set in a var and is not
>> present on the deployment host] 
>>
>> TASK [lxc_hosts : Gather variables for each operating system]
>> 
>>
>> ok: [aio1] =>
>> (item=/etc/ansible/roles/lxc_hosts/vars/ubuntu-18.04-host.yml)
>>
>> TASK [lxc_hosts : Gather container variables]
>> 
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>>
>> ok: [aio1] => (item=/etc/ansible/roles/lxc_hosts/vars/ubuntu-18.04.yml)
>>
>> TASK [lxc_hosts : include_tasks]
>> *
>>
>> included: /etc/ansible/roles/lxc_hosts/tasks/lxc_pre_install.yml for aio1
>
> A little later in the same run:
>
>> TASK [lxc_container_create : Check the physical_host variable is set]
>> 
>>
>> TASK [lxc_container_create : Collect physical host facts if missing]
>> *
>>
>> TASK [lxc_container_create : Kernel version and LXC backing store check]
>> *
>>
>> TASK [lxc_container_create : Gather variables for each operating system]
>> *
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>>
>> ok: [aio1_cinder_api_container-3255dd97] =>
>> (item=/etc/ansible/roles/lxc_container_create/vars/ubuntu-18.04.yml)
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>>
>> ok: [aio1_designate_container-54f1c305] =>
>> (item=/etc/ansible/roles/lxc_container_create/vars/ubuntu-18.04.yml)
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>>
>>  [WARNING]: Invalid request to find a file that matches a "null" value
>
> And then, finally, the fatal error:
>
>> TASK [lxc_container_create : include_tasks]
>> **
>>
>> included:
>> /etc/ansible/roles/lxc_container_create/tasks/lxc_container_create_dir.yml
>> for aio1_cinder_api_container-3255dd97, aio1_designate_container-54f1c305,
>> aio1_galera_container-b332cdef, aio1_glance_container-8d10cc70,
>> aio1_heat_api_container-362fdd4a, aio1_horizon_container-d76a2adc,
>> aio1_keystone_container-78616d24, 

Re: [Openstack] openstack-ansible variable overwrite question

[Mohammed Naser]

On Sun, Jul 1, 2018 at 6:14 PM, Satish Patel  wrote:
> I have deployed OSA and all good but having small issue in following file.
>
> # cat /etc/neutron/plugins/ml2/linuxbridge_agent.ini
>
> [linux_bridge]
> physical_interface_mappings = flat:eth12,vlan:br-vlan
>
> I WANT TO CHANGE IT TO FOLLWOING
>
> physical_interface_mappings = vlan:br-vlan
>
>
> I have overwrite variable in following file like this.
>
> # cat /etc/openstack_deploy/user_variables.yml
>
> neutron_linuxbridge_agent_ini_overrides:
>   linux_bridge:
> physical_interface_mappings = vlan:br-vlan

It's a YAML structure, you want this:

neutron_linuxbridge_agent_ini_overrides:
  linux_bridge:
physical_interface_mappings: vlan:br-vlan

>
> after re-run playbook it updated file with following format, am i
> missing something here?
>
> [DEFAULT]
> linux_bridge = physical_interface_mappings = vlan:br-vlan
>
> [linux_bridge]
> physical_interface_mappings = flat:eth12,vlan:br-vlan
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [openstack-dev] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Hi Paul:

On Thu, Jun 28, 2018 at 5:03 PM, Paul Belanger  wrote:
> On Thu, Jun 28, 2018 at 12:56:22PM -0400, Mohammed Naser wrote:
>> Hi everyone:
>>
>> This email is to ask if there is anyone out there opposed to removing
>> SELinux bits from OpenStack ansible, it's blocking some of the gates
>> and the maintainers for them are no longer working on the project
>> unfortunately.
>>
>> I'd like to propose removing any SELinux stuff from OSA based on the 
>> following:
>>
>> 1) We don't gate on it, we don't test it, we don't support it.  If
>> you're running OSA with SELinux enforcing, please let us know how :-)
>> 2) It extends beyond the scope of the deployment project and there are
>> no active maintainers with the resources to deal with them
>> 3) With the work currently in place to let OpenStack Ansible install
>> distro packages, we can rely on upstream `openstack-selinux` package
>> to deliver deployments that run with SELinux on.
>>
>> Is there anyone opposed to removing it?  If so, please let us know. :-)
>>
> While I don't use OSA, I would be surprised to learn that selinux wouldn't be
> supported.  I also understand it requires time and care to maintain. Have you
> tried reaching out to people in #RDO, IIRC all those packages should support
> selinux.

Indeed, the support from RDO for SELinux works very well.  In this case however,
OpenStack ansible deploys from source and therefore places binaries in different
places than the default expected locations for the upstream `openstack-selinux`.

As we work towards adding 'distro' support (which to clarify, it means
install from
RPMs or DEBs rather than from source), we'll be able to pull in that package and
automagically get SELinux support that's supported by an upstream that
tracks it.

> As for gating, maybe default to selinux passive for it to report errors, but 
> not
> fail.  And if anybody is interested in support it, they can do so and enable
> enforcing again when everything is fixed.

That's reasonable.  However, right now we have bugs around the distribution
of SELinux modules and how they are compiled inside the the containers,
which means that we're not having problems with the rules as much as uploading
the rules and getting them compiled inside the server.

I hope I cleared up a bit more of our side of things, I'm actually
looking forward
for us being able to support upstream distro packages.

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Hi Paul:

On Thu, Jun 28, 2018 at 5:03 PM, Paul Belanger  wrote:
> On Thu, Jun 28, 2018 at 12:56:22PM -0400, Mohammed Naser wrote:
>> Hi everyone:
>>
>> This email is to ask if there is anyone out there opposed to removing
>> SELinux bits from OpenStack ansible, it's blocking some of the gates
>> and the maintainers for them are no longer working on the project
>> unfortunately.
>>
>> I'd like to propose removing any SELinux stuff from OSA based on the 
>> following:
>>
>> 1) We don't gate on it, we don't test it, we don't support it.  If
>> you're running OSA with SELinux enforcing, please let us know how :-)
>> 2) It extends beyond the scope of the deployment project and there are
>> no active maintainers with the resources to deal with them
>> 3) With the work currently in place to let OpenStack Ansible install
>> distro packages, we can rely on upstream `openstack-selinux` package
>> to deliver deployments that run with SELinux on.
>>
>> Is there anyone opposed to removing it?  If so, please let us know. :-)
>>
> While I don't use OSA, I would be surprised to learn that selinux wouldn't be
> supported.  I also understand it requires time and care to maintain. Have you
> tried reaching out to people in #RDO, IIRC all those packages should support
> selinux.

Indeed, the support from RDO for SELinux works very well.  In this case however,
OpenStack ansible deploys from source and therefore places binaries in different
places than the default expected locations for the upstream `openstack-selinux`.

As we work towards adding 'distro' support (which to clarify, it means
install from
RPMs or DEBs rather than from source), we'll be able to pull in that package and
automagically get SELinux support that's supported by an upstream that
tracks it.

> As for gating, maybe default to selinux passive for it to report errors, but 
> not
> fail.  And if anybody is interested in support it, they can do so and enable
> enforcing again when everything is fixed.

That's reasonable.  However, right now we have bugs around the distribution
of SELinux modules and how they are compiled inside the the containers,
which means that we're not having problems with the rules as much as uploading
the rules and getting them compiled inside the server.

I hope I cleared up a bit more of our side of things, I'm actually
looking forward
for us being able to support upstream distro packages.

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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack-operators] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Also, this is the change that drops it, so feel free to vote with your
opinion there too:

https://review.openstack.org/578887 Drop SELinux support from os_swift

On Thu, Jun 28, 2018 at 12:56 PM, Mohammed Naser  wrote:
> Hi everyone:
>
> This email is to ask if there is anyone out there opposed to removing
> SELinux bits from OpenStack ansible, it's blocking some of the gates
> and the maintainers for them are no longer working on the project
> unfortunately.
>
> I'd like to propose removing any SELinux stuff from OSA based on the 
> following:
>
> 1) We don't gate on it, we don't test it, we don't support it.  If
> you're running OSA with SELinux enforcing, please let us know how :-)
> 2) It extends beyond the scope of the deployment project and there are
> no active maintainers with the resources to deal with them
> 3) With the work currently in place to let OpenStack Ansible install
> distro packages, we can rely on upstream `openstack-selinux` package
> to deliver deployments that run with SELinux on.
>
> Is there anyone opposed to removing it?  If so, please let us know. :-)
>
> Thanks!
> Mohammed
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.com



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Also, this is the change that drops it, so feel free to vote with your
opinion there too:

https://review.openstack.org/578887 Drop SELinux support from os_swift

On Thu, Jun 28, 2018 at 12:56 PM, Mohammed Naser  wrote:
> Hi everyone:
>
> This email is to ask if there is anyone out there opposed to removing
> SELinux bits from OpenStack ansible, it's blocking some of the gates
> and the maintainers for them are no longer working on the project
> unfortunately.
>
> I'd like to propose removing any SELinux stuff from OSA based on the 
> following:
>
> 1) We don't gate on it, we don't test it, we don't support it.  If
> you're running OSA with SELinux enforcing, please let us know how :-)
> 2) It extends beyond the scope of the deployment project and there are
> no active maintainers with the resources to deal with them
> 3) With the work currently in place to let OpenStack Ansible install
> distro packages, we can rely on upstream `openstack-selinux` package
> to deliver deployments that run with SELinux on.
>
> Is there anyone opposed to removing it?  If so, please let us know. :-)
>
> Thanks!
> Mohammed
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.com



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[Openstack-operators] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Hi everyone:

This email is to ask if there is anyone out there opposed to removing
SELinux bits from OpenStack ansible, it's blocking some of the gates
and the maintainers for them are no longer working on the project
unfortunately.

I'd like to propose removing any SELinux stuff from OSA based on the following:

1) We don't gate on it, we don't test it, we don't support it.  If
you're running OSA with SELinux enforcing, please let us know how :-)
2) It extends beyond the scope of the deployment project and there are
no active maintainers with the resources to deal with them
3) With the work currently in place to let OpenStack Ansible install
distro packages, we can rely on upstream `openstack-selinux` package
to deliver deployments that run with SELinux on.

Is there anyone opposed to removing it?  If so, please let us know. :-)

Thanks!
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [openstack-ansible] dropping selinux support

[Mohammed Naser]

Hi everyone:

This email is to ask if there is anyone out there opposed to removing
SELinux bits from OpenStack ansible, it's blocking some of the gates
and the maintainers for them are no longer working on the project
unfortunately.

I'd like to propose removing any SELinux stuff from OSA based on the following:

1) We don't gate on it, we don't test it, we don't support it.  If
you're running OSA with SELinux enforcing, please let us know how :-)
2) It extends beyond the scope of the deployment project and there are
no active maintainers with the resources to deal with them
3) With the work currently in place to let OpenStack Ansible install
distro packages, we can rely on upstream `openstack-selinux` package
to deliver deployments that run with SELinux on.

Is there anyone opposed to removing it?  If so, please let us know. :-)

Thanks!
Mohammed

-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [nova] Adding hostId to metadata

[Mohammed Naser]

Hi everyone:

While working with the OpenStack infrastructure team, we noticed that
we were having some intermittent issues where we wanted to identify a
theory if all VMs with this issue were landing on the same hypervisor.

However, there seems to be no way of directly accessing `hostId` from
inside the virtual machine (such as using the metadata API).  This is
a very useful thing to expose over the metadata API as not only would
it help for troubleshooting these types of scenarios however it would
also help software that can manage anti-affinity simply by checking
the API and taking scheduling decisions.

I've proposed the following patch to add this[1], however, this is
technically an API change, and the blueprints document specifies that
"API changes always require a design discussion."

Also, I believe that we're in a state where getting a spec would
require an exception.  However, this is a very trivial change.  Also,
according to the notes in the metadata file, it looks like there is
one "bump" per OpenStack release[3] which means that this change can
just be part of that release-wide version bump of the OpenStack API.

Can we include this trivial patch in the upcoming Rocky release?

Thanks,
Mohammed

[1]: https://review.openstack.org/577933
[2]: https://docs.openstack.org/nova/latest/contributor/blueprints.html
[3]: 
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/metadata/base.py#n60

__
OpenStack Development Mailing 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 debugging help?

[Mohammed Naser]

Hey Lars,

Do you have a full job that's running which shows those issues?

Thanks,
Mohammed

On Mon, Jun 18, 2018 at 11:13 AM, Lars Kellogg-Stedman  wrote:
> Hey folks,
>
> I'm trying to patch puppet-keystone to support multi-valued
> configuration options (like trusted_dashboard).  I have a patch that
> works, mostly, but I've run into a frustrating problem (frustrating
> because it would seem to be orthogonal to my patches, which affect the
> keystone_config provider and type).
>
> During the initial deploy, running tripleo::profile::base::keystone
> fails with:
>
>   "Error: Could not set 'present' on ensure: undefined method `new'
>   for nil:NilClass at
>   /etc/puppet/modules/tripleo/manifests/profile/base/keystone.pp:274",
>
> The line in question is:
>
>   70: if $step == 3 and $manage_domain {
>   71:   if hiera('heat_engine_enabled', false) {
>   72: # create these seperate and don't use ::heat::keystone::domain since
>   73: # that class writes out the configs
>   74: keystone_domain { $heat_admin_domain:
> ensure  => 'present',
> enabled => true
>   }
>
> The thing is, despite the error...it creates the keystone domain
> *anyway*, and a subsequent run of the module will complete without any
> errors.
>
> I'm not entirely sure that the error is telling me, since *none* of
> the puppet types or providers have a "new" method as far as I can see.
> Any pointers you can offer would be appreciated.
>
> Thanks!
>
> --
> Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [tc] StarlingX project status update

[Mohammed Naser]

Hi everyone:

This email is just to provide an update to the initial email regarding
the state of StarlingX.  The team has proposed a set of repositories
to be imported[1] which are completely new projects (not forks of
OpenStack or any other open source software).

Importing those projects will help us on-board the new StarlingX
contributors to our community, using the same tools we use for
developing our other projects.

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

If anyone has any questions, I'd be more than happy to address them.

Regards,
Mohammed

On Wed, May 30, 2018 at 4:23 PM, Mohammed Naser  wrote:
> Hi everyone:
>
> Over the past week in the summit, there was a lot of discussion
> regarding StarlingX
> and members of the technical commitee had a few productive discussions 
> regarding
> the best approach to deal with a proposed new pilot project for
> incubation in the OSF's Edge
> Computing strategic focus area: StarlingX.
>
> If you're not aware, StarlingX includes forks of some OpenStack
> components and other open source software
> which contain certain features that are specific to edge and
> industrial IoT computing use cases.  The code
> behind the project is from Wind River (and is used to build a product
> called "Titanium
> Cloud").
>
> At the moment, the goal of StarlingX hosting their projects on the
> community infrastructure
> is to get the developers used to the Gerrit workflow.  The intention
> is to evenutally
> work with upstream teams in order to bring the features and bug fixes which 
> are
> specific to the fork back upstream, with an ideal goal of bringing all
> the differences
> upstream.
>
> We've discussed around all the different ways that we can approach
> this and how to
> help the StarlingX team be part of our community.  If we can
> succesfully do this, it would
> be a big success for our community as well as our community gaining
> contributors from
> the Wind River team.  In an ideal world, it's a win-win.
>
> The plan at the moment is the following:
> - StarlingX will have the first import of code that is not forked,
> simply other software that
>   they've developed to help deliver their product.  This code can be
> hosted with no problems.
> - StarlingX will generate a list of patches to be brought upstream and
> the StarlingX team
>   will work together with upstream teams in order to start backporting
> and upstreaming the
>   codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
> on the responsibility of
>   monitoring the progress upstreaming these patches.
> - StarlingX contains a few forks of other non-OpenStack software. The
> StarlingX team will work
>   with the authors of the original projects to ensure that they do not
> mind us hosting a fork
>   of their software.  If they don't, we'll proceed to host those
> projects. If they prefer
>   something else (hosting it themselves, placing it on another hosting
> service, etc.),
>   the StarlingX team will work with them in that way.
>
> We discussed approaches for cases where patches aren't acceptable
> upstream, because they
> diverge from the project mission or aren't comprehensive. Ideally all
> of those could be turned
> into acceptable changes that meet both team's criteria. In some cases,
> adding plugin interfaces
> or driver interfaces may be the best alternative. Only as a last
> resort would we retain the
> forks for a long period of time.
>
> From what was brought up, the team from Wind River is hoping to
> on-board roughly 50 new full
> time contributors.  In combination with the features that they've
> built that we can hopefully
> upstream, I am hopeful that we can come to a win-win situation for
> everyone in this.
>
> Regards,
> Mohammed

__
OpenStack Development Mailing 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] [tc] StarlingX project status update

[Mohammed Naser]

Hi everyone:

Over the past week in the summit, there was a lot of discussion
regarding StarlingX
and members of the technical commitee had a few productive discussions regarding
the best approach to deal with a proposed new pilot project for
incubation in the OSF's Edge
Computing strategic focus area: StarlingX.

If you're not aware, StarlingX includes forks of some OpenStack
components and other open source software
which contain certain features that are specific to edge and
industrial IoT computing use cases.  The code
behind the project is from Wind River (and is used to build a product
called "Titanium
Cloud").

At the moment, the goal of StarlingX hosting their projects on the
community infrastructure
is to get the developers used to the Gerrit workflow.  The intention
is to evenutally
work with upstream teams in order to bring the features and bug fixes which are
specific to the fork back upstream, with an ideal goal of bringing all
the differences
upstream.

We've discussed around all the different ways that we can approach
this and how to
help the StarlingX team be part of our community.  If we can
succesfully do this, it would
be a big success for our community as well as our community gaining
contributors from
the Wind River team.  In an ideal world, it's a win-win.

The plan at the moment is the following:
- StarlingX will have the first import of code that is not forked,
simply other software that
  they've developed to help deliver their product.  This code can be
hosted with no problems.
- StarlingX will generate a list of patches to be brought upstream and
the StarlingX team
  will work together with upstream teams in order to start backporting
and upstreaming the
  codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
on the responsibility of
  monitoring the progress upstreaming these patches.
- StarlingX contains a few forks of other non-OpenStack software. The
StarlingX team will work
  with the authors of the original projects to ensure that they do not
mind us hosting a fork
  of their software.  If they don't, we'll proceed to host those
projects. If they prefer
  something else (hosting it themselves, placing it on another hosting
service, etc.),
  the StarlingX team will work with them in that way.

We discussed approaches for cases where patches aren't acceptable
upstream, because they
diverge from the project mission or aren't comprehensive. Ideally all
of those could be turned
into acceptable changes that meet both team's criteria. In some cases,
adding plugin interfaces
or driver interfaces may be the best alternative. Only as a last
resort would we retain the
forks for a long period of time.

From what was brought up, the team from Wind River is hoping to
on-board roughly 50 new full
time contributors.  In combination with the features that they've
built that we can hopefully
upstream, I am hopeful that we can come to a win-win situation for
everyone in this.

Regards,
Mohammed

__
OpenStack Development Mailing 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][all] A culture change (nitpicking)

[Mohammed Naser]

On Tue, May 29, 2018 at 10:43 AM, Artom Lifshitz  wrote:
> I dunno, there's a fine line to be drawn between getting a finished
> product that looks unprofessional (because of typos, English mistakes,
> etc), and nitpicking to the point of smothering and being
> counter-productive. One idea would be that, once the meat of the patch
> has passed multiple rounds of reviews and looks good, and what remains
> is only nits, the reviewer themselves take on the responsibility of
> pushing a new patch that fixes the nits that they found.

I'd just like to point out that what you perceive as a 'finished
product that looks unprofessional' might be already hard enough for a
contributor to achieve.  We have a lot of new contributors coming from
all over the world and it is very discouraging for them to have their
technical knowledge and work be categorized as 'unprofessional'
because of the language barrier.

git-nit and a few minutes of your time will go a long way, IMHO.

> On Tue, May 29, 2018 at 9:55 AM, Julia Kreger
>  wrote:
>> During the Forum, the topic of review culture came up in session after
>> session. During these discussions, the subject of our use of nitpicks
>> were often raised as a point of contention and frustration, especially
>> by community members that have left the community and that were
>> attempting to re-engage the community. Contributors raised the point
>> of review feedback requiring for extremely precise English, or
>> compliance to a particular core reviewer's style preferences, which
>> may not be the same as another core reviewer.
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may also be time limited.
>> Or an operator who noticed something that was clearly a bug and that
>> put forth a very minor fix and doesn't have the time to revise it over
>> and over.
>>
>> While nitpicks do help guide and teach, the consensus seemed to be
>> that we do need to shift the culture a little bit. As such, I've
>> proposed a change to our principles[1] in governance that attempts to
>> capture the essence and spirit of the nitpicking topic as a first
>> step.
>>
>> -Julia
>> -
>> [1]: https://review.openstack.org/570940
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> --
> Artom Lifshitz
> Software Engineer, OpenStack Compute DFG
>
> __
> OpenStack Development Mailing 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] Organizational diversity tag

[Mohammed Naser]

On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez  wrote:
> Mohammed Naser wrote:
>>
>> During the TC retrospective at the OpenStack summit last week, the
>> topic of the organizational diversity tag is becoming irrelevant was
>> brought up by Thierry (ttx)[1].  It seems that for projects that are
>> not very active, they can easily lose this tag with a few changes by
>> perhaps the infrastructure team for CI related fixes.
>>
>> As an action item, Thierry and I have paired up in order to look into
>> a way to resolve this issue.  There have been ideas to switch this to
>> a report that is published at the end of the cycle rather than
>> continuously.  Julia (TheJulia) suggested that we change or track
>> different types of diversity.
>>
>> Before we start diving into solutions, I wanted to bring this topic up
>> to the mailing list and ask for any suggestions.  In digging the
>> codebase behind this[2], I've found that there are some knobs that we
>> can also tweak if need-be, or perhaps we can adjust those numbers
>> depending on the number of commits.
>
>
> Right, the issue is that under a given level of team activity, there is a
> lot of state flapping between single-vendor, no tag, and
> diverse-affiliation. Some isolated events (someone changing affiliation, a
> dozen of infra-related changes) end up having a significant impact.
>
> My current thinking was that rather than apply a mathematical rule to
> produce quantitative results every month, we could take the time for a
> deeper analysis and produce a qualitative report every quarter.

I like this idea, however...

> Alternatively (if that's too much work), we could add a new team tag
> (low-activity ?) that would appear for all projects where the activity is so
> low that the team diversity tags no longer really apply.

I think as a first step, it would be better to look into adding a
low-activity team that so that anything under X number of commits
would fall under that tag.  I personally lean towards this because
it'll be a useful indication for consumers of deliverables of these
projects, because I think low activity is just as important as
diversity/single-vendor driven projects.

The only thing I have in mind is the possible 'feeling' for projects
which are very stable, quiet and functioning to end up with
low-activity tag, giving an impression that they are unmaintained.  I
think in general most associate low activity = unmaintained.. but I
can't come up with any better options either.

> --
> 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 Development Mailing 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-Infra] afs02 r/o volume mirrors - resolved

[Mohammed Naser]

On Sat, May 26, 2018 at 8:32 PM, Ian Wienand  wrote:
> On 05/25/2018 08:00 PM, Ian Wienand wrote:
>>
>> I am now re-running the sync in a root screen on afs02 with -localauth
>> so it won't timeout.
>
>
> I've now finished syncing back all R/O volumes on afs02, and the update
> cron jobs have been running successfully.
>
> Thanks,

Thank you for your work in getting everything back together while most
were busy at the summit!

> -i
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [tc] Organizational diversity tag

[Mohammed Naser]

Hi everyone!

During the TC retrospective at the OpenStack summit last week, the
topic of the organizational diversity tag is becoming irrelevant was
brought up by Thierry (ttx)[1].  It seems that for projects that are
not very active, they can easily lose this tag with a few changes by
perhaps the infrastructure team for CI related fixes.

As an action item, Thierry and I have paired up in order to look into
a way to resolve this issue.  There have been ideas to switch this to
a report that is published at the end of the cycle rather than
continuously.  Julia (TheJulia) suggested that we change or track
different types of diversity.

Before we start diving into solutions, I wanted to bring this topic up
to the mailing list and ask for any suggestions.  In digging the
codebase behind this[2], I've found that there are some knobs that we
can also tweak if need-be, or perhaps we can adjust those numbers
depending on the number of commits.

All feedback welcome. :)

Regards,
Mohammed

[1]: https://etherpad.openstack.org/p/YVR-tc-retrospective
[2]: https://github.com/openstack/governance/blob/master/tools/teamstats.py

__
OpenStack Development Mailing 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] [sdk] issues with using OpenStack SDK Python client

[Mohammed Naser]

script_config_openstack_for_onap.py", line 537, in 
> configure_all_ONAP
> if tiny_flavor != None:
>   File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
> 358, in __eq__
> return all([self._body.attributes == comparand._body.attributes,
> *** traceback.print_exception():
> Traceback (most recent call last):
>   File "auto_script_config_openstack_for_onap.py", line 537, in 
> configure_all_ONAP
> if tiny_flavor != None:
>   File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
> 358, in __eq__
> return all([self._body.attributes == comparand._body.attributes,
> AttributeError: 'NoneType' object has no attribute '_body'
>

Same bug as the other I believe, here: https://review.openstack.org/567230

>
> 
> For the image creation:
>
> ah, OK, indeed, there is an image proxy (even 2: v1, v2),
> and maybe the compute / image operations are redundant (or maybe not, for 
> convenience) ?
>
> and yes, it worked ! There was no need for additional parameters.
>
>
>
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. WARNING: Computer viruses can be transmitted via 
> email. The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage caused 
> by any virus transmitted by this email. www.wipro.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [tc][goals] tracking status of old goals for new projects

[Mohammed Naser]

On Mon, May 7, 2018 at 9:52 AM, Doug Hellmann  wrote:
> There is a patch to update the Python 3.5 goal for Kolla [1]. While
> I'm glad to see the work happening, the change adds a new deliverable
> to an old goal, and it isn’t clear whether we want to use that
> approach for tracking goal work indefinitely. I see a few options.
>
> 1. We could update the existing document.
>
> 2. We could set up stories in storyboard like we are doing for newer
>goals.

I think that this is the way to go moving forward.  That will
encourage projects to still
hit these goals and track them in someway.

It also makes those changes much quicker to update for projects as they don't
have to go through the entire governance merge process.

> 3. We could do nothing to record the work related to the goal.
>
> I like option 2, because it means we will be consistent with future
> tracking data and we end up with fewer changes in the governance repo
> (which was the reason for moving to storyboard in the first place).
>
> What do others think?
>
> Doug
>
> [1] https://review.openstack.org/#/c/557863/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [puppet] Proposing Tobias Urdin to join Puppet OpenStack core

[Mohammed Naser]

Hi everyone,

Due to active cores having no objections, I have officially added
Tobias to our cores.

Welcome, Tobias! :)

Thanks,
Mohammed

On Fri, Apr 27, 2018 at 5:13 PM, Alex Schultz <aschu...@redhat.com> wrote:
> +1
>
> On Fri, Apr 27, 2018 at 11:41 AM, Emilien Macchi <emil...@redhat.com> wrote:
>> +1, thanks Tobias for your contributions!
>>
>> On Fri, Apr 27, 2018 at 8:21 AM, Iury Gregory <iurygreg...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> On Fri, Apr 27, 2018, 12:15 Mohammed Naser <mna...@vexxhost.com> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> I'm proposing that we add Tobias Urdin to the core Puppet OpenStack
>>>> team as they've been putting great reviews over the past few months
>>>> and they have directly contributed in resolving all the Ubuntu
>>>> deployment issues and helped us bring Ubuntu support back and make the
>>>> jobs voting again.
>>>>
>>>> Thank you,
>>>> Mohammed
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing 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
>>>
>>
>>
>>
>> --
>> 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 Development Mailing 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] [openstack-ansible] Implement rotations for meetings handling

[Mohammed Naser]

On Wed, May 2, 2018 at 11:14 AM, Jean-Philippe Evrard
 wrote:
> Hello everyone,
>
> Now that we are all part-time, I'd like to toy with a new idea,
> proposed in the past by Jesse, to rotate the duties with people who
> are involved in OSA, or want to get involved more (it's not restricted
> to core developers!).
>
> One of the first duties to be handled this way could be the weekly meeting.

+1

I think that's something that we can share amongst us as a responsibility and
take turns doing.

> Handling the meeting is not that hard, it just takes time to prepare,
> and to facilitate.
>
> I think everyone should step into this, not only core developers, but
> core developers are now expected to run the meetings when their turn
> comes.
>
>
> What are the actions to take:
> - Prepare the triage. Generate the list of the bugs for the week.
> - Ping people with the triage links around 1h before the weekly
> meeting. It would give them time to get prepared for meeting,
> eventually updating the agenda, and read the current bugs
> - Ping people at the beginning of the meeting
> - Chair the meeting: The structure of the meeting is now always
> the same, a recap of the week, and handling the bug triage.
> - After the meeting we would ask who is volunteer to run next
> meeting, and if none, a meeting char will be selected amongst core
> contributors at random.
>
> Thank you for your understanding.
>
> Jean-Philippe Evrard (evrardjp)
>
> __
> OpenStack Development Mailing 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][stackalytics][neutron] neutron-lib not showing as TC-approved project on stackalytics

[Mohammed Naser]

On Wed, May 2, 2018 at 9:16 AM, Boden Russell  wrote:
> Back in 2016 we tagged neutron-lib as a "tc-approved-release" and as a
> result neutron-lib commits/reviews showed up on stackalytics under
> TC-approved Project Types.
>
> However as of recent that's seemed to have changed and neutron-lib
> commits/reviews are no longer showing up [1] even though it appears to
> still be tagged [2] IIUC.
>
> Is neutron-lib not showing up as a TC-approved project in
> stackalytics intentional? If so can some please refer me as to why. If
> not how do we get stackalytics to pick it up again?

I think at the moment, Stackalytics is not in an entirely consistent
state, you'll notice in the header:

"The data is being loaded now and is not complete"

I am going to throw a guess that the data hasn't be fully loaded up
yet to appear, it would probably be good to check back once it's fully
loaded and that header is disappeared.

> Thanks
>
>
> [1]
> http://stackalytics.com/?release=rocky_type=tc:approved-release=commits
> [2]
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2065
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [puppet] Proposing Tobias Urdin to join Puppet OpenStack core

[Mohammed Naser]

Hi everyone,

I'm proposing that we add Tobias Urdin to the core Puppet OpenStack
team as they've been putting great reviews over the past few months
and they have directly contributed in resolving all the Ubuntu
deployment issues and helped us bring Ubuntu support back and make the
jobs voting again.

Thank you,
Mohammed

__
OpenStack Development Mailing 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] campaign question: How can we make contributing to OpenStack easier?

[Mohammed Naser]

On Mon, Apr 23, 2018 at 10:06 AM, Doug Hellmann  wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
>
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
>
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
>
> Which of those would you change, and how?
>
> Where else should we be looking for contributors?

I think that for the most part, the most vocal audience is the one
that contributes the most is
mostly very comfortable with the tools and processes that we have in
place today.  However,
I think we may have become 'blind' to the viewpoint of new
contributors and forgot some of
our habits might be very difficult pain points for other users.

## Communication

There is a significant amount of communication and work that happens
over IRC.  I'll admit,
it's one of my most preferable ways of communicating.  However, it's
not something that
is common for newer contributors to use.  Our developer manual lists
it before anything:

https://docs.openstack.org/infra/manual/developers.html#irc-account

There are a few other communities which are growing quickly and
they're using alternative
ways of communication.  I personally prefer  IRC, but maybe we should
put our preferences
aside and look at what's sustainable, because we have to be
progressive and move quickly.

Perhaps we should look into a OpenStack Slack community in combination
with an IRC
bridge?

 ## Tooling

The majority of long time OpenStack contributors are very comfortable
with the Gerrit
workflow.  They're also very comfortable with rebasing patches,
pushing them, setting
up dependencies, etc.

The newer developer might have some Gerrit experience but more than
likely, they might
probably have more of a GitHub workflow experience and that's the
easiest way that
the can submit code.

While my own preference is to use Gerrit, I think that perhaps looking
into opening up a
way for contributions via GitHub to be available could be an
interesting option.  Now, the
technical side of me can imagine all the challenges, but again, we
must keep things easy
and approachable.

If submitting a patch to the OpenStack community involves setting up
an account in the
Canonical "Ubuntu One" OpenID, creating a username in Gerrit
afterwards, sign the CLA,
which could get complicated depending on your organization, upload
your keys, setup
git-review before being able to push up a single patch (and then
there's Launchpad for
bugs and some projects are on Storyboard, etc)

That's a lot of extra work that we're putting on new potential
contributors.  I don't mind it,
but I think we have to collectively think about new potential
contributors rather than
our preferences.

I'm giving a lot of ideas that I might not have technical solutions in
place, but I think putting
them out might bring up some other ways that we can come to a
compromise and make it work
to make contributing to OpenStack easy.

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

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

Re: [openstack-dev] [puppet] Add new puppet-senlin repository to Puppet OpenStack

[Mohammed Naser]

Done!

Thanks :)

On Tue, Apr 10, 2018 at 4:09 AM, 钟生平 <chd...@163.com> wrote:
> Hi, Mohammed
>
> Needs PTL+1, Can you review?
>
> Thanks,
> Zhong Shengping
>
>
> At 2018-04-10 14:03:54, "钟生平" <chd...@163.com> wrote:
>
> Hi, core members
>
> I have added new puppet-senlin repository to Puppet OpenStack[1][2][3]. I'm
> going to work on this module. Please review.
>
> [1]https://review.openstack.org/#/c/559537/
> [2]https://review.openstack.org/#/c/559539/
> [3]https://review.openstack.org/#/c/559563/
>
> Thanks,
> Zhong Shengping
>
>
>
>
>
>
>



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Mohammed Naser]

On Fri, Mar 16, 2018 at 5:34 PM, Jeremy Stanley  wrote:
> On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
> [...]
>> It seems mod_wsgi doesn't want python applications catching SIGHUP,
>> as Apache expects to be able to catch that. By default, it even ensures
>> signal handlers do not get registered.[0]
> [...]
>> Given we just had a goal to make all API services runnable as a WSGI
>> application, it seems wrong to enable mutable config for API services.
>> It's a super useful thing though, so I'd love to figure out a way we can do
>> it.
> [...]
>
> Given these are API services, can the APIs grow a (hopefully
> standardized) method to trigger this in lieu of signal handling? Or
> if the authentication requirements are too much, Zuul and friends
> have grown RPC sockets which can be used to inject these sorts of
> low-level commands over localhost to their service daemons (or could
> probably also do similar things over UNIX sockets if you don't want
> listeners on the loopback interface).

Throwing an idea out there, but maybe listening to file modification
events using something like inotify could be a possibility?

> --
> 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 Development Mailing 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] Going but not gone

[Mohammed Naser]

Major,

I've only recently had the chance to work with you more recently on
several projects but it's always been great to see the type of work
that you do.  From seeing the work that you do inside OpenStack, to
your extremely informative blog and the talks you've given.  You'll be
greatly missed in the OpenStack community and I (and surely believe
the majority of OpenStackers) hope that we cross paths again in the
future. :)

Best of luck!

Regards,
Mohammed

On Fri, Mar 9, 2018 at 8:54 AM, Major Hayden  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello there,
>
> I'm leaving my current role for a new opportunity and, unfortunately, this 
> means I won't be as involved in OpenStack as much in the near future. I've 
> spoken with our fearless OpenStack-Ansible PTL and I let JP know that I will 
> resign from the core reviewers group immediately if I feel that I cannot meet 
> the obligations of the role.
>
> With that said, the OpenStack community has been truly amazing. My first 
> humble contribution[0] was a fix for broken glance tests back in 2011. I've 
> done a little more since then and I'm proud to be a tiny part of what 
> OpenStack has become today.
>
> I'd like to thank everyone who has reviewed one of my patches, fixed one of 
> the bugs I created with my patches, and fixed the gate jobs that I broke with 
> my patches. Thanks to everyone who has attended one of my talks at the 
> Summits and thanks to everyone who has put up with my oddball suggestions at 
> Design Summits, Forums, and PTGs. I have learned an *incredible* amount about 
> OpenStack, Python, Linux, open source, communities, and how to be a better 
> human.
>
> Thanks to the leaders of the OpenStack Foundation as well for their continued 
> support. They have been excellent listeners and they took lots of time to 
> consider my suggestions for improvements.
>
> I love you all and working in this community has been one of the best 
> experiences in my professional career. :)
>
> [0] https://review.openstack.org/#/c/2652/
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAlqikg0ACgkQc3BR4MEB
> H7HN9Q/+PKC0TpfosAcZwotuVoSncoJc5D3RDL6RgO09Vm1xbI84BWkv6b6tJz4/
> SvBmiqR7LtXUQDN1yiDg1g8Bq8gNKJO7E0hW7WqRE5rJmXAX2Gpx80pQ04mO0LBv
> 21OaeJSGElT5MdQYu/wz6oP8iNwjAqUaU7b/BZFXcGgpA+S9qDMaQCMK/EXnrodd
> hsDbBxtOridNk9j7SefgwIGZKOr4gdPCxvqnTfj0/X5Cjb+OfMU4rU6dRSIoVaiz
> JVrwZr7DVVyvJmF5JFtpsOJGS9SF7YkOJKia3BsmCnJWeNm9+r1n2XjSXHY240tQ
> gjNfqgvWbyaLddm+8ZMC77zsZu3Kaf4M2ta9F95K0/PlsShoZYBCDso23aDRsjps
> czR3RjT51bdGdEDNhpJkimHQLLFqrvO6NRfg6Azf+Wii3/POrtez60Nx49SQgBul
> PTB/i+mHl44Yn9R2VpWgqKM+WMixRxD75SRyOlDXrU0setUv/91Hz+x32cqeeiX0
> C8mWOPh9POOdQPLeIalR2E4F9//CFv4nWZNSjpwIEEeXLd/Mlkyf2ue7ye+1s/5U
> JYo2wygRLEiLimacaoEyTRguR5/QsKtMieqKKfIYQglQDQkulWhhxOeqJmkpP10p
> xQp11b/GIwrXA4wVi5KA3hQEB/ST/2ENvTO76e/oGW41RK9S0gw=
> =5+cM
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Pros and Cons of face-to-face meetings

[Mohammed Naser]

On Thu, Mar 8, 2018 at 12:49 PM, Flint WALRUS  wrote:
> Pretty easy, put the PTG online with a livestream on
> YouTube/Hangout/whatever platform that will then be saved and could even be
> watched later on!

+1

I think that we can work out a solution so that every room at the PTG
has a live stream
going with the ability of people to join remotely.  This would be
hugely beneficial for
those who are unable to attend as they'll be able to join the room and
be part of the
discussion.

I can imagine that it involves quite a bit of logistics, but with the
right planning and
testing, I think it could work out great.

> It’s just a matter of some hardware and a decent internet bandwidth that’s
> already available to almost every places where a PTG took place.
>
> Problem solved.
>
> PS: Even if I second your thoughts about the fact that some can make it to a
> physical meeting for some reason (And I’m one of them), your email sounds a
> little bit aggressive. Miss some smiley ? ;-)
>
> Le jeu. 8 mars 2018 à 15:04, Jens Harbott  a écrit :
>>
>> With the current PTG just finished and seeing discussions happen about
>> the format of the next[0], it seems that the advantages of these seem
>> to be pretty clear to most, so let me use the occasion to remind
>> everyone of the disadvantages.
>>
>> Every meeting that is happening is excluding those contributors that
>> can not attend it. And with that it is violating the fourth Open
>> principle[1], having a community that is open to everyone. If you are
>> wondering whom this would affect, here's a non-exclusive (sic) list of
>> valid reasons not to attend physical meetings:
>>
>> - Health issues
>> - Privilege issues (like not getting visa or travel permits)
>> - Caretaking responsibilities (children, other family, animals, plants)
>> - Environmental concerns
>>
>> So when you are considering whether it is worth the money and effort
>> to organise PTGs or similar events, I'd like you also to consider
>> those being excluded by such activities. It is not without a reason
>> that IRC and emails have been settled upon as preferred means of
>> communication. I'm not saying that physical meetings should be dropped
>> altogether, but maybe more effort can be placed into providing means
>> of remote participation, which might at least reduce some effects.
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
>> [1] https://governance.openstack.org/tc/reference/opens.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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