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

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

[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

Re: [openstack-dev] [nova] PTL Election Season

[Mohammed Naser]

> On Jan 22, 2018, at 6:46 PM, Jay S Bryant  wrote:
> 
> 
> 
>> On 1/22/2018 5:09 PM, Matt Riedemann wrote:
>>> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>>> Election details: https://governance.openstack.org/election/
>>> 
>>> Please read the stipulations and timelines for candidates and electorate 
>>> contained in this governance documentation.
>>> 
>>> Be aware, in the PTL elections if the program only has one candidate, that 
>>> candidate is acclaimed and there will be no poll. There will only be a poll 
>>> if there is more than one candidate stepping forward for a program's PTL 
>>> position.
>>> 
>>> There will be further announcements posted to the mailing list as action is 
>>> required from the electorate or candidates. This email is for information 
>>> purposes only.
>>> 
>>> If you have any questions which you feel affect others please reply to this 
>>> email thread.
>>> 
>> 
>> To anyone that cares, I don't plan on running for Nova PTL again for the 
>> Rocky release. Queens was my fourth tour and it's definitely time for 
>> someone else to get the opportunity to lead here. I don't plan on going 
>> anywhere and I'll be here to help with any transition needed assuming 
>> someone else (or a couple of people hopefully) will run in the election. 
>> It's been a great experience and I thank everyone that has had to put up 
>> with me and my obsessive paperwork and process disorder in the meantime.
>> 
> Matt,
> 
> Thanks for all you have done!  Many good things have been done during your 
> tour!
> 
> Jay
> 

+1

Matt, you’ve been an excellent PTL for the Nova project.  The work that you’ve 
helped lead with the the Nova team has improved our experience with operating 
Nova and made our lives easier.

Your constant reaching out with operators to make sure that the changes align 
with what we expect is great. 

You’ll still be around but I want to extend my personal thank you!

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

__
OpenStack Development Mailing 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] Ubuntu problems + Help needed

[Mohammed Naser]

gt;>>> https://review.openstack.org/529670
>>>>>
>>>> As a follow up, the mirrors have landed and two of the four scenarios
>>>> now pass.  Scenario001 is failing on ceilometer-api which was removed
>>>> so I have a patch[0] to remove it. Scenario004 is having issues with
>>>> neutron and the db looks to be very unhappy[1].
>>>>
>>>> Thanks,
>>>> -Alex
>>>>
>>>> [0] https://review.openstack.org/529787
>>>> [1] 
>>>> http://logs.openstack.org/57/529657/2/check/puppet-openstack-integration-4-scenario004-tempest-ubuntu-xenial/ce6f987/logs/neutron/neutron-server.txt.gz#_2017-12-21_22_58_37_338
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
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] Ubuntu problems + Help needed

[Mohammed Naser]

Hi everyone,

I'll get right into the point.

At the moment, the Puppet OpenStack modules don't have much
contributors which can help maintain the Ubuntu support.  We deploy on
CentOS (so we try to get all the fixes in that we can) and there is a
lot of activity from the TripleO team as well which does their
deployments on CentOS which means that the CentOS support is very
reliable and CI is always sought after.

However, starting a while back, we started seeing occasional failures
with Ubuntu deploys which lead us set the job to non-voting.  At the
moment, the Puppet integration jobs for Ubuntu are always failing
because of some Tempest issue.  This means that with every Puppet
change, we're wasting ~80 minutes of CI run time for a job that will
always fail.

We've had a lot of support from the packaging team at RDO (which are
used in Puppet deployments) and they run our integration before
promoting packages which makes it helpful in finding issues together.
However, we do not have that with Ubuntu neither has there been anyone
who is taking initiative to look and investigate those issues.

I understand that there are users out there who use Ubuntu with Puppet
OpenStack modules.  We need your help to come and try and clear those
issues out. We'd be more than happy to give assistance to lead you in
the right way to help fix those issues.

Unfortunately, if we don't have any folks stepping up to resolving
this, we'll be forced to drop all CI for Ubuntu and make a note to
users that Ubuntu is not fully tested and hope that as users run into
issues, they can contribute fixes back (or that someone can work on
getting Ubuntu gating working again).

Thanks for reading through this, I am quite sad that we'd have to drop
support for such a major operating system, but there's only so much we
can do with a much smaller team.

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] [infra] Gerrit issues

[Mohammed Naser]

Hi Gary,

It looks like Gerrit is having some issues indeed and they are getting
worked on at the moment.

Thanks,
Mohammed

