Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal

2018-01-31 Thread Pavlo Shchelokovskyy
Lance,

that's a single patch renaming the sample policy file from .json to .yaml,
so I do not think it is a real blocker.
Besides we have another patch on review that deletes those files altogether
(and which I like more and there was an ML thread resulting in a decision
to indeed remove them).

I'll ask the patch owner to abandon it.

Cheers,

On Wed, Jan 31, 2018 at 7:23 PM, Lance Bragstad <lbrags...@gmail.com> wrote:

>
>
> On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:
> > Hi!
> >
> > On 01/31/2018 06:16 PM, Lance Bragstad wrote:
> >> Hey folks,
> >>
> >> The tracking tool for the policy-and-docs-in-code goal for Queens [0]
> >> lists a couple projects remaining for the goal [1].  I wanted to start a
> >> discussion with said projects to see how we want to go about the work in
> >> the future, we have a couple of options.
> >
> > I was under assumption that ironic has finished this goal. I'll wait
> > for pas-ha to weigh in, but I was not planning any activities for it.
> It looks like there is still an unmerged patch tagged with the
> policy-and-docs-in-code topic [0].
>
> [0]
> https://review.openstack.org/#/q/is:open+topic:policy-and-
> docs-in-code+project:openstack/ironic
> >
> >>
> >> I can update the document the goal document saying the work is still
> >> underway for those projects. We can also set aside time at the PTG to
> >> finish up that work if people would like more help. This might be
> >> something we can leverage the baremetal/vm room for if we get enough
> >> interest [2].
> >
> > Mmm, the scope of the bm/vm room is already unclear to me, this may
> > add to the confusion. Maybe just a "Goals workroom"?
> >
> >>
> >> I want to get the discussion rolling if there is something we need to
> >> coordinate for the PTG. Thoughts?
> >>
> >> Thanks,
> >>
> >> Lance
> >>
> >>
> >> [0] https://governance.openstack.org/tc/goals/queens/policy-in-
> code.html
> >> [1] https://www.lbragstad.com/policy-burndown/
> >> [2]
> >> http://lists.openstack.org/pipermail/openstack-dev/2018-
> January/126743.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
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

2018-01-30 Thread Pavlo Shchelokovskyy
+1 to Jim,

I'm specifically interested in app creds and RBAC as I'd like to find a way
to pass some of API access creds to the ironic deploy ramdisk, and it seems
one of those could help. Let's discuss :)

Cheers,

On Tue, Jan 30, 2018 at 6:03 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Tue, Jan 30, 2018 at 10:33 AM, Colleen Murphy <coll...@gazlene.net>
> wrote:
>
>> At the last PTG we had some time on Monday and Tuesday for
>> cross-project discussions related to baremetal and VM management. We
>> don't currently have that on the schedule for this PTG. There is still
>> some free time available that we can ask for[1]. Should we try to
>> schedule some time for this?
>>
>
> I'd attend for the topics you list below, FWIW.
>
>
>>
>> From a keystone perspective, some things we'd like to talk about with
>> the BM/VM teams are:
>>
>> - Unified limits[2]: we now have a basic REST API for registering
>> limits in keystone. Next steps are building out libraries that can
>> consume this API and calculate quota usage and limit allocation, and
>> developing models for quotas in project hierarchies. Input from other
>> projects is essential here.
>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>> problem, and we'd like to guide other projects through the migration.
>> - Application credentials[4]: this main part of this work is largely
>> done, next steps are implementing better access control for it, which
>> is largely just a keystone team problem but we could also use this
>> time for feedback on the implementation so far
>>
>> There's likely some non-keystone-related things that might be at home
>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>> two for these projects? Or perhaps not dedicated days, but
>> planned-in-advance meeting time? Or should we wait and schedule it
>> ad-hoc if we feel like we need it?
>>
>
> There's always plenty to discuss between nova and ironic, but we usually
> just schedule those topics somewhat ad-hoc. Never opposed to some
> dedicated time if folks will show up, though. :)
>
> // jim
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] Remove in-tree policy and config?

2018-01-22 Thread Pavlo Shchelokovskyy
John,

+1.

The sample file in etc/ironic/ in our repo is actually (almost) always out
of sync with the one in the docs - the docs one is re-generated on each
commit with new/changed stuff from third-party libs, the version in
etc/ironic is only updated manually when someone remembers it (as people
usually tend to limit the changes to this file in their commit to relevant
ones).

Cheers,

On Mon, Jan 22, 2018 at 2:45 PM, John Garbutt <j...@johngarbutt.com> wrote:

> Hi,
>
> While I was looking at the traits work, I noticed we still have policy and
> config in tree for ironic and ironic inspector:
>
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/policy.json.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/ironic.conf.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json
>
> And in a similar way:
> http://git.openstack.org/cgit/openstack/ironic-inspector/
> tree/policy.yaml.sample
> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf
>
> There is an argument that says we shouldn't force operators to build a
> full environment to generate these, but this has been somewhat superseded
> by us having good docs:
>
> https://docs.openstack.org/ironic/latest/configuration/sample-config.html
> https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-config.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-policy.html
>
> It could look something like this (but with the tests working...):
> https://review.openstack.org/#/c/536349
>
> What do you all think?
>
> Thanks,
> johnthetubaguy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [keystone] multiple federated keystones with single Identity Provider

2017-12-07 Thread Pavlo Shchelokovskyy
Hi all,

We have a following use case - several independent keystones (say KeyA and
KeyB), using fernet tokens and synchronized fernet keys, and single
external IdP for federated auth.

Is it generally possible to configure both KeyA and KeyB such that scoped
token issued by KeyA for a federated user is valid on KeyB?

Currently we have the next problem - although domains/projects where
keystone's mapping engine assigns federated users are equal by name between
KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB  are
different, which seems to invalidate the scoped token issued by KeyA when
trying to use it for KeyB. And it is not possible to create
projects/domains with specific UUIDs via keystone API (which would probably
solve this problem for non-autoprovisioned projects).

Is such usage scenario supported? Or one should always use the unscoped
token first to list projects/domains available on a specific keystone
instance and then get a scoped token for usage o this instance only?

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

2017-11-21 Thread Pavlo Shchelokovskyy
Hi all,

thank you all for your replies.

AFAIU the consensus is leaning towards option 1, so I've proposed a patch
to governance that adds networking-generic-switch under ironic:

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

(not actually sure how that works / being decided on from TC side, but will
see :) )

Cheers,

On Mon, Nov 20, 2017 at 6:14 PM, Ruby Loo <opensr...@gmail.com> wrote:

>
>
> On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker <stendul...@gmail.com
> > wrote:
>
>> Thank you. I too vote for 'Option 1'.
>>
>> Thanks and Regards
>> Shiv
>>
>>
>>
>> On Wed, Nov 15, 2017 at 1:03 AM, Villalovos, John L <
>> john.l.villalo...@intel.com> wrote:
>>
>>> Thanks for sending this out.
>>>
>>>
>>>
>>> I would vote for Option 1.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* [openstack-dev] [ironic] inclusion of
>>> openstack/networking-generic-switch project under OpenStack baremetal
>>> program
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> as this topic it was recently brought up in ironic IRC meeting, I'd like
>>> to start a discussion on the subject.
>>>
>>>
>>>
>>> A quick recap - networking-generic-switch project (n-g-s) was born out
>>> of necessity to do two things:
>>>
>>>
>>>
>>> -  test the "network isolation for baremetal nodes" (a.k.a.
>>> multi-tenancy) feature of ironic on upstream gates in virtualized
>>> environment and
>>>
>>> - do the same on cheap/simple/dumb hardware switches that are not
>>> supported by other various openstack/networking-* projects.
>>>
>>>
>>>
>>> Back when it was created AFAIR neutron governance (neutron stadium) was
>>> under some changes, so in the end n-g-s ended up not belonging to any
>>> official program.
>>>
>>>
>>>
>>> Over time n-g-s grew to be an essential part of ironic gate testing
>>> (similar to virtualbmc). What's more, we have reports that it is already
>>> being used in production.
>>>
>>>
>>>
>>> Currently the core reviewers team of n-g-s consists of 4 people (2 of
>>> those are currently core reviewers in ironic too), all of them are working
>>> for the same company (Mirantis). This poses some risk as companies and
>>> people come and go, plus since some voting ironic gate jobs depend on n-g-s
>>> stability, a more diverse group of core reviewers from baremetal program
>>> might be beneficial to be able to land patches in case of severe gate
>>> troubles.
>>>
>>>
>>>
>>> Currently I know of 3 proposed ways to change the current situation:
>>>
>>>
>>>
>>> 1) include n-g-s under ironic (OpenStack Baremetal program) governance,
>>> effectively including ironic-core team to the core team of  n-g-s similar
>>> to how ironic-inspector currently governed (keeping an extended sub-core
>>> team). Reasoning for addition is the same as with virtualbmc/sushy
>>> projects, with the debatable difference that the actual scope of n-g-s is
>>> quite bigger and apparently includes production use-cases;
>>>
>>>
>>>
>>> 2) keep things as they are now, just add ironic-stable-maint team to the
>>> n-g-s core reviewers to decrease low diversity risks;
>>>
>>>
>>>
>>> 3) merge the code from n-g-s into networking-baremetal project which is
>>> already under ironic governance.
>>>
>>>
>>>
>>> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
>>> fond of 3) as it kind of stretches the networking-baremetal scope too much
>>> IMHO.
>>>
>>>
>>>
>>> Eager to hear your comments and proposals.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> --
>>>
>>> Dr. Pavlo Shchelokovskyy
>>>
>>> Senior Software Engineer
>>>
>>> Mirantis Inc
>>>
>>> www.mirantis.com
>>>
>>>
>  I'm good with 1 or 2. Since we have two 1's and no nays (so far), let's
> go with 1 and move on :)
>
> Thanks for bringing this up!
>
> --ruby
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

2017-11-14 Thread Pavlo Shchelokovskyy
Hi all,

as this topic it was recently brought up in ironic IRC meeting, I'd like to
start a discussion on the subject.

A quick recap - networking-generic-switch project (n-g-s) was born out of
necessity to do two things:

-  test the "network isolation for baremetal nodes" (a.k.a. multi-tenancy)
feature of ironic on upstream gates in virtualized environment and
- do the same on cheap/simple/dumb hardware switches that are not supported
by other various openstack/networking-* projects.

Back when it was created AFAIR neutron governance (neutron stadium) was
under some changes, so in the end n-g-s ended up not belonging to any
official program.

Over time n-g-s grew to be an essential part of ironic gate testing
(similar to virtualbmc). What's more, we have reports that it is already
being used in production.

Currently the core reviewers team of n-g-s consists of 4 people (2 of those
are currently core reviewers in ironic too), all of them are working for
the same company (Mirantis). This poses some risk as companies and people
come and go, plus since some voting ironic gate jobs depend on n-g-s
stability, a more diverse group of core reviewers from baremetal program
might be beneficial to be able to land patches in case of severe gate
troubles.

Currently I know of 3 proposed ways to change the current situation:

1) include n-g-s under ironic (OpenStack Baremetal program) governance,
effectively including ironic-core team to the core team of  n-g-s similar
to how ironic-inspector currently governed (keeping an extended sub-core
team). Reasoning for addition is the same as with virtualbmc/sushy
projects, with the debatable difference that the actual scope of n-g-s is
quite bigger and apparently includes production use-cases;

2) keep things as they are now, just add ironic-stable-maint team to the
n-g-s core reviewers to decrease low diversity risks;

3) merge the code from n-g-s into networking-baremetal project which is
already under ironic governance.

As a core in n-g-s myself I'm happy with either 1) or 2), but not really
fond of 3) as it kind of stretches the networking-baremetal scope too much
IMHO.

Eager to hear your comments and proposals.

Cheers,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic][tempest][qa] dropping the ironic-inspector-tempest-plugin repo

2017-10-31 Thread Pavlo Shchelokovskyy
Hi all,

there exists this repo
http://git.openstack.org/cgit/openstack/ironic-inspector-tempest-plugin.
It is basically empty and there's a single pending review adding initial
cookiecutter-generated project stuff.
I am not sure who/how asked for creation of this project (may be automated
for the x-project goal?),
but eventually Ironic community decided to keep tempest tests for both
ironic and ironic-inspector in a single repo 'ironic-tempest-plugin' (work
of moving ironic tests there is in progress, inspector will follow).

Thus a question to QA/tempest team - would that play nice with tempest and
scripts/logic around running it on gates if two separate projects with
different names would have a common tempest plugin project?
If yes, then we should request to delete this
'ironic-inspector-tempest-plugin' project as it is and will be empty and
useless, just confusing users.
If not, ironic community probably might have to re-assess its decision...

Cheers,

-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] testing ansible-deploy in gates

2017-10-31 Thread Pavlo Shchelokovskyy
Hi all,

as we have agreed on the PTG, we are about to pull the ansible-deploy
interface from ironic-staging-drivers to ironic. We obviously need to test
it on gates too, in a non-voting mode like snmp and redfish ones.

This raises couple of questions/concerns:

1. Testing hardware types on gates.
This is the first? interface that does not have any "classic" driver
associated with it. All our devstack setup logic is currently based on
classic drivers instead of hardware types, in particular all the
"is_deployed_by" functions and logic depending on them.
As we are about to deprecate the classic drivers altogether and eventually
remove them, we ought to start moving our setup and testing procedures to
hardware types as well.
(another interesting point would be how much effort we need to adapt all
our unit tests to use hw types instead of 'fake' and other classic
drivers...)

2. Deploy ramdisk image to use.
Current job in staging drivers does small rebuild of tinyipa image during
deploy. I'd like to avoid it as much as possible, so I propose to add all
the logic which is there to default build options and scripts of tinyipa
build. This includes installing SSH server and enabling SSH access to the
ramdisk, and some small mangling with files and file links.
A separate question would be SSH keys. We could either not bake them to the
image and generate them each time anew, but that would still require an
image rebuild on (each?) devstack run. Or we could generate them once, bake
the public key to the image and publish the private key to tarballs.o.o, so
it could be re-used by IPA scripts and jobs to build fresh images on merge
and during tests. There are surely certain security consideration to such
approach, but as tinyipa is targeted for testing (virtual) environments and
not production, I suppose we could probably neglect them.

WDYT?

Another aspect of this is (as we agreed) we would need to move all the
'imagebuild' folder content from IPA repo to a separate repo, and devise a
way to use this repo in our devstack plugin.

I'm eager to hear your thoughts and comments.

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

2017-10-31 Thread Pavlo Shchelokovskyy
On Mon, Oct 30, 2017 at 9:46 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100:
> > Hi all,
> >
> > So far driver requirements [1] have been managed outside of
> global-requirements.
> > This was mostly necessary because some dependencies were not on PyPI.
> This is no
> > longer the case, and I'd like to consider managing them just like any
> other
> > dependencies. Pros:
> > 1. making these dependencies (and their versions) more visible for
> packagers
> > 2. following the same policies for regular and driver dependencies
> > 3. ensuring co-installability of these dependencies with each other and
> with the
> > remaining openstack
> > 4. potentially using upper-constraints in 3rd party CI to test what
> packagers
> > will probably package
> > 5. we'll be able to finally create a tox job running unit tests with all
> these
> > dependencies installed (FYI these often breaks in RDO CI)
> >
> > Cons:
> > 1. more work for both the requirements team and the vendor teams
> > 2. inability to use ironic release notes to explain driver requirements
> changes
> > 3. any objections from the requirements team?
> >
> > If we make this change, we'll drop driver-requirements.txt, and will use
> > setuptools extras to list then in setup.cfg (this way is supported by
> g-r)
> > similar to what we do in ironicclient [2].
> >
> > We either will have one list:
> >
> > [extras]
> > drivers =
> >sushy>=a.b
> >python-dracclient>=x.y
> >python-prolianutils>=v.w
> >...
> >
> > or (and I like this more) we'll have a list per hardware type:
> >
> > [extras]
> > redfish =
> >sushy>=a.b
> > idrac =
> >python-dracclient>=x.y
> > ilo =
> >...
> > ...
> >
> > WDYT?
>
> The second option is what I would expect.
>
>
I also would prefer option 2 (per driver extras), with a catch-all [all]
extra to install all of those in one short command

I have a separate concern about ansible-deploy interface. It obviously
depends on Ansibe, but so does most of upstream infra. I am not sure if
adding  (somehow restricted) Ansible to g-r won't break anything.

Doug
>
> >
> > [1] https://github.com/openstack/ironic/blob/master/driver-
> requirements.txt
> > [2] https://github.com/openstack/python-ironicclient/blob/
> master/setup.cfg#L115
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] ironic-staging-drivers core cleanup and additions

2017-08-25 Thread Pavlo Shchelokovskyy
Dmitry and all,

thank you for your trust. I'll do my best to keep the project alive and
healthy.

Best regards,

On Thu, Aug 24, 2017 at 4:15 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> We seem to be in agreement, so I'll apply these changes. Thanks all!
>
>
> On 08/22/2017 11:24 AM, Dmitry Tantsur wrote:
>
>> Hi all!
>>
>> This email concerns the ironic-staging-drivers project which is outside
>> of the official Ironic governance. Please ignore it if you don't care about
>> this project.
>>
>> I've checked the core [1] and the release [2] teams for the project, and
>> I think they need an update based (see [3]).
>>
>> I suggest removing the following people:
>> * Dan Prince (due to inactivity)
>> * Lucas Alvares Gomes (due to priorities change)
>> * Imre Farkas (no longer works on OpenStack)
>>
>> I suggest adding Pavlo Shchelokovskyy, who actively contributes to and
>> reviews the project, to the core team.
>>
>> I've cc'ed affected people as I was a bit too lazy to reach to them on
>> IRC :) Please let me know your opinion.
>>
>> [1] https://review.openstack.org/#/admin/groups/1258,members
>> [2] https://review.openstack.org/#/admin/groups/1259,members
>> [3] http://stackalytics.com/?module=ironic-staging-drivers=pike
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

2017-08-11 Thread Pavlo Shchelokovskyy
Hi Mark,

I do not propose to remove handling of plain http image references
altogether, just remove the code pieces in glance service utils that
pretend to support such refs *for glance images*.

This code is never reached exactly due to plain http links being recognized
as such from the very begining, and thus they will use a different 'image
service' (HttpImageService) that has no notion of glance api, its required
auth etc.

Cheers,

On Fri, Aug 11, 2017 at 11:59 AM, Mark Goddard <m...@stackhpc.com> wrote:

> Hi Pavlo,
>
> #3 is used in Bifrost, where there is no Glance service but the default
> driver is agent_ipmitool. The images are served by the local nginx service.
> For example, taken from one ironic node:
>
> 'image_source':  u'http://10.41.253.100:8080/deployment_image.qcow2'
>
> Mark
>
> On 10 August 2017 at 08:20, Pavlo Shchelokovskyy <
> pshchelokovs...@mirantis.com> wrote:
>
>> HI Dmitry,
>>
>> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur <dtant...@redhat.com>
>> wrote:
>>
>>> Hi!
>>>
>>> Thanks for raising this.
>>>
>>> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:
>>>
>>>> Hi all,
>>>>
>>>> currently our GlanceImageService seems to support several ways of
>>>> defining a reference to glance image:
>>>>
>>>> 1) simple image UUID [0]
>>>> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
>>>> anything starting with 'glance://' and ending with '/')
>>>> 3) full REST path to the image (as in 
>>>> http:///v2/images/),
>>>> also used to extract the glance API address [2]
>>>>
>>>> Support for #3 must surely be removed, as we are moving to API endpoint
>>>> discovery from keystone catalog.
>>>> Besides I am pretty sure this code path can not actually be reached
>>>> currently, as the 'is_glance_image' will ignore such image refs and return
>>>> False for those [3], and 'get_image_service' would also not return the
>>>> GlanceImageService instance for such image refs [4].
>>>> Hence the question - if it is unusable anyway now, should we execute
>>>> the standard deprecation process when removing support for it or just
>>>> remove right away?
>>>>
>>>
>>> If unsure, always use the standard process ;) Unless somebody is ready
>>> to set up DevStack, and try it out, and prove that it's completely and
>>> hopelessly broken.
>>
>>
>> Did just that [0] - hacked up our tempest configuration so that the
>> 'http' url for whole disk image used for *HttpLink standalone tests leads
>> to /v2/images/ [1].
>> As I kind of expected, both *HttpLink standalone tests failed, right on
>> validating of the deploy interface when trying to do a HEAD on that URL
>> instead of 'glance image show', receiving 401 [2].
>> On a side note, it seems our logging is insufficient in this parts, as I
>> could not find any relevant logs in ironic-conductor even at debug level,
>> all that's there are final RPC processing error logs from api.
>>
>> So I am quite confident that this code paths [3] in service_utils is a
>> dead end indeed :-/
>>
>> [0] https://review.openstack.org/#/c/492184/
>> [1] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
>> [2] http://logs.openstack.org/84/492184/1/check/gate-ironic-
>> dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
>> [3] https://github.com/openstack/ironic/blob/7e6ce7e78c4378f
>> 2f86d085df61a26507a410738/ironic/common/glance_service/
>> service_utils.py#L159-L166
>>
>>
>>>
>>>
>>>> As for the #1 and #2 I do not see any big difference between those, and
>>>> proposed deprecating and eventually removing support for #2 ('glance://'
>>>> scheme) as part of [5]. Two people in review already raised a concern about
>>>> removing such support.
>>>>
>>>
>>> To be honest, I like glance:// more, as it makes it obvious where
>>> the image is coming from vs http://. I don't mind removing it too much,
>>> but I guess supporting it is not a lot of code, right?
>>>
>>
>> That's not too much burden indeed, as long as we actually do only that -
>> as I said, right now it is more like "glance:///uuid"
>>
>>
>>>
>>>> Thus I'd like to ask a broader audience - do we need support for glance
>>>> image references i

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

2017-08-10 Thread Pavlo Shchelokovskyy
HI Dmitry,