On Wed, Dec 20, 2017 at 8:00 AM, Gary Kotton  wrote:
> Hi,
>
> Anyone else experience problems accessing gerrit?
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing 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][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

Jens,

That's quite an interesting catch.  I'm reaching out to the author of
this change to get some more information.

Thanks,
Mohammed

On Tue, Nov 14, 2017 at 2:02 PM, Jens Harbott <j.harb...@x-ion.de> wrote:
> 2017-11-14 16:29 GMT+00:00 Mohammed Naser <mna...@vexxhost.com>:
>> Hi everyone,
>>
>> Thank you so much for the work on this, I'm sure we can progress with
>> this together.  I have noticed that this only occurs in master and
>> never in the stable branches.  Also, it only occurs under Ubuntu (so
>> maybe something related to mod_wsgi version?)
>>
>> Given that we don't have any "master" built packages for Ubuntu, we
>> test against the latest release which is the pike release.
>>
>> https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/repos.pp#L6-L10
>>
>> I've noticed the issue is not as present in older branches but much
>> more visible in master.
>
> So does the issue not happen at all for stable/pike or less often?
> Anyway that would seem to indicate not an issue with the Ubuntu
> packages, but with the way they are deployed.
>
> If you look at [1] you can see that for pike you setup nova-api wsgi
> with workers=1 and threads=$::os_workers, which in master was swapped,
> see [2]. I'd suggest testing a revert of that change.
>
> [1] 
> https://github.com/openstack/puppet-nova/blob/stable/pike/manifests/wsgi/apache_api.pp
> [2] 
> https://github.com/openstack/puppet-nova/commit/df638e2526d2d957318519dfcfb9098cb7726095
>
> __
> OpenStack Development Mailing 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][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

Hi everyone,

Thank you so much for the work on this, I'm sure we can progress with
this together.  I have noticed that this only occurs in master and
never in the stable branches.  Also, it only occurs under Ubuntu (so
maybe something related to mod_wsgi version?)

Given that we don't have any "master" built packages for Ubuntu, we
test against the latest release which is the pike release.

https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/repos.pp#L6-L10

I've noticed the issue is not as present in older branches but much
more visible in master.

Thanks,
Mohammed

On Tue, Nov 14, 2017 at 6:21 AM, Tobias Urdin  wrote:
> Yea, I've been scavenging the logs for any kind of indicator on what
> might have gone wrong but I can't see anything
> related to a deadlock even though I'm very certain that's the issue but
> don't know what's causing it.
>
> Perhaps we will need to manually recreate this issue and then
> troubleshoot it manually.
> The apache2 mod_wsgi config should be OK according to the docs [1].
>
> Best regards
>
> [1]
> http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html
>
> On 11/14/2017 11:12 AM, Jens Harbott wrote:
>> 2017-11-14 8:24 GMT+00:00 Tobias Urdin :
>>> Trying to trace this, tempest calls the POST /servers//action
>>> API endpoint for the nova compute api.
>>>
>>> https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/floating_ips_client.py#L82
>>>
>>> Nova then takes the requests and tries to do this floating ip association
>>> using the neutron server api.
>>>
>>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/nova/nova-api.txt.gz
>>>
>>> 2017-10-29 23:12:35.521 17800 ERROR nova.api.openstack.compute.floating_ips
>>> [req-7f810cc7-a498-4bf4-b27e-8fc80d652785 42526a28b1a14c629b83908b2d75c647
>>> 2493426e6a3c4253a60c0b7eb35cfe19 - default default] Unable to associate
>>> floating IP 172.24.5.17 to fixed IP 10.100.0.8 for instance
>>> d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
>>> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
>>> timed out: ConnectTimeout: Request to
>>> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
>>> timed out
>>>
>>> Checking that timestamp in the neutron-server logs:
>>> http://paste.openstack.org/show/626240/
>>>
>>> We can see that during this timestamp right before at 23:12:30.377 and then
>>> after 23:12:35.611 everything seems to be doing fine.
>>> So there is some connectivity issues to the neutron API from where the Nova
>>> API is running causing a timeout.
>>>
>>> Now some more questions would be:
>>>
>>> * Why is the return code 400? Are we being fooled or is it actually a
>>> connection timeout.
>>> * Is the Neutron API stuck causing the failed connection? All talk are done
>>> over loopback so chance of a problem there is very low.
>>> * Any firewall catching this? Not likely since the agent processes requests
>>> right before and after.
>>>
>>> I can't find anything interesting in the overall other system logs that
>>> could explain that.
>>> Back to the logs!
>> I'm pretty certain that this is a deadlock between nova and neutron,
>> though I cannot put my finger on the exact spot yet. But looking at
>> the neutron log that you extracted you can see that neutron indeed
>> tries to give a successful answer to the fip request just after nova
>> has given up waiting for it (seems the timeout is 30s here):
>>
>> 2017-10-29 23:12:35.932 18958 INFO neutron.wsgi
>> [req-e737b7dd-ed9c-46a7-911b-eb77efe11aa8
>> 42526a28b1a14c629b83908b2d75c647 2493426e6a3c4253a60c0b7eb35cfe19 -
>> default default] 127.0.0.1 "PUT
>> /v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c HTTP/1.1"
>> status: 200  len: 746 time: 30.4427412
>>
>> Also, looking at
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/apache_config/10-nova_api_wsgi.conf.txt.gz
>> is seems that nova-api is started with two processes and one thread,
>> not sure if that means two processes with one thread each or only one
>> thread total, anyway nova-api might be getting stuck there.
>>
>> __
>> OpenStack Development Mailing 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 

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

Hi,

Hope that everyone had safe travels and enjoyed their time at Sydney
(and those who weren't there enjoyed a bit of quiet time!).  I'm just
sending this email if anyone had a chance to look more into this (or
perhaps we can get some help if there are any Canonical folks on the
list?)

I would be really sad if we had to drop Ubuntu/Debian support because
we cannot test it.  I think there are a lot of users out there using
it!  I'd be more than happy to provide any assistance/information in
troubleshooting this.

Thank you,
Mohammed

On Thu, Nov 2, 2017 at 1:10 PM, Mohammed Naser <mna...@vexxhost.com> wrote:
> On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin <tobias.ur...@crystone.com> 
> wrote:
>> I've been staring at this for almost an hour now going through all the logs
>> and I can't really pin a point from
>>
>> where that error message is generated. Cannot find any references for the
>> timed out message that the API returns or the unable to associate part.
>>
>>
>> What I'm currently staring at is why would the instance fixed ip 172.24.5.17
>> be references as a network:router_gateway port in the OVS agent logs.
>>
>> 2017-10-29 23:19:27.591 11856 INFO
>> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
>> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
>> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
>> 'network_qos_policy_id': None, 'qos_policy_id': None,
>> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
>> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
>> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
>> 'ip_address': '172.24.5.17'}], 'device_owner': u'network:router_gateway',
>> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
>> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled':
>> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type':
>> u'flat', 'security_groups': []}
>>
>>
>> Anybody else seen anything interesting?
>
> Hi Tobias,
>
> Thanks for looking out.  I've spent a lot of time and I haven't
> successfully identified much, I can add the following
>
> - This issue is intermittent in CI
> - It does *not* happen on any specific providers, I've seen it fail on
> both OVH and Rackspace.
> - Not *all* floating iP assignments fail, if you look at the logs, you
> can see it attach a few successfully before failing
>
> But yeah, I'm still quite at a loss and not having this coverage isn't fun.
>
>>
>>
>> On 10/30/2017 11:08 PM, Brian Haley wrote:
>>
>> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>>
>>  From a quick glance at the logs my guess is that the issue is related
>> to this stack trace in the l3 agent logs:
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>>
>> I'm not sure what's causing it to complain there. But, I'm on a plane
>> right now (which is why this is a top post, sorry) so I can't really dig
>> much more than that. I'll try to take a deeper look at things later when
>> I'm on solid ground. (hopefully someone will beat me to it by then though)
>>
>> I don't think that l3-agent trace is it, as the failure is coming from
>> the API.  It's actually a trace that's happening due to the async nature
>> of how the agent runs arping, fix is
>> https://review.openstack.org/#/c/507914/ but it only removes the log noise.
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
>> has some tracebacks that look config related, possible missing DB table?
>>   But I haven't looked very closely.
>>
>> -Brian
>>
>>
>> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
>> <mna...@vexxhost.com> wrote:
>>
>> Hi everyone,
>>
>> I'm looking for some help regarding an issue that we're having with
>> the Puppet OpenStack modules, we've had very inconsistent failures in
>> the Xenial with the following error:
>>
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
>>  Details: {u'message': u'Unable to associate floating IP
>> 172.24.5.17 <http://172.24.5.17>

[openstack-dev] [puppet][ci] PTI jobs for Puppet modules

[Mohammed Naser]

Hi everyone,

With a few languages getting PTI jobs which are defined in
project-config, I think Puppet should be a candidate as the build and
release process of Puppet modules is the same across all modules.

Given that Puppet OpenStack has a large number of modules, in addition
to Infra's puppet modules, it would be good to have a project-template
specific for build and release of Puppet modules.

Most of the work is already done (the build and release jobs are
there).  The main work which is left is simply to create a
project-template for project-config (say openstack-puppet-jobs) and
then update project-config for all puppet modules to use this template
and make sure it gets removed from the specific repos.

If no one is opposed to this (or perhaps has any ideas on how we can
do this in a better way), I will start the work and push up a change
shortly that takes care of this.

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

Re: [openstack-dev] [Release-job-failures][puppet] Release of openstack/puppet-magnum failed

[Mohammed Naser]

Sorry for the top post, looks like it was puppet-magnum that might be missing 
adding “puppet” to its bindep file. 

I’ll look into this shortly

Sent from my iPhone

> On Nov 13, 2017, at 9:57 AM, Doug Hellmann  wrote:
> 
> Excerpts from zuul's message of 2017-11-13 09:25:04 +:
>> Build failed.
>> 
>> - release-openstack-puppet 
>> http://logs.openstack.org/52/5294a365d29a7c6745856aae5d78f09c709f7fc1/release/release-openstack-puppet/fd776d7/
>>  : POST_FAILURE in 1m 36s
>> - announce-release announce-release : SKIPPED
>> 
> 
> The error for this one is:
> 
> 2017-11-13 09:24:26.571661 | TASK [Build puppet module]
> 2017-11-13 09:24:27.661667 | ubuntu-xenial | ERROR
> 2017-11-13 09:24:27.662090 | ubuntu-xenial | {
> 2017-11-13 09:24:27.662189 | ubuntu-xenial |   "failed": true,
> 2017-11-13 09:24:27.662277 | ubuntu-xenial |   "msg": "[Errno 2] No such file 
> or directory",
> 2017-11-13 09:24:27.662363 | ubuntu-xenial |   "rc": 2
> 2017-11-13 09:24:27.662458 | ubuntu-xenial | }
> 
> It's not clear from the error output what file is missing.
> 
> 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][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

On Thu, Nov 2, 2017 at 1:02 PM, Tobias Urdin <tobias.ur...@crystone.com> wrote:
> I've been staring at this for almost an hour now going through all the logs
> and I can't really pin a point from
>
> where that error message is generated. Cannot find any references for the
> timed out message that the API returns or the unable to associate part.
>
>
> What I'm currently staring at is why would the instance fixed ip 172.24.5.17
> be references as a network:router_gateway port in the OVS agent logs.
>
> 2017-10-29 23:19:27.591 11856 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-7274c6f7-18ef-420d-ad5a-9d0fe4eb35c6 - - - - -] Port
> 053a625c-4227-41fb-9a26-45eda7bd2055 updated. Details: {'profile': {},
> 'network_qos_policy_id': None, 'qos_policy_id': None,
> 'allowed_address_pairs': [], 'admin_state_up': True, 'network_id':
> 'f9647756-41ad-4ec5-af49-daefe410815e', 'segmentation_id': None,
> 'fixed_ips': [{'subnet_id': 'a31c7115-1f3e-4220-8bdb-981b6df2e18c',
> 'ip_address': '172.24.5.17'}], 'device_owner': u'network:router_gateway',
> 'physical_network': u'external', 'mac_address': 'fa:16:3e:3b:ec:c3',
> 'device': u'053a625c-4227-41fb-9a26-45eda7bd2055', 'port_security_enabled':
> False, 'port_id': '053a625c-4227-41fb-9a26-45eda7bd2055', 'network_type':
> u'flat', 'security_groups': []}
>
>
> Anybody else seen anything interesting?