On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> Hi!
>
> Thanks for raising this.
>
> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:
>
>> Hi all,
>>
>> currently our GlanceImageService seems to support several ways of
>> defining a reference to glance image:
>>
>> 1) simple image UUID [0]
>> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
>> anything starting with 'glance://' and ending with '/')
>> 3) full REST path to the image (as in 
>> http:///v2/images/),
>> also used to extract the glance API address [2]
>>
>> Support for #3 must surely be removed, as we are moving to API endpoint
>> discovery from keystone catalog.
>> Besides I am pretty sure this code path can not actually be reached
>> currently, as the 'is_glance_image' will ignore such image refs and return
>> False for those [3], and 'get_image_service' would also not return the
>> GlanceImageService instance for such image refs [4].
>> Hence the question - if it is unusable anyway now, should we execute the
>> standard deprecation process when removing support for it or just remove
>> right away?
>>
>
> If unsure, always use the standard process ;) Unless somebody is ready to
> set up DevStack, and try it out, and prove that it's completely and
> hopelessly broken.


Did just that [0] - hacked up our tempest configuration so that the 'http'
url for whole disk image used for *HttpLink standalone tests leads to
/v2/images/ [1].
As I kind of expected, both *HttpLink standalone tests failed, right on
validating of the deploy interface when trying to do a HEAD on that URL
instead of 'glance image show', receiving 401 [2].
On a side note, it seems our logging is insufficient in this parts, as I
could not find any relevant logs in ironic-conductor even at debug level,
all that's there are final RPC processing error logs from api.

So I am quite confident that this code paths [3] in service_utils is a dead
end indeed :-/

[0] https://review.openstack.org/#/c/492184/
[1]
http://logs.openstack.org/84/492184/1/check/gate-ironic-dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
[2]
http://logs.openstack.org/84/492184/1/check/gate-ironic-dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
[3]
https://github.com/openstack/ironic/blob/7e6ce7e78c4378f2f86d085df61a26507a410738/ironic/common/glance_service/service_utils.py#L159-L166


>
>
>> As for the #1 and #2 I do not see any big difference between those, and
>> proposed deprecating and eventually removing support for #2 ('glance://'
>> scheme) as part of [5]. Two people in review already raised a concern about
>> removing such support.
>>
>
> To be honest, I like glance:// more, as it makes it obvious where
> the image is coming from vs http://. I don't mind removing it too much,
> but I guess supporting it is not a lot of code, right?
>

That's not too much burden indeed, as long as we actually do only that - as
I said, right now it is more like "glance:///uuid"


>
>> Thus I'd like to ask a broader audience - do we need support for glance
>> image references in 'glance://*' form? Is it actually used somewhere?
>> What are the benefits of having it besides simple UUID?
>>
>> [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n149
>> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n155
>> [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n160
>> [3] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n208
>> [4] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/image_service.py#n267
>> [5] https://review.openstack.org/#/c/467728
>>
>> Cheers,
>>
>> --
>> Dr. Pavlo Shchelokovskyy
>> Senior Software Engineer
>> Mirantis Inc
>> www.mirantis.com <http://www.mirantis.com>
>>
>>
>> 
>> __
>> 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
>



-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

2017-08-07 Thread Pavlo Shchelokovskyy
Hi all,

currently our GlanceImageService seems to support several ways of defining
a reference to glance image:

1) simple image UUID [0]
2) image UUID prefixed with 'glance://' protocol [1] (well, actually
anything starting with 'glance://' and ending with '/')
3) full REST path to the image (as in
http:///v2/images/),
also used to extract the glance API address [2]

Support for #3 must surely be removed, as we are moving to API endpoint
discovery from keystone catalog.
Besides I am pretty sure this code path can not actually be reached
currently, as the 'is_glance_image' will ignore such image refs and return
False for those [3], and 'get_image_service' would also not return the
GlanceImageService instance for such image refs [4].
Hence the question - if it is unusable anyway now, should we execute the
standard deprecation process when removing support for it or just remove
right away?

As for the #1 and #2 I do not see any big difference between those, and
proposed deprecating and eventually removing support for #2 ('glance://'
scheme) as part of [5]. Two people in review already raised a concern about
removing such support.

Thus I'd like to ask a broader audience - do we need support for glance
image references in 'glance://*' form? Is it actually used somewhere?
What are the benefits of having it besides simple UUID?

[0]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n149
[1]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n155
[2]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n160
[3]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n208
[4]
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/image_service.py#n267
[5] https://review.openstack.org/#/c/467728

Cheers,

-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic][python-ironicclient][keystoneauth] Getting rid of a custom HTTPClient implementation

2017-07-31 Thread Pavlo Shchelokovskyy
Hi Vlad,

On Fri, Jul 21, 2017 at 9:09 PM, Vladyslav Drok <vd...@mirantis.com> wrote:

> Greetings!
>
> I have a patch [0] to deprecate the custom HTTPClient implementation that
> we have in python-ironicclient. Currently it is used when the 'ironic'
> command is issued in a standalone mode, that is, with '--ironic-url' and
> '--os-auth-token' parameters,
>

recently released keystoneauth 3.1.0 has a new 'none' auth plugin that can
be used for standalone mode together with endpoint_override Adapter option
instead of 'admin_token' auth plugin [1]. Maybe that would allow you to
simplify the code a bit. Note that the bump to ironicclient reguirements re
keystoneauth is not merged yet [2].

[1]
https://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/noauth.py
[2] https://review.openstack.org/#/c/488117/


> or when a client is instantiated through the following module [1] directly
> without passing the session object, or even directly calling HTTPClient
> constructor at [2]. In other cases, keystoneauth's SessionClient derivative
> object is used. [0] will basically substitute the HTTPClient with the
> SessionClient (by using the 'admin_token' auth plugin). It seems like a
> breaking change, as most likely some HTTP error codes and exceptions thrown
> may be different, so I think we'll need the major client library version
> bump. We'll also make it clear in the docs that the only "true" way for
> instantiating the client is through 'get_client' method in [3].
>
> After that, we'll need to remove the HTTPClient class completely, and here
> a question is, whether we should have another major version bump? Or can we
> remove it right away, and single major version bump should be enough? (as
> the HTTPClient defined in [2] was not something we advertised as a part of
> our public python API)
>

There are actually more reasons for a major version  bump - we've reached
feature parity of our OSC plugin with 'ironic' CLI and should start to
phase the latter out (and drop OSC from hard client requirements).
So I'd vote for las minor version release with many deprecations warnings,
and clean up HTTPClient and officially deprecate 'ironic' CLI in the next
release that would be a major version bump.


> Any suggestions welcome :)
>
> -Vlad
>
> [0] https://review.openstack.org/359061
> [1] https://github.com/openstack/python-ironicclient/
> blob/master/ironicclient/v1/client.py
> [2] https://github.com/openstack/python-ironicclient/
> blob/master/ironicclient/common/http.py
> [3] https://github.com/openstack/python-ironicclient/
> blob/master/ironicclient/client.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
>
>

Cheers,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic][magnum][kolla][ansible][puppet][rally] removing SSH drivers from Ironic

2017-07-05 Thread Pavlo Shchelokovskyy
Hi all,

as mitaka branch was finally EOLed, Ironic team is going to proceed with
removal of SSH-based power and management drivers for virtualized HW which
were deprecated back in newton release.

Since newton the virtualbmc-based simulation of IPMI-capable HW is
officially supported, and we plan to switch all gates away from using *_ssh
drivers and eventually remove those from the ironic code, most probably in
Pike release.

I've skimmed through the project-config/zuul/layout.yaml and found a number
of projects that use some gate jobs with 'ironic' in the job name which are
not defined in project-config/jenkins/jobs/ironic.yaml, those project are
tagged in the subject of this message.

While kolla, magnum, OSA and rally seem to have only non-voting jobs with
ironic and thus should not be completely broken by removal of SSH drivers
anyway, puppet-ironic seems to have a voting
"puppet-openstack-integration-jobs-scenario002" job.

This message especially concerns deployment-specific projects that do not
install ironic via DevStack in their gate jobs. To successfully install a
working ironic which is capable to actually deploy nodes, such projects
will have to incorporate some additional steps to setup virtualbmc-based HW
simulation for baremetal nodes and configure nodes enrolled in ironic
accordingly.

If your project is mentioned, please ensure that any ironic-including gate
jobs you use do not setup ironic with *_ssh drivers, and switch to other
supported drivers if needed. Examples of necessary steps can be found in
ironic's DevStack plugin and in the playbooks of openstack/bifrost project.

For any questions please do not hesitate to contact ironic team, we'll be
glad to help you.

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

2017-06-16 Thread Pavlo Shchelokovskyy
HI all,

On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <zbit...@redhat.com> wrote:

> On 16/06/17 05:09, Kaz Shinohara wrote:
>
>> I still takes `deferred _auth_method=password` behalf of trusts because
>> we don't enable trusts in the Keystone side due to some internal reason.
>>
>
> Free advice: whatever reason you have for not enabling trusts, storing
> user passwords in the Heat database is 100x worse.
>
> The issues what you pointed are correct(e.g. user_domain_id), we don't use
>> the domain well and also added some patches to skip those issues.
>>
>
> Why aren't those upstream?
>
> But I guess that the majority of heat users already moved to trusts and it
>> is obviously better solution in terms of security and granular role control.
>> As the edge case(perhaps), if a user want to take password auth, it would
>> be too tricky for them to introduce it, therefore I agree your 2nd option.
>>
>> If we will remove the `deferred_auth_method=password` from heat.conf,
>> should we keep `deferred_auth_method` self or will replace it to a new
>> config option just to specify the trusts enable/disable ?  Do you have any
>> idea on this?
>> Also I'm thinking that `reauthentication_method` also might be
>> changed/merged ?
>>
>> Regards,
>> Kaz Shinohara
>>
>>
>> 2017-06-16 14:11 GMT+09:00 Rabi Mishra <ramis...@redhat.com > ramis...@redhat.com>>:
>>
>
> [snip]
>
> I'm not sure whether this works with keystone v2 and anyone is using
>> it or not. Keeping in mind that heat-cli is deprecated and keystone
>> v3 is now the default, we've 2 options
>>
>> 1. Continue to support 'deferred_auth_method=passsword' option and
>> fix all the above issues.
>>
>> 2. Remove/deprecate the option in pike itlsef.
>>
>> I would prefer option 2, but probably I miss some history and use
>> cases for it.
>>
>
> Am I right in thinking that any user (i.e. not just the [heat] service
> user) can create a trust? I still see occasional requests about 'standalone
> mode' for clouds that don't have Heat available to users (which I suspect
> is broken, otherwise people wouldn't be asking), and I'm guessing that
> standalone mode has heretofore required deferred_auth_method=password.
>

When trusts are enabled, generally any user can create a trust to any other
user, but only with itself as trustor  - there's a strict rule for that in
default keystone policy.json [0]. The only other reason that might block
this is when the user is already a trustee, and trust chaining is disabled
or already exhausted for this trustee. A tiny problem might be that it
seems you need to know both the user_id/project_id of trustor (can be
resolved by trustor itself) and the user_id of trustee - which is generally
impossible for non-admin users, so a trustee must give the trustor its id.

[0]
http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138


> So if we're going to remove the option then we should probably either
> officially disown standalone mode or rewrite the instructions such that it
> can be used with the trusts method.
>
> 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
>


Cheers,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic][nova] Goodbye^W See you later

2017-06-08 Thread Pavlo Shchelokovskyy
Jim,

very sad to see you go :( Undeniably you played a major part in ironic and
its community becoming what they are today - an awesome project made by
awesome people.

Hopefully we'll have a chance to work together again someday :)

All the best in your new endeavors,
Pavlo.

On Thu, Jun 8, 2017 at 4:00 PM, milanisko k  wrote:

> Best of luck, jroll!
>
> <3
> milan
>
> čt 8. 6. 2017 v 14:46 odesílatel Jim Rollenhagen 
> napsal:
>
>> Hey friends,
>>
>> I've been mostly missing for the past six weeks while looking for a new
>> job, so maybe you've forgotten me already, maybe not. I'm happy to tell you
>> I've found one that I think is a great opportunity for me. But, I'm sad to
>> tell you that it's totally outside of the OpenStack community.
>>
>> The last 3.5 years have been amazing. I'm extremely grateful that I've
>> been able to work in this community - I've learned so much and met so many
>> awesome people. I'm going to miss the insane(ly awesome) level of
>> collaboration, the summits, the PTGs, and even some of the bikeshedding.
>> We've built amazing things together, and I'm sure y'all will continue to do
>> so without me.
>>
>> I'll still be lurking in #openstack-dev and #openstack-ironic for a
>> while, if people need me to drop a -2 or dictate old knowledge or whatever,
>> feel free to ping me. Or if you just want to chat. :)
>>
>> <3 jroll
>>
>> P.S. obviously my core permissions should be dropped now :P
>> 
>> __
>> OpenStack Development Mailing List (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] [ironic] using keystone right - catalog, endpoints, tokens and noauth

2017-06-01 Thread Pavlo Shchelokovskyy
Hi all,

thanks Monty for the feedback. I've started this set of patches in ironic
[0] (very WiP currently), and would really like some eyes on them (not
right now, as I plan to rewrite those basing on this conversation :) but
soon I hope). Also I have some questions/comments inline:

On Thu, May 25, 2017 at 12:36 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 05/24/2017 12:51 PM, Eric Fried wrote:
>
>> Pavlo-
>>
>> There's a blueprint [1] whereby we're trying to address a bunch of
>> these same concerns in nova.  You can see the first part in action here
>> [2].  However, it has become clear that nova is just one of the many
>> services that would benefit from get_service_url().  With the full
>> support of mordred (let's call it The Full Monty), we've got our sights
>> on moving that method into ksa itself for that purpose.
>>
>
> Yes - this has started with documenting how to consume Keystone Catalog
> and discovery properly.
>
> https://review.openstack.org/#/q/topic:version-discovery
>
> (it's a big stack)
>
> Once we're good with that - the next step is getting ksa updated to be
> able to handle the end-to-end. It does most of it today, but there are
> enough edgecases it doesn't that you wind up having to do something else,
> like efried just did in nova. The goal is to make that not necessary - and
> so that it's both possible and EASY for everyone to CORRECTLY consume
> catalog and version discovery.
>
> (more comments inline below)
>
>
> Please have a look at this blueprint and change set.  Let us know
>> if
>> your concerns would be addressed if this were available to you from ksa.
>>
>> [1]
>> https://specs.openstack.org/openstack/nova-specs/specs/pike/
>> approved/use-service-catalog-for-endpoints.html
>> [2] https://review.openstack.org/#/c/458257/
>>
>> Thanks,
>> efried
>>
>> On 05/24/2017 04:46 AM, Pavlo Shchelokovskyy wrote:
>>
>>> Hi all,
>>>
>>> There are several problems or inefficiencies in how we are dealing with
>>> auth to other services. Although it became much better in Newton, some
>>> things are still to be improved and I like to discuss how to tackle
>>> those and my ideas for that.
>>>
>>> Keystone endpoints
>>> ===
>>>
>>> Apparently since February-ish DevStack no longer sets up 'internal'
>>> endpoints for most of the services in core devstack [0].
>>> Luckily we were not broken by that right away - although when
>>> discovering a service endpoint from keystone catalog we default to
>>> 'internal' endpoint [1], for most services our devstack plugin still
>>> configures explicit service URL in the corresponding config section, and
>>> thus the service discovery from keystone never takes place (or that code
>>> path is not tested by functional/integration testing).
>>>
>>> AFAIK different endpoint types (internal vs public) are still quite used
>>> by deployments (and IMO rightfully so), so we have to continue
>>> supporting that. I propose to take the following actions:
>>>
>>
> I agree you should continue supporting it.
>
> I'm not sure it's important for you to change your defaults ... as long at
> it's possible to consistently set "interface=public" or
> "interface=internal" and have the results be correct, I think that's the
> big win.
>
> - in our devstack plugin, stop setting up the direct service URLs in
>>> config, always use keystone catalog for discovery
>>>
>>
> YES
>
> - in every conf section related to external service add
>>> 'endpoint_type=[internal|public]' option, defaulting to 'internal', with
>>> a warning in option description (and validated on conductor start) that
>>> it will be changed to 'public' in the next release
>>>
>>
> efried just added a call to keystoneauth which will register all of the
> appropriate CONF options that are needed to request a service endpoint from
> the catalog - register_adapter_conf_options:
>
> http://git.openstack.org/cgit/openstack/keystoneauth/tree/ke
> ystoneauth1/loading/__init__.py#n39
>
> The word "adapter" in this case isn't directly important - but there are
> three general concepts in keystoneauth that relate to how you connect:
>
> auth
>  - how you authenticate - auth_type, username, password, etc.
> session
>  - how the transport layer connects - certs, timeouts, etc.
> adapter
>  - what base endpoint to mount from the catalog - service_type, inte

Re: [openstack-dev] [ironic] why is glance image service code so complex?

2017-05-24 Thread Pavlo Shchelokovskyy
Hi,

regarding #1: there are actually 4 methods there that are not used anywhere
in ironic, which are to list images and create/update/delete an image in
Glance.
The question is do we consider those classes to be a part of public ironic
Python API? Are we safe to remove them right away? Or should we go a
standard deprecation process on those - log runtime warnings when they are
used in Pike (unfortunately it seems it won't be possible to issue a single
warning on conductor start) and remove in Queens?

I'd also like to add a question #4:

In the image-related code we have special handling of "glance://" URL
scheme. Is anyone using that still? Do we really have to support it or can
we deprecate it as a recognized URL scheme for image_source?

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, May 23, 2017 at 7:11 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 05/23/2017 05:52 PM, Pavlo Shchelokovskyy wrote:
>
>> Hi all,
>>
>> I've started to dig through the part of Ironic code that deals with
>> glance and I am confused by some things:
>>
>> 1) Glance image service classes have methods to create, update and delete
>> images. What's the use case behind them? Is ironic supposed to actively
>> manage images? Besides, these do not seem to be used anywhere else in
>> ironic code.
>>
>
> Yeah, I don't think we upload anything to glance. We may upload stuff to
> Swift though, but that's another story.
>
>
>> 2) Some parts of code (and quite a handful of options in [glance] config
>> section) AFAIU target a situation when both ironic and glance are deployed
>> standalone with possibly multiple glance API services so there is no
>> keystone catalog to discover the (load-balanced) glance endpoint from. We
>> even have our own round-robin implementation for those multiple glance
>> hosts o_0
>>
>> 3) Glance's direct_url handling - AFAIU this will work iff there is a
>> single conductor service and single glance registry service configured with
>> simple file backend deployed on the same host (with appropriate file access
>> permissions between ironic and glance), and glance is configured to
>> actually provide direct_url for the image - very much a DevStack (though
>> with non-standard settings).
>>
>> Do we actually have to support such narrow deployment scenarios as in 2)
>> and 3)? While for 2) we probably should continue support standalone Glance,
>> keeping implementations for our own round-robin load-balancing and retries
>> seems out of ironic scope.
>>
>
> Yeah, I'd expect people to deploy HA proxy or something similar for
> load-balancing. Not sure what you mean by retries though.
>
> Number 3, I suspect, is for simple all-in-one deployments. I don't
> remember the whole background, so I can't comment more.
>
>
>> Most of those do seem to be a legacy code crust from nova-baremetal era,
>> but I might be missing something. I'm eager to hear your comments.
>>
>
> #1 and #2 probably. I'm fine with getting rid of them.
>
>
>> Cheers,
>>
>> Dr. Pavlo Shchelokovskyy
>> Senior Software Engineer
>> Mirantis Inc
>> www.mirantis.com
>> <http://www.mirantis.com>
>>
>>
>> 
>> __
>> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] using keystone right - catalog, endpoints, tokens and noauth

2017-05-24 Thread Pavlo Shchelokovskyy
Hi all,

There are several problems or inefficiencies in how we are dealing with
auth to other services. Although it became much better in Newton, some
things are still to be improved and I like to discuss how to tackle those
and my ideas for that.

Keystone endpoints
===

Apparently since February-ish DevStack no longer sets up 'internal'
endpoints for most of the services in core devstack [0].
Luckily we were not broken by that right away - although when discovering a
service endpoint from keystone catalog we default to 'internal' endpoint
[1], for most services our devstack plugin still configures explicit
service URL in the corresponding config section, and thus the service
discovery from keystone never takes place (or that code path is not tested
by functional/integration testing).

AFAIK different endpoint types (internal vs public) are still quite used by
deployments (and IMO rightfully so), so we have to continue supporting
that. I propose to take the following actions:

- in our devstack plugin, stop setting up the direct service URLs in
config, always use keystone catalog for discovery
- in every conf section related to external service add
'endpoint_type=[internal|public]' option, defaulting to 'internal', with a
warning in option description (and validated on conductor start) that it
will be changed to 'public' in the next release
- use those values from CONF wherever we ask for service URL from catalog
or instantiate client with session.
- populate these options in our devstack plugin to be 'public'
- in Queens, switch the default to 'public' and use defaults in devstack
plugin, remove warnings.

Unify clients creation


again, in those config sections related to service clients, we have many
options to instantiate clients from (especially glance section, see my
other recent ML about our image service code). Many of those seem to be
from the time when keystone catalog was missing some functionality or not
existing at all, and keystoneauth lib abstracting identity and client
sessions was not there either.

To simplify setup and unify as much code as possible I'd like to propose
the following:

- in each config section for service client add (if missing) a
'_url' option that should point to the API of given service and
will be used *only in noauth mode* when there's no Keystone catalog to
discover the service endpoint from
- in the code creating service clients, always create a keystoneauth
session from config sections, using appropriate keystoneauth identity
plugin - 'token_endpoint' with fake token _url for noauth mode,
'password' for service user client, 'token' when using a token from
incoming request. The latter will have a benefit to make it possible for
the session to reauth itself when user token is about to expire, but might
require changes in some public methods to pass in the full task.context
instead of just token
- always create clients from sessions. Although AFAIK all clients ironic
uses already support this, some in ironic code (e.g. glance) still always
create a client from token and endpoint directly.
- deprecate some options explicitly registered by ironic in those sections
that are becoming redundant - including those that relate to HTTP session
settings (like timeout, retries, SSL certs and settings) as those will be
used from options registered by keystoneauth Session, and those multiple
options that piece together a single service URL.

This will decrease the complexity of service client-related code and will
make configuring those cleaner.

Of course all of this has to be done minding proper deprecation process,
although that might complicate things (as usual :/).

Legacy auth
=

Probably not worth specific mention, but we implemented a proper
keystoneauth-based loading of client auth options back in Newton almost a
year ago, so the code attempting to load auth for clients in a deprecated
way from "[keystone_authtoken]" section can be safely removed already.

As always, I'm eager to hear your comments.

[0] https://review.openstack.org/#/c/433272/
[1] http://git.openstack.org/cgit/openstack/ironic/tree/
ironic/common/keystone.py#n118

Best regards,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] why is glance image service code so complex?

2017-05-23 Thread Pavlo Shchelokovskyy
Hi all,

I've started to dig through the part of Ironic code that deals with glance
and I am confused by some things:

1) Glance image service classes have methods to create, update and delete
images. What's the use case behind them? Is ironic supposed to actively
manage images? Besides, these do not seem to be used anywhere else in
ironic code.

2) Some parts of code (and quite a handful of options in [glance] config
section) AFAIU target a situation when both ironic and glance are deployed
standalone with possibly multiple glance API services so there is no
keystone catalog to discover the (load-balanced) glance endpoint from. We
even have our own round-robin implementation for those multiple glance
hosts o_0

3) Glance's direct_url handling - AFAIU this will work iff there is a
single conductor service and single glance registry service configured with
simple file backend deployed on the same host (with appropriate file access
permissions between ironic and glance), and glance is configured to
actually provide direct_url for the image - very much a DevStack (though
with non-standard settings).

Do we actually have to support such narrow deployment scenarios as in 2)
and 3)? While for 2) we probably should continue support standalone Glance,
keeping implementations for our own round-robin load-balancing and retries
seems out of ironic scope.

Most of those do seem to be a legacy code crust from nova-baremetal era,
but I might be missing something. I'm eager to hear your comments.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [heat][ironic][tripleo] ironic resources in heat

2017-04-27 Thread Pavlo Shchelokovskyy
HI all,

from some conversations I had during Pike PTG and recently in IRC I
understood that the need for ironic resources in heat has arisen again. I
remember back when it was proposed for the first time there was some
opposition from ironic community (although I personally find it reasonable
to have those) but AFAIU this is no longer the case.

I would gladly revive old Steven Hardy patches [0] (have them starred on
Gerrit since then :) ) and make it happen if there are no objections.

I also see that the spec itself to this regard has been recently
re-proposed [1], so if someone is already working on those, I'm
volunteering to help with it with my both ironic and heat hats on :)

[0]
https://review.openstack.org/#/q/project:openstack/heat+topic:bp/ironic-resource
[1] https://review.openstack.org/#/c/393108/

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] New resource implementation workflow

2017-04-11 Thread Pavlo Shchelokovskyy
Hi Norbert,

my biggest concern with the workflow you've shown is that in the meantime
it would be possible to create undeletable stacks / stacks that leave
resources behind after being deleted. As the biggest challenge is usually
in updates (if it is not UpdateReplace) I'd suggest implementing create and
delete together. To ease development you could start with only basic
properties for the resource if it is possible to figure out their set (with
some sane defaults if those are absent in API) and add more tunable
resource properties later.

I also remember that Heat has smth like 'hidden' in resource plugin
declaration. Usually it is used to hide deprecated resource types so that
new stacks with those can not be created but old ones can be at least
deleted. May be you could use that flag while developing until you think
that resource is already usable, although it might complicate your own
testing of those resources.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés <norbert.e.il...@ericsson.com
> wrote:

> Hi everyone,
>
> Me and two of my colleagues are working on adding Neutron Trunk support to
> Heat. One of us working on the resource implementation, one on the unit
> tests and one on the functional tests. But all of these looks like a big
> chunk of work so I'm wondering how can we divide them into smaller parts.
>
> One idea is to split them along life cycle methods (create, update,
> delete, etc.), for example:
>  * Implement the resource creation + the relevant unit tests + the
> relevant functional tests, review and merge these
>  * implementing the delete operation + the relevant unit tests + the
> relevant functional tests, review and merge these
>  * move on to implementing the update operation + tests... and so on.
>
> Lastly, when the last part of the code and tests merged, we can document
> the new resource, create templates in the heat-templates etc.
>
> Is this workflow sounds feasible?
>
> I mostly concerned about the fact that there will be a time period when
> only a half-done feature merged into the Heat codebase, and I'm not sure if
> this is acceptable?
>
> Has anybody implemented a new resource with a team? I would love to hear
> some experiences about how others have organized this kind of work.
>
> Cheers,
> Norbert
>
> __
> OpenStack Development Mailing List (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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy
Clark,

thanks for reply.

On Mon, Apr 10, 2017 at 6:49 PM, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Mon, Apr 10, 2017, at 08:31 AM, Pavlo Shchelokovskyy wrote:
> > Hi infra team,
> >
> > on order to test a piece of functionality I am developing, during the
> > devstack plugin run I need to create an extra user with password-less
> > sudo
> > permissions. As I am not sure of intricacies of our infra setup, I'd like
> > to clarify if it is acceptable.
> >
> > TL;DR
> > There is 'openstack/networking-generic-switch' project that mainly aims
> > to
> > provide a Neutron ML2 plugin suitable to manage cheap HW switches that
> > only
> > allow configuration over SSH. The problem with those is that these
> > switches
> > usually have limitations on the number of concurrent SSH sessions open on
> > the switch.
> >
> > In order to overcome this, I am attempting to introduce DLM to
> > networking-generic-switch to globally limit the number of active SSH
> > connections to a given switch across all threads of neutron-service on
> > all
> > hosts [0].
> >
> > To test this locally in my Xenial DevStack VM, I am creating and
> > configuring "ovsmanager" user with password-less sudo permissions (so it
> > is
> > able to manage OVS), limit the number of allowed sessions for that user
> > in
> > /etc/security/limits.d/ and configure networking-generic-switch to access
> > localhost via that user to simulate a switch with limited number
> > of allowed SSH sessions.
> >
> > My questions is is it ok if I replicate this logic in the devstack plugin
> > of networking-generic-switch to set up gate testing for this feature?
> > In the end it seems it boils down to whether infra re-uses VMs it creates
> > to run gate jobs for anything else and if such changes can affect those
> > re-using these VMs, but I might be missing something else.
> >
> > [0] https://review.openstack.org/#/c/452959/
>
> The test instances that run devstack are single use VMs that are not
> reused. Every job running on these instances starts with sudo access,
> but by default we remove sudo access for the stack user which is what
> the OpenStack services run as. We do this to force those services to use
> rootwrap (or its equivalent) and test that the rootwrap rules are
> functional.
>
> As long as you create your new user during the initial devstack run you
> shouldn't have any issues with this.
>
> It wasn't mentioned above, but I would run a separate sshd for this
> rather than modify the existing one as ssh is the control mechanism for
> the test jobs. Better to run a separate independent service that won't
> conflict with job control.
>
> Hope this helps,
> Clark
>
>
I'm not going to control the number of sessions via SSH itself and change
the /etc/ssh/sshd_config, instead I'm going to create a file
/etc/security/limits.d/ovsmanager.conf (this is the place on Ubuntu Xenial)
with

# 
ovsmanager -   maxlogins   2

AFAIU this should not interfere with any other users and the number of
sessions/connections they are allowed (I would even prepend "ngs_" to the
created user name so it is clear what created it).

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (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] [infra] is it ok to create extra users with sudo permissions during devstack run

2017-04-10 Thread Pavlo Shchelokovskyy
Hi infra team,

on order to test a piece of functionality I am developing, during the
devstack plugin run I need to create an extra user with password-less sudo
permissions. As I am not sure of intricacies of our infra setup, I'd like
to clarify if it is acceptable.

TL;DR
There is 'openstack/networking-generic-switch' project that mainly aims to
provide a Neutron ML2 plugin suitable to manage cheap HW switches that only
allow configuration over SSH. The problem with those is that these switches
usually have limitations on the number of concurrent SSH sessions open on
the switch.

In order to overcome this, I am attempting to introduce DLM to
networking-generic-switch to globally limit the number of active SSH
connections to a given switch across all threads of neutron-service on all
hosts [0].

To test this locally in my Xenial DevStack VM, I am creating and
configuring "ovsmanager" user with password-less sudo permissions (so it is
able to manage OVS), limit the number of allowed sessions for that user in
/etc/security/limits.d/ and configure networking-generic-switch to access
localhost via that user to simulate a switch with limited number
of allowed SSH sessions.

My questions is is it ok if I replicate this logic in the devstack plugin
of networking-generic-switch to set up gate testing for this feature?
In the end it seems it boils down to whether infra re-uses VMs it creates
to run gate jobs for anything else and if such changes can affect those
re-using these VMs, but I might be missing something else.

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

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] Translations removal

2017-03-22 Thread Pavlo Shchelokovskyy
HI all,

my 5 cents:

- option 1) is ugly due to code/string duplication;
- options 2) and 3) are not going to work for translators as others already
pointed;
- option 4) has a caveat that we should do it consistently - either
translate all or translate none, so there won't be a mess of log messages
written in different languages at seemingly random;
- option 5) from Lucas looks nice and easy, but I'm afraid we still have to
i18n the errors returned to end user in API responses.

So how about half-solution 6) - reorg our exception messages (at least
those returned from API) to always include some string that is i18n'ed in
the exception class declaration itself, but may have part of strings passed
in at instantiation, so nowhere the whole exception message is completely
passed in when instantiating the exception. Downside is that final
exception message may be returned in two languages (half i18n'ed, half
English).

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Mar 22, 2017 at 4:13 PM, Lucas Alvares Gomes <lucasago...@gmail.com>
wrote:

> Hi,
>
> >> Possible options to handle that:
> >>
> >> 1)  Duplicate messages:
> >>
> >> LOG.error(“”, {: })
> >>
> >> raise Exception(_(“”) % {: })
> >>
> >> 2)  Ignore this error
> >>
> >> 3)  Talk to hacking people about possible upgrade of this check
> >>
> >> 4)  Pass translated text to LOG in such cases
> >>
> >>
> >>
> >> I’d personally vote for 2. What are your thoughts?
> >
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
>
> +1
>
> Just throwing and idea here: Is not translating anything an option ?
>
> Personally I don't see much benefits in translating a software like
> Ironic, there are many "user facing" parts that will remain in
> english, e.g: The resource attributes name, node's states (powered
> off, powered on, deploying, deploy wait...), etc... So why bother ? I
> think it's fair to assume that people using Ironic directly (not via
> horizon for example) understands english. It's a lot of overhead to
> get it translated and there are very few people working on it for
> Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the
> costs of having duplicated strings all over in the code overweight the
> benefits.
>
> I did some translation of Ironic to Brazilian Portuguese in the past
> myself and it's really tough to keep up the pace, strings are added or
> changed very rapidly.
>
> So again, is:  "5) Not translate anything" an option here ?
>
> [0] https://translate.openstack.org/iteration/view/ironic/
> master?dswid=9016
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] New mascot design

2017-03-10 Thread Pavlo Shchelokovskyy
Hi Heidi,

imo this one is the best so far.

+1 I like it too.

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Fri, Mar 10, 2017 at 6:37 PM, Miles Gould <mgo...@redhat.com> wrote:

> On 10/03/17 16:28, Heidi Joy Tretheway wrote:
>
>> Hi Ironic team,
>> Here’s an update on your project logo. Our illustrator tried to be as
>> true as possible to your original, while ensuring it matched the line
>> weight, color palette and style of the rest. Thanks for your patience as
>> we worked on this! Feel free to direct feedback to me; we really want to
>> get this right for you.
>>
>
> I like it!
>
> Miles
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] Removal of the ipminative / pyghmi driver

2017-03-10 Thread Pavlo Shchelokovskyy
Hi all,

small note for future - we could re-evaluate possibility of testing this
driver on gates with VMs when qemu version with BMC support (plus
[python-]libvirt support for such functionality) is generally available in
distros.

In this case we could stop using virtualbmc and use qemu natively. Not sure
how valuable such testing would be, but it won't for sure be pyghmi talking
to pyghmi.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Mar 9, 2017 at 8:40 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 03/09/2017 07:19 PM, Jay Faulkner wrote:
>
>> Hi all,
>>
>> The ipminative driver Is currently an anomaly in ironic’s tree, despite
>> the driver being initially deprecated in Newton[1], and   our desire to
>> drop them reiterated on the mailing list in December[2], it was has not
>> been removed from the tree prior to the Ocata release.
>>
>> At the PTG the ironic team had a short discussion about the ipminative
>> (aka pyghmi) driver — the conclusion was that unless third party CI was run
>> against the driver, we would be forced to follow through on the deprecation
>> and remove it. Testing in upstream CI, against VirtualBMC, was mostly
>> rejected due to both the ipminative driver and virtualbmc using the same
>> python ipmi library (pyghmi), and therefore not being a valid test case.
>> Additionally, further adding urgency to the removal, several active ironic
>> contributors who have tested ipminative drivers in real-world environments
>> have reported them as unstable.
>>
>> The promise of a native python driver to talk to ipmi in ironic is great,
>> but without proper testing and stability, keeping it in-tree does more harm
>> to ironic users than good — in fact, there’s very little indication to a
>> deployer using ironic that the driver may not work stably.
>>
>> Therefore, I’m giving the mailing list a two week warning — unless
>> volunteers come willing to run third party CI against the ipminative
>> drivers in the next two weeks, I will be submitting a patch to remove them
>> entirely from the tree. The driver could then be moved into
>> ironic-staging-drivers by any interested contributors.
>>
>
> Thanks for writing it Jay. Indeed, we spent too much time waiting for
> someone to overtake this driver. I'm very much in favor of removing it, if
> somebody does not step up *right now*.
>
>
>
>> -
>> Jay Faulkner
>> OSIC
>>
>> Related-bug: https://bugs.launchpad.net/ironic/+bug/1671532
>>
>> [1] https://docs.openstack.org/releasenotes/ironic/newton.html
>> [2] http://lists.openstack.org/pipermail/openstack-dev/2016-Dece
>> mber/108666.html
>> 
>> __
>> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] state of the stable/mitaka branches

2017-03-02 Thread Pavlo Shchelokovskyy
Hi Dmitry,

> I'm not sure why removing of *_ssh drivers from master should
> necessary break stable/mitaka, where these drivers are present. Could
> you elaborate?

My main concern is the following: both project-config and devstack-gate are
branch-less. When removing the *_ssh drivers from tree, we have to remove
them from 'enabled_drivers' list in ironic.conf too (so that conductor
would not fail to start). Most our jobs are not setting enabled_drivers
themselves, but use whatever devstack-gate is setting. Currently it enables
either pxe_ssh+pxe_ipmitool, or agent_ssh+agent_ipmitool (depending on
deploy driver starting with 'agent' or not). If we drop *_ssh from
enabled_drivers in devstack-gate, then the jobs that actually use *_ssh
will fail instead.

AFAIU this affects only mitaka branch, so a possible way of moving forward
is actually let it EOL and then continue with *_ssh drivers removal.

I'm also kind of wondering what the grenade job in stable/newton will test
after mitaka EOL? upgrade from mitaka-eol tag to stable/newton branch? Then
even that might be affected if devstack-gate + project config will not be
able to set *_ssh in enabled drivers while grenade will try to use them.

On Thu, Mar 2, 2017 at 12:39 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 03/01/2017 08:19 PM, Jay Faulkner wrote:
>
>>
>> On Mar 1, 2017, at 11:15 AM, Pavlo Shchelokovskyy <
>>> pshchelokovs...@mirantis.com> wrote:
>>>
>>> Greetings ironicers,
>>>
>>> I'd like to discuss the state of the gates in ironic and other related
>>> projects for stable/mitaka branch.
>>>
>>> Today while making some test patches to old branches I discovered the
>>> following problems:
>>>
>>> python-ironicclient/stable/mitaka
>>> All unit-test-like jobs are broken due to not handling upper
>>> constraints. Because of it a newer than actually supported
>>> python-openstackclient is installed, which already lacks some modules
>>> python-ironicclient tries to import (these were moved to osc-lib).
>>> I've proposed a patch that copies current way of dealing with upper
>>> constraints in tox envs [0], gates are passing.
>>>
>>> ironic/stable/mitaka
>>> While not actually being gated on, using virtualbmc+ipmitool drivers is
>>> broken. The reason is again related to upper constraints as what happens is
>>> old enough version of pyghmi (from mitaka upper constraints) is installed
>>> with most recent virtualbmc (not in upper constraints), and those versions
>>> are incompatible.
>>> This highlights a question whether we should propose virtualbmc to upper
>>> constraints too to avoid such problems in the future.
>>> Meanwhile a quick fix would be to hard-code the supported virtualbmc
>>> version in the ironic's devstack plugin for mitaka release.
>>> Although not strictly supported for Mitaka release, I'd like that
>>> functionality to be working on stable/mitaka gates to test for upcoming
>>> removal of *_ssh drivers.
>>>
>>> I did not test other projects yet.
>>>
>>>
>> I can attest jobs are broken for stable/mitaka on ironic-lib as well —
>> our jobs build docs unconditionally, and ironic-lib had no docs in Mitaka.
>>
>
> Oh, fun.
>
> Well, the docs job is easy to exclude. But we seem to have
> virtualbmc-based jobs there. As I already wrote in another message, I'm not
> even sure they're supposed to work..


Yes, the ironic-lib:mitaka is kind of completely broken currently :( There
are several pieces that need to be fixed to get it back to healthy state
(even if only to leave it healthy for EOL). Luckily (or not?), most of the
fixes go thru other projects, so it is doable without one giant squashed
commit:

- docs job - need to be disabled for ironic-lib/mitaka in project-config

- gate-tempest-dsvm-ironic-lib-* - two of them are gating, so they must be
fixed. they are affected by that very virtualbmc+pyghmi incompatibility.
The fix would be to
1) introduce virtualbmc to requirements:master and cherry-pick that (with
version changes) all the way down to mitaka. patch to master is already
here [0]
2) make a patch to ironic's devstack plugin master to install virtualbmc
minding u-c (3 chars fix :) ) and cherry-pick that all the way down to
mitaka as well (test patch to mitaka is here [1], will have to be replaced
with proper cherry-pick from master)
This is already kind of tested with this layered depends-on patch [2] -
those ipmitool jobs are passing

- ironic-lib-coverage-* - in ironic-lib:mitaka tox jobs also do not use
u-c, but it seems it is not the reason of failures here, as the current
"tox -recover" does not pass neither with u-c fr

Re: [openstack-dev] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octa

2017-03-02 Thread Pavlo Shchelokovskyy
Hi Andrea,

I am not sure why the new tempest.scenario.manager has to be developed that
way. May I humbly suggest another path? Roughly goes like:

1) Rename the present class to "OldScenarioTest", set the original name to
point to it (ScenarioTest=OldScenarioTest) (in a single commit)

2) Create a new class NewScenarioTest (initially a copy of the old one?),
development/refactoring/rewrite happens there, do not merge any new
features in OldScenarioTest

3) add a tempest config option "USE_NEW_SCENARIO_MANAGER", False by default

4) conditionally on the value of USE_NEW_SCENARIO_MANAGER set the
ScenarioTest to point to OldScenarioTest or NewScenarioTest

5) add a gate job(s) to tempest that forces USE_NEW_SCENARIO_MANAGER to
True to test the new code, non-voting from the start, gate on it later

This way the projects using tempest plugins and other tempest consumers
will not be affected at all. Later each project on its jobs using tempest
can try to enforce USE_NEW_SCENARIO_MANAGER to True if wishing to test the
new one or switch to it when it is ready. Eventually when new one is
stable, the config option might be removed and new class renamed to the
name of the original class.

The only downside of such approach I see might be a small? explosion of
number of jobs in the tempest project (running on both new and old
manager), but I'd think at least in the beginning of this refactoring
effort the tempest team would like to have the number of jobs testing the
new manager limited any way.

I might be completely wrong with this advice, as I presume tempest team
have put a lot of thinking into this problem already. But still, could you
consider such approach?

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Mon, Feb 27, 2017 at 1:34 PM, Andrea Frittoli <andrea.fritt...@gmail.com>
wrote:

> Hello folks,
>
> TL;DR: if today you import manager,py from tempest.scenario please
> maintain a copy of [0] in tree until further notice.
>
> Full message:
> --
>
> One of the priorities for the QA team in the Pike cycle is to refactor
> scenario tests to a sane code base [1].
>
> As they are now, changes to scenario tests are difficult to develop and
> review, and failures in those tests are hard to debug, which is in many
> directions far away from where we need to be.
>
> The issue we face is that, even though tempest.scenario.manager is not
> advertised as a stable interface in Tempest, many project use it today for
> convenience in writing their own tests. We don't know about dependencies
> outside of the OpenStack ecosystem, but we want to try to make this
> refactor a smooth experience for our uses in OpenStack, and avoid painful
> gate breakages as much as possible.
>
> The process we're proposing is as follows:
> - hold a copy of [0] in tree - in most cases you won't even have to change
> your imports as a lot of projects use tempest/scenario in their code base.
> You may decide to include the bare minimum you need from that module
> instead of all of it. It's a bit more work to make the patch, but less
> un-used code lying around afterwards.
> - the QA team will refactor scenario tests, and make more interfaces
> stable (test.py, credential providers). We won't advertise every single
> change in this process, only when we start and once we're done.
> - you may decide to discard your local copy of manager.py and consume
> Tempest stable interfaces directly. We will help with any question you may
> have on the process and on Tempest interfaces.
>
> Repositories affected by the refactor are (based on [2]):
>
> blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,
> manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,
> neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-
> service,tempest-horizon,vmware-nsx,watcher
>
> If we don't hear from a team at all in the next two weeks, we will assume
> that the corresponding Tempest plugin / bunch of tests is not in use
> anymore, and ignore it. If you use tempest.scenario.manager.py today and
> your repo is not on the list, please let us know!
>
> I'm happy to propose an initial patch for any team that may require it -
> just ping me on IRC (andreaf).
> I won't have the bandwidth myself to babysit each patch through review and
> gate though.
>
> Thank you for your cooperation and patience!
>
> Andrea
>
> [0] http://git.openstack.org/cgit/openstack/tempest/tree/
> tempest/scenario/manager.py
> [1] https://etherpad.openstack.org/p/pike-qa-priorities
> [2] https://github.com/andreafrittoli/tempest_stable_
> interfaces/blob/master/data/get_deps.sh
>
> ___