Hi Tobias,

Thanks for looking out.  I've spent a lot of time and I haven't
successfully identified much, I can add the following

- This issue is intermittent in CI
- It does *not* happen on any specific providers, I've seen it fail on
both OVH and Rackspace.
- Not *all* floating iP assignments fail, if you look at the logs, you
can see it attach a few successfully before failing

But yeah, I'm still quite at a loss and not having this coverage isn't fun.

>
>
> On 10/30/2017 11:08 PM, Brian Haley wrote:
>
> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>
>  From a quick glance at the logs my guess is that the issue is related
> to this stack trace in the l3 agent logs:
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>
> I'm not sure what's causing it to complain there. But, I'm on a plane
> right now (which is why this is a top post, sorry) so I can't really dig
> much more than that. I'll try to take a deeper look at things later when
> I'm on solid ground. (hopefully someone will beat me to it by then though)
>
> I don't think that l3-agent trace is it, as the failure is coming from
> the API.  It's actually a trace that's happening due to the async nature
> of how the agent runs arping, fix is
> https://review.openstack.org/#/c/507914/ but it only removes the log noise.
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
> has some tracebacks that look config related, possible missing DB table?
>   But I haven't looked very closely.
>
> -Brian
>
>
> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
> <mna...@vexxhost.com> wrote:
>
> Hi everyone,
>
> I'm looking for some help regarding an issue that we're having with
> the Puppet OpenStack modules, we've had very inconsistent failures in
> the Xenial with the following error:
>
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
>
> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
>  Details: {u'message': u'Unable to associate floating IP
> 172.24.5.17 <http://172.24.5.17>  to fixed IP10.100.0.8
> <http://10.100.0.8>  for instance
> d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
>
> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
> timed out', u'code': 400}
>
> At this point, we're at a bit of a loss.  I've tried my best in order
> to find the root cause however we have not been able to do this.  It
> was persistent enough that we elected to go non-voting for our Xenial
> gates, however, with no fix ahead of us, I feel like this is a waste
> of resources and we need to either fix this or drop CI for Ubuntu.  We
> don't deploy on Ubuntu and most of the developers working on the
> project don't either at this point, so we need a bit of resources.
>
> If you're a user of Puppet on Xenial, we need your help!  Without any
> resources going to fix this, we'd unfortunately have to drop support
>

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

On Mon, Oct 30, 2017 at 6:07 PM, Brian Haley <haleyb@gmail.com> wrote:
> On 10/30/2017 05:46 PM, Matthew Treinish wrote:
>>
>>  From a quick glance at the logs my guess is that the issue is related to
>> this stack trace in the l3 agent logs:
>>
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-l3-agent.txt.gz?level=TRACE#_2017-10-29_23_11_15_146
>>
>> I'm not sure what's causing it to complain there. But, I'm on a plane
>> right now (which is why this is a top post, sorry) so I can't really dig
>> much more than that. I'll try to take a deeper look at things later when I'm
>> on solid ground. (hopefully someone will beat me to it by then though)
>
>
> I don't think that l3-agent trace is it, as the failure is coming from the
> API.  It's actually a trace that's happening due to the async nature of how
> the agent runs arping, fix is https://review.openstack.org/#/c/507914/ but
> it only removes the log noise.

Indeed, I've reached out to Neutron team on IRC and Brian informed me
that this was just log noise.

> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/neutron/neutron-server.txt.gz
> has some tracebacks that look config related, possible missing DB table?
> But I haven't looked very closely.

The tracebacks are because the Neutron server is started before the
MySQL database is sync'd (afaik, Ubuntu behaviour is to start services
on install, so we haven't had a chance to sync the db).  You can see
the service later restart with none of these database issues.  The
other reason to eliminate config issues is the fact that this happens
intermittently (though, often enough that we had to switch it to
non-voting).  If it was a config issue, it would constantly and always
fail.

Thank you Brian & Matthew for your help so far.

> -Brian
>
>
>> On October 31, 2017 1:25:55 AM GMT+04:00, Mohammed Naser
>> <mna...@vexxhost.com> wrote:
>>
>> Hi everyone,
>>
>> I'm looking for some help regarding an issue that we're having with
>> the Puppet OpenStack modules, we've had very inconsistent failures in
>> the Xenial with the following error:
>>
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/
>>
>> http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
>>  Details: {u'message': u'Unable to associate floating IP
>> 172.24.5.17 <http://172.24.5.17>  to fixed IP10.100.0.8
>> <http://10.100.0.8>  for instance
>> d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
>>
>> https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
>> timed out', u'code': 400}
>>
>> At this point, we're at a bit of a loss.  I've tried my best in order
>> to find the root cause however we have not been able to do this.  It
>> was persistent enough that we elected to go non-voting for our Xenial
>> gates, however, with no fix ahead of us, I feel like this is a waste
>> of resources and we need to either fix this or drop CI for Ubuntu.  We
>> don't deploy on Ubuntu and most of the developers working on the
>> project don't either at this point, so we need a bit of resources.
>>
>> If you're a user of Puppet on Xenial, we need your help!  Without any
>> resources going to fix this, we'd unfortunately have to drop support
>> for Ubuntu because of the lack of resources to maintain it (or
>> assistance).  We (Puppet OpenStack team) would be more than happy to
>> work together to fix this so pop-in at #puppet-openstack or reply to
>> this email and let's get this issue fixed.
>>
>> 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 Development Mailing 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][qa][ubuntu][neutron] Xenial Neutron Timeouts

[Mohammed Naser]

Hi everyone,

I'm looking for some help regarding an issue that we're having with
the Puppet OpenStack modules, we've had very inconsistent failures in
the Xenial with the following error:


http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/

http://logs.openstack.org/47/514347/1/check/puppet-openstack-integration-4-scenario001-tempest-ubuntu-xenial/ed5a657/logs/testr_results.html.gz
Details: {u'message': u'Unable to associate floating IP
172.24.5.17 to fixed IP 10.100.0.8 for instance
d265626a-77c1-4d2f-8260-46abe548293e. Error: Request to
https://127.0.0.1:9696/v2.0/floatingips/2e3fa334-d6ac-443c-b5ba-eeb521d6324c
timed out', u'code': 400}

At this point, we're at a bit of a loss.  I've tried my best in order
to find the root cause however we have not been able to do this.  It
was persistent enough that we elected to go non-voting for our Xenial
gates, however, with no fix ahead of us, I feel like this is a waste
of resources and we need to either fix this or drop CI for Ubuntu.  We
don't deploy on Ubuntu and most of the developers working on the
project don't either at this point, so we need a bit of resources.

If you're a user of Puppet on Xenial, we need your help!  Without any
resources going to fix this, we'd unfortunately have to drop support
for Ubuntu because of the lack of resources to maintain it (or
assistance).  We (Puppet OpenStack team) would be more than happy to
work together to fix this so pop-in at #puppet-openstack or reply to
this email and let's get this issue fixed.

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

Re: [openstack-dev] [nova][neutron] How do you use the instance IP filter?

[Mohammed Naser]

On Fri, Oct 27, 2017 at 12:48 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-10-26 22:26:59 -0400 (-0400), Mohammed Naser wrote:
> [...]
> > The use-case for us is that it helps us easily identify or find VMs which
> > we get any abuse reports for (or anything we see malicious traffic going
> > to/from).  We usually search for an *exact* match of the IP address as we
> > are simply trying to perform a lookup of instance ID based on the IP
> > address.  Regex matching isn't important in our case.
> [...]
>
> Does it allow you to identify which instance had that IP address
> over a specific timeframe? One problem we encounter is that we get
> abuse reports forwarded from our service providers telling us that
> our instance with some particular IP address was performing port
> scans or participating in a denial of service attack, and invariably
> when we check our logs we did not have an instance with that IP
> address at the timeframe indicated by the original abuse reporter
> (we had an instance with that IP address at some point for an hour
> or two maybe, but not until days later when the abuse team went
> checking to see who was responsible, and yet they tend to just
> assume everyone has long-lived instances and that IP addresses don't
> bounce around from tenant to tenant with great frequency).
>

Unfortunately, it does not, which means if the VM is gone, it is much
harder at finding the exact source of the abuse at the time.  However,
generally, in our experience, malicious VMs are not short lived but they
are long lived.  We'll generally find them running before we received the
report which means that the abuse report came for that user indeed.

The other nice thing which I noticed is that Neutron generally doesn't
re-use IPs until it cycles the entire subnet/CIDR, so if you have a large
number of IPs and you don't have a big churn in VMs, it's unlikely that a
VM will get the same IP in a short period of time.


> It seems like OpenStack could generally benefit from a mechanism for
> correlating abuse complaints to specific instances/tenants in a way
> that allows performing time-based lookups as well. Compute instances
> are ephemeral, so treating abuse complaints the same as you would in
> a dedicated hosting environment doesn't really work so well.
> --
> 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] [nova][neutron] How do you use the instance IP filter?

[Mohammed Naser]

On Thu, Oct 26, 2017 at 10:23 PM, Matt Riedemann 
wrote:

> Nova has had this long-standing known performance issue if you're
> filtering a large number of instances by IP. The instance IPs are stored in
> a JSON blob in the database so we don't do filtering in SQL. We pull the
> instances out of the database, deserialize the JSON and then apply a regex
> filter match in the nova-api python code.
>
> At the Queens PTG we talked about possible ways to fix this and came up
> with this nova spec:
>
> https://specs.openstack.org/openstack/nova-specs/specs/queen
> s/approved/improve-filter-instances-by-ip-performance.html
>
> The idea is to have nova get ports from neutron and apply the IP filter in
> neutron to whittle down the ports, then from that list of ports get the
> instances to pull out of the nova database.
>
> One issue that has come up with this is neutron does not currently support
> regex filters when listing ports. There is an RFE for adding that:
>
> https://bugs.launchpad.net/neutron/+bug/1718605
>
> The proposed neutron implementation is to just do SQL LIKE substring
> matching in the database.
>
> However, one issue that has come up is that the compute API accepts a
> python regex filter and uses re.match():
>
> https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L2469
>
> At least one good thing about that is match() only matches from the
> beginning of the string unlike search().
>
> So for example I can filter on "192.16.*[1-5]$" if I wanted to, but that's
> not going to work with just a LIKE substring filter in SQL.
>
> The question is, does anyone actually do more than basic substring
> matching with the IP filter today? Because if we started using neutron,
> that behavior would be broken. We've never actually documented the match
> restrictions on the IP filter, but that's not a good reason to break it.
>

The use-case for us is that it helps us easily identify or find VMs which
we get any abuse reports for (or anything we see malicious traffic going
to/from).  We usually search for an *exact* match of the IP address as we
are simply trying to perform a lookup of instance ID based on the IP
address.  Regex matching isn't important in our case.


> One option is to make this configurable such that deployments which rely
> on the complicated pattern matching can just use the existing nova code
> despite performance issues. However, that's not interoperable, I hate
> config-driven API behavior, and it would mean maintaining two code paths in
> nova, which is also terrible.
>
> I was trying to think of a way to determine if the IP filter passed to
> nova is basic or a complicated pattern match and let us decide that way,
> but I'm not sure if there are good ways to detect that - maybe by simply
> looking for special characters like (, ), - and $? But then there is [] and
> we have an IPv6 filter, so that gets messy too...
>
> For now I'd just like to know if people rely on the regex match or not.
> Other ideas on how to handle this are appreciated.
>
> --
>
> 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

Re: [openstack-dev] [puppet] avoid rechecks

[Mohammed Naser]

Hi Arnaud,

Apologies for not following up with that email, things should be okay now
and we've mostly patched up our CI for Zuul v3 :)

Thanks,
Mohammed

On Fri, Oct 20, 2017 at 8:18 AM, Arnaud MORIN <arnaud.mo...@gmail.com>
wrote:

> Hi Mohammed and all,
>
> Can we help with the puppet CI?
>
> Cheers,
> Arnaud.
>
> On 1 October 2017 at 17:27, Mohammed Naser <mna...@vexxhost.com> wrote:
>
>> Hi everyone,
>>
>> As the Puppet modules CI is still in the process of getting plumbed
>> properly with Zuul v3, you'll notice many of your checks failing.  If
>> you notice a job that has a legacy- prefix, it is probably not
>> migrated yet and will likely fail, therefore, I'd avoid a recheck to
>> avoid taking up resources for a job that will fail.
>>
>> If none of your jobs are prefixed with legacy- then you can do the
>> normal troubleshooting and recheck if it is a timeout of the job or a
>> connectivity issue.
>>
>> I'll keep everyone updated at the progress of moving things over.
>>
>> Thanks,
>> Mohammed
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [puppet] Proposing Alfredo Moralejo core on puppet-openstack-integration

[Mohammed Naser]

On Fri, Oct 13, 2017 at 1:21 PM, Emilien Macchi  wrote:

> Alfredo has been doing an incredible work on maintaining Puppet
> OpenStack CI; by always testing OpenStack from trunk and taking care
> of issues. He has been involved in fixing the actual CI problems in
> OpenStack projects but also maintaining puppet-openstack-integration
> repository in a consistent and solid manner.
> Also, he has an excellent understanding how things work in this
> project and I would like to propose him part of p-o-i maintainers
> (among the rest of the whole core team and also dmsimard).
>

Indeed, Alfredo has helped us a lot by giving assistance from the packagers
side of things and making sure that they release working packages, and
proposing fixes for issues that block promotion of packages to avoid
breaking our CI.

+2 from me :)


>
> As usual, feel free to vote and give feedback.
>
> 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
>
__
OpenStack Development Mailing 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][election] Question for the candidates

[Mohammed Naser]

On Thu, Oct 12, 2017 at 10:10 PM, Ed Leafe <e...@leafe.com> wrote:
> On Oct 12, 2017, at 8:10 PM, Mohammed Naser <mna...@vexxhost.com> wrote:
>
>> I think that the OpenStack infrastructure team is doing a wonderful
>> job at keeping such a huge CI system working to the best of their
>> effort, however, I think that there needs to be a stronger
>> relationship between projects and the infrastructure team in order for
>> us to help alleviate some of the load that is on them. There are a lot
>> of moving components from dealing with multiple cloud infrastructure
>> donors, operating two flavours of clouds internally, maintaining the
>> codebase of Zuul and other system administration related tasks.
>
> Thanks for the answer, and I definitely agree. But I don't feel that you 
> answered the important part: what would you have wanted the TC to do about 
> this?

Thanks for responding Ed.

I would propose that the TC should work on a motion and present it to
the OpenStack development community to encourage projects on creating
an infrastructure liaison role.  While I'd understand that the
infrastructure team is quite busy these days, but before working on
setting a motion in place, it would be best to listen more to the
infrastructure team about this sort of concept and how we can bridge
the gap between developers and the infrastructure team.