[openstack-dev] [ironic] state of the stable/mitaka branches

2017-03-01 Thread Pavlo Shchelokovskyy
Greetings ironicers,

I'd like to discuss the state of the gates in ironic and other related
projects for stable/mitaka branch.

Today while making some test patches to old branches I discovered the
following problems:

python-ironicclient/stable/mitaka
All unit-test-like jobs are broken due to not handling upper constraints.
Because of it a newer than actually supported python-openstackclient is
installed, which already lacks some modules python-ironicclient tries to
import (these were moved to osc-lib).
I've proposed a patch that copies current way of dealing with upper
constraints in tox envs [0], gates are passing.

ironic/stable/mitaka
While not actually being gated on, using virtualbmc+ipmitool drivers is
broken. The reason is again related to upper constraints as what happens is
old enough version of pyghmi (from mitaka upper constraints) is installed
with most recent virtualbmc (not in upper constraints), and those versions
are incompatible.
This highlights a question whether we should propose virtualbmc to upper
constraints too to avoid such problems in the future.
Meanwhile a quick fix would be to hard-code the supported virtualbmc
version in the ironic's devstack plugin for mitaka release.
Although not strictly supported for Mitaka release, I'd like that
functionality to be working on stable/mitaka gates to test for upcoming
removal of *_ssh drivers.

I did not test other projects yet.

With all the above, the question is should we really fix the gates for the
mitaka branch now? According to OpenStack release page [1] the Mitaka
release will reach end-of-life on April 10, 2017.

[0] https://review.openstack.org/#/c/439742/
[1] https://releases.openstack.org/#release-series

Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] gate jobs using or enabling *_ssh drivers

2017-03-01 Thread Pavlo Shchelokovskyy
Hi ironicers,

at the PTG we decided to remove the unsupported SSH drivers from ironic
code tree during Pike release. Below is an update on which CI jobs for
projects under Baremetal program governance do still use them and thus are
blocking us from removing these drivers.

tl;dr: 2 tempest-dsvm jobs + 2 grenade-dsvm jobs + 3 in bifrost + most just
enable some *_ssh driver

First of all, most of the gates running ironic service as part of DevStack
are at least enabling one of {agent,pxe}_ssh drivers due to current
defaults in openstack-infra/devstack-gate [0-1]. As our job builders in
project-config mostly do not set enabled drivers themselves (only
experimental standalone job does it), this must be fixed last (after no job
running thru devstack-gate is using *_ssh drivers is left) before removing
*_ssh drivers from ironic code.

Following is the per-project list of jobs that still deploy nodes via *_ssh
drivers and thus also rely on them being in enabled_drivers

ironic:
- gate-tempest-dsvm-ironic-multitenant-network-ubuntu-xenial
- gate-grenade-dsvm-ironic-ubuntu-xenial

ironic-inspector:
- gate-grenade-dsvm-ironic-inspector-ubuntu-xenial

python-ironicclient:
- gate-tempest-dsvm-python-ironicclient-src-ubuntu-xenial

I have assigned myself to the rfe bug [2] and will start putting up test
patches to ironic and devstack-gate to test the deploy driver change, and
then propose changes to devstack-gate/project-config when sure nothing gets
broken.

The whole switch might be a bit complicated due to project-config and
devstack-gate being branch-less, and we still have mitaka branch around,
which, while seeming to support testing with ipmitool+virtualbmc, has no
solid record of running such tests. However, Mitaka release is EOLed in
just one month [3], so even if there are problems, we could merge the
relevant changes after this date.

Additionally, while not depending on devstack/devstack-gate, bifrost
defaults to *_ssh drivers when in testing mode, and its functional jobs are
thus using *_ssh drivers. The series of patches to switch away from them is
on review [4] and the last one already passes relevant CI jobs.

[0] https://github.com/openstack-infra/devstack-gate/blob/
4eade8fab85dca475b0dd8d54d98649e6cdfcd57/devstack-vm-gate.sh#L416-L422
[1] https://github.com/openstack-infra/devstack-gate/blob/
24a6ed073b547fbbd484157e544b4bc10dda8880/devstack-vm-gate-wrap.sh#L235
[2] https://bugs.launchpad.net/ironic/+bug/1570301
[3] https://releases.openstack.org/#release-series
[4] https://review.openstack.org/#/q/status:open+project:
openstack/bifrost+branch:master+topic:bug/1659876

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] New mascot design

2017-02-01 Thread Pavlo Shchelokovskyy
Hi,

+1 to Jay, the 3.0 version looks ok - it is friendly and rocking :)

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Feb 1, 2017 at 10:38 PM, Jay Faulkner <j...@jvf.cc> wrote:

> Of the options presented, I think the new 3.0 version most brings to mind
> a rocking bear.  It’s still tough to be OK with a new logo, given that
> pixie boots is beloved by our team partially because Lucas took the time to
> make us one — but it seems like not accepting a new logo created by the
> foundation would lead to Ironic getting less marketing and resources, so
> I’m not keen to go down that path. With that in mind, I’m +1 to version 3.0
> of the bear.
>
> -Jay
>
> > On Feb 1, 2017, at 12:05 PM, Heidi Joy Tretheway <heidi...@openstack.org>
> wrote:
> >
> > Hi Ironic team,
> >
> > I’m sorry our second proposal again missed the mark. It wasn’t the
> illustrator’s intention to mimic the Bear Surprise painting that gained
> popularity in Russia as a meme. Our illustrator created a face-forward bear
> with paws shaped as if it had index and ring “fingers" down, like a hand
> gesture popular at a heavy metal concert. It was not meant to mimic the
> painting of a side-facing bear with paws and all “fingers" up to surprise.
> That said, once it’s seen, it’s tough to expect the community to un-see it,
> so we’ll take another approach.
> >
> > The issue with your old mascot is twofold: it doesn’t fit the
> illustration style for the entire suite of 60+ mascots, and it contains a
> human-made element (drumsticks). As part of our overall guidelines,
> human-made objects and symbols were not allowed, and we applied these
> standards to all projects.
> >
> > Your team told us you want a heavy metal bear, so we used the Kiss
> band-style makeup and the hand gesture to suggest metal without using an
> instrument or symbol. We tried to mimic your original logo’s expression.
> After releasing v1, we listened to your team’s comment that the first
> version was too angry looking, so you’ll see a range of expressions from
> fierce to neutral to happy.
> >
> >
> > 
> > I’d love to find a compromise with your team that will be in keeping
> with the style of the project logo suite. I’ll watch your ML for additional
> concerns about this proposed v3:
> > 
> >
> > Our illustration team’s next step is to parse the community feedback
> from the Ironic team (note that there is a substantial amount of
> conflicting feedback from 21 members of your team) and determine if we have
> majority support for a single direction.
> >
> > While new project logos are optional, virtually every project asked be
> represented in our family of logos. Only logos in this new style will be
> used on the project navigator and in other promotional ways.
> >
> > Feel free to join me for a quick chat tomorrow at 9:30 a.m. Pacific:
> > Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/5038169769
> > Or iPhone one-tap (US Toll): +16465588656,5038169769# or +14086380968,
> 5038169769#
> > Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US
> Toll)
> > Meeting ID: 503 816 9769
> > International numbers available: https://zoom.us/zoomconference?m=
> E5Gcj6WHnrCsWmjQRQr7KFsXkP9nAIaP
> >
> >
> >
> >
> >
> > Heidi Joy Tretheway
> > Senior Marketing Manager, OpenStack Foundation
> > 503 816 9769 | Skype: heidi.tretheway
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (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] [ironic] New mascot design

2017-01-31 Thread Pavlo Shchelokovskyy
Hi all,

this new logo actually reminds me of a wide-spread Russian meme

(Warning, might be considered NSFW)

http://knowyourmeme.com/memes/preved-medved-%D0%BF%D1%80%D0%B5%D0%B2%D0%B5%D0%B4-%D0%BC%D0%B5%D0%B4%D0%B2%D0%B5%D0%B4

Not the best connotation to my taste :-/

So yeah, even the previous design was better :(

+1 to Lucas.

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Feb 1, 2017 at 3:28 AM, <arkady.kanev...@dell.com> wrote:

> I think Russian already owns the bear.
>
>
>
> *From:* Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> *Sent:* Tuesday, January 31, 2017 2:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [ironic] New mascot design
>
>
>
> Hey ironic-ers,
>
> The foundation has passed along a new version of our mascot (attached) to
> us, and would like your feedback on it.
>
> They're hoping to have all mascot-related things ready in time for the
> PTG, so please do send your thoughts quickly, if you have them. :)
>
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] User survey question

2017-01-04 Thread Pavlo Shchelokovskyy
Hi,

from my part, if it would be appropriate, I'd like to use this opportunity
to estimate the iPXE adoption.

So the question targeting those USING and TESTING ironic would be:

- does the hardware you are managing with ironic support iPXE?
- do you use ironic with iPXE enabled? ("[pxe]ipxe_enabled = True" in
ironic.conf)

Another question would be to estimate the base of users that use
iscsi_deploy feature and also the vendor-specific drivers. So questions for
those USING and TESTING ironic would be:

- do you rely on iscsi-based deploy method or agent-based one?
- do you rely on common drivers like agent_ipmotool or pxe_ipmitool, or use
vendor-specific drivers like ilo_*, drac_* etc? if using vendor specific
drivers, what features of those are the reason for such choice?

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Jan 4, 2017 at 2:07 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> Hey all,
>
> We have an opportunity to ask a question on the upcoming User Survey,
> which will launch by February 1st. We can choose the audience to direct
> the question to, choosing from those USING, TESTING, or INTERESTED
> in Ironic (or some combination of these).
>
> The hope is that the Foundation folks can get us the raw answers before
> the PTG.
>
> So, Ironicers, what question would you like to ask users, and which group
> of
> users would you like to ask?
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

2017-01-03 Thread Pavlo Shchelokovskyy
>
>> 
>> __
>> 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
>

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] early prototype for HW VNC console interface

2016-12-26 Thread Pavlo Shchelokovskyy
Hi all,

While the work on generic graphical console [0] has somewhat stalled, I
went ahead and created a prototype of graphical console interface for some
specific Dell servers of interest for me (iDRAC8).

This of course is too far away from any production use, but still with a
couple of hacks I was able to get a graphical console in horizon Dashboard
connected and operating with a nova instance deployed onto ironic node :)

I've posted my experiences in my blog [1], hopefully you'll find it it
interesting or at least amusing. Questions and comments are very welcome.

[0] https://review.openstack.org/#/c/306074/ 
[1] *http://pshchelo.github.io/vnc-in-ironic.html
*

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


[openstack-dev] [ironic] iscsi-deploy vs agent-deploy comparison

2016-12-13 Thread Pavlo Shchelokovskyy
Hi all,

recent comments in some of my patches hinted me that I might be missing
some understanding of ironic workings, so I'd like to ask the following
question:

What features/possibilities the iscsi-deploy currently has that
agent-deploy has not (for example comparing pxe_ipmitool and agent_ipmitool
drivers)?

The only thing I'm aware of is that agent-deploy requires user images to be
accessible over clean no-auth HTTP from inside provisioning network (and in
integrated deployment that means swift as glance backend) while
iscsi-deploy does not need this (works with arbitrary glance backend / not
reachable from provisioning network).

Are there other advantages of iscsi-deploy compared to agent-deploy?

Best regards,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic][heat][mistral][magnum] Manage Ironic resource in Orchestration.

2016-12-12 Thread Pavlo Shchelokovskyy
ral will do.
>
> My preference would be Heat+Mistral as discussed above, but open to other
> ideas.
>
> I don't think conflating any of this with the Nova resource is a good idea
> - if we decide to implement the workflow directly in heat as an alternative
> to depending on Mistral it should probably be a new resource, perhaps
> implemented with a properties schema that makes overridding the normal nova
> server resource easy.
>
> I still think Heat+Mistral provides a cleaner solution tho, so I'd like to
> see that further explored before committing to an internal reimplementation
> of such workflow.
>
> Thanks for reviving this topic - I'm certainly interested in helping move
> this forward and/or discussing further.
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] unsupported drivers and their future

2016-12-08 Thread Pavlo Shchelokovskyy
Hi all,

On Thu, Dec 8, 2016 at 6:58 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Wed, Dec 7, 2016 at 1:52 PM, Pavlo Shchelokovskyy <
> pshchelokovs...@mirantis.com> wrote:
>
>> HI all,
>>
>> we (ironic community) some time ago decided [0] to require third-party CI
>> for any driver that is present in the main ironic code tree. I'd like to
>> discuss the state of currently unsupported drivers and how to proceed with
>> them.
>>
>> Here is the current rundown, please correct me if I've got something
>> wrong:
>>
>> * AMT - already in ironic-staging-drivers repo, patch removing those from
>> ironic is on review [1]
>>
>
> Agree - as a note, those were deprecated September 16, so we need to wait
> for December 16 to land that.
>
> I've -2'd the patch, but reviews welcome so we can land that on the 16th.
>

Thanks for reminding about deprecation period. This also means that the
last patch for removal of deprecated agent vendor passthru is blocked until
Dec 16 too. I will rebase that chain again and change commit order so we
could in principle land the updates to iLO and OneView drivers without
being blocked for a week.


>
>> * iBoot - already in ironic-staging-drivers repo, patch removing those
>> from ironic is on review [1]
>>
>
> Ditto.
>
>
>> * WakeOnLan - already in ironic-staging-drivers repo, patch removing
>> those from ironic is on review [1]
>>
>
> Ditto.
>
>
>> * IPMINative/Pyghmi - community driver, AFAIU community still considers
>> those as a viable alternative for the future and is constantly
>> re-evaluating maturity of pyghmi IPMI implementation, so these are to stay
>> for now
>>
>
> Well, we deprecated these, unless someone gets CI running for it, I plan
> to drop them.
>

Thanks for clarification.


>
>> * SSH - community driver, still used on several ironic gate jobs and in
>> jobs of other projects under Baremetal program (like bifrost). Besides
>> AFAIK quite a number of people use it for development. So it is to stay in
>> the tree for some more time too, at least until all upstream gate jobs are
>> moved to ipmitool-based drivers.
>>
>
> Like Dmitry said, we should move these jobs over ASAP and then drop this
> driver.
>

Basically those are grenade job, couple of jobs in ironicclient and IPA,
bifrost itself and many (all?) inspector-related ones.
We also have our devstack plugin defaulting to pxe_ssh for
IRONIC_DEPLOY_DRIVER, and have it too in the default for
IRONIC_ENABLED_DRIVERS. Only one job seems to use these defaults implicitly
though.

Complete list of jobs still using *_ssh drivers is below.

Ironic
- gate-grenade-dsvm-ironic (pxe_ssh)
- gate-tempest-dsvm-ironic-multitenant-network-ubuntu-xenial (agent_ssh)
- gate-tempest-dsvm-ironic-inspector-nv (agent_ssh)

The inspector one seems easy.
The multitenant one - the multinode job is also testing Ironic with network
isolation on and is using ipmitool driver, so we might consider just
dropping the single node multitenant job and make the multinode job voting.
If not, single node multitenant could also be easily fixed.
Most problems I would expect with grenade...

Other projects under ironic governance:

ironic-ui, molteniron, ironic-tempest-plugin,
ironic-inspector-tempest-plugin do not have any functional/integration jobs
(last two are empty actually :) )

ironic-lib, virtualbmc jobs are using only ipmitool drivers

python-ironicclient
- gate-tempest-dsvm-python-ironicclient-src (pxe_ssh)
- gate-ironicclient-dsvm-functional (pxe_ssh as implicit default of ironic
devstack plugin, also implicitly uses default enabled drivers)

ironic-python-agent
- gate-tempest-dsvm-ironic-inspector-src-ubuntu-xenial-nv (agent_ssh)

ironic-inspector
- gate-tempest-dsvm-ironic-inspector (agent_ssh)
- gate-grenade-dsvm-ironic-inspector (pxe_ssh)
- gate-tempest-dsvm-ironic-inspector-discovery (agent_ssh)

python-ironic-inspector-client
- gate-tempest-dsvm-python-ironic-inspector-client-ubuntu-xenial (agent_ssh)

bifrost
uses *_ssh drivers when in testing mode. Switching to virtualbmc would
require some effort.


>
>> * SNMP - people are working to enable testing it in CI, patches are
>> landing, stays in tree
>>
>
> Agree.
>
>
>> * VirtualBox - community driver, for testing only, VirtualBox can be used
>> via SSH driver and I am not aware of any plans for (third-party) CI for it
>> (although it would in principle be possible even in upstream). Is anyone
>> actually using this driver?
>>
>
> Someone that no longer works on Ironic submitted this. It's for using
> VirtualBox on a Windows host where we don't have SSH (it uses VBox's web
> API). This is also deprecated and I plan to remove it.
>

[openstack-dev] [ironic] unsupported drivers and their future

2016-12-07 Thread Pavlo Shchelokovskyy
HI all,

we (ironic community) some time ago decided [0] to require third-party CI
for any driver that is present in the main ironic code tree. I'd like to
discuss the state of currently unsupported drivers and how to proceed with
them.

Here is the current rundown, please correct me if I've got something wrong:

* AMT - already in ironic-staging-drivers repo, patch removing those from
ironic is on review [1]
* iBoot - already in ironic-staging-drivers repo, patch removing those from
ironic is on review [1]
* WakeOnLan - already in ironic-staging-drivers repo, patch removing those
from ironic is on review [1]
* IPMINative/Pyghmi - community driver, AFAIU community still considers
those as a viable alternative for the future and is constantly
re-evaluating maturity of pyghmi IPMI implementation, so these are to stay
for now
* SSH - community driver, still used on several ironic gate jobs and in
jobs of other projects under Baremetal program (like bifrost). Besides
AFAIK quite a number of people use it for development. So it is to stay in
the tree for some more time too, at least until all upstream gate jobs are
moved to ipmitool-based drivers.
* SNMP - people are working to enable testing it in CI, patches are
landing, stays in tree
* VirtualBox - community driver, for testing only, VirtualBox can be used
via SSH driver and I am not aware of any plans for (third-party) CI for it
(although it would in principle be possible even in upstream). Is anyone
actually using this driver?
* MSFTOCS - vendor driver, I am not aware of any plans for third-party CI
* SeaMicro - vendor driver, I am not aware of any plans for third-party CI

Based on that I propose to remove VirtualBox, MSFTOCS and SeaMicro drivers
from ironic right away. If anybody is interested in supporting them they
would have to extract those drivers (together with unit tests and docs) to
separate repos or propose them to ironic-staging-drivers minding the
warning [2].

[0]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/third-party-ci.html
[1] https://review.openstack.org/#/c/397847
[2]
http://ironic-staging-drivers.readthedocs.io/en/latest/README.html#what-the-ironic-staging-drivers-is-not

Best regards,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] Removing agent vendor passthru and unsupported drivers

2016-11-14 Thread Pavlo Shchelokovskyy
Hi Ironicers,

currently I'm busy with removing the lookup/heartbeats "as vendor passthru"
from Ironic which we slated for removal in Ocata, and have the following
question.

Removing the old agent vendor passthru requires changes to some unsupported
drivers whose copies are already in ironic-staging-drivers. The drivers in
question are WoL, iBoot and especially AMT (which uses a custom
not-so-vendor passthru).

AFAIU according to our third-party drivers policy, those unsupported
drivers have to be removed from Ironic tree anyway (as there is no plan to
test them on third-party CI AFAIK) and this looks like a perfect time to do
it.

So ideally I'd like to fix those in ironic-staging-drivers and then remove
them from Ironic tree via a depends-on patch.

What do you think on such plan?

Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] matrix of deploy combinations tested on upstream gates

2016-11-02 Thread Pavlo Shchelokovskyy
Hi Ironicers,

to have better visibility of what is being tested on our gates, I've
started an etherpad that aims to describe what combination of settings /
deploy options is being tested by each currently running (voting and not)
check / gate job

https://etherpad.openstack.org/p/ironic-gate-jobs-described

The work is in progress, but please chime in and correct any mistake I'm
making :)

In the future this would better be published as wiki page or as part of dev
docs (etherpad formatting capabilities are not that great..).

Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic][docs] What is the policy for backporting docs changes to stable branches?

2016-10-05 Thread Pavlo Shchelokovskyy
Hi all,

lately I realized that docs for two of the features I was working on during
Newton cycle are absent from Ironic's new install guide [0]. This is my
fault, and I am sorry for missing that out. Currently I am working on
adding those pieces.

The two omissions I am worried about are:

- booting iPXE nodes directly from object storage [1] (already merged to
master)
- proper way of configuring auth info for service clients [2] (on review)

AFAIU the install guide is release-specific and the /newton/ version is
built and published from stable/newton branch. While not having the former
of two patches above in stable release docs is probably no big deal (new
feature), configuring service user auth as currently advised by Ironic's
Newton install guide will work but result in a deprecation warning log
message, which I would find strange having just set Ironic up the
recommended way.

Given the above, should those doc amendments be proposed as backports to
stable/newton once they are merged in master? What is the general policy
for backporting documentation amendments/fixes?

[0] http://docs.openstack.org/project-install-guide/baremetal/newton/
[1] https://review.openstack.org/#/c/379358/
[2] https://review.openstack.org/#/c/382358/

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] weekly subteam report

2016-09-13 Thread Pavlo Shchelokovskyy
Hi all,

On Mon, Sep 12, 2016 at 9:28 PM, Loo, Ruby <ruby@intel.com> wrote:

> Cross-project:
> ==
> - Infra insists on switching new jobs to Xenial
>

A small heads up. If we have any gate jobs that use PXE instead of iPXE,
those won't work on Xenial with current Ironic devstack plugin due to some
packaging changes made in Ubuntu since about 15.04.

Bug: https://bugs.launchpad.net/ironic/+bug/1611850
Fix on review: https://review.openstack.org/#/c/326024/

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [heat] resigning from heat-cores

2016-09-12 Thread Pavlo Shchelokovskyy
Hi Heaters,

with great regret I announce my resignation from the heat-core team.

About a year ago I was reassigned to another project, and despite my best
efforts I came to conclusion that unfortunately I can not keep up with
duties expected from Heat core team member in appropriate capacity.

I do still work on OpenStack, so I'm not leaving the community altogether,
and will be available in e.g. IRC. I also have some ideas left to implement
in Heat, but, given the great community we've built around the project, I
could surely make it as an ordinary contributor.