I don't think the TC's resolution should operate by enforcement but
rather by empowerment, therefore I would hope that the result of this
would be a well documented resolution regarding this subject which
could demonstrate the strong value in adopting this role within
project teams, encouraging teams to find that individual (or many) who
can step up and work together with the infrastructure team.


> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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][election] Question for the candidates

[Mohammed Naser]

On Thu, Oct 12, 2017 at 2:38 PM, Ed Leafe  wrote:
> In the past year or so, has there been anything that made you think “I wish 
> the TC would do something about that!” ? If so, what was it, and what would 
> you have wanted the TC to do about it?

This is great and the timing of this question is more important than ever.

I think that the OpenStack infrastructure team is doing a wonderful
job at keeping such a huge CI system working to the best of their
effort, however, I think that there needs to be a stronger
relationship between projects and the infrastructure team in order for
us to help alleviate some of the load that is on them. There are a lot
of moving components from dealing with multiple cloud infrastructure
donors, operating two flavours of clouds internally, maintaining the
codebase of Zuul and other system administration related tasks.

I do think that just like how projects have a release liaison, bug
czar, there should be a notion of a infrastructure team liaison.
Often, there are a lot of things going on in the infrastructure side
of things, jobs might be breaking (for infra related and unrelated
reasons), and keeping up with what's going on on the infrastructure
team to report to the project team.

This would help the infrastructure team tremendously by allowing a
much easier communication channel, as well as assist the team in
avoiding being behind on infrastructure updates and suddenly finding
themselves in the red for a while.

>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing 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][election] Question for the candidates

[Mohammed Naser]

On Thu, Oct 12, 2017 at 5:48 PM, Emilien Macchi <emil...@redhat.com> wrote:
> On Thu, Oct 12, 2017 at 12:42 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
> [...]
>
>> To candidates:
>>
>> Would you please self select a change (or changes) from
>> https://github.com/openstack/governance/ in the past ~12 mo or so where they
>> thought the outcome or the discussion/process was particular good and
>> explain why you think so?
>>
>> It'd be super helpful to me, thanks!
>
> The vision exercise was, in my opinion, one of the more exciting
> things we have done in 2017.
> It's not an easy thing to do because of our diverses opinions, but
> together we managed to write something down, propose it to the
> community in the open and make it better afterward (of course this
> will never finish).
>
> Outcome related, I loved the fact we're thinking outside of the
> OpenStack community and see how we can make OpenStack projects usable
> in environments without all the ecosystem. I also like to see our
> strong efforts to increase diversity in all sorts and our work to
> improve community health.
>
> Beside the outcome, I loved to see all TC members able to work
> together on this Vision in the open, I hope we can do more of that in
> the future, even outside of the TC (in teams). (ex: doc team had a PTG
> session about visioning as well).
> I hope I answered the question, please let me know if that's not the
> case if you want more details.

I think Emilien here covers a lot of what I personally agreed with,
however, I'd like to add more about the cloud application mission:

https://github.com/openstack/governance/blob/master/resolutions/20170317-cloud-applications-mission.rst

As we are delivering fundamental building blocks for applications, we
need to make sure that provide open standards which put into place
best practices in order to consume those resources.  In that
resolution, it introduces some concepts which are quite prevalent in
many other infrastructure cloud components (which generally are not
self-hosted) that are not yet very strong inside OpenStack.

For example, using domains for specific applications, improving policy
support for a more predictable set of ACLs which allows developers to
be more productive and empower them more to automate their
infrastructure

The good thing is quite a few good things have come out of this:

- The OpenStack provider for Kubernetes is getting stronger than even
(and will soon hopefully get gating to improve stability)
- Policy in code has made great process over the past few cycles
(great stepping stone towards more predictable ACLs)

However, I think that we still have quite a bits way to make things
more standardized on this side of things, some projects use
"ResellerAdmin", others picked "_Member_", some went with "member",
others have ACLs that use "creator", some projects have
project-specific role names.  I think that the next step would be to
unify all of those, so that at least the (base) roles are predictable
across clouds.

> --
> 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] [all][tc] TC Candidates: what does an OpenStack user look like?

[Mohammed Naser]

On Thu, Oct 12, 2017 at 8:15 PM, Zane Bitter <zbit...@redhat.com> wrote:
> On 12/10/17 15:07, Mohammed Naser wrote:
>>
>> Hi Zane,
>>
>> Thank you for your question.  I think you're raising a critical
>> question which we must all come to (fairly relative) agreement to so
>> that we can all build OpenStack in the same direction.
>>
>> On Thu, Oct 12, 2017 at 12:51 PM, Zane Bitter <zbit...@redhat.com> wrote:
>>>
>>> (Reminder: we are in the TC election campaigning period, and we all have
>>> the
>>> opportunity to question the candidates. The campaigning period ends on
>>> Saturday, so make with the questions.)
>>>
>>>
>>> In my head, I have a mental picture of who I'm building OpenStack for.
>>> When
>>> I'm making design decisions I try to think about how it will affect these
>>> hypothetical near-future users. By 'users' here I mean end-users, the
>>> actual
>>> consumers of OpenStack APIs. What will it enable them to do? What will
>>> they
>>> have to work around? I think we probably all do this, at least
>>> subconsciously. (Free tip: try doing it consciously.)
>>>
>>> So my question to the TC candidates (and incumbent TC members, or anyone
>>> else, if they want to answer) is: what does the hypothetical OpenStack
>>> user
>>> that is top-of-mind in your head look like? Who are _you_ building
>>> OpenStack
>>> for?
>>
>>
>> Ideally, I think that OpenStack should be targeted to become a core
>> infrastructure tool that's part of organizations all around the world
>> which can deliver both OpenStack-native services (think Nova for VMs,
>> Cinder for block storage) and OpenStack-enabled services (think Magnum
>> which deployed Kubernetes integrated with OpenStack, Sahara which
>> deploys Big Data software integrated with Swift).
>>
>> This essentially makes OpenStack sit at the heart of the operations of
>> every organization (ideally!).  It also translates well with
>> OpenStack's goal of providing a unified set of APIs and interfaces
>> which are always predictable to do the operations that you expect them
>> to do.  With time, this will make OpenStack much more accessible, as
>> it becomes very easy to interact with as any individuals move from one
>> organization to another.
>>
>> To put in shorter terms: We need to continue to build standardized
>> APIs, with simple and easy-to-use interfaces.  If we keep doing this
>> and we do it right, naturally, OpenStack will become more accessible,
>> therefore much easier to interact with because consuming OpenStack is
>> second nature.
>>
>> It might be a big leap to say this, but making an HTTP request is the
>> last of any developers problem with the amount of interactions most of
>> us have done against HTTP endpoints.  If we do things right with
>> OpenStack, making an OpenStack request should be just as much of a
>> second nature inside most organizations.
>>
>> The one thing that I'll close on which I find critical is ensuring
>> that everything is fully delivered.  As simple as it sounds, we should
>> not have any "manual" steps in any of the OpenStack processes or
>> requests.  If we do, then I believe we need to go back to the drawing
>> board and try again.  For example, an OpenStack project that deploys a
>> software *should not* have a manual process (or steps) to do after it
>> deploys a software.  Instead, it should be fully integrated.
>
>
> I don't disagree with any of that, but I feel compelled to point out that
> you managed to say quite a lot about what we should build without once
> mentioning anything about who is going to use it, even though that was
> explicitly the question.
>
> I'm not trying to call you out specifically; in fact, I'm worried that this
> may be a widespread problem in OpenStack, which is the reason I asked the
> question in the first place.
>

You're raising a very good point here.  However, I think that this is
a very hard question to answer, because there is no single profile of
OpenStack user.  We should aim to be as agnostic and as open as
possible.  The reason why is because I imagine infrastructure as a
core component, a building block to help organization reach their
internal goals.

At the end of the day, I'd even go as far as comparing to to
electricity.  The end-user can vary from many different ways, but if
we do our best at delivering it in a predictable and standardized way,
we'll see people take it and create many different things out of it in
ways that we would nev

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

[Mohammed Naser]

Hi Zane,

Thank you for your question.  I think you're raising a critical
question which we must all come to (fairly relative) agreement to so
that we can all build OpenStack in the same direction.

On Thu, Oct 12, 2017 at 12:51 PM, Zane Bitter  wrote:
> (Reminder: we are in the TC election campaigning period, and we all have the
> opportunity to question the candidates. The campaigning period ends on
> Saturday, so make with the questions.)
>
>
> In my head, I have a mental picture of who I'm building OpenStack for. When
> I'm making design decisions I try to think about how it will affect these
> hypothetical near-future users. By 'users' here I mean end-users, the actual
> consumers of OpenStack APIs. What will it enable them to do? What will they
> have to work around? I think we probably all do this, at least
> subconsciously. (Free tip: try doing it consciously.)
>
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack user
> that is top-of-mind in your head look like? Who are _you_ building OpenStack
> for?

Ideally, I think that OpenStack should be targeted to become a core
infrastructure tool that's part of organizations all around the world
which can deliver both OpenStack-native services (think Nova for VMs,
Cinder for block storage) and OpenStack-enabled services (think Magnum
which deployed Kubernetes integrated with OpenStack, Sahara which
deploys Big Data software integrated with Swift).

This essentially makes OpenStack sit at the heart of the operations of
every organization (ideally!).  It also translates well with
OpenStack's goal of providing a unified set of APIs and interfaces
which are always predictable to do the operations that you expect them
to do.  With time, this will make OpenStack much more accessible, as
it becomes very easy to interact with as any individuals move from one
organization to another.

To put in shorter terms: We need to continue to build standardized
APIs, with simple and easy-to-use interfaces.  If we keep doing this
and we do it right, naturally, OpenStack will become more accessible,
therefore much easier to interact with because consuming OpenStack is
second nature.

It might be a big leap to say this, but making an HTTP request is the
last of any developers problem with the amount of interactions most of
us have done against HTTP endpoints.  If we do things right with
OpenStack, making an OpenStack request should be just as much of a
second nature inside most organizations.