It was an honor to be a member of this team, I’ve learned a lot during this
time. Hope to see some of you in Barcelona :)

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user

2016-07-04 Thread Pavlo Shchelokovskyy
Hi Johannes,

this is still not too optimal, as AFAIK admin role is still global, so
admin in tenant also means admin of whole OpenStack, thus it still can
assign himself/whomever the 'service' role and get access to global stack
list.

Best solution would probably be to create a separate domain in Keystone,
and a service user in it, and check in policy json the actual
domain+tenant+some role or username in this tenant. This domain and tenant
are completely controlled by Magnum service then (creds are in the magnum
config) - all similar to how Heat is working.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Mon, Jul 4, 2016 at 12:43 PM, Johannes Grassler <jgrass...@suse.de>
wrote:

> Hello,
>
> Magnum has a periodic task that checks the state of the Heat stacks it
> creates
> for its bays. It does this across all users/tenants that have Magnum bays.
> Currently it uses a global stack-list operation to query these Heat stacks:
>
>
> https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83
>
> Now the Magnum service user does not normally have permission to perform
> this operation,
> hence the Magnum documentation currently suggests the following change to
> Heat's policy.json:
>
> | stacks:global_index: "role:admin",
>
> This is less than optimal since it allows any tenant's admin user to
> perform a
> global stack-list. Would it be an option to have something like this in
> Heat's
> default policy.json?
>
> | stacks:global_index: "role:service",
>
> That way the global stack-list would be restricted to service users and
> seting
> Magnum (or other services that use Heat internally) wouldn't need a change
> to
> Heat's policy.json.
>
> If that kind of approach is feasible I'd be happy to submit a change.
>
> Cheers,
>
> Johannes
>
> --
> Johannes Grassler, Cloud Developer
> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> Maxfeldstr. 5, 90409 Nürnberg, Germany
>
> __
> OpenStack Development Mailing List (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] [Heat][tripleo] Tripleo holding on to old, bad data

2016-06-28 Thread Pavlo Shchelokovskyy
Adam,

not only "available", Nova would also not schedule to Ironic nodes which
have maintenance==True regardless of their provisioning state.

Also, you might have orphaned Ironic nodes, when node is available, but
still has instance_uuid assigned without actual instance in Nova. These
AFAIK would also not be scheduled to. To fix it update the node resetting
this field

ironic node-update  remove instance_uuid

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, Jun 28, 2016 at 1:29 AM, Adam Young <ayo...@redhat.com> wrote:

> On 06/26/2016 07:00 PM, Steve Baker wrote:
>
>> Assuming the stack is deleted and nova is showing no servers, you likely
>> have ironic nodes which are not in a state which can be scheduled.
>>
>> Do an ironic node-list, you want Power State: Off, Provisioning State:
>> available, Maintenance: False
>>
>
> Yes, we have that.  First thing we checked.  I assume "available" is the
> most important part of that?
>
>
>
>>
>> On 25/06/16 09:27, Adam Young wrote:
>>
>>> A coworker and I have both had trouble recovering from failed overcloud
>>> deploys.  I've wiped out whatever data I can, but, even with nothing in the
>>> Heat Database, doing an
>>>
>>> openstack overcloud deploy
>>>
>>> seems to be looking for a specific Nova server by UUID:
>>>
>>>
>>> heat resource-show 93afc25e-1ab2-4773-9949-6906e2f7c115 0
>>>
>>> | resource_status_reason | ResourceInError:
>>> resources[0].resources.Controller: Went to status ERROR due
>>> t│·
>>> o "Message: No valid host was found. There are not enough hosts
>>> available., Code: 500" |
>>> │·
>>> | resource_type  | OS::TripleO::Controller
>>>
>>>
>>> Inside the Nova log I see:
>>>
>>>
>>> 2016-06-24 21:05:06.973 15551 DEBUG nova.api.openstack.wsgi
>>> [req-c8a5179c-2adf-45a6-b186-7d7b29cd8f39
>>> bcd│·fefb36f3ca9a8f3cfa445ab40
>>> ec662f250a85453cb40054f3aff49b58 - - -] Returning 404 to user: Instance
>>> 8f9│·0c961-4609-4c9b-9d62-360a40f88eed
>>> could not be found. __call__
>>> /usr/lib/python2.7/site-packages/nova/api/│·
>>> openstack/wsgi.py:1070
>>>
>>>
>>> How can I get the undercloud back to a clean state?
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] moving ansible-deploy driver patches to ironic-staging-drivers

2016-06-06 Thread Pavlo Shchelokovskyy
HI All,

As you might have noticed, lately we (mostly myself and Yuri) were working
on an experimental deployment driver that utilizes Ansible to provision the
node (spec proposed at [0]). We started the work in common Ironic’s Gerrit
project and lately realized that those patches put a lot of unneeded strain
on to the OpenStack CI. There are already about 10 patches refining the
implementation [1]. Each new patch/change-set/rebase triggers a lot of CI
jobs (most are quite heavy ones) that do not test our implementation at all.

We decided to move the development to ironic-staging-drivers, where current
PoC implementation belongs better. Ironic-staging-drivers project has much
less default CI jobs, and we hope there we’ll have better chances to
iterate faster without stomping on Ironic’s CI. Ironic-staging-drivers repo
also looks like a good place to put the corresponding bootstrap image
building code we developed along with the driver implementation.

I have proposed a single commit capturing the current state of our
implementation to Ironic-staging-drivers at [2]. We kindly ask
ironic-staging-drivers project core team to bear with us as we move
forward, and hope for their support. When the driver’s value is proven it
should be re-proposed to the main tree.

For those who expressed interest the code is and will be easily accessible
in the new place.

[0] https://review.openstack.org/#/c/241946
[1] https://review.openstack.org/#/q/topic:bug/1526308
[2] https://review.openstack.org/325974

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] third party CI systems - vendor requirement milestones status

2016-05-26 Thread Pavlo Shchelokovskyy
Hi,

on a side-note concerning editing the Wiki, apparently registration of new
accounts on OpenStack Wiki is disabled (closed some time ago due to bot
spam), so if you do not have an account already, you won't be able to edit
the page. The solution is only to ping people with valid accounts and ask
them to make the changes for you.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, May 25, 2016 at 7:56 PM, Kurt Taylor <kurt.r.tay...@gmail.com>
wrote:

> We are in the final stretch for requiring CI testing for ironic drivers. I
> have organized the CI teams that I know about and their current status into
> the following wiki page:
>
> https://wiki.openstack.org/wiki/Ironic/Drivers#3rd_Party_CI_required_implementation_status
>
> I have already heard from a few folks with edits, but please review this
> info and let me know if you have any changes. You can make needed changes
> yourself, but let me know so I can keep track.
>
> Thanks!
> Kurt Taylor (krtaylor)
>
> __
> OpenStack Development Mailing List (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][ansible][ironic] Reusing Ansible code in OpenStack projects

2016-05-25 Thread Pavlo Shchelokovskyy
Hi All,

I had the same question in "legal-discuss" ML and would like to summarize
the outcome to benefit all.

It appears that we are in green in regards of the subject in question:

- from the driver itself we are launching "ansible-playbook" as a subprocess
- our custom Ansible callback plugin for logging is implemented w/o
importing any Ansible code (API is pretty simple and straightforward)
- Ansible's module_utils is licensed under *BSD* (2 clause) [0] which
allows us to use it in our custom modules licensed under Apache-2 (thanks
to Clint Byrum for pointing that out).

If you are interested, you can find the code under this Gerrit topic [1].
Any comments or suggestions are as always very welcome.

[0]
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py#L1-L27
[1] https://review.openstack.org/#/q/topic:bug/1526308

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, May 19, 2016 at 8:28 PM, Clint Byrum <cl...@fewbar.com> wrote:

> Excerpts from Pavlo Shchelokovskyy's message of 2016-05-19 15:28:03 +0300:
> > Hi all,
> >
> > I have a question re FOSS licenses interplay. I am pretty sure that
> > OpenStack community (e.g. openstack-ansible) has already faced such
> > questions and I would really appreciate any advice.
> >
> > We are developing a new ansible-based deployment driver for Ironic [0]
> and
> > would like to use some parts of ansible-lib Python API to avoid
> boilerplate
> > code in custom Ansible modules and callbacks we are writing, and in the
> > future probably use Ansible Python API to launch playbooks themselves.
> >
> > The problem is Ansible and ansible-lib in particular are licensed under
> GPL
> > v3 [1] "or later" [2]. According to [3] Apache 2.0 license is only one
> way
> > compatible with GPL v3 (GPL v3-licensed code can include Apache
> > 2.0-licensed code, but not vice versa).
> >
> > I am by far not a legal expert, so my questions are:
> >
> > Does it mean that the moment I do "from ansible import ..." in my Python
> > code, which AFAIU means I am "linking" to it, I am required to use a
> > GPLv3-compliant license for my code too (in particular not Apache 2.0)?
> > What problems might that imply in respect with including such code in an
> > OpenStack project (e.g. submitting it to Ironic repo) and distributing
> the
> > project?
>
> Yes that's what it means. You can write modules in any license you want
> because AnsibleModule is BSD 2-clause, but plugins must be GPLv3.
>
> > If there are indeed problems with that, would it be safer to keep the
> code
> > in a separate project and also distribute it separately?
> > Even when distributed separately, will merely using (dynamically
> importing
> > at run-time) a GPLv3-licensed driver from ApacheV2-licensed Ironic
> > constitute any license violation?
> >
>
> I think your options are to make it function without the plugins, and
> distribute just them separately (so a bare bones version comes with
> Ironic, but it works better w/ the GPLv3 plugins), or just distribute
> the whole thing separately.
>
> Long term, you might approach Ansible about possibly making their plugin
> interface LGPL so that people can write non-GPL plugins. But, it may be
> part of a broader strategy to ensure that contribution happens in the
> open. As an OSS hippie, I applaud them for choosing a strong copyleft
> license. :)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tc][ansible][ironic] Reusing Ansible code in OpenStack projects

2016-05-19 Thread Pavlo Shchelokovskyy
Hi all,

I have a question re FOSS licenses interplay. I am pretty sure that
OpenStack community (e.g. openstack-ansible) has already faced such
questions and I would really appreciate any advice.

We are developing a new ansible-based deployment driver for Ironic [0] and
would like to use some parts of ansible-lib Python API to avoid boilerplate
code in custom Ansible modules and callbacks we are writing, and in the
future probably use Ansible Python API to launch playbooks themselves.

The problem is Ansible and ansible-lib in particular are licensed under GPL
v3 [1] "or later" [2]. According to [3] Apache 2.0 license is only one way
compatible with GPL v3 (GPL v3-licensed code can include Apache
2.0-licensed code, but not vice versa).

I am by far not a legal expert, so my questions are:

Does it mean that the moment I do "from ansible import ..." in my Python
code, which AFAIU means I am "linking" to it, I am required to use a
GPLv3-compliant license for my code too (in particular not Apache 2.0)?
What problems might that imply in respect with including such code in an
OpenStack project (e.g. submitting it to Ironic repo) and distributing the
project?
If there are indeed problems with that, would it be safer to keep the code
in a separate project and also distribute it separately?
Even when distributed separately, will merely using (dynamically importing
at run-time) a GPLv3-licensed driver from ApacheV2-licensed Ironic
constitute any license violation?

Note that technically we could avoid re-using Ansible code for Ansible
modules and callbacks, just that it would be much-much less convenient.

[0] https://review.openstack.org/#/q/topic:bug/1526308
[1] https://github.com/ansible/ansible/blob/devel/COPYING
[2] https://github.com/ansible/ansible/blob/devel/lib/ansible/__init__.py#L8
[3] http://www.apache.org/licenses/GPL-compatibility.html

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] usage of ironic-lib

2016-05-16 Thread Pavlo Shchelokovskyy
Hi,

I'd like to point that ironic-lib is already used outside of Ironic tree -
for the third-party deployment drivers, e.g this fuel-agent based one [0].

[0]
https://github.com/openstack/fuel-agent/blob/master/contrib/ironic/ironic-fa-deploy/ironic_fa_deploy/modules/fuel_agent.py#L30

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Mon, May 16, 2016 at 6:14 PM, Lucas Alvares Gomes <lucasago...@gmail.com>
wrote:

> Hi,
>
> On Mon, May 16, 2016 at 3:56 PM, Sam Betts (sambetts)
> <sambe...@cisco.com> wrote:
> > I personally disagree with saying that if we wanted it make it usable by
> > projects other than ones in the Ironic umbrella it should go into oslo. I
> > think that non-ironic projects directly related to Ironic such as out of
> > tree drivers etc, should be able to utilise the code placed into
> > ironic-lib.
> >
> > Neutron are doing a very similar thing for all their drivers/extensions
> > they have broken out over the last 2 cycles,
> >
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-li
> > b.html.
> >
> > Making ironic-lib available to out of tree drivers etc also puts us into
> a
> > good position to begin the work to stabilise things like the driver API.
> > Neutron is making the rule that out of tree drivers shouldn¹t
> > inherit/import anything from the neutron core code base, only
> neutron-lib,
> > they are doing this to provide a stable interface that shouldn¹t be
> broken
> > by changes to neutron core. I think we could do the same, with in-tree
> > drivers dog-fooding the driver api we provide in ironic-lib.
> >
>
> I'm personally fine with that goal, if we as a community agree that in
> the soon future of ironic-lib should target a broader audience. The
> thing is that I don't think the lib was conceived with that in mind,
> we started small (baby-steps) sharing partitioning code from Ironic
> and Ironic-Python-Agent, now that it's done we can start working
> towards making it a more generic library.
>
> What I don't think we should do is say that the library's _right now_
> ready for it, the interfaces we have at the moment should not be
> considered stable, Ironic is very opinionated in many aspects
> (specially when partitioning the disk), there's no documentation, no
> release notes, etc...
>
> So, if agreed, let's do it, but let's do it properly.
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [magnum] Jinja2 for Heat template

2016-05-12 Thread Pavlo Shchelokovskyy
Hi,

not sure why 3 will bring chaos when implemented properly.

Can you abstract the "thing" (sorry, not quite familiar with Magnum) that
needs FP + FP itself into a custom resource/nested stack? Then you could
use single master template plus two environments (one with FP, one
without), and choose which one to use right where you have this logic split
in your code.

Option 2 is not so bad either IMO (AFAIK Trove was doing that at sometime,
not sure of current status), but the above would be nicer.

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, May 12, 2016 at 4:44 AM, Yuanying OTSUKA <yuany...@oeilvert.org>
wrote:

> Hi, all.
>
> Now, I’m trying to implement following bp.
> * https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips
>
> This bp requires to disable/enable “floating ip resource” in heat template
> dynamically.
> We have 3 options to implement this.
>
> 1. Use “conditions function”
> *
> https://blueprints.launchpad.net/heat/+spec/support-conditions-function
> 2. Dynamically generate heat template using Jinja2
> 3. Separate heat template to “kubecluster-with-floatingip.yaml” and
> “kubecluster-no-floatingip.yaml”
>
> Option 1 is easy to implement, but unfortunately this isn’t supported by
> Mitaka release.
> Option 2 needs a Jinja2 template support by Magnum.
> Option 3 will bring chaos.
>
> Please let me know what you think.
>
>
> Thanks
> -OTSUKA, Yuanying
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

2016-03-19 Thread Pavlo Shchelokovskyy
Hi Evgeniy,

On Fri, Mar 18, 2016 at 4:26 PM, Evgeniy L <e...@mirantis.com> wrote:
>
>
>> On the other side, there is ongoing work to have an ansible-based deploy
>> ramdisk in Ironic, maybe inspector could benefit from it too. Didn't think
>> about it yet, would be interesting to discuss on the summit.
>
>
> And here, I would appreciate if you have any link to get more context (I
> was able to find only playbook for Ironic installation).
> In Fuel we had an idea to implement tasks (abstract from specific
> deployment tool) to make configuration and get information about specific
> hardware.
>

Please see this patch https://review.openstack.org/#/c/238183/

This is a PoC of ansible-deploy driver for Ironic. We are in the process of
polishing/refactoring it to be more "ansibly" but the current prototype is
already working. We also plan to add an Inspect interface to it at some
point (or implement similar logic in Inspector if it would be needed) - it
should be as easy as running the like of "ansible -m setup" and parsing the
result.

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer

2016-03-19 Thread Pavlo Shchelokovskyy
+1 :)

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Mar 16, 2016 at 1:18 PM, Rabi Mishra <ramis...@redhat.com> wrote:

> > Hi Heaters,
> >
> > The Mitaka release is close to finish, so it's good time for reviewing
> > results of work.
> > One of this results is analyze contribution results for the last release
> > cycle.
> > According to the data [1] we have one good candidate for nomination to
> > core-review team:
> > Oleksii Chuprykov.
> > During this release he showed significant value of review metric.
> > His review were valuable and useful. Also He has enough level of
> > expertise in Heat code.
> > So I think he is worthy to join to core-reviewers team.
> >
> > I ask you to vote and decide his destiny.
> >  +1 - if you agree with his candidature
> >  -1  - if you disagree with his candidature
> >
> > [1] http://stackalytics.com/report/contribution/heat-group/120
>
> +1
>
> > --
> > Regards,
> > Sergey.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

2016-02-09 Thread Pavlo Shchelokovskyy
Hi,

Ironic also supports running it as standalone service, w/o
Keystone/Glance/Neutron/Nova etc integration, deploying images from HTTP
links. Could that be an option too?

BTW, there is already an official project under OpenStack Baremetal program
called Bifrost [0] that, quoting, "automates the task of deploying a base
image onto a set of known hardware using Ironic" by installing and
configuring Ironic in standalone mode.

[0] https://github.com/openstack/bifrost

Cheers,

On Tue, Feb 9, 2016 at 6:46 PM Dennis Dmitriev <ddmitr...@mirantis.com>
wrote:

> Hi all!
>
> To run system tests on CI on a daily basis using baremetal servers
> instead of VMs, Fuel admin node also should be bootstrapped.
>
> There is no a simple way to mount an ISO with Fuel as a CDROM or USB
> device to a baremetal server, so we choose the provisioning with PXE.
>
> It could be done in different ways:
>
> - Configure a libvirt bridge as dnsmasq/tftp server for admin/PXE network.
>   Benefits: no additional services to be configured.
>   Doubts: ISO should be mounted on the CI host (via fusefs?); a HTTP
> or NFS server for basic provisioning should be started in the admin/PXE
> network (on the CI host);
>
> - Start a VM that is connected to admin/PXE network, and configure
> dnsmasq/tftp there.
>   Benefits: no additional configuration on the CI host should be
> performed
>   Doubts: starting the PXE service becomes a little complicated
>
> - Use Ironic for manage baremetal nodes.
>   Benefits: good support for different hardware, support for
> provisioning from ISO 'out of the box'.
>   Doubts: support for Ironic cannot be implemented in short terms,
> and there should be performed additional investigations.
>
> My question is:  what other benefits or doubts I missed for first two
> ways? Is there other ways to provision baremetal with Fuel that can be
> automated in short terms?
>
> Thanks for any suggestions!
>
>
> --
> Regards,
> Dennis Dmitriev
> QA Engineer,
> Mirantis Inc. http://www.mirantis.com
> e-mail/jabber: dis.x...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Adding Ironic node kills devstack configuration

2016-02-03 Thread Pavlo Shchelokovskyy
Hi Pavel,

1. Unfortunately no, it is not possible to "update" a running devstack by
executing stack.sh, everything is created from scratch - e.g. empty DB is
created and all migration scripts are being run to ensure that the DB is in
the state required by the component.
2. Could you please post (to pastebin for example) your full local.conf? It
is not clear - are you trying to deploy a multi-node devstack with ironic
on one node, or just deploy an all-in-one with Ironic?

For example, here is my working devstack config (all-in-one with Ironic)
for master branch (reinstalled with it about two days ago). May be you find
some inspiration there :)

http://paste.openstack.org/show/485815/

Cheers,

On Tue, Feb 2, 2016 at 1:43 PM Pavel Fedin <p.fe...@samsung.com> wrote:

>  Hello again!
>
>  Now i am trying to add Ironic-driven compute note to existing devstack.
> Below is my local.conf for it. When i run stack.sh, it does
> something, then starts to reinitialize projects, users, groups, tenants,
> etc, effectively destroying my existing configuration.
> After that it dies with "cannot connect to... something", and my system is
> in non-working state, ready for reinstalling from
> scratch.
>  Actually, two questions:
> 1. Is it possible to tell stack.sh to keep old configuration? Rebuilding
> it every time is very tedious task.
> 2. Why does my compute node wipe everything out? Because i enable 'key'
> (keystone ?) service? But ironic forces me to do it ("key"
> service is required by ironic). So how do i install the thing correctly ?
>
> --- cut ---
> [[local|localrc]]
> HOST_IP=10.51.0.5
> SERVICE_HOST=10.51.0.4
> MYSQL_HOST=$SERVICE_HOST
> RABBIT_HOST=$SERVICE_HOST
> GLANCE_HOSTPORT=$SERVICE_HOST:9292
> ADMIN_PASSWORD=nfv
> DATABASE_PASSWORD=$ADMIN_PASSWORD
> RABBIT_PASSWORD=$ADMIN_PASSWORD
> SERVICE_PASSWORD=$ADMIN_PASSWORD
> DATABASE_TYPE=mysql
>
> # Services that a compute node runs
> ENABLED_SERVICES=n-cpu,rabbit,q-agt
>
> ## Open vSwitch provider networking options
> PHYSICAL_NETWORK=public
> OVS_PHYSICAL_BRIDGE=br-ex
> PUBLIC_INTERFACE=ens33
> Q_USE_PROVIDER_NETWORKING=True
> Q_L3_ENABLED=False
>
> # Enable Ironic plugin
> enable_plugin ironic git://git.openstack.org/openstack/ironic
>
> enable_service key
> enable_service glance
>
> # Enable Swift for agent_* drivers
> enable_service s-proxy
> enable_service s-object
> enable_service s-container
> enable_service s-account
>
> # Swift temp URL's are required for agent_* drivers.
> SWIFT_ENABLE_TEMPURLS=True
>
> # Create 3 virtual machines to pose as Ironic's baremetal nodes.
> IRONIC_VM_COUNT=2
> IRONIC_VM_SSH_PORT=22
> IRONIC_BAREMETAL_BASIC_OPS=True
> IRONIC_DEPLOY_DRIVER_ISCSI_WITH_IPA=True
>
> # Enable Ironic drivers.
> IRONIC_ENABLED_DRIVERS=fake,agent_ssh,agent_ipmitool,pxe_ssh,pxe_ipmitool
>
> # Change this to alter the default driver for nodes created by devstack.
> # This driver should be in the enabled list above.
> IRONIC_DEPLOY_DRIVER=pxe_ssh
>
> # The parameters below represent the minimum possible values to create
> # functional nodes.
> IRONIC_VM_SPECS_RAM=1024
> IRONIC_VM_SPECS_DISK=10
>
> # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition.
> IRONIC_VM_EPHEMERAL_DISK=0
>
> # To build your own IPA ramdisk from source, set this to True
> IRONIC_BUILD_DEPLOY_RAMDISK=False
>
> VIRT_DRIVER=ironic
> --- cut ---
>
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] Changing the default Server/SoftwareDeployment transports?

2016-01-22 Thread Pavlo Shchelokovskyy
+1 from me.

Somewhat related, would also be nice to switch the default for
"user_data_format" in OS::Nova::Server to RAW someday, as now it defaults
to HEAT_CFNTOOLS.

Best regards,

On Fri, Jan 22, 2016 at 11:38 AM Steven Hardy <sha...@redhat.com> wrote:

> Hi all,
>
> Wanted to start some discussion re $subject, context is:
>
> https://bugs.launchpad.net/heat/+bug/1507568
>
> Here, we're hitting issues because by default OS::Nova::Server uses the
> POLL_SERVER_CFN transport.  This made sense back when the
> SoftwareDeployment stuff was first implemented, but now we have other
> options, and there are some negative consequenses of choosing this default:
>
> 1. All heat deployments rely on the heat-api-cfn service by default, when
> this should really be a CFN compatibility layer.
>
> 2. Related to (1) we then require the keystone ec2tokens extension to be
> enabled
>
> 3. The cfn API action DescribeStackResource is used to retrieve server
> metadata.  Because that API has no action to only show the metadata, we get
> *all* data for that resource - and recent changes to show all attributes by
> default have made this *much* higher overhead than it once was.
>
> 4. As mentioned in the bug above, trying to resolve all the attributes
> doesn't work, because we're using stack domain user credentials to poll the
> CFN API, which don't have access to the related nova API for the server
> resource.  This can probably be fixed, but an alternative is just don't use
> this API.
>
> So, my question is, now that we have other (better) alternatives, can we
> consider switching the Server transport e.g to POLL_SERVER_HEAT by default,
> and relatedly the SoftwareDeployment signal_transport to HEAT_SIGNAL?
>
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-software_config_transport
>
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareDeployment-prop-signal_transport
>
> The advantage of this is it only requires the native heat-api service, when
> all other options require some other service/API to exist.
>
> Long term, we should probably consider deprecating the CFN transport for
> these (native) resources, but switching the default would be the first step
> - what do people think?
>
> Thanks,
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic][neutron][keystone] how to reauth the token

2015-12-16 Thread Pavlo Shchelokovskyy
Hi all,

I'd like to start discussion on how Ironic is using Neutron when Keystone
is involved.

Recently the patch [0] was merged in Ironic to fix a bug when the token
with which to create the neutronclient is expired. For that Ironic now
passes both username/password of its own service user and the token from
the request to the client. But that IMO is a wrong thing to do.

When token is given but happens to be expired, neutronclient will
reauthentificate [1] using provided credentials for service tenant and user
- but in fact the original token might have come from completely different
tenant. Thus the action neutron is performing might look for / change
resources in the service tenant instead of the tenant for which the
original token was issued.

Ironic by default is admin-only service, so the token that is accepted is
admin-scoped, but still it might be coming from different tenants (e.g.
service tenant or actual admin tenant, or some other tenant that admin is
logged into). And even in the case of admin-scoped token I'm not sure how
this will work for domain-separated tenants in Keystone v3. Does
admin-scoped neutronclient show all ports including those created by
tenants in domains other than the domain of admin tenant?

If I understand it right, the best we could do is use keystoneauth *token
auth plugins that can reauth when the token is about to expire (but of
course not when it is already expired).

[0] https://review.openstack.org/#/c/255885
[1]
https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-10 Thread Pavlo Shchelokovskyy
Hi all,
fix for tests in #2 is on review, https://review.openstack.org/#/c/255811/

cheers,

On Thu, Dec 10, 2015 at 1:15 PM Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 12/09/2015 10:58 PM, Jim Rollenhagen wrote:
> > On Fri, Dec 04, 2015 at 05:38:43PM +0100, Dmitry Tantsur wrote:
> >> Hi!
> >>
> >> As you all probably know, we've switched to reno for managing release
> notes.
> >> What it also means is that the release team has stopped managing
> milestones
> >> for us. We have to manually open/close milestones in launchpad, if we
> feel
> >> like. I'm a bit tired of doing it for inspector, so I'd prefer we stop
> it.
> >> If we need to track release-critical patches, we usually do it in
> etherpad
> >> anyway. We also have importance fields for bugs, which can be applied to
> >> both important bugs and important features.
> >>
> >> During a quick discussion on IRC Sam mentioned that neutron also dropped
> >> using blueprints for tracking features. They only use bugs with RFE tag
> and
> >> specs. It makes a lot of sense to me to do the same, if we stop tracking
> >> milestones.
> >>
> >> For both ironic and ironic-inspector I'd like to get your opinion on the
> >> following suggestions:
> >> 1. Stop tracking milestones in launchpad
> >> 2. Drop existing milestones to avoid confusion
> >> 3. Stop using blueprints and move all active blueprints to bugs with RFE
> >> tags; request a bug URL instead of a blueprint URL in specs.
> >>
> >> So in the end we'll end up with bugs for tracking user requests, specs
> for
> >> complex features and reno for tracking for went into a particular
> release.
> >>
> >> Important note: if you vote for keeping things for ironic-inspector, I
> may
> >> ask you to volunteer in helping with them ;)
> >
> > We decided we're going to try this in Monday's meeting, following
> > roughly the same process as Neutron:
> >
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> >
> > Note that as the goal here is to stop managing blueprints and milestones
> > in launchpad, a couple of things will differ from the neutron process:
> >
> > 1) A matching blueprint will not be created; the tracking will only be
> > done in the bug.
> >
> > 2) A milestone will not be immediately chosen for the feature
> > enhancement, as we won't track milestones on launchpad.
> >
> > Now, some requests for volunteers. We need:
> >
> > 1) Someone to document this process in our developer docs.
> >
> > 2) Someone to update the spec template to request a bug link, instead of
> > a blueprint link.
> >
> > 3) Someone to help move existing blueprints into RFEs.
> >
> > 4) Someone to point specs for incomplete work at the new RFE bugs,
> > instead of the existing blueprints.
> >
> > I can help with some or all of these, but hope to not do all the work
> > myself. :)
>
> I'll help you with as many things as my time allows. Documentation is my
> week point, so I'll start with #2.
>
> >
> > Thanks for proposing this, Dmitry!
> >
> > // jim
> >
> >
> __
> > OpenStack Development Mailing List (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
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-08 Thread Pavlo Shchelokovskyy
Hi Dmitry,

not true, the gate-ironic-specs-python27 requires that LP blueprint is
provided in a spec [0].

If we are to get away from LP blueprints and at least not register new
ones, this must be fixed. I'll test if the job accepts a link to LP RFE bug
instead of LP blueprint though.

[0]
http://logs.openstack.org/21/254421/1/check/gate-ironic-specs-python27/ab07a3f/console.html#_2015-12-07_22_52_07_669

On Tue, Dec 8, 2015 at 11:31 AM Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 12/08/2015 08:12 AM, Pavlo Shchelokovskyy wrote:
> > Hi all,
> >
> > I have a question regarding #1 (Stop using LP for blueprints):
> >
> > what should we now use instead of "specifies" and "implements" Gerrit
> > tags in commit messages? Simple Depends-On:  should
> > suffice but is not visually specific enough, and only replaces
> > "implements" tag.
>
> Closes-Bug for RFE bug, I guess. As a bonus point we'll distinguish
> between Partial-Bug and Closes-Bug.
>
> >
> > Also as a side note, some gate jobs for spec repos must be modified to
> > accommodate for the new process - they are still requiring a LP
> > blueprint reference to be specified in the body of a spec
> > (e.g. gate-ironic-specs-python27).
>
> No gate jobs require a blueprint reference anywhere (otherwise we would
> not be able to land bug fixes :)
>
> >
> > Best regards,
> >
> > On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur <dtant...@redhat.com
> > <mailto:dtant...@redhat.com>> wrote:
> >
> > On 12/07/2015 02:42 PM, Doug Hellmann wrote:
> >  > Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22
> +0100:
> >  >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> >  >>> Dmitry Tantsur wrote:
> >  >>>>
> >  >>>> 2015-12-04 18:26 GMT+01:00 Doug Hellmann
> > <d...@doughellmann.com <mailto:d...@doughellmann.com>
> >  >>>> <mailto:d...@doughellmann.com <mailto:d...@doughellmann.com
> >>>:
> >  >>>>
> >  >> 
> >  >>>>
> >  >>>>   Please don't delete anything older than Mitaka.
> >  >>>>
> >  >>>>
> >  >>>> Do you have any hints how to not confuse users in this case?
> >  >>>
> >  >>> I think what Doug means is you should not delete existing closed
> >  >>> milestones like:
> >  >>> https://launchpad.net/ironic/kilo/2015.1.0
> >  >>> or:
> >  >>> https://launchpad.net/ironic/liberty/4.2.0
> >  >>> since we use the Launchpad pages there as the list of features
> > and bugs
> >  >>> fixed for those pre-reno releases.
> >  >>>
> >  >>> Deleting those milestones would lose useful user information
> for no
> >  >>> gain: you can't use them anymore (since they are closed) so
> > they are
> >  >>> unlikely to confuse anyone ?
> >  >>>
> >  >>
> >  >> I wonder how to avoid giving impression that development has
> > stopped on
> >  >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released
> > tarball, as
> >  >> we no longer push tarballs to launchpad.
> >  >>
> >  >
> >  > I think the fact that we'll be announcing new releases by pointing
> >  > to other URLs (the releases site, for example) will help avoid
> that
> >  > sort of confusion. You could also add a note to the top of the
> > project
> >  > page on launchpad.
> >
> > +1
> >
> >  >
> >  > If, over time, we see a lot of folks actually confused about the
> >  > move we can figure out a way to migrate the old data elsewhere so
> >  > it can be deleted. But that's not going to happen this cycle, so
> >  > please leave it intact for now.
> >
> > Understood, thanks for explanation. So I withdraw suggestion #2.
> >
> >  >
> >  > Doug
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.o

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-07 Thread Pavlo Shchelokovskyy
Hi all,

I have a question regarding #1 (Stop using LP for blueprints):

what should we now use instead of "specifies" and "implements" Gerrit tags
in commit messages? Simple Depends-On:  should suffice but
is not visually specific enough, and only replaces "implements" tag.

Also as a side note, some gate jobs for spec repos must be modified to
accommodate for the new process - they are still requiring a LP blueprint
reference to be specified in the body of a spec
(e.g. gate-ironic-specs-python27).

Best regards,

On Mon, Dec 7, 2015 at 3:52 PM Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 12/07/2015 02:42 PM, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2015-12-07 13:18:22 +0100:
> >> On 12/07/2015 10:48 AM, Thierry Carrez wrote:
> >>> Dmitry Tantsur wrote:
> >>>>
> >>>> 2015-12-04 18:26 GMT+01:00 Doug Hellmann <d...@doughellmann.com
> >>>> <mailto:d...@doughellmann.com>>:
> >>>>
> >> 
> >>>>
> >>>>   Please don't delete anything older than Mitaka.
> >>>>
> >>>>
> >>>> Do you have any hints how to not confuse users in this case?
> >>>
> >>> I think what Doug means is you should not delete existing closed
> >>> milestones like:
> >>> https://launchpad.net/ironic/kilo/2015.1.0
> >>> or:
> >>> https://launchpad.net/ironic/liberty/4.2.0
> >>> since we use the Launchpad pages there as the list of features and bugs
> >>> fixed for those pre-reno releases.
> >>>
> >>> Deleting those milestones would lose useful user information for no
> >>> gain: you can't use them anymore (since they are closed) so they are
> >>> unlikely to confuse anyone ?
> >>>
> >>
> >> I wonder how to avoid giving impression that development has stopped on
> >> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
> >> we no longer push tarballs to launchpad.
> >>
> >
> > I think the fact that we'll be announcing new releases by pointing
> > to other URLs (the releases site, for example) will help avoid that
> > sort of confusion. You could also add a note to the top of the project
> > page on launchpad.
>
> +1
>
> >
> > If, over time, we see a lot of folks actually confused about the
> > move we can figure out a way to migrate the old data elsewhere so
> > it can be deleted. But that's not going to happen this cycle, so
> > please leave it intact for now.
>
> Understood, thanks for explanation. So I withdraw suggestion #2.
>
> >
> > 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
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] Rico Lin for heat-core

2015-12-07 Thread Pavlo Shchelokovskyy
+1 :)

On Mon, Dec 7, 2015, 17:12 Thomas Herve <the...@redhat.com> wrote:

> On Mon, Dec 7, 2015 at 1:39 PM, Sergey Kraynev <skray...@mirantis.com>
> wrote:
>
>>
>> Hi all.
>>
>> I'd like to nominate Rico Lin for heat-core. He did awesome job with
>> providing useful and valuable reviews. Also his contribution is really high
>> [1] .
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/60
>>
>> Heat core-team, please vote with:
>>  +1 - if you agree
>>   -1 - if you disagree
>>
>>
> +1.
>
> --
> Thomas
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] specs process for ironic-inspector

2015-12-04 Thread Pavlo Shchelokovskyy
Oh, I just found it. Sorry for bothering.

Cheers,

On Fri, Dec 4, 2015 at 12:03 PM Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 12/03/2015 06:13 PM, Pavlo Shchelokovskyy wrote:
> > Hi Dmitry,
> >
> > should we also configure Launchpad to have blueprints references there
> > (for release/milestone targeting etc)? Or is it not needed?
>
> Not sure what you mean, we do have Launchpad configured for blueprints.
> We used and will continue to use it for tracking features. Now some more
> complex blueprints will need a spec in addition. Does it answer your
> question?
>
> >
> > Cheers,
> >
> > On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur <dtant...@redhat.com
> > <mailto:dtant...@redhat.com>> wrote:
> >
> > FYI: the process is in effect now.
> >
> > Please submit specs to
> > https://github.com/openstack/ironic-inspector-specs/
> > Approved specs will appear on
> > http://specs.openstack.org/openstack/ironic-inspector-specs/
> >
> > --
> > Dr. Pavlo Shchelokovskyy
> > Senior Software Engineer
> > Mirantis Inc
> > www.mirantis.com
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] specs process for ironic-inspector

2015-12-03 Thread Pavlo Shchelokovskyy
Hi Dmitry,

should we also configure Launchpad to have blueprints references there (for
release/milestone targeting etc)? Or is it not needed?

Cheers,

On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur <dtant...@redhat.com> wrote:

> FYI: the process is in effect now.
>
> Please submit specs to
> https://github.com/openstack/ironic-inspector-specs/
> Approved specs will appear on
> http://specs.openstack.org/openstack/ironic-inspector-specs/
>
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [heat][infra] heat-templates dsvm gate

2015-12-02 Thread Pavlo Shchelokovskyy
Hi all,

I would like to discuss how to fix and improve $subject, which targets to
validate the templates present in the repo. Current state is the following:

the gate does merely validate the "parseability" of YAML/JSON templates and
very basic check on template structure. Any other real checks as would be
actually performed in real deployment are not executed because:
- only Heat and Keystone are installed on this gate;
- for resources for any other service service-based resource exposure kicks
in early, producing "Service {name} does not have required endpoint in
service catalog for the resource type {resource}" errors,
- which are ignored by the script running the validation (to not block the
gate, bug 1492942)

Thus for example the check that properties of the resources are confirming
to the schema of a particular resource is not performed, and we might be
having faulty templates (e.g. with typos) in the repo. I hoped to fix this
with mapping all resources to OS::Heat::None, but it turned out this would
not be really helpful, as the None-resource has any property and attribute.

So I propose that heat-templates repo can configure its environment itself
by using the "post_test_hook" facilities provided and supported by gate
setup. We need that to better control the environment the tests are being
run in. In particular, I'd like to add some fake service endpoints to
Keystone, so service-based exposure is out of the validation way.

Thereby I ask Heat and Infra team to take a look at these two patches:
- [0] in heat-templates and
- [1] in project-config (depends on [0]).

Though these are simply moving couple of bash lines from project-config to
heat-templates, we want to be sure they work so that we do not break the
gate. Unfortunately I can not prove my further patches [2] are working as
it seems Depend-On does not work for referencing project-config changes.

[0] https://review.openstack.org/#/c/252515/
[1] https://review.openstack.org/#/c/252523/
[2]
https://review.openstack.org/#/q/status:open+project:openstack/heat-templates+branch:master+topic:bug/1492942,n,z

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] Install Time Too Long Ironic in devstack

2015-12-01 Thread Pavlo Shchelokovskyy
Hi Zhi,

it seems that Ironic is building a new deploy ramdisk for you with
diskimage-builder. You can skip it if you state

IRONIC_BUILD_DEPLOY_RAMDISK=False

in your local.conf, then the bootstrap image will be downloaded from
tarballs.o.o.

If you are interested here is a sample ironic setting from my local.conf I
use to deploy Ironic with DevStack, and it takes about 1000s to complete
with full reclone:

https://github.com/pshchelo/stackdev/blob/master/local.conf.sample#L128-L145

(this is a sample config, so uncomment all options in this section).

Best regards,

On Tue, Dec 1, 2015 at 9:39 AM Zhi Chang <chang...@unitedstack.com> wrote:

> hi, all
> I want to install Ironic in my devstack by the document
> http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html.
> During the install process, my console displays:
> 2015-12-01 07:08:44.390 | + PACKAGES=
> 2015-12-01 07:08:44.391 | ++ find /tmp/in_target.d/install.d -maxdepth 1
> -name 'package-installs-*'
> 2015-12-01 07:08:44.393 | + '[' -n '' ']'
> 2015-12-01 07:08:44.393 | + package-installs-v2 --phase install.d
> /tmp/package-installs.json
> 2015-12-01 07:08:44.461 | Map file for ubuntu element does not exist.
> 2015-12-01 07:08:44.492 | Map file for ubuntu element does not exist.
> 2015-12-01 07:08:44.526 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.558 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.595 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.633 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.668 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.703 | Map file for deploy-ironic element does not
> exist.
> 2015-12-01 07:08:44.815 | Map file for deploy-tgtadm element does not
> exist.
> 2015-12-01 07:08:44.857 | Map file for deploy-tgtadm element does not
> exist.
>
> I wait this a very very long time, does it right? And my devstack's
> local.conf at: http://paste.openstack.org/show/480462/
>
> Could someone help me?
>
> Thx
> Zhi Chang
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic][inspector] CMDB integration

2015-11-30 Thread Pavlo Shchelokovskyy
Hi all,

we are looking at how ironic-inspector could integrate with external CMDB
solutions and be able fetch a minimal set of data needed for discovery
(e.g. IPMI credentials and IPs) from CMDB. This could probably be achieved
with data filters framework that is already in place, but we have one
question:

what are people actually using? There are simple (but not conceivably used
in real life) choices to make a first implementation, like fetching a csv
file from HTTP link. Thus we want to learn if there is an already known and
working solution operators are actually using, either open source or at
least with open API.

We really appreciate if you chime in :) This would help us design this
feature the way that will benefit community the most.

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][ironic] do we really need websockify with numpy speedups?

2015-11-27 Thread Pavlo Shchelokovskyy
Hi Roman,

those wheels still have to be built and maintained by someone. As there are
no wheels for Linux in upstream PyPI, those would have to be built and
maintained by openstack-infra, and I'm not sure how big variety of
platforms has to be supported. Just taking corresponding deb/rpm package
from upstream seems better option in such case.

Cheers,

On Thu, Nov 26, 2015 at 3:57 PM Roman Podoliaka <rpodoly...@mirantis.com>
wrote:

> Hi Pavlo,
>
> Can we just use a wheel package for numpy instead?
>
> Thanks,
> Roman
>
> On Thu, Nov 26, 2015 at 3:00 PM, Pavlo Shchelokovskyy
> <pshchelokovs...@mirantis.com> wrote:
> > Hi again,
> >
> > I've went on and created a proper pull request to websockify [0], comment
> > there if you think we need it :)
> >
> > I also realized that there is another option, which is to include
> > python-numpy to files/debs/ironic and files/debs/nova (strangely it is
> > already present in rpms/ for nova, noVNC and spice services).
> > This should install a pre-compiled version from distro repos, and should
> > also speed things up.
> >
> > Any comments welcome.
> >
> > [0] https://github.com/kanaka/websockify/pull/212
> >
> > Best regards,
> >
> > On Thu, Nov 26, 2015 at 1:44 PM Pavlo Shchelokovskyy
> > <pshchelokovs...@mirantis.com> wrote:
> >>
> >> Hi all,
> >>
> >> I was long puzzled why devstack is installing numpy. Being a fantastic
> >> package itself, it has the drawback of taking about 4 minutes to
> compile its
> >> C extensions when installing on our gates (e.g. [0]). I finally took
> time to
> >> research and here is what I've found:
> >>
> >> it is used only by websockify package (installed by AFAIK ironic and
> nova
> >> only), and there it is used to speed up the HyBi protocol. Although the
> code
> >> itself has a path to work without numpy installed [1], the setup.py of
> >> websockify declares numpy as a hard dependency [2].
> >>
> >> My question is do we really need those speedups? Do we test any feature
> >> requiring fast HyBi support on gates? Not installing numpy would shave 4
> >> minutes off any gate job that is installing Nova or Ironic, which seems
> like
> >> a good deal to me.
> >>
> >> If we decide to save this time, I have prepared a pull request for
> >> websockify that moves numpy requirement to "extras" [3]. As a
> consequence
> >> numpy will not be installed by default as dependency, but still
> possible to
> >> install with e.g. "pip install websockify[fastHyBi]", and package
> builders
> >> can also specify numpy as hard dependency for websockify package in
> package
> >> specs.
> >>
> >> What do you think?
> >>
> >> [0]
> >>
> http://logs.openstack.org/82/236982/6/check/gate-tempest-dsvm-ironic-agent_ssh/1141960/logs/devstacklog.txt.gz#_2015-11-11_19_51_40_784
> >> [1]
> >>
> https://github.com/kanaka/websockify/blob/master/websockify/websocket.py#L143
> >> [2] https://github.com/kanaka/websockify/blob/master/setup.py#L37
> >> [3]
> >>
> https://github.com/pshchelo/websockify/commit/0b1655e73ea13b4fba9c6fb4122adb1435d5ce1a
> >>
> >> Best regards,
> >> --
> >> Dr. Pavlo Shchelokovskyy
> >> Senior Software Engineer
> >> Mirantis Inc
> >> www.mirantis.com
> >
> > --
> > Dr. Pavlo Shchelokovskyy
> > Senior Software Engineer
> > Mirantis Inc
> > www.mirantis.com
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova][ironic] do we really need websockify with numpy speedups?