The one thing that I'll close on which I find critical is ensuring
that everything is fully delivered.  As simple as it sounds, we should
not have any "manual" steps in any of the OpenStack processes or
requests.  If we do, then I believe we need to go back to the drawing
board and try again.  For example, an OpenStack project that deploys a
software *should not* have a manual process (or steps) to do after it
deploys a software.  Instead, it should be fully integrated.

> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
>
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my opinion
> is that we have a bunch of people with *different* answers on the TC,
> because I think that will lead to better discussion and hopefully better
> decisions.
>
> Discuss.

Thanks for your very interesting question once again. :)

> cheers,
> Zane.
>
> __
> OpenStack Development Mailing 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] [tc][election] TD candidacy (mnaser)

[Mohammed Naser]

Dear OpenStack users and developers,

I'm submitting my candidacy for a position in the OpenStack TC.

I believe that being involved in many facets surrounding OpenStack makes me
a good candidate to be a member of the technical commitee.

On one of the most important sides, the community:  I have spoken to countless
users, potential users of OpenStack and continue to have conversations about
why users choose OpenStack and the reason why they do not want to use it.  I
think having this external feedback is extremely beneficial in order to take
the best decisions, as those users are impacted by our very decisions.

At the same time, thinking about developers who work hard on our community
to produce the awesome technology we work on:  I have personally been one of
them and continue to be one of them.  I have started contributing to OpenStack
since 2011 across many projects and I am the current PTL for the Puppet
OpenStack team.  In addition, I continue to assist and fix any issues that I
see at hand, helping out the infrastructure team when needed as well.

Finally, one of the critical points is deployers:  I have architected, operated
and deployed our public cloud with OpenStack since 2011, in addition to many
other private cloud deployments.  Our public cloud has a long history, having
started it's life early and undergone many upgrades.  I have personally
overseen all those upgrades and brought feedback directly back to projects
as well as including bug fixes for the projects.

I believe strong leadership comes from setting an example.  With the involvement
in the community, working with the developers and being a deployer myself that
contributes back, I believe that it puts me in a unique position to understand
many parts of the equation that helps us take the best decisions in order to
have a sustainable technical future for the OpenStack projects.

I strongly believe that we have the most solid fundamental infrastructure
software at the moment.  However, I think that the focus should increase in
working with other external communities which depend on infrastructure to
increase our implementations.  For example, working with Kubernetes in order
to strengthen the cloud providers and perhaps get even more integration features
such as auto-scaling.  This will solidify OpenStack as the best set of
infrastructure services in the market.

In addition, I believe that we should put more effort and try to encourage
more work on projects which abstract existing complicated software into a
service.  The few projects that come into mind are Magnum (deploying container
orchestration services) and Sahara (big data platforms).  Those projects can
help make OpenStack a single centralized unit where users can get infrastructure
but easy access to services, on-demand, built with best practices and integrated
with the external tools as explained in the paragraph above.

For me, OpenStack is a wonderful community filled with awesome people who are
all extremely supportive of each other and work together.  I am extremely
proud to be part of this wonderful community and I hope that by becoming an
elected TC, I can help the success of all OpenStack projects from my experience.

Thank you very much for taking the time to read this and I wish the best of
luck to all other candidates.

Regards,
Mohammed Naser

__
OpenStack Development Mailing 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-operators] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

[Mohammed Naser]

On Fri, Oct 6, 2017 at 1:32 PM, Mathieu Gagné <mga...@calavera.ca> wrote:
> Why not supporting this use case?
>
> Same reason as before: A user might wish to keep its IP addresses.
>
> The use cannot do the following to bypass the limitation:
> 1) stop instance
> 2) detach root volume
> 3) delete root volume
> 4) create new volume
> 5) attach as root
> 6) boot instance
>
> Last time I tried, operation fails at step 2. I would need to test
> against latest version of Nova to confirm.

You are right, this is indeed something that is not possible.

> Otherwise boot-from-volume feels like a second class citizen.
>
> --
> Mathieu
>
>
> On Fri, Oct 6, 2017 at 1:22 PM, Matt Riedemann <mriede...@gmail.com> wrote:
>> This came up in IRC discussion the other day, but we didn't dig into it much
>> given we were all (2 of us) exhausted talking about rebuild.
>>
>> But we have had several bugs over the years where people expect the root
>> disk to change to a newly supplied image during rebuild even if the instance
>> is volume-backed.
>>
>> I distilled several of those bugs down to just this one and duplicated the
>> rest:
>>
>> https://bugs.launchpad.net/nova/+bug/1482040
>>
>> I wanted to see if there is actually any failure on the backend when doing
>> this, and there isn't - there is no instance fault or anything like that.
>> It's just not what the user expects, and actually the instance image_ref is
>> then shown later as the image specified during rebuild, even though that's
>> not the actual image in the root disk (the volume).
>>
>> There have been a couple of patches proposed over time to change this:
>>
>> https://review.openstack.org/#/c/305079/
>>
>> https://review.openstack.org/#/c/201458/
>>
>> https://review.openstack.org/#/c/467588/
>>
>> And Paul Murray had a related (approved) spec at one point for detach and
>> attach of root volumes:
>>
>> https://review.openstack.org/#/c/221732/
>>
>> But the blueprint was never completed.
>>
>> So with all of this in mind, should we at least consider, until at least
>> someone owns supporting this, that the API should fail with a 400 response
>> if you're trying to rebuild with a new image on a volume-backed instance?
>> That way it's a fast failure in the API, similar to trying to backup a
>> volume-backed instance fails fast.
>>
>> If we did, that would change the API response from a 202 today to a 400,
>> which is something we normally don't do. I don't think a microversion would
>> be necessary if we did this, however, because essentially what the user is
>> asking for isn't what we're actually giving them, so it's a failure in an
>> unexpected way even if there is no fault recorded, it's not what the user
>> asked for. I might not be thinking of something here though, like
>> interoperability for example - a cloud without this change would blissfully
>> return 202 but a cloud with the change would return a 400...so that should
>> be considered.
>>
>> --
>>
>> 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-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

[openstack-dev] [puppet] avoid rechecks

[Mohammed Naser]

Hi everyone,

As the Puppet modules CI is still in the process of getting plumbed
properly with Zuul v3, you'll notice many of your checks failing.  If
you notice a job that has a legacy- prefix, it is probably not
migrated yet and will likely fail, therefore, I'd avoid a recheck to
avoid taking up resources for a job that will fail.

If none of your jobs are prefixed with legacy- then you can do the
normal troubleshooting and recheck if it is a timeout of the job or a
connectivity issue.

I'll keep everyone updated at the progress of moving things over.

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

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

[Mohammed Naser]

Hi Vega,

Please check the document. Some jobs were migrated with incorrect nodesets and 
have to be switched to multinode in the job definition in openstack-zuul-jobs

Good luck
Mohammed

Sent from my iPhone