2015-11-26 Thread Pavlo Shchelokovskyy
Hi all,

I was long puzzled why devstack is installing numpy. Being a fantastic
package itself, it has the drawback of taking about 4 minutes to compile
its C extensions when installing on our gates (e.g. [0]). I finally took
time to research and here is what I've found:

it is used only by websockify package (installed by AFAIK ironic and nova
only), and there it is used to speed up the HyBi protocol. Although the
code itself has a path to work without numpy installed [1], the setup.py of
websockify declares numpy as a hard dependency [2].

My question is do we really need those speedups? Do we test any feature
requiring fast HyBi support on gates? Not installing numpy would shave 4
minutes off any gate job that is installing Nova or Ironic, which seems
like a good deal to me.

If we decide to save this time, I have prepared a pull request for
websockify that moves numpy requirement to "extras" [3]. As a consequence
numpy will not be installed by default as dependency, but still possible to
install with e.g. "pip install websockify[fastHyBi]", and package builders
can also specify numpy as hard dependency for websockify package in package
specs.

What do you think?

[0]
http://logs.openstack.org/82/236982/6/check/gate-tempest-dsvm-ironic-agent_ssh/1141960/logs/devstacklog.txt.gz#_2015-11-11_19_51_40_784
[1]
https://github.com/kanaka/websockify/blob/master/websockify/websocket.py#L143
[2] https://github.com/kanaka/websockify/blob/master/setup.py#L37
[3]
https://github.com/pshchelo/websockify/commit/0b1655e73ea13b4fba9c6fb4122adb1435d5ce1a

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][ironic] do we really need websockify with numpy speedups?

2015-11-26 Thread Pavlo Shchelokovskyy
Hi again,

I've went on and created a proper pull request to websockify [0], comment
there if you think we need it :)

I also realized that there is another option, which is to include
python-numpy to files/debs/ironic and files/debs/nova (strangely it is
already present in rpms/ for nova, noVNC and spice services).
This should install a pre-compiled version from distro repos, and should
also speed things up.

Any comments welcome.

[0] https://github.com/kanaka/websockify/pull/212

Best regards,

On Thu, Nov 26, 2015 at 1:44 PM Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi all,
>
> I was long puzzled why devstack is installing numpy. Being a fantastic
> package itself, it has the drawback of taking about 4 minutes to compile
> its C extensions when installing on our gates (e.g. [0]). I finally took
> time to research and here is what I've found:
>
> it is used only by websockify package (installed by AFAIK ironic and nova
> only), and there it is used to speed up the HyBi protocol. Although the
> code itself has a path to work without numpy installed [1], the setup.py of
> websockify declares numpy as a hard dependency [2].
>
> My question is do we really need those speedups? Do we test any feature
> requiring fast HyBi support on gates? Not installing numpy would shave 4
> minutes off any gate job that is installing Nova or Ironic, which seems
> like a good deal to me.
>
> If we decide to save this time, I have prepared a pull request for
> websockify that moves numpy requirement to "extras" [3]. As a consequence
> numpy will not be installed by default as dependency, but still possible to
> install with e.g. "pip install websockify[fastHyBi]", and package builders
> can also specify numpy as hard dependency for websockify package in package
> specs.
>
> What do you think?
>
> [0]
> http://logs.openstack.org/82/236982/6/check/gate-tempest-dsvm-ironic-agent_ssh/1141960/logs/devstacklog.txt.gz#_2015-11-11_19_51_40_784
> [1]
> https://github.com/kanaka/websockify/blob/master/websockify/websocket.py#L143
> [2] https://github.com/kanaka/websockify/blob/master/setup.py#L37
> [3]
> https://github.com/pshchelo/websockify/commit/0b1655e73ea13b4fba9c6fb4122adb1435d5ce1a
>
> Best regards,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [openstack-dev ] [Heat] how to verify heat resource plugin

2015-11-19 Thread Pavlo Shchelokovskyy
Hi Mohan,

well, you should have the service you are developing the resource plugin
for installed somewhere and run heat against it, creating the stack with
the new resource type your plugin is defining, and checking that the thing
it creates is working, can be updated and deleted via heat template changes
and heat stack update and delete.
Can "sfc' neutron extension be deployed on devstack? that would be the
easiest way to test it.

Also, if it is a new type of upstream Neutron extension, I encourage you to
propose your new resource plugin to heat main tree via Gerrit.
If it is some custom downstream Neutron extension, you would like to check
the contrib folder in the heat repo, especially at e.g. Kilo release - back
then we had a lot of plugins there. so you could learn how to make a real
plugin out of your resource, that can be installed aside and registered
with a clean upstream Heat installation w/o modifying main Heat source code.

Best regards,

On Thu, Nov 19, 2015 at 5:06 PM Mohan Kumar <nmohankumar1...@gmail.com>
wrote:

> Hi team,
>
>  Currently working on adding heat resource plugin for neutron extension
> "networking-sfc" , similar to firewall implementation  "
> https://github.com/openstack/heat/blob/master/heat/engine 
> resources/openstack/neutron/firewall.py
> <https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/firewall.py>
> "
>
>   I have gone through some code in heat repo and the guides and developed
> code locally  at "heat/engine/resources/openstack/neutron/sfc.py  ( " 
> *http://paste.openstack.org/show/479425
> <http://paste.openstack.org/show/479425>*/
> <http://paste.openstack.org/show/479425/> " ) .
>
>  how to verify my changes are working ,any pointers ?
>
>  I'm new this concept and please help me to get started with this !
>
> Thanks.,
> Mohankumar.N
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ironic] specs process for ironic-inspector

2015-11-19 Thread Pavlo Shchelokovskyy
Hi all,

+1 for specs in general, big features require a proper review and
discussion for which LP is not a good choice.

+1 for not requiring a spec for small features, LP BP is enough for just
time/release tracking, but of course cores can request a proper spec to be
proposed if feeling feature is worth discussion.

0 for using ironic-specs. It will increase visibility to wider ironic
community, sure. But it seems ironic-inspector has to decide how integrated
it should be with the other ironic project infra pieces as well. For
example, there is now a patch on review to build a proper sphinx docs for
ironic-inspector. Should those then be published and where? Should
ironic-inspector have own doc site e.g.
http://docs.openstack.org/developer/ironic-inspector/, or somehow be
incorporated in ironic doc site? IMO decision on specs and docs should be
consistent.

Best regards,

On Thu, Nov 19, 2015 at 3:20 PM Dmitry Tantsur <dtant...@redhat.com> wrote:

> Hi folks!
>
> I've been dodging subj for some time (mostly due to my laziness), but
> now it seems like the time has come. We're discussing 2 big features:
> autodiscovery and HA that I would like us to have a proper consensus on.
>
> I'd like to get your opinion on one of the options:
> 1. Do not have specs, only blueprints are enough for us.
> 2. Reuse ironic-specs repo, create our own subdirectory with our own
> template
> 3. Create a new ironic-inspector-specs repo.
>
> I vote for #2, as sharing a repo with the remaining ironic would
> increase visibility of large inspector changes (i.e. those deserving a
> spec). We would probably use [inspector] tag in the commit summary, so
> that people explicitly NOT wanting to review them can quickly ignore.
>
> Also note that I still see #1 (use only blueprints) as a way to go for
> simple features.
>
> WDYT?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

2015-11-10 Thread Pavlo Shchelokovskyy
Hi,
I like the last variant by Lucas, and agree we need to ensure the CLI
interface is consistent between power and provision commands.

Best regards,

On Tue, Nov 10, 2015 at 12:00 PM Lucas Alvares Gomes <lucasago...@gmail.com>
wrote:

> > It's still not 100% consistent, "power" is a noun, "provision" is a verb.
> > Not sure it matters, though, adding OSC folks so that they can weigh in.
> >
>
> "provision" can also be a noun [1]. But since the OSC syntax suggest
> having a verb we could have something like:
>
> $ openstack baremetal set power --on | --off 
> $ openstack baremetal set provision --provide | --active | ... 
>
> [1] http://www.thefreedictionary.com/provision
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

2015-11-03 Thread Pavlo Shchelokovskyy
Hi all,

For auto-setting driver options on enrollment, I would vote for option 2
with default being fake driver + optional CMDB integration. This would ease
managing a homogeneous pool of BMs, but still (using fake driver or data
from CMDB) work reasonably well in heterogeneous case.

As for setting a random password, CMDB integration is crucial IMO. Large
deployments usually have some sort of it already, and it must serve as a
single source of truth for the deployment. So if inspector is changing the
ipmi password, it should not only notify/update Ironic's knowledge on that
node, but also notify/update the CMDB on that change - at least there must
be a possibility (a ready-to-use plug point) to do that before we roll out
such feature.

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] core team nomination

2015-10-20 Thread Pavlo Shchelokovskyy
+1 for both!

On Tue, Oct 20, 2015 at 6:14 PM Thomas Herve <the...@redhat.com> wrote:

> +1!
>
> --
> Thomas
>
> On Tue, Oct 20, 2015 at 3:38 PM, Sergey Kraynev <skray...@mirantis.com>
> wrote:
>
>> I'd like to propose new candidates for heat core-team:
>> Rabi Mishra
>> Peter Razumovsky
>>
>> According statistic both candidate made a big effort in Heat as
>> reviewers and as contributors [1][2].
>> They were involved in Heat community work  during last several releases
>> and
>> showed good understanding of Heat code.
>> I think, that they are ready to became core-reviewers.
>>
>> Heat-cores, please vote with +/- 1.
>>
>> [1] http://stackalytics.com/report/contribution/heat-group/180
>> [2] http://stackalytics.com/?module=heat-group=person-day
>> --
>> Regards,
>> Sergey.
>>
>> __
>> OpenStack Development Mailing List (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
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel][Plugins][Ironic] Deploy Ironic with fuel ?

2015-10-20 Thread Pavlo Shchelokovskyy
Hi Loic,

the story of this plugin is a bit complicated. We've done it as PoC of
integrating Ironic into Mirantis OpenStack/Fuel during 7.0 release.
Currently we are working on integrating Ironic into core of Fuel targeting
its 8.0 release. Given that, the plugin is not official in any sense, is
not certified according to Fuel plugins guidelines, is not supported at all
and has had only limited testing on a small in-house lab.

To successfully deploy Ironic with this plugin "as-is" you'd most probably
need access to Mirantis package repositories as it relies on some patches
to fuel-agent that we use for bootstrapping, and some of those are not
merged yet, so we use repos created by our CI from Gerrit changes. Probably
though you can hack on the code and disable such dependencies/building and
uploading the custom bootstrap image, activate clear upstream Ironic
drivers and then use upstream images with e.g. ironic-python-agent for
bootstrapping baremetal nodes.

As to your network setup question - the baremetal network is somewhat
similar to the public network in Fuel, which needs two ip ranges defined,
one for service nodes, and the other for actual VMs to assign as floating
ips. Thus networking setup for the plugin should be done as follows (naming
it "baremetal" is mandatory):

fuel network-group --name baremetal --cidr 192.168.3.0/24 -c --nodegroup 1
--meta='{ip_range: ["192.168.3.2", "192.168.3.50"], notation: "ip_ranges"}'

where the ip range (I've put some example values) is for those service
OpenStack nodes that host Ironic services and need to have access to this
provider network where BM nodes do live (this range is then auto-filled to
network.baremetal section of Networking settings tab in Fuel UI). The range
for the actual BM nodes is defined then on the "Settings->Ironic" tab in
Fuel UI once Ironic checkbox there is activated.

I admit we do need to make some effort and document the plugin a bit better
(actually at all :) ) to not confuse people wishing to try it out.

Best regards,


> On Mon, Oct 19, 2015 at 6:45 AM, <loic.nico...@orange.com> wrote:
>
>> Hello,
>>
>>
>>
>> I’m currently searching for information about Ironic Fuel plugin :
>> https://github.com/openstack/fuel-plugin-ironic I don’t find any
>> documentation on it.
>>
>>
>>
>> I’ve tried to install and deploy an Openstack environment with Fuel 7.0
>> and Ironic plugin but it failed. After adding ironic role to a node Fuel UI
>> crashed, due to a missing network “baremetal” . When creating a network
>> group
>>
>>
>>
>> fuel network-group --create --node-group 1 --name \
>>
>> "baremetal" --cidr 192.168.3.0/24
>>
>> UI works again, but I got some errors in the deployment, during network
>> configuration. So I think I have to configure a network template, did
>> someone already do this for this plugin ?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Loic
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> 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
>>
>>
> --
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Neutron][Ironic] Testing Ironic multi-tenancy feature

2015-10-12 Thread Pavlo Shchelokovskyy
Hi all,

we would like to start preliminary testing of Ironic multi-tenant network
setup which is supported by Neutron in Liberty according to [1]. According
to Neutron design integration with network equipment is done via ML2
plugins. We are looking for plugins and network equipment that can work
with such Ironic multi-tenant setup. Could community recommend a pair of
hardware switch/corresponding Neutron plugin that already supports this
functionality?

[1]
https://blueprints.launchpad.net/neutron/+spec/neutron-ironic-integration

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] Traditional question about Heat IRC meeting time.

2015-09-29 Thread Pavlo Shchelokovskyy
+1, works for me too

On Tue, Sep 29, 2015 at 12:57 PM Sergey Kraynev <skray...@mirantis.com>
wrote:

> Hi Heaters!
>
> Previously we had constant "tradition" to change meeting time for
> involving more people from different time zones.
> However last release cycle show, that two different meetings with 07:00
> and 20:00 UTC are comfortable for most of our contributors. Both time
> values are acceptable for me and I plan to visit both meetings. So I
> suggested to leave it without any changes.
>
> What do you think about it ?
>
> Regards,
> Sergey.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] Integration Test Questions

2015-09-12 Thread Pavlo Shchelokovskyy
have a minimum of a short
> blurb for each method.  Comments?

A (multi-line) doc string for module/test method would suffice. For
longer scenario tests we already do this describing a scenario the
test aim to pass through.

> Should we add a 'high level coverage' summary in our README?  It could help
> all of us know at a high level where we are at in terms of which resources
> we have tests for and which api's, etc.

As for APIs - I believe we could use some functional test coverage
tool. I am not sure if there is a common thing already settled for in
the community though. It might be a good cross-project topic to
discuss during summit with Tempest community, they might already have
something in the works.

As for resources - we do try to exercise the native Heat ones that are
there to provide the functionality of Heat itself (ASGs, RGs etc), but
AFAIK we have no plans on deep testing all the other resources in a
functional way.

>
> Let us know what you all think!

Thanks again for bringing this up. "If it is not tested - it does not works" :)

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

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


[openstack-dev] [Heat] Bugs for Rackspace resources that use scheduler tasks

2015-08-19 Thread Pavlo Shchelokovskyy
Hi Randall, Jason

this is re bug https://bugs.launchpad.net/heat/+bug/1393268

As most of in-tree resources are now fixed in this regard, Steve Baker
asked me to create separate bugs for Rackspace resources from Heat's
contrib that need fixing. As I am not comfortable with messing around in
those resources (and I remember I've talked with Randall about this last
summit), I have assigned those bugs to Randall first so you can spread them
between your heat team.

Not sure when/if you guys will switch to convergence, so I've made those
bugs about using scheduler.TaskRunner objects as Medium (those are must for
convergence phase 2), and those where only rich objects are passed around
as Low.

Bugs in question are:
- Rackspace Cloud Network https://bugs.launchpad.net/heat/+bug/1486464
  (this one is easy, it almost does the right thing already), priority Low
- Rackspace Cloud LoadBalancer https://bugs.launchpad.net/heat/+bug/1486463
  (this one is bad, especially the update logic), priority Medium

Best regards,
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 答复: Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

2015-07-31 Thread Pavlo Shchelokovskyy
+1 for both from me,

Best regards,

On Fri, Jul 31, 2015, 11:20 Huangtianhua huangtian...@huawei.com wrote:

 +1 :)

 -邮件原件-
 发件人: Steve Baker [mailto:sba...@redhat.com]
 发送时间: 2015年7月31日 12:36
 收件人: OpenStack Development Mailing List
 主题: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn for
 heat-core

 I believe the heat project would benefit from Kanagaraj Manickam and Ethan
 Lynn having the ability to approve heat changes.

 Their reviews are valuable[1][2] and numerous[3], and both have been
 submitting useful commits in a variety of areas in the heat tree.

 Heat cores, please express your approval with a +1 / -1.

 [1] http://stackalytics.com/?user_id=kanagaraj-manickammetric=marks
 [2] http://stackalytics.com/?user_id=ethanlynnmetric=marks
 [3] http://stackalytics.com/report/contribution/heat-group/90

 __
 OpenStack Development Mailing List (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

-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Heat] conditional resource exposure - second thoughts

2015-07-14 Thread Pavlo Shchelokovskyy
Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would like
to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this new
features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack components
or give them required roles :)

resource-type-show
Right now the plan is to disable showing unavailable to the user
resources. But may be we should leave this as it is, for the same purpose
as above (or again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way for
a user to check validity of any template with any in principle supported
resources?

The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,
 --
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat]: stack stays interminably under the status create in progress

2015-05-05 Thread Pavlo Shchelokovskyy
Hi Sara,

first, what version of OpenStack are you using? Second, could you provide
us with actual template that exhibits such behavior and the way it was
launched (Dashboard or CLI, with which parameters and other arguments)?
Would be much easier for us to reason about possible failure scenarios.

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, May 5, 2015 at 4:02 PM, ICHIBA Sara ichi.s...@gmail.com wrote:

 Hello there,

 I started a project where I need to deploy stacks and orchastrate them
 using heat (autoscaling and so on..). I just started playing with heat and
 the creation of my first stack is never complete. It stays in the status
 create in progress. My log files don't say much. For my template i'm using
 a veery simple one to launch a small instance.

 Any ideas what that might be?

 In advance, thank you for your response.
 sara,

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


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


Re: [openstack-dev] [heat] suggestion for lock/protect stack blueprint

2015-04-08 Thread Pavlo Shchelokovskyy
Hi Noa,

would you kindly propose this blueprint as a spec in heat-specs project on
review.openstack.org? It is way easier to discuss specs in a Gerrit review
format than in ML. If you need a help with submitting a spec for a review,
come to our IRC channel (#heat at freenode.net), we'll gladly help you with
that.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) 
noa.koff...@alcatel-lucent.com wrote:

 Hey,

 I would like to suggest a blueprint to allow locking/protecting a
 stack. Similar to: nova server lock or glance-image --is-protected
 flag.
 Once a stack is locked, the only operation allowed on the stack is
 unlock - heat engine should reject any stack operations and ignore
 signals that modify the stack (such as scaling).

 The lock operation should have a lock_resources flag (default = True):
 When True: perform heat lock and enable lock/protect for each stack
 resource that supports it (nova server, glance image,...).
 when False: perform heat lock - which would lock the stack and all
 nested stacks (actions on resources will not be effected).

 Use-cases:
 1. we received several requests from application vendors, to allow
 maintenance mode for the application. When in maintenance no topology
 changes are permitted. For example a maintenance mode is required for
 a clustered DB app that needs a manual reboot of one of its servers -
 when the server reboots all the other servers are redistributing the
 data among themselves which causes high CPU levels which in turn might
 cause an undesired scale out (which will cause another CPU spike and so
 on...).
 2. some cloud-admins have a configuration stack that initializes the
 cloud (Creating networks, flavors, images, ...) and these resources
 should always exist while the cloud exists. Locking these configuration
 stacks, will prevent someone from accidently deleting/modifying the
 stack or its resources.

 This feature might even raise in significance, once convergence phase 2
 is in place, and many other automatic actions are performed by heat.
 The ability to manually perform admin actions on the stack with no
 interruptions is important.

 Any thoughts/comments/suggestions are welcome.

 Thanks
 Noa Koffman.



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

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


Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups

2015-04-03 Thread Pavlo Shchelokovskyy
?

 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


Best regards,
Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Interaction between heat and nova

2015-04-03 Thread Pavlo Shchelokovskyy
Abhishek,

for communication with Nova Heat is using Nova's REST API via
python-novaclient exclusively. So if any Nova functionality is exposed via
novaclient's Python API - Heat can in principle do it.

Another question is what are those check and change you are willing to
do? This should be in line with Heat resource life cycle model. If it is
some general thing applicable/useful to any OpenStack deployment you can
propose a patch (or a spec first) and we can consider including it in
upstream. If it is more specific to your deployment - you can make yourself
a specialized resource as Heat resource plugin and override/extend any
methods of OS::Nova::Server resource and use this plugin instead of
OS::Nova::Server in your cloud (for an example see Rackspace Cloud Server
resource in heat/contrib).

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Fri, Apr 3, 2015 at 10:12 AM, Abhishek Talwar/HYD/TCS 
abhishek.tal...@tcs.com wrote:

 Hi Folks,

 I am trying if we can have an api call from heat to nova and hit one of
 the nova clients method. I want to have a check in heat and if that happens
 it should request nova for a change in the instance through one of nova's
 command.

 Any information regarding this.


  Thanks and Regards

 Abhishek Talwar

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you


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


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


[openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze

2015-04-02 Thread Pavlo Shchelokovskyy
Hi all,

we have a problem with dependencies for the kilo-rc1 release of Heat - see
bug [1]. Root cause is ceilometerclient was not updated for a long time and
just got an update recently. We are sure that Heat in Kilo would not work
with ceilometerclient =1.0.12 (users would not be able to create
Ceilometer alarms in their stacks). In the same time, global requirements
have  ceilometerclient =1.0.12. That works on the gate, but will fail for
any deployment that happens to use an outdated pypi mirror. I am also
afraid that if the version of ceilometerclient would be upper-capped to
1.0.12 in stable/kilo, Heat in stable/kilo would be completely broken in
regards to Ceilometer alarms usage.

The patch to global requirements was already proposed [2] but is blocked by
requirements freeze. Can we somehow apply for an exception and still merge
it? Are there any other OpenStack projects besides Heat that use
ceilometerclient's Python API (just asking to assert the testing burden)?

[1] https://bugs.launchpad.net/python-ceilometerclient/+bug/1423291

[2] https://review.openstack.org/#/c/167527/


Best regards,
Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][Horizon] What we can do for Heat in Horizon else?

2015-04-02 Thread Pavlo Shchelokovskyy
Hi folks,

there is another not covered feature that jumps at me:

say you have a stack containing an autoscaling group (a nested stack) where
the scaled resource is also a nested stack. I can click on the uuid of the
asg to get a page similar to other stacks showing me the structure of the
nested stack described by autoscaling group, but I can not further click on
the uuid of the scaled resource to get its representation as a stack.
Copy-pasting the uuid of the scaled resource into the Horizon url as
HorizonHost/project/stacks/uuid does the trick and the structure of the
resource as a stack is displayed.

As an example you can use the templates for the test_autoscaling_lb
integration test, under review [1]
[1] https://review.openstack.org/#/c/165944/

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 11:55 AM, Sergey Kraynev skray...@mirantis.com
wrote:

 Hi community.

 I want to ask feedback from our Heat team and also involve Horizon team in
 this discussion.
 AFAIK during Kilo was implemented bp:
 https://blueprints.launchpad.net/horizon/+spec/heat-ui-improvement

 This bp add more base Heat functionality to Horizon.
 I asked some ideas from Heat guys. What we want to have here else ?

 There is only one idea for me about topology:
 create some filters for displaying only particular resources (by their
 type)
 F.e. stack has 50 resources, but there is half of them network resources.
 As user I want to see only network level, so I enable filtering by network
 resources.


 Regards,
 Sergey.

 __
 OpenStack Development Mailing List (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] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze

2015-04-02 Thread Pavlo Shchelokovskyy
Sean,

unfortunately, in Heat we do not have yet integration tests for all the
Heat resources (creating them in real OpenStack), and Ceilometer alarms are
in those not covered. In unit tests the real client is of course mocked
out. When we stumbled on this issue during normal Heat usage, we promptly
raised a bug suggesting to make a new release, but propagating it to
requirements took some time. The gate is not affected as it installs as per
= in requirements the latest which is 1.0.13.

With 1.0.12 ceilometerclient and Heat-Kilo, the Ceilometer alarm resource
not doesn't work quite as expected, it can not be created at all, failing
any stack that has it in the template.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 1:12 PM, Sean Dague s...@dague.net wrote:

 On 04/02/2015 05:42 AM, Eoghan Glynn wrote:
 
 
  Hi all,
 
  we have a problem with dependencies for the kilo-rc1 release of Heat -
 see
  bug [1]. Root cause is ceilometerclient was not updated for a long time
 and
  just got an update recently. We are sure that Heat in Kilo would not
 work
  with ceilometerclient =1.0.12 (users would not be able to create
 Ceilometer
  alarms in their stacks). In the same time, global requirements have
  ceilometerclient =1.0.12. That works on the gate, but will fail for any
  deployment that happens to use an outdated pypi mirror. I am also afraid
  that if the version of ceilometerclient would be upper-capped to 1.0.12
 in
  stable/kilo, Heat in stable/kilo would be completely broken in regards
 to
  Ceilometer alarms usage.
 
  The patch to global requirements was already proposed [2] but is
 blocked by
  requirements freeze. Can we somehow apply for an exception and still
 merge
  it? Are there any other OpenStack projects besides Heat that use
  ceilometerclient's Python API (just asking to assert the testing
 burden)?
 
  [1] https://bugs.launchpad.net/python-ceilometerclient/+bug/1423291
 
  [2] https://review.openstack.org/#/c/167527/
 
  Pavlo - part of the resistance here I suspect may be due to the
  fact that I inadvertently broke the SEMVER rules when cutting
  the ceilometerclient 1.0.13 release, i.e. it was not sufficiently
  backward compatible with 1.0.12 to warrant only a Z-version bump.
 
  Sean - would you be any happier with making a requirements freeze
  exception to facilitate Heat if we were to cut a fresh ceiloclient
  release that's properly versioned, i.e. 2.0.0?

 A couple of concerns:

 #1 - would have been really nice if the commit message for the review
 included the above block of text. The current commit message is not
 clear that Heat *can not* work.

 #2 - why wasn't the fact that Heat *can not* work raised earlier,
 because I assume that means there are tests that are blocking all kinds
 of changes?

 If this is truly blocking we can raise with Thierry, he has final
 override here. However, if this means that one resource type doesn't
 work quite as expected, I don't think that warrants a freeze bump. The
 libraries are set to = here so nothing in Kilo that prevents users from
 deciding to take that upgrade.

 Forcing that upgrade on all users for 1 use case which a user may or may
 not be using is not the point of GR.

 -Sean

 --
 Sean Dague
 http://dague.net

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

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


Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze

2015-04-02 Thread Pavlo Shchelokovskyy
Hi all,

a (may be hasty) update.

I just tried using a quite fresh devstack master that somehow still
(PIP_UPGRADE=False?) has ceilometerclient as 1.0.12,
and ceilometer alarms do work as expected, template is [1]. May be the
actual bug/backward incompatibility was somewhere in oslo-incubator and
latest syncs fixed it.

I urge Heat team to double-check if 1.0.12 does indeed work now, so we can
call of the dogs and close this issue.

[1]
https://github.com/pshchelo/stackdev/blob/master/templates/autoscaling/asg.yaml

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 1:46 PM, Sergey Kraynev skray...@mirantis.com
wrote:

 Hi Guys.


 A couple of concerns:

 #1 - would have been really nice if the commit message for the review
 included the above block of text. The current commit message is not
 clear that Heat *can not* work.


 I will update commit message regarding info mentioned in this thread.



 #2 - why wasn't the fact that Heat *can not* work raised earlier,
 because I assume that means there are tests that are blocking all kinds
 of changes?


 The reason, why we don't tell it early is:
  when issue was found we ask ceilometer team to bump new version,
 after that I uploaded patch to global-requirements and believed that it
 will be merged before release.
 It does not block gates (due to reason mentioned above), but the reality
 is so, that with 1.0.12 version
 user can not use any ceilometer resources in Heat (as result we loose
 autoscaling templates, where ceilometer plays one of major roles).



 If this is truly blocking we can raise with Thierry, he has final
 override here. However, if this means that one resource type doesn't
 work quite as expected, I don't think that warrants a freeze bump. The
 libraries are set to = here so nothing in Kilo that prevents users from
 deciding to take that upgrade.

 Forcing that upgrade on all users for 1 use case which a user may or may
 not be using is not the point of GR.

 -Sean

 --
 Sean Dague
 http://dague.net

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



 Regards,
 Sergey.

 __
 OpenStack Development Mailing List (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] [Heat] [Ceilometer] [depfreeze] bug is unresolved due to requirements freeze

2015-04-02 Thread Pavlo Shchelokovskyy
Hi all,

my previous update was a bit too hasty indeed - the problem is still there.

Steps I took:

in two empty virtualenvs I installed cilometerclient 1.0.12 and 1.0.13 and
compared pip freeze outputs - everything is the same except the
ceilometerclient itself.

Then I re-installed my DevStack with PIP_UPGRADE=True, all the latest
allowed libs are installed (that's what happens on the gate, right?),
ceilometerclient is 1.0.13 and all its dependencies are exactly as in those
two virtualenvs. Everything works, alarm resources are created by Heat.

Then I manually downgraded ceilometerclient to 1.0.12, restarted all Heat
and Ceilometer services - and can no more create Ceilometer alarms via Heat.

Upgrading ceilometerclient back (and restarting Ceilometer and Heat) solves
the problem.

We do better bump the requirements. The only projects I know of using
ceilometerclient are Heat, Horizon and Ceilometer itself.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 3:36 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 04/02/2015 01:58 PM, Eoghan Glynn wrote:
 
  Pavlo Shchelokovskyy wrote:
  unfortunately, in Heat we do not have yet integration tests for
  all the Heat resources (creating them in real OpenStack), and
  Ceilometer alarms are in those not covered. In unit tests the
  real client is of course mocked out. When we stumbled on this
  issue during normal Heat usage, we promptly raised a bug
  suggesting to make a new release, but propagating it to
  requirements took some time. The gate is not affected as it
  installs as per = in requirements the latest which is 1.0.13.
 
  With 1.0.12 ceilometerclient and Heat-Kilo, the Ceilometer
  alarm resource not doesn't work quite as expected, it can not
  be created at all, failing any stack that has it in the
  template.
 
  I'm +1 on the change.
 
  Let's wait until tomorrow to make sure this is not completely
  unacceptable to packagers.
 

 Packaging wise, it does not seem like a great deal, since all
 new/updated dependencies that were touched from 1.0.12 to 1.0.13 are
 already present in other Kilo components for a long time (all of them
 are covered by neutron kilo deps). The package hasn't changed a lot
 (just a new CONTRIBUTE file was introduced that can be easily
 added/skipped from downstream packages).

 Though, have we actually determined that the issue we try to tackle is
 still present in Kilo? I don't see an update to the latest email from
 Pavlo in the thread where he said that he cannot reproduce it.

 So in the end, if it fixes a valid bug, I don't see a huge problem
 packaging wise to bump the version. Though there can be other
 concerns, like exposing a new code to users that could potentially get
 new bugs with the bump. [I personally don't consider it a huge risk
 though.]

 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJVHTevAAoJEC5aWaUY1u577IgIANuqzfg5Oo/JhKY/RlpcEYB0
 rOKI6DhlE5YXMiOsUR4R5w6kl8NdlJGLkj4OSilBzSFQ+LwmiqRR3T3xll6HwLSE
 IZYxMvM/YIKF34nsJ+G40u/8OQzNATnWXby4YwAR58YG96c/EDy50smJDlPVcuKd
 IC8P44qklbmqr7LhU+V7PeB25QuLNyyJNuo3Ni7FuuXPiwC3GzBChuCk+Yol3a8J
 jPJwF/sBX9lDquroaCuhIJXBv/imv73H2Ccar1J+3QMqvbqtLs6yFnepW93aaQFn
 sMe7aQC9zlHZMi72CY5G2h/PpBG2CpLJQ0wQN22xgtrMQ90lFFqTPGxnyvpJeBo=
 =mE3g
 -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] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-27 Thread Pavlo Shchelokovskyy
Hi,

On Thu, Mar 26, 2015 at 10:26 PM, Zane Bitter zbit...@redhat.com wrote:

 On 26/03/15 10:38, Pavlo Shchelokovskyy wrote:

 Hi all,

 following IRC discussion here is a summary of what I propose can be done
 in this regard, in the order of increased decoupling:

 1) make a separate requirements.txt for integration tests and modify the
 tox job to use it. The code of these tests is pretty much decoupled
 already, not using any modules from the main heat tree. The actual
 dependencies are mostly api clients and test framework. Making this
 happen should decrease the time needed to setup the tox env and thus
 speed up the test run somewhat.


 +1

  2) provide separate distutils' setup.py/setup.cfg
 http://setup.py/setup.cfg to ease packaging and installing this test
 suit to run it against an already deployed cloud (especially scenario
 tests seem to be valuable in this regard).


 +1

  3) move the integration tests to a separate repo and use it as git
 submodule in the main tree. The main reasons not to do it as far as I've
 collected are not being able to provide code change and test in the same
 (or dependent) commits, and lesser reviewers' attention to a separate
 repo.


 -0

 I'm not sure what the advantage is here, and there are a bunch of
 downsides (basically, I agree with Ryan). Unfortunately I missed the IRC
 discussion, can you elaborate on how decoupling to this degree might help
 us?


Presumably this could enable a more streamlined packaging and publishing of
the test suit (e.g. to PyPI). But I agree, right now it is not really
needed given the downsides, I just brought it up as an extreme separation
case to collect more opinions.

Given the feedback we have in the thread, I will proceed with the first
point as this should have immediate benefit for the duration of the test
job and already give help to those who want to package the test suit
separately. Distutils stuff can be added later.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] heat delete woes in Juno

2015-03-26 Thread Pavlo Shchelokovskyy
Hi Matt,

if it would be feasible/appropriate, could you provide us with templates
for stacks that show this behavior (try to get them with heat
template-show stack-name-or-id)? This would help us to test and
understand the problem better.

And yes, just the day before I was contacted by one of my colleagues who
seems to experience similar problems with Juno-based OpenStack deployment
(though I did not had a chance to look through the issue yet).

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Mar 26, 2015 at 8:17 PM, Matt Fischer m...@mattfischer.com wrote:

 Nobody on the operators list had any ideas on this, so re-posting here.

 We've been having some issues with heat delete-stack in Juno. The issues
 generally fall into three categories:

 1) it takes multiple calls to heat to delete a stack. Presumably due
 to heat being unable to figure out the ordering on deletion and resources
 being in use.

 2) undeleteable stacks. Stacks that refuse to delete, get stuck in
 DELETE_FAILED state. In this case, they show up in stack-list and
 stack-show, yet resource-list and stack-delete deny their existence. This
 means I can't be sure whether they have any real resources very easily.

 3) As a corollary to item 1, stacks for which heat can never unwind the
 dependencies and stay in DELETE_IN_PROGRESS forever.

 Does anyone have any work-arounds for these or recommendations on cleanup?
 My main worry is removing a stack from the database that is still consuming
 the customer's resources. I also don't just want to remove stacks from the
 database and leave orphaned records in the DB.

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


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


[openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

2015-03-26 Thread Pavlo Shchelokovskyy
Hi all,

following IRC discussion here is a summary of what I propose can be done in
this regard, in the order of increased decoupling:

1) make a separate requirements.txt for integration tests and modify the
tox job to use it. The code of these tests is pretty much decoupled
already, not using any modules from the main heat tree. The actual
dependencies are mostly api clients and test framework. Making this happen
should decrease the time needed to setup the tox env and thus speed up the
test run somewhat.

2) provide separate distutils' setup.py/setup.cfg to ease packaging and
installing this test suit to run it against an already deployed cloud
(especially scenario tests seem to be valuable in this regard).

3) move the integration tests to a separate repo and use it as git
submodule in the main tree. The main reasons not to do it as far as I've
collected are not being able to provide code change and test in the same
(or dependent) commits, and lesser reviewers' attention to a separate repo.

What do you think about it? Please share your comments.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Heat][Nova] volumes handling on AWS Instance suspend/resume/delete

2015-03-13 Thread Pavlo Shchelokovskyy
Hi all,

as I am removing scheduler tasks from server resources, I have the
following question:

in OS Server resource on suspend/resume/delete we do not care about
attached volumes. In fact Nova keeps them attached to the suspended
instance (volumes are in 'in-use' state) and after server resume they are
still attached to the server without any additional steps. On server delete
Nova again detaches all the volumes automatically.

On the other hand, in AWS Instance resource we manually detach volumes on
delete/suspend and reattach them on resume. What's the point of that? Is it
for some compatibility with instance+volumes behavior in real AWS or some
leftover from earlier Nova days?

An advice from anyone with AWS experience would be appreciated, as if it is
not for compatibility sake, I would gladly remove that seemingly
unnecessary logic.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][Nova] volumes handling on AWS Instance suspend/resume/delete

2015-03-13 Thread Pavlo Shchelokovskyy
Answer found - AWS CFN has no notion of stack suspend/resume, thus actual
AWS resources have it neither. As it it an OpenStack feature, and I know
how Nova + Cinder behave currently, it looks safe to remove the mentioned
logic.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Fri, Mar 13, 2015 at 4:22 PM, Pavlo Shchelokovskyy 
pshchelokovs...@mirantis.com wrote:

 Hi all,

 as I am removing scheduler tasks from server resources, I have the
 following question:

 in OS Server resource on suspend/resume/delete we do not care about
 attached volumes. In fact Nova keeps them attached to the suspended
 instance (volumes are in 'in-use' state) and after server resume they are
 still attached to the server without any additional steps. On server delete
 Nova again detaches all the volumes automatically.

 On the other hand, in AWS Instance resource we manually detach volumes on
 delete/suspend and reattach them on resume. What's the point of that? Is it
 for some compatibility with instance+volumes behavior in real AWS or some
 leftover from earlier Nova days?

 An advice from anyone with AWS experience would be appreciated, as if it
 is not for compatibility sake, I would gladly remove that seemingly
 unnecessary logic.

 Best regards,

 Pavlo Shchelokovskyy
 Software Engineer
 Mirantis Inc
 www.mirantis.com

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


Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

2015-03-12 Thread Pavlo Shchelokovskyy
Hi,

as you have a separate monitoring solution (not Ceilometer), it seems you
can use ResourceGroup instead of AutoscalingGroup and issue heatclient/rest
calls to do a stack-update with desired size of the group when needed. The
group members will be numbered, and as already said you can also control
the removal. One possible downside is that AFAIR the numbers would not be
reused on subsequent scale-down/ups.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Mar 11, 2015 at 2:46 PM, ELISHA, Moshe (Moshe) 
moshe.eli...@alcatel-lucent.com wrote:

 I am familiar of the removal policies. Thanks!

 Our use case for parameters on scale out is as follows:

 Every server has a unique index that identifies it.
 The first server has an index of 1, the second has an index of 2, etc.
 The index of each server must exist prior to the configuration phase of
 the server.

 This use case is an outcome of a virtualization process for an NFV
 application.
 In the past this application was scaled manually by adding physical cards
 into slots - the index is the slot number.
 In order to allow a smooth and fast transition of the app into the cloud -
 the requirement is to stay with the same architecture.


 The current suggested solution is as follows:

 The HOT will be created with an AutoScalingGroup and two ScalingPolicies
 for scale out and scale in.
 Like many other NFV applications, this application also has a Life Cycle
 Manager of its own that monitors and decides when to scale.
 When scale is needed, the LCM will invoke the alarm_url exposed by these
 ScalingPolicies while providing the server index for the newly created
 server.

 The index is just one example of a parameter needed at scale out - there
 can be others.
 Much more design is needed when the desired_capacity  1 or  the
 scaling_adjustment  1 or in percentage but let's first agree that the use
 case is OK.


 -Original Message-
 From: Steven Hardy [mailto:sha...@redhat.com]
 Sent: Wednesday, March 11, 2015 12:39 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

 On Wed, Mar 11, 2015 at 09:01:04AM +, ELISHA, Moshe (Moshe) wrote:
 Hey,
 
 
 
 Can someone please share the current status of the Autoscaling
 signals to
 allow parameter passing for UserData blueprint -
  https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters.

 This is quite old, and subsequent discussions have happened which indicate
 a slightly different approach, e.g this thread here where I discuss
 approaches to signalling an AutoScalingGroup to remove a specific group
 member.  As Angus has noted, ResourceGroup already allows this via a
 different interface.


 http://lists.openstack.org/pipermail/openstack-dev/2014-December/053447.html

 We have a very concrete use case that require passing parameters on
 scale
 out.
 
 What is the best way to revive this blueprint?

 Probably the first thing is to provide a more detailed description of your
 use-case.

 I'll try to revive the AutoScalingGroup signal patch mentioned in the
 thread above this week, it's been around for a while and is probably needed
 for any interface where we pass data in to influence AutoScalingGroup
 adjustment behaviour asynchronously (e.g not via the template definition).

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

 Steve

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

 __
 OpenStack Development Mailing List (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] [heat] operators vs users for choosing convergence engine

2015-02-03 Thread Pavlo Shchelokovskyy
+1, that would ease the development and also drive adoption IMO, as people
could start using/experimenting with it earlier, and more eyes == less
bugs. You can never predict all the ways how users would use and abuse your
new shiny feature :)

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, Feb 3, 2015 at 6:48 AM, Robert Collins robe...@robertcollins.net
wrote:

 I think incremental adoption is a great principle to have and this
 will enable that.

 So +1

 -Rob

 On 3 February 2015 at 13:52, Steve Baker sba...@redhat.com wrote:
  A spec has been raised to add a config option to allow operators to
 choose
  whether to use the new convergence engine for stack operations. For some
  context you should read the spec first [1]
 
  Rather than doing this, I would like to propose the following:
  * Users can (optionally) choose which engine to use by specifying an
 engine
  parameter on stack-create (choice of classic or convergence)
  * Operators can set a config option which determines which engine to use
 if
  the user makes no explicit choice
  * Heat developers will set the default config option from classic to
  convergence when convergence is deemed sufficiently mature
 
  I realize it is not ideal to expose this kind of internal implementation
  detail to the user, but choosing convergence _will_ result in different
  stack behaviour (such as multiple concurrent update operations) so there
 is
  an argument for giving the user the choice. Given enough supporting
  documentation they can choose whether convergence might be worth trying
 for
  a given stack (for example, a large stack which receives frequent
 updates)
 
  Operators likely won't feel they have enough knowledge to make the call
 that
  a heat install should be switched to using all convergence, and users
 will
  never be able to try it until the operators do (or the default switches).
 
  Finally, there are also some benefits to heat developers. Creating a
 whole
  new gate job to test convergence-enabled heat will consume its share of
 CI
  resource. I'm hoping to make it possible for some of our functional
 tests to
  run against a number of scenarios/environments. Being able to run tests
  under classic and convergence scenarios in one test run will be a great
 help
  (for performance profiling too).
 
  If there is enough agreement then I'm fine with taking over and updating
 the
  convergence-config-option spec.
 
  [1]
 
 https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

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

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


  1   2   >