> On Sep 30, 2017, at 7:35 AM, Vega Cai  wrote:
> 
> Hi,
> 
> In Tricircle we use the "multinode" topology to setup a test environment with 
> three regions, "CentralRegion" and "RegionOne" in one node, and "RegionTwo" 
> in the other node. I notice that the job definition has been migrated to 
> openstack-zuul-jobs/blob/master/playbooks/legacy/tricircle-dsvm-multiregion/run.yaml,
>  but the job fails with the error that "public endpoint for image service in 
> RegionTwo region not found", so I guess the node of "RegionTwo" is not 
> correctly running. Since the original log folder for the second "subnode-2/" 
> is missing in the job report, I also cannot figure out what the wrong is with 
> the second node.
> 
> Any hints to debug this problem?
> 
> 
>> On Fri, 29 Sep 2017 at 22:59 Monty Taylor  wrote:
>> Hey everybody!
>> 
>> tl;dr - If you're having issues with your jobs, check the FAQ, this
>> email and followups on this thread for mentions of them. If it's an
>> issue with your job and you can spot it (bad config) just submit a patch
>> with topic 'zuulv3'. If it's bigger/weirder/you don't know - we'd like
>> to ask that you send a follow up email to this thread so that we can
>> ensure we've got them all and so that others can see it too.
>> 
>> ** Zuul v3 Migration Status **
>> 
>> If you haven't noticed the Zuul v3 migration - awesome, that means it's
>> working perfectly for you.
>> 
>> If you have - sorry for the disruption. It turns out we have a REALLY
>> complicated array of job content you've all created. Hopefully the pain
>> of the moment will be offset by the ability for you to all take direct
>> ownership of your awesome content... so bear with us, your patience is
>> appreciated.
>> 
>> If you find yourself with some extra time on your hands while you wait
>> on something, you may find it helpful to read:
>> 
>>https://docs.openstack.org/infra/manual/zuulv3.html
>> 
>> We're adding content to it as issues arise. Unfortunately, one of the
>> issues is that the infra manual publication job stopped working.
>> 
>> While the infra manual publication is being fixed, we're collecting FAQ
>> content for it in an etherpad:
>> 
>>https://etherpad.openstack.org/p/zuulv3-migration-faq
>> 
>> If you have a job issue, check it first to see if we've got an entry for
>> it. Once manual publication is fixed, we'll update the etherpad to point
>> to the FAQ section of the manual.
>> 
>> ** Global Issues **
>> 
>> There are a number of outstanding issues that are being worked. As of
>> right now, there are a few major/systemic ones that we're looking in to
>> that are worth noting:
>> 
>> * Zuul Stalls
>> 
>> If you say to yourself "zuul doesn't seem to be doing anything, did I do
>> something wrong?", we're having an issue that jeblair and Shrews are
>> currently tracking down with intermittent connection issues in the
>> backend plumbing.
>> 
>> When it happens it's an across the board issue, so fixing it is our
>> number one priority.
>> 
>> * Incorrect node type
>> 
>> We've got reports of things running on trusty that should be running on
>> xenial. The job definitions look correct, so this is also under
>> investigation.
>> 
>> * Multinode jobs having POST FAILURE
>> 
>> There is a bug in the log collection trying to collect from all nodes
>> while the old jobs were designed to only collect from the 'primary'.
>> Patches are up to fix this and should be fixed soon.
>> 
>> * Branch Exclusions being ignored
>> 
>> This has been reported and its cause is currently unknown.
>> 
>> Thank you all again for your patience! This is a giant rollout with a
>> bunch of changes in it, so we really do appreciate everyone's
>> understanding as we work through it all.
>> 
>> 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
> 
> -- 
> BR
> Zhiyuan
> __
> OpenStack Development Mailing 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-operators] [tripleo] Making containerized service deployment the default

[Mohammed Naser]

On Mon, Sep 18, 2017 at 3:04 PM, Alex Schultz  wrote:
> Hey ops & devs,
>
> We talked about containers extensively at the PTG and one of the items
> that needs to be addressed is that currently we still deploy the
> services as bare metal services via puppet. For Queens we would like
> to switch the default to be containerized services.  With this switch
> we would also start the deprecation process for deploying services as
> bare metal services via puppet.  We still execute the puppet
> configuration as part of the container configuration process so the
> code will continue to be leveraged but we would be investing more in
> the continual CI of the containerized deployments and reducing the
> traditional scenario coverage.
>
> As we switch over to containerized services by default, we would also
> begin to reduce installed software on the overcloud images that we
> currently use.  We have an open item to better understand how we can
> switch away from the golden images to a traditional software install
> process during the deployment and make sure this is properly tested.
> In theory it should work today by switching the default for
> EnablePackageInstall[0] to true and configuring repositories, but this
> is something we need to verify.
>
> If anyone has any objections to this default switch, please let us know.

I think this is a great initiative.  It would be nice to share some of
the TripleO experience in containerized deployments so that we can use
Puppet for containerized deployments.  Perhaps we can work together on
adding some classes which can help deploy and configure containerized
services with Puppet.

>
> Thanks,
> -Alex
>
> [0] 
> https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/tripleo-packages.yaml#L33-L36
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
OpenStack Development Mailing 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][tripleo] Gates broken, avoid rechecks

[Mohammed Naser]

Hi everyone,

Just a quick heads up that at the moment, there is an issue in the
TripleO CI which is in the process of being fixed at the moment:

https://bugs.launchpad.net/tripleo/+bug/1717545

As certain Puppet modules gate for TripleO, please don't recheck
changes that have failing jobs which start with `gate-tripleo-ci-` as
they will fail anyways.

I'll send an update email when things are fixed (or when you see that
bug resolved).

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] [puppet] Add Mohammed Naser to cores

[Mohammed Naser]

Thank you for the kind words everyone! :)

On Tue, Sep 5, 2017 at 12:06 PM, Dmitry Tantsur  wrote:
> I think it's not unreasonable to give core rights to the PTL :)
>
>
> On 09/05/2017 05:42 PM, Alex Schultz wrote:
>>
>> Hey folks,
>>
>> I'm writing to ask that we add mnaser to the cores list for the puppet
>> modules.  He's been a user and contributor for some time and is also
>> the new PTL.  Let me know if there are any objections.
>>
>> Thanks,
>> -Alex
>>
>> __
>> OpenStack Development Mailing 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] [puppet][puppet-ceph]

[Mohammed Naser]

On Tue, Sep 5, 2017 at 4:15 AM, Emil Enemærke  wrote:
> Hi,
>
> I have stated using the puppet-ceph module for deploying ceph, and have
> noticed a heavy use of exec in fx define 'ceph::osd'
> (https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp). Is
> there a reason for not writing this define as an ensurable type/provider?
> Otherwise I will fork the module an start on rewriting it for a
> type/provider.
>

Thanks for helping out.  I'm happy to see folks using the puppet-ceph
modules!  I think the reason why we've relied of the Exec's is purely
historic.  If you have a patch that would convert it to an ensurable
type and provider, we'd be more than happy to merge it!

>
> Cheers
> Emil
>
> __
> OpenStack Development Mailing 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