Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.
On 07/24/2015 12:59 PM, Zaro wrote:
Hello Tang, Openstack slaves only have a single executor so what you
are probably seeing is due to using build slaves that have multiple
executors. There were a few bugs[1] that was fixed recently around
these types of deadlock issues. The new gearman-plugin release[2]
contains fixes for those issues. Also if you want to test the
gearman-plugin with Jenkins independently of zuul you can use the
simple gearman-plugin-client[3] to send jobs your gearman server to
see if the jobs get built.
[1] https://issues.jenkins-ci.org/browse/JENKINS-28891 and
https://issues.jenkins-ci.org/browse/JENKINS-25867
[2]
http://repo.jenkins-ci.org/repo/org/jenkins-ci/plugins/gearman-plugin/0.1.2/
[3] https://github.com/zaro0508/gearman-plugin-client
Hi Zaro,
Thanks for the reply.
But I updated the gearman plugin to 0.1.2, and used the
gearman-plugin-client to submit jobs.
# python gear_client.py -s localhost
--function=build:noop-check-communication
Sat Jul 25 14:16:57 2015
Sending job: build:noop-check-communication to localhost with
params={'OFFLINE_NODE_WHEN_COMPLETE': 'false', 'uuid':
'08ad7a195237493d91eea55789e76128'}
Waiting for jobs to finish.
It doesn't work. The job submitted by the client is also pending.
BTW, I cannot see the job submitted by client in my Jenkins GUI. Is that
correct ?
Thanks.
-Khai
On Thu, Jul 23, 2015 at 9:13 PM, Tang Chen tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:
On 07/24/2015 12:00 PM, Tang Chen wrote:
On 07/24/2015 10:08 AM, Tang Chen wrote:
On 07/23/2015 11:44 PM, Asselin, Ramy wrote:
Are you running on 'master' nodes? I remember seeing
an issue where with a recent version of Jenkins or a
plugin where it doesn't execute jobs on the master node.
But when run on non-master jenkins slaves, it works fine.
I checked my configuration, and made sure these things:
1. I have only a master node, no slave node.
2. I have 20 idle executors on master node.
3. My master node is online.
4. My master node is set to Utilize this node as much as
possible.
5. zuul is able to be notified by Gerrit, and tell Jenkins
to start jobs.
But the jobs are always pending.
And my Gearman reports this error sometimes.
2015-07-25 10:50:44,914 ERROR gear.Server: Exception in poll loop:
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/gear/__init__.py,
line 2614, in _doPollLoop
self._pollLoop()
File
/usr/local/lib/python2.7/dist-packages/gear/__init__.py,
line 2626, in _pollLoop
ret = self.poll.poll()
IOError: [Errno 4] Interrupted system call
Not sure if it has anything to do with this problem.
In Jenkins GUI, Gearman connection is tested successfully on
127.0.0.1:4730 http://127.0.0.1:4730.
Seeing from zuul debug log, Gearman has successfully submitted the
jobs.
2015-07-25 11:42:09,255 DEBUG zuul.Scheduler: Adding trigger
event: TriggerEvent patchset-created openstack-dev/sandbox master
205360,1
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Done adding trigger
event: TriggerEvent patchset-created openstack-dev/sandbox master
205360,1
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Run handler awake
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Fetching trigger event
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Processing trigger
event TriggerEvent patchset-created openstack-dev/sandbox master
205360,1
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:
Event TriggerEvent patchset-created openstack-dev/sandbox master
205360,1 for change Change 0x7ff518312c10 205360,1 matched
EventFilter types: patchset-created in pipeline
IndependentPipelineManager check
2015-07-25 11:42:09,257 INFO zuul.Scheduler: Adding
openstack-dev/sandbox, Change 0x7ff518312c10 205360,1 to
Pipeline check
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:
Considering adding change Change 0x7ff518312c10 205360,1
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:
Checking for changes needed by Change 0x7ff518312c10 205360,1:
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:
No changes needed
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:
Adding change Change 0x7ff518312c10 205360,1 to queue
ChangeQueue check: openstack-dev/sandbox
2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager:
Event TriggerEvent patchset-created openstack-dev/sandbox master
205360,1 for change Change 0x7ff518312c10 205360,1 matched
EventFilter types: patchset-created in pipeline
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, On Thu, Jul 23, 2015 at 11:53 AM Alexander Makarov amaka...@mirantis.com wrote: Colleagues, I would like to request an exception from the Feature Freeze for Fernet tokens support added to the fuel-library in the following CR: https://review.openstack.org/#/c/201029/ Keystone part of the feature is implemented in the upstream and the change impacts setup configuration only. Please, respond if you have any questions or concerns related to this request. Thanks in advance. -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB
Matt, Your hybrid driver seems to be doing something different than what Julian was asking - namely providing some “automatic role assignments” for users stored in LDAP (unless I am not understanding your patch)? I guess you could argue that’s a restricted version of being able to create group memberships outside of LDAP (which is Julian what I think you are asking for….), but probably a somewhat different use case? Henry On 24 Jul 2015, at 05:51, Matt Fischer m...@mattfischer.com wrote: Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind. I know some of the Keystone team has pretty strong opinions about this but it works for us. And nice to run into you again... On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards bigjo...@gmail.com mailto:bigjo...@gmail.com wrote: Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Cheers, Julian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Restore OSD devices with Puppet Ceph module
On Wed, Jul 22, 2015 at 3:52 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Greetings, While working on upgrade of OpenStack with Fuel installer, I meet a requirement to re-add OSD devices with the existing data set to a Ceph cluster using Puppet module. Node is reinstalled during the upgrade, thus disks used for OSDs are not mounted at Puppet runtime. Current version of Ceph module in fuel-library only supports addition of new OSD devices. Mounted devices are skipped. Not mounted devices with Ceph UUID in GPT label are passed to 'ceph-deploy osd prepare' command that formats the device, recreates file system and all existing data is lost. I proposed a patch to allow support for OSD devices with existing data set: https://review.openstack.org/#/c/203639/2 However, this fix is very straightforward and doesn't account for different corner cases, as was pointed out by Mykola Golub in review. As this problem seems rather significant to me, I'd like to bring this discussion to the broader audience. So, here's the comment with my replies inline: Oleg, Sorry for the delay. I saw your message buth missed that apart my comments it contained your replies. See my comments below. I am not sure just reactivating disks that have a filesystem is a safe approach: 1) If you are deploying a mix of new and restored disks you may end up with confiicting OSDs joining the cluster with the same ID. 2) It makes sense to restore OSDs only if a monitor (cluster) is restored, otherwise activation of old OSDs will fail. 3) It might happen that the partition contains a valid filesystem by accident (e.g. the user reused disk/hosts from another cluster) -- it will not join the cluster because wrong fsid and credentials but the deployment will unexpectedly fail. 1) As far as I can tell, OSD device IDs are assgined by Ceph cluster based on already existing devices. So, if some ID is stored on the device, either device with the given ID already exists in the cluster and no other new device will the same ID, or cluster doesn't know about a device with the given ID, and that means we already lost the data placement before. I though here about the case when you are restoring the cluster from scratch, readding OSD devices to the osd map. So agree, in your case, if OSDs are not removed from the cluster map, it should work. 2) This can be fixed by adding a check that ensures that fsid parameter in ceph.conf on the node and cluster-fsid on the device are equal. Otherwise the device is treated like a new device, i.e. passed to 'ceph-deploy osd prepare'. Yes, I think after succesfully mounting this device we should check both that cluster ID matches and the osd ID matches what is in the cluster map. 3) This situation would be covered by previous check, in my understanding. Yes, if you add the check like above and failing the check will cause redeploy it should work. Is it posible to pass information that the cluster is restored using partition preservation? Becasue I think a much safer approach is: 1) Pass some flag from the user that we are restoring the cluster 2) Restore controller (monitor) and abort deployment if it fails. 3) When deploying osd host, if 'restore' flag is present, skip prepare step and try only activate for all disks if possible (we might want to ignore activate error, and continue with other disks so we restore osds as many as possible) The case I want to support by this change is not restoration of the whole cluster, but rather support for reinstallation of OSD node's operating system. For this case, the approach you propose seems actually more correct than my implementation. For node being reinstalled we do not expect new devices, but only ones with the existing data set, so we don't need to specifically check for it, but rather just skip prepare for all devices. If this is for the case of restoring a one OSD node I think you can go forwadrd with your approach. If it were supposed for the case when a whole cluster need to be recovered that I would prefore mine. I just though about restoring the whole cluster case, because recently some people were asking me about possibility to restore after the whole cluster lost. We still need to check that the value of fsid on the disk is consistent with the cluster's fsid. Which issues should we anticipate with this kind of approach? Apart issues already mentioned that you agreed to address I think nothing, I am looking forward at reviewing your updated patch :-) Another question that is still unclear to me is if someone really needs support for a hybrid use case when the new and existing unmounted OSD devices are mixed in one OSD node? I don't think we need to support, but if does not forbidden for users... we don't know in what state the cluster a user is trying to restore, I could imaging it having old and new osd disks. -- Best regards, Oleg Gelbukh
Re: [openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver
Hello Mike, Hello Cinder Community! After finding solutions for the two aforementioned bugs the Quobyte Cinder CI has now been reporting without finding further blocking issues. I triggered a range of rechecks in the last days that the CI has been working on in the last ~36h. Please review if these results meet your expectations. There have been a few (i think ~5) fails because of apt-get package installation issues but upon recheck those tests worked ok, too. There was one genuine failing patch reported afaicr which was also reported by jenkins and other CIs. Thanks and best regards Silvan Kaiser 2015-07-15 19:32 GMT+02:00 Silvan Kaiser sil...@quobyte.com: Hello Mike! Thanks for looking into this. Yes, the fails are caused by the two open bugs i mentioned [1,2]. We will continue to see into those. Regards Silvan [1] https://bugs.launchpad.net/nova/+bug/1465416 [2] https://bugs.launchpad.net/cinder/+bug/1473116 2015-07-15 0:07 GMT+02:00 Mike Perez thin...@gmail.com: On 17:44 Jul 14, Silvan Kaiser wrote: Hello Cinder Community! I'd like to request a feature freeze exception for change [1], re-adding the Quobyte driver to Cinder. The driver was removed in change [2] due to missing CI activity [3], it was originally added in the kilo release [4]. We've been able to remove the CI's issues and it has been reporting for a week now [5], stably testing and consistently showing two bugs (one in Nova and one in our driver/Cinder), referenced on the CIs status page [6]. We're monitoring the CI results continuously and the detected bugs are beeing addressed. The complete logs can be reviewed at [7]. CI status changes are published on the Quobyte CI Status page in the wiki [6], where there’s also our contact information. Thanks a lot for considering and best regards Silvan Kaiser (kaisers/casusbelli in IRC) [1] https://review.openstack.org/#/c/201507/ [2] https://review.openstack.org/#/c/191192/ [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068609.html [4] https://review.openstack.org/#/c/94186/ [5] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069183.html [6] https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI [7] http://176.9.127.22:8081/?C=M;O=D The last 120 jobs have failed. Here's a paste of the 60 of them: http://paste.openstack.org/show/375484/ -- Mike Perez __ OpenStack Development Mailing 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. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- -- *Quobyte* GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ OpenStack Development Mailing List (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] [all] cross project communication: Return request-id to caller
Hi Devs, X-Openstack-Request-Id. We have analysed python-cinderclient, python-glanceclient, python-novaclient, python-keystoneclient and python-neutronclient to check the return types. There are 9 ways return values are returned from python clients: 1. List 2. Dict 3. Resource class object 4. None 5. Tuple 6. Exception 7. Boolean (True/False, for keystoneclient) 8. Generator (for list api's in glanceclient) 9. String (for novaclient) Out of 9 we have solution for all return types except generator. In case of glance-client list api's are returning generator which is immutable. So it is not possible to return request-id in this case, which is a blocker for adopting the solution. I have added detail analysis for above return types in etherpad [2] as solution #3. If you have any suggestion in case of generation type then please let me know. [1] http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-07-21.01.log.html [2] https://etherpad.openstack.org/p/request-id Thanks Best Regards, Abhishek Kekane __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.
That is correctly, the Jenkins UI will not show any info about the gearman
queue. If job is pending in Jenkins that means it's been added to the
gearman queue and has been moved to the jenkins build queue. The jenkins
UI will only show the job once it's in the jenkins queue.
Hmm. What happens when you manually start a build by click on the build
icon in the jenkins UI? I'm wondering if maybe your labels are configured
correctly for your jobs and slaves. Are there any labels on the job or the
nodes (master or slaves)? I think the jobs would be in a pending state if
there are labels on nodes and jobs but they do not match. I would check to
see if there are any labels on the jobs and if there are then I would
remove all of the labels and try again. There are step by step directions
on how to setup the gearman-plugin in the jenkins wiki[1] which also shows
you how to debug by viewing the gearman server queue and function
registrations. Try to make sure the functions are registered correctly and
that the job is in the queue after you run the gear-client command.
A couple of questions:
What version of Jenkins are you running? I think openstack runs on 1.565.3
Also I don't think we've ever tested Jenkins and the gearman server running
on the same machine or VM. Maybe one thing you can try is to run them on
separate VMs?
[1] https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin
On Thu, Jul 23, 2015 at 11:20 PM, Tang Chen tangc...@cn.fujitsu.com wrote:
On 07/24/2015 12:59 PM, Zaro wrote:
Hello Tang, Openstack slaves only have a single executor so what you
are probably seeing is due to using build slaves that have multiple
executors. There were a few bugs[1] that was fixed recently around these
types of deadlock issues. The new gearman-plugin release[2] contains
fixes for those issues. Also if you want to test the gearman-plugin with
Jenkins independently of zuul you can use the simple
gearman-plugin-client[3] to send jobs your gearman server to see if the
jobs get built.
[1] https://issues.jenkins-ci.org/browse/JENKINS-28891 and
https://issues.jenkins-ci.org/browse/JENKINS-25867
[2]
http://repo.jenkins-ci.org/repo/org/jenkins-ci/plugins/gearman-plugin/0.1.2/
[3] https://github.com/zaro0508/gearman-plugin-client
Hi Zaro,
Thanks for the reply.
But I updated the gearman plugin to 0.1.2, and used the
gearman-plugin-client to submit jobs.
# python gear_client.py -s localhost
--function=build:noop-check-communication
Sat Jul 25 14:16:57 2015
Sending job: build:noop-check-communication to localhost with
params={'OFFLINE_NODE_WHEN_COMPLETE': 'false', 'uuid':
'08ad7a195237493d91eea55789e76128'}
Waiting for jobs to finish.
It doesn't work. The job submitted by the client is also pending.
BTW, I cannot see the job submitted by client in my Jenkins GUI. Is that
correct ?
Thanks.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, I vote -1 for the same reasons. Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. So, the next steps as I see them are: 1) Freeze feature in fuel 2) Submit a spec to openstack puppet to make the feature completed (address revocation, expiration, rotation of the fernet tokens). This also seems related to the already existing blueprint for fuel [1] and the mail thread [2] 3) Implement the feature upstream 4) Backport this to fuel fork in 8.0, or consume it upstream directly in the case the related blueprint [3] will be already implemented by that time. [0] https://review.openstack.org/185441 [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.
Hi Zaro,
Thanks to reply.
On 07/24/2015 03:06 PM, Zaro wrote:
That is correctly, the Jenkins UI will not show any info about the
gearman queue. If job is pending in Jenkins that means it's been
added to the gearman queue and has been moved to the jenkins build
queue. The jenkins UI will only show the job once it's in the jenkins
queue.
Hmm. What happens when you manually start a build by click on the
build icon in the jenkins UI? I'm wondering if maybe your labels are
configured correctly for your jobs and slaves. Are there any labels
on the job or the nodes (master or slaves)? I think the jobs would be
in a pending state if there are labels on nodes and jobs but they do
not match. I would check to see if there are any labels on the jobs
and if there are then I would remove all of the labels and try again.
There are step by step directions on how to setup the gearman-plugin
in the jenkins wiki[1] which also shows you how to debug by viewing
the gearman server queue and function registrations. Try to make sure
the functions are registered correctly and that the job is in the
queue after you run the gear-client command.
A couple of questions:
What version of Jenkins are you running? I think openstack runs on
1.565.3
Also I don't think we've ever tested Jenkins and the gearman server
running on the same machine or VM. Maybe one thing you can try is to
run them on separate VMs?
I don't have any label, and only a master, no slave.
My jenkins is 1.609.1.
The whole problem is described here:
http://paste.openstack.org/show/405051/
Please help to check and see.
BTW, I post the problem to #openstack-infra IRC channel. You can join
into that meeting if you'd like to.
Thanks.
[1] https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin
On Thu, Jul 23, 2015 at 11:20 PM, Tang Chen tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:
On 07/24/2015 12:59 PM, Zaro wrote:
Hello Tang, Openstack slaves only have a single executor so what
you are probably seeing is due to using build slaves that have
multiple executors. There were a few bugs[1] that was fixed
recently around these types of deadlock issues. The new
gearman-plugin release[2] contains fixes for those issues. Also
if you want to test the gearman-plugin with Jenkins independently
of zuul you can use the simple gearman-plugin-client[3] to send
jobs your gearman server to see if the jobs get built.
[1] https://issues.jenkins-ci.org/browse/JENKINS-28891 and
https://issues.jenkins-ci.org/browse/JENKINS-25867
[2]
http://repo.jenkins-ci.org/repo/org/jenkins-ci/plugins/gearman-plugin/0.1.2/
[3] https://github.com/zaro0508/gearman-plugin-client
Hi Zaro,
Thanks for the reply.
But I updated the gearman plugin to 0.1.2, and used the
gearman-plugin-client to submit jobs.
# python gear_client.py -s localhost
--function=build:noop-check-communication
Sat Jul 25 14:16:57 2015
Sending job: build:noop-check-communication to localhost with
params={'OFFLINE_NODE_WHEN_COMPLETE': 'false', 'uuid':
'08ad7a195237493d91eea55789e76128'}
Waiting for jobs to finish.
It doesn't work. The job submitted by the client is also pending.
BTW, I cannot see the job submitted by client in my Jenkins GUI.
Is that correct ?
Thanks.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
Do we have any success here.. ? On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz aschu...@mirantis.com wrote: Vladimir, Thanks. Can you point me to the error for perestroika? I'd be happy to take a look as well. I spent most of Friday throwing various options at the CI system to try and figure out how to get the spec to work with the CI fuel-library package building so perhaps there's a different way to handle this in the spec. -Alex On Mon, Jul 20, 2015 at 10:02 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, As I've just found out this package available here [1] is not actually build with your patch (instead it is from previous successful build). Looks like perestroika can not build this package due to some environment related issues. I've poked Dmitry Burmistrov to check it out. However, your patch is OK, make system can build this package and ISO passes BVT tests. [1] http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm Vladimir Kozhukalov On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Yes, spec is much better place to introduce this. BTW, perestroika builds new package for every commit and patch set and publishes them via HTTP. Please check here http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm if the package contains all necessary upstream modules. Vladimir Kozhukalov On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com wrote: Not until we start using it then any ci that tests with that module will validate the modules inclusion. You can check the output of the jobs as we are printing what modules are managed by librarian. -Alex On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote: Fantastic, do we have some way to validate that the module was pulled in properly as part of fuel-library CI? On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote: Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next week we are going to switch building all the packages to perestroika. And in order to gather upstream modules right before building fuel-library package, we need to change perestroika build scripts. 2) Currently we build packages using make system and you are right about the place where you need to make changes. https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82 If you create shell script, I'll help you to add it to make code. I have updated my review[0] to extract the update logic to it's own bash script that can be invoked by the build scripts. Let me know what would be the best way to wedge this in there. I think for the perestroika this would also be needed for the fuel-library build, so if you point me at that I can see if I can help make that change as well. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ Vladimir Kozhukalov On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com wrote: I believe build_repo function is the best way to do this [0]. So for fuel-library we'll need to run a shell script right from the repo before 'touch $$@'. We can make
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ OpenStack Development Mailing List (not for 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] 7.0 Release - Feature Freeze in action
Thanks Eugene! Congratulations everyone. It was not easy, but we got all essential features merged except a couple of more or less minor parts from them, which require exceptions. Unfortunately, some High priority blueprints didn't make it. Let's see what do we do about exceptions requests. Thanks, On Thu, Jul 23, 2015 at 3:06 PM Eugene Bogdanov ebogda...@mirantis.com wrote: Hello everyone, Please be informed that we have officially entered Feature Freeze state for Fuel 7.0 Release. This means that since now on we focus on bugfixing and stop accepting new code except bugfix commits. If you believe that the code for your feature still needs to be merged as an exception, please file an exception request as described in [1]. 3 Feature Freeze Exception requests have already been filed [2]. We're working closely with Feature Leads and Core Reviewers to assess risks and additional time estimations. We expect to take decisions on all 3 cases by tomorrow EOD Pacific Time and communicate them in respective threads. Thanks everyone for your contributions and collaborative efforts. Let's keep up good work. -- EugeneB [1] https://wiki.openstack.org/wiki/FeatureFreeze [2] Exception requests: #1: Environment Upgrade extensions for Nailgun API: https://review.openstack.org/#/c/192551/ #2: CLI changes of working with custom node labels: *https://review.openstack.org/#/c/204524/ https://review.openstack.org/#/c/204524/* #3: Fernet Tokens support: https://review.openstack.org/#/c/201029/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB
On 24 July 2015 at 14:50, Steve Martinelli steve...@ca.ibm.com wrote: The LDAP driver for identity shouldn't require write access to look up groups. It'll only require write access if you want to allow Keystone to create/delete/update new groups. Not sure what you mean by requires an LDAP admin to set up groups separately either. Have any more details you can share? Hi Steve Assuming LDAP access is read-only, group info would need to be set up in the LDAP server itself prior to keystone accessing it. This is not something that many large corporations would be willing to accommodate, which means you'd need to get group data from elsewhere. Hence, my suggestion! __ OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB
On 24 July 2015 at 14:51, Matt Fischer m...@mattfischer.com wrote: Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind. Oh cool, I'll check that out, thanks for the pointer. Ideally I'd like to get something in-tree, but this might be a good start. I know some of the Keystone team has pretty strong opinions about this but it works for us. There's clearly a problem that needs solving, but I'd like to hear the opinions. And nice to run into you again... Likewise! Cheers. __ OpenStack Development Mailing List (not for 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] Moving instack upstream
On 24/07/15 00:56, James Slagle wrote: On Thu, Jul 23, 2015 at 2:40 AM, Derek Higgins der...@redhat.com wrote: See below On 21/07/15 20:29, Derek Higgins wrote: Hi All, Something we discussed at the summit was to switch the focus of tripleo's deployment method to deploy using instack using images built with tripleo-puppet-elements. Up to now all the instack work has been done downstream of tripleo as part of rdo. Having parts of our deployment story outside of upstream gives us problems mainly because it becomes very difficult to CI what we expect deployers to use while we're developing the upstream parts. Essentially what I'm talking about here is pulling instack-undercloud upstream along with a few of its dependency projects (instack, tripleo-common, tuskar-ui-extras etc..) into tripleo and using them in our CI in place of devtest. Getting our CI working with instack is close to working but has taken longer then I expected because of various complications and distractions but I hope to have something over the next few days that we can use to replace devtest in CI, in a lot of ways this will start out by taking a step backwards but we should finish up in a better place where we will be developing (and running CI on) what we expect deployers to use. Once I have something that works I think it makes sense to drop the jobs undercloud-precise-nonha and overcloud-precise-nonha, while switching overcloud-f21-nonha to use instack, this has a few effects that need to be called out 1. We will no longer be running CI on (and as a result not supporting) most of the the bash based elements 2. We will no longer be running CI on (and as a result not supporting) ubuntu Should anybody come along in the future interested in either of these things (and prepared to put the time in) we can pick them back up again. In fact the move to puppet element based images should mean we can more easily add in extra distros in the future. 3. While we find our feet we should remove all tripleo-ci jobs from non tripleo projects, once we're confident with it we can explore adding our jobs back into other projects again Nothing has changed yet, I order to check we're all on the same page this is high level details of how I see things should proceed so shout now if I got anything wrong or you disagree. Ok, I have a POC that has worked end to end in our CI environment[1], there are a *LOT* of workarounds in there so before we can merge it I need to clean up and remove some of those workarounds and todo that a few things need to move around, below is a list of what has to happen (as best I can tell) 1) Pull in tripleo-heat-template spec changes to master delorean We had two patches in the tripleo-heat-template midstream packaging that havn't made it into the master packaging, these are https://review.gerrithub.io/241056 Package firstboot and extraconfig templates https://review.gerrithub.io/241057 Package environments and newtork directories I've merged these 2 (the ones against the correct branch, not the ones you abandoned :-) ) thanks 2) Fixes for instack-undercloud (I didn't push these directly incase it effected people on old versions of puppet modules) https://github.com/rdo-management/instack-undercloud/pull/5 Can you submit this on gerrithub?: https://review.gerrithub.io/#/q/project:rdo-management/instack-undercloud Duh, I don't know why I thought we were using gerrit for the templates and not instack*, sorry https://review.gerrithub.io/241257 https://review.gerrithub.io/241257 3) Add packaging for various repositories into openstack-packaging I've pulled the packaging for 5 repositories into https://github.com/openstack-packages https://github.com/openstack-packages/python-ironic-inspector-client https://github.com/openstack-packages/python-rdomanager-oscplugin https://github.com/openstack-packages/tuskar-ui-extras https://github.com/openstack-packages/ironic-discoverd https://github.com/openstack-packages/tripleo-common I havn't imported these into gerrithub (incase following discussion we need to delete them again) but assuming we're in agreement we should pull them into gerrithub) 4) update rdoinfo https://github.com/redhat-openstack/rdoinfo/pull/69 If everybody is happy with all above we should merge this, all of the packages needed will now be on the delorean master repository 5) Move DELOREAN_REPO_URL in tripleo-ci to a new delorean repo that includes all of the new packages 6) Take most of the workarounds out of this patch[1] and merge it 7) Reorg the tripleo ci tests (essentially remove all of the bash element based tests). 3 - 7 sound good to me. 8) Pull instack, instack-undercloud, python-rdomanager-oscplugin, triple-common, tuskar-ui-extras and maybe more into the upstream gerrit +1, note that tripleo-common is already in gerrit/git.openstack.org (http://git.openstack.org/cgit/openstack/tripleo-common) ack, thanks, I've updated the patch to rdoinfo From here
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Yes, it is the only CR left (https://review.openstack.org/#/c/204321/). It is tested manually, is on review and should be merged today or the next workday. Aleksey Kasatkin On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (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] [FFE] FF Exception request for Custom node attributes feature
Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (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] FF Exception request for Templates for Networking feature
Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (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] [FFE] FF Exception request for Env Upgrade feature
Hi, If we have a rule that feature freeze exceptions should have essential priority, I'm not sure if it matters how risky it's, the risk is low, but it's not zero. Thanks, On Thu, Jul 23, 2015 at 9:09 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Oleg, considering that your feature is essential for the release, sounds like there is no way we can't give an exception. I'm glad that it's perceived by low risk by core reviewer from Nailgun team (Evgeny). If there are no concerns from other, then we are giving FF exception. However, I'd like to understand how much it will take to finish this work and additional resources required. We need to switch to bugfix work, and the more we continue working on features / enhancements, the less confidence I have that we can meet HCF deadline. Thanks, On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote: Hi, The patch into Nailgun requires additional work to do, but as far as I can see it doesn't affect any other parts of the system, also it's implemented as an extension, which means if the feature will introduce bugs which we won't be able to fix in a required time, it can be easily disabled without removing from master with just removing one line from a file [1] (removing it from extensions list). So I think it's ok to accept environment upgrade feature as an exception for feature freeze. Thanks, [1] https://review.openstack.org/#/c/202969/7/nailgun/nailgun/extensions/base.py On Wed, Jul 22, 2015 at 10:18 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Environment Upgrade extensions added to the Nailgun API [1]. The Nailgun side of the feature is implemented in the following CRs: https://review.openstack.org/#/q/status:open+topic:bp/nailgun-api-env-upgrade-extensions,n,z These changes are implemented as an extension [2] to the Nailgun. It barely touches the core code and doesn't change the existing functionality. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://review.openstack.org/#/c/192551/ [2] https://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z -- Best regards, Oleg Gelbukh __ OpenStack Development Mailing List (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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On 24 July 2015 at 05:00, Julian Edwards bigjo...@gmail.com wrote: Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Hey Julian, Can I suggest reading this excellent write up by Adam Young? http://adam.younglogic.com/2013/10/read-only-ldap-in-keystone/ Tl;DR is that the *User* management can come from LDAP via the Identity driver, but the Project/Tenants and Roles on these come from the *Assignment* driver via SQL - almost as an overlay. This would seem to solve the issue you outline? As a side note, I had a comparable idea for an external AuthN driver to plug into legacy RBAC systems but this area of Keystone wants to focus on Federation rather than extending interaction at other levels. You may fine the thread of interest: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048639.html Thanks -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (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] Need your check whether these bps are OK for Liberty
Hi Mike, I kindly need your help to have a check whether the following blueprints are OK to be merged in Liberty: https://blueprints.launchpad.net/cinder/+spec/huawei-storage-volume-migration-support https://blueprints.launchpad.net/cinder/+spec/huawei-driver-fc-zone-enhancement https://blueprints.launchpad.net/cinder/+spec/huawei-storage-multiple-pools-support https://blueprints.launchpad.net/cinder/+spec/huawei-storage-iscsi-multipath-support https://blueprints.launchpad.net/cinder/+spec/support-smartx-for-huawei-volume-driver https://blueprints.launchpad.net/cinder/+spec/huawei-driver-support-retype The corresponding code are already committed and are under review now: https://review.openstack.org/#/c/188251/ https://review.openstack.org/#/c/188365/ https://review.openstack.org/#/c/188732/ https://review.openstack.org/#/c/202023/ https://review.openstack.org/#/c/201578/ https://review.openstack.org/#/c/201406/ https://review.openstack.org/#/c/201485/ These blueprints are all for the existing cinder driver, and just try to add some furthers that other drivers already have. And the corresponding Third Party CI are reporting stably now. I just want you to have a check whether these bps are OK for Liberty or there is something I forgot to do and need to complete. Thanks and best regards, -- Liuxinguo __ OpenStack Development Mailing List (not for 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][python-fuelclient] Implementing new commands
Hi all, I think that in current situation the best solution will be to add new features for the both versions of client. It may cause a little slowing down of developing each feature, but we won't have to return to them in future. 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com: Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C.. but only if implementing support in either fuel or fuel2 may be postponed to SCF. Thanks, Igor On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote: Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client __ OpenStack Development Mailing List (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][python-fuelclient] Implementing new commands
FWIW, I'm for option B, combined with clear timeline for porting features of fuel-variant to fuel2. For example, we are developing client-side functions for fuel-octane (cluster upgrade) extensions only for fuel2, and don't plan to implement it for 'fuel'. The main reason why we can't just drop 'fuel', or rather switch it to fuel2 syntax, IMO, is the possibility that someone somewhere uses its current syntax for automation. However, if the function is completely new, the automation of this function should be implemented with the new version of syntax. -- Best regards, Oleg Gelbukh On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev fzhad...@mirantis.com wrote: Hi all, I think that in current situation the best solution will be to add new features for the both versions of client. It may cause a little slowing down of developing each feature, but we won't have to return to them in future. 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com: Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C.. but only if implementing support in either fuel or fuel2 may be postponed to SCF. Thanks, Igor On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote: Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com : Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1]
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands
Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.
On 07/24/2015 03:36 PM, Tang Chen wrote:
Hi Zaro,
Thanks to reply.
On 07/24/2015 03:06 PM, Zaro wrote:
That is correctly, the Jenkins UI will not show any info about the
gearman queue. If job is pending in Jenkins that means it's been
added to the gearman queue and has been moved to the jenkins build
queue. The jenkins UI will only show the job once it's in the
jenkins queue.
Hmm. What happens when you manually start a build by click on the
build icon in the jenkins UI?
If I click the build icon in the jenkins UI, the job can run. Wired,
isn't it ?
Thanks.
I'm wondering if maybe your labels are configured correctly for your
jobs and slaves. Are there any labels on the job or the nodes
(master or slaves)? I think the jobs would be in a pending state if
there are labels on nodes and jobs but they do not match. I would
check to see if there are any labels on the jobs and if there are
then I would remove all of the labels and try again. There are step
by step directions on how to setup the gearman-plugin in the jenkins
wiki[1] which also shows you how to debug by viewing the gearman
server queue and function registrations. Try to make sure the
functions are registered correctly and that the job is in the queue
after you run the gear-client command.
A couple of questions:
What version of Jenkins are you running? I think openstack runs on
1.565.3
Also I don't think we've ever tested Jenkins and the gearman server
running on the same machine or VM. Maybe one thing you can try is to
run them on separate VMs?
I don't have any label, and only a master, no slave.
My jenkins is 1.609.1.
The whole problem is described here:
http://paste.openstack.org/show/405051/
Please help to check and see.
BTW, I post the problem to #openstack-infra IRC channel. You can join
into that meeting if you'd like to.
Thanks.
[1] https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin
On Thu, Jul 23, 2015 at 11:20 PM, Tang Chen tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:
On 07/24/2015 12:59 PM, Zaro wrote:
Hello Tang, Openstack slaves only have a single executor so
what you are probably seeing is due to using build slaves that
have multiple executors. There were a few bugs[1] that was
fixed recently around these types of deadlock issues. The new
gearman-plugin release[2] contains fixes for those issues. Also
if you want to test the gearman-plugin with Jenkins
independently of zuul you can use the simple
gearman-plugin-client[3] to send jobs your gearman server to see
if the jobs get built.
[1] https://issues.jenkins-ci.org/browse/JENKINS-28891 and
https://issues.jenkins-ci.org/browse/JENKINS-25867
[2]
http://repo.jenkins-ci.org/repo/org/jenkins-ci/plugins/gearman-plugin/0.1.2/
[3] https://github.com/zaro0508/gearman-plugin-client
Hi Zaro,
Thanks for the reply.
But I updated the gearman plugin to 0.1.2, and used the
gearman-plugin-client to submit jobs.
# python gear_client.py -s localhost
--function=build:noop-check-communication
Sat Jul 25 14:16:57 2015
Sending job: build:noop-check-communication to localhost with
params={'OFFLINE_NODE_WHEN_COMPLETE': 'false', 'uuid':
'08ad7a195237493d91eea55789e76128'}
Waiting for jobs to finish.
It doesn't work. The job submitted by the client is also pending.
BTW, I cannot see the job submitted by client in my Jenkins GUI.
Is that correct ?
Thanks.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. Getting rid of the global CONF object usage in all these files trivially now solves the circular dependancy import problem, as well as improving the overall structure and isolation of our code, freeing all these methods from unexpected side-effects from global variables. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for 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][python-fuelclient] Implementing new commands
Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C.. but only if implementing support in either fuel or fuel2 may be postponed to SCF. Thanks, Igor On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote: Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client __ OpenStack Development Mailing List (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:
Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova
On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote: In fact, I did an example of what I thought it would look like already: https://review.openstack.org/#/c/205154/ I welcome discussion on this, especially from people who couldn't make it to the mid-cycle. Its up to y'all if you do that on this thread or in that review. I think this kind of thing needs to have a spec proposed for it, so we can go through the details of the problem and the design considerations for it. This is especially true considering this proposal comes out of a f2f meeting where the majority of the community was not present to participate in the discussion. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for 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-tc][deb-packaging] Updated proposal for OpenStack deb packages
Igor Yozhikov wrote: Hello again to everyone, resending this letter due to typo in the topic of the previous letter, apologize for this. * Introductory words:* I want to present renewed proposal for packaging of OpenStack components for deb based Linux distributions. In case of stackforge retirement, I believe that new repositories for deb specs should appears under the //openstack// name-space instead of //stackforge//. This and further steps was also advised by dhellmann, anteaya and angdraug at #openstack-meeting irc channel during/after TechnicalCommittee meeting http://paste.openstack.org/show/399927/ yesterday 21 of Jul 2015. Also it would be great to discuss all of this during next TC meeting July 28th. Igor, The following was proposed to the TC, but needs a revision to match what you propose here: https://review.openstack.org/#/c/185187/ Would you mind updating the proposed change there ? That way we could discuss it at the TC next week... -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
wants why there should be a constraint which is related to some internal id
in Nailgun database? For example if he deleted node-5 and then he wants
to replace this node with another one, he can and should be able to provide
for this replacement node hostname node-5, even if node's id in the database
is 6.
Thanks,
On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward xar...@gmail.com wrote:
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com
wrote:
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames
in format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
How is this a main use case? This is exactly what we should not support.
If they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom
node naming in this case.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (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
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin ness not properly scoped
Adam Young wrote: [...] There should be no Global Admin Tokens. They are a security risk, and violate the principal of Least Privilege. https://en.wikipedia.org/wiki/Principle_of_least_privilege. Thanks for taking on this long-standing issue. Should we have some cross-project spec to scope the work needed in the various projects and track overall acceptance of the plan ? -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] why do we gate tempest using q-vpn not q-l3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/23/2015 05:52 PM, Armando M. wrote: On 23 July 2015 at 05:25, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi all, I've stumbled on this one. It turns out we gate neutron against openstack installation that runs vpn-agent instead of l3-agent [1]. Is it really what we want to do? I would expect that gate validates l3 agent as is, as is usually found on usual installations that do not need vpn connections. We run with q-fwaas as well (which then lead to [1] as command line for the L3 agent execution). Same can be said for fwaas, no? [1] + setsid /usr/local/bin/neutron-vpn-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini --config-file=/etc/neutron/vpn_agent.ini --config-file /etc/neutron/fwaas_driver.ini Or is it the neat way we make sure we don't break vpn-agent? The tempest-full test suite used to exercise network core capabilities as well as advanced services (with test_vpnaas_extensions and test_fwaas_extensions), now that it doesn't anymore [2] we could drop both, as coverage is ensured by the neutron-dsvm-api job. [2] https://review.openstack.org/#/c/186559/ I will only note that it effectively disabled test coverage for stable branches where we don't have those new jobs yet. Doug told in comments we have a plan to introduce those back into stable branches in several weeks, a month ago. I wonder whether we have anything reviewable to make it happen. I requested drop for advanced services from neutron tempest jobs: https://review.openstack.org/#/c/205473/ Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVsgiYAAoJEC5aWaUY1u57ZnEH/09olZehrRaovDD3sIlLEIPs cpV8fjHiBHBmpmo7DznGVcXDyk6jaJrIB0OMEwy0QkO11WDRw0cy1kH40of2Zd89 jImnW/Xo0KQQTHhjwm7J6tZ8lZI6SMR40WG40Hi9ZpaWVfIZPTl0SoIEzZwF8sgs cAFTxPd9h7Uc1MGM91Uazx112sMFtVBx+RMt21o53nX/uBjS5nBkXmDVFk0XDc0A EiRdhzU1JlOeYixA3FUtHUKHVAsWsV0XPeXgJn7tI2lDuZR0cwTYPuliQjXmyjiJ z3yDAFQhmFZ8PWZcvQCEC6cy8fS4C4h/ylaM/+/GK5zhcOThe90LwWeOWB0caPw= =K3qh -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel Zabbix in deployment tasks
Hi, I've read the tickets and wondering, how can we remove zabbix completely from Nailgun/UI? We still have old environments which should be able to support zabbix, or it is not the case for experimental? In this case we should warn the user, that after upgrade he will not be able manage his previous env. Thanks, On Wed, Jul 22, 2015 at 8:59 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, The code is present in 6.1 also. https://github.com/stackforge/fuel-library/blob/stable/6.1/deployment/puppet/osnailyfacter/modular/zabbix/tasks.yaml I changed the status of bug to Confirmed for 6.1 as it's 100% done. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 21, 2015 at 10:54 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Actually, I didn't participate in that process a lot - just reviewed plugin couple of times and as I know, we had had a commits that deleted zabbix from current Fuel. There is bug about that: https://bugs.launchpad.net/fuel/+bug/1455664 There is a review: https://review.openstack.org/#/c/182615/ Seems that it should be resolved and merged to have zabbix code actually deleted from current master. On Thu, Jul 16, 2015 at 1:29 PM, Mike Scherbakov mscherba...@mirantis.com wrote: I thought it was done... Stas - do you know anything about it? On Thu, Jul 16, 2015 at 9:18 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, Working on granular deployment, I realized we still call zabbix.pp in deployment tasks. As far as I know zabbix was moved to plugin. Should we remove zabbix from 1. Deployment graph 2. fixtures 3. Tests 4. Any other places Are we going to clean up zabbix code as part of migration to plugin? -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (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] [FFE] FF Exception request for Custom node attributes feature
I apologize for my hasty email earlier. Thank you all who tried to help me but I have to revoke my additions to this feature. I completely missed the fact that labels may be changed after the deployment is done. It creates inconsistency between label values and actual values in astute.yaml on the nodes. It's bad UX and it may break a cluster in some circumstances. Merging my code we just add a new tech dept into Fuel and it's not we want to do. So, thank you again, and I'll come up later with a better proposal for 8.0. On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
The problem is that hostnames of nodes appear in /etc/hosts files, and
entries in those files have to be unique to make any sense. Thus, we either
need to provide a user with ability to create their own generators of node
names (not sure that's makes sense), require a user to provide a name for
every node and validate that every name is unique (which I guess the
blueprint in question implies), or provide ability to generate node
hostname by some user-defined template (prefix) suffixed with ID-based
iterator. We should choose one of options for every environment and don't
mix them, as Fedor pointed out.
-Oleg
On Fri, Jul 24, 2015 at 12:07 PM, Evgeniy L e...@mirantis.com wrote:
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
wants why there should be a constraint which is related to some internal id
in Nailgun database? For example if he deleted node-5 and then he wants
to replace this node with another one, he can and should be able to provide
for this replacement node hostname node-5, even if node's id in the
database
is 6.
Thanks,
On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward xar...@gmail.com wrote:
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com
wrote:
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames
in format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
How is this a main use case? This is exactly what we should not support.
If they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom
node naming in this case.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (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
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
+1 to merging the CLI part, if all our comments there are filed as High priority bugs and then fixed ASAP - romcheg 24 лип. 2015 о 07:58 Mike Scherbakov mscherba...@mirantis.com написав(ла): Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com mailto:ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com mailto:jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/ https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com mailto:mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com mailto:skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com mailto:ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com mailto:jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature
Colleagues, actually, i'm tottaly agree with Mike. We can merge https://review.openstack.org/#/c/196114/ w/o additional Ceilometer support (will be moved to next release). So if we merge it today we dont need FFE for this feature. Regards, Andrian On Fri, Jul 24, 2015 at 1:18 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Since we are in FF state already, I'd like to have urgent estimate from one of fuel-library cores: - holser - alex_didenko - aglarendil - bogdando aglarendil is on vacation though. Guys, please take a look at https://review.openstack.org/#/c/196114/ - can we accept it as exception? Seems to be good to go... I still think that additional Ceilometer support should be moved to the next release. Thanks, On Thu, Jul 23, 2015 at 1:56 PM Mike Scherbakov mscherba...@mirantis.com wrote: Hi Andrian, this is High priority blueprint [1] for 7.0 timeframe. It seems we still didn't merge the main part [2], and need FF exception for additional stuff. The question is about quality. If we focus on enhancements, then we don't focus on bugs. Which whether means to deliver work with lower quality of slip the release. My opinion is rather don't give FF exception in this case, and don't have Ceilometer support for this new feature. [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role [2] https://review.openstack.org/#/c/196114/ On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote: Hi, The patch patch for fuel-library https://review.openstack.org/#/c/196114/ that implements 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires additional work to do (ceilometer support.), but as far as I can see it doesn't affect any other parts of the product. We plan to implement it in 3 working days (2 for implementation, 1 day for writing system test and test runs), it should not be hard since we already support ceilometer compute agent deployment on controller nodes. We need 1 DevOps engineer and 1 QA engineer to be engaged for this work. So I think it's ok to accept this feature as an exception for feature freeze. Regards, Andrian Noga Project manager Partner Centric Engineering Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen -- -- Regards, Andrian Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua __ OpenStack Development Mailing List (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][CI] gate-{name}-requirements job fails on stable/juno
Hi all, In oslo.db we recently hit a requirements checking job failure [0]. It's caused by the fact the job tries to import a module from openstack_requirements package, which is missing in stable/juno branch of requirements project [1]. The job must have been broken for stable/juno since [2] was merged. stable/kilo and master are ok, as corresponding branches of requirements project already have openstack_requirements package. There are more failures in other projects [3]. Please advice on how we are going to fix this to unblock changes to requirements for stable/juno. Thanks, Roman [0] http://logs.openstack.org/75/186175/1/check/gate-oslo.db-requirements/b3a973d/console.html [1] https://github.com/openstack/requirements/tree/stable/juno [2] https://review.openstack.org/#/c/195857/2 [3] https://review.openstack.org/#/q/file:requirements.txt+branch:stable/juno+status:open,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)
Team, I would like to request an exception from the Feature Freeze for [1] fix. It requires changes in fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already tested, I'm fixing UT now. BP - [4] Code has backward-compatibility mode. I need one more week to finish it. Also I'm asking someone to be an assigned code-reviewer for this ticket to speed-up review process. Thanks [1] https://bugs.launchpad.net/fuel/+bug/1464656 [2] https://review.openstack.org/#/c/204814 [3] https://review.openstack.org/#/c/204811 [4] https://review.openstack.org/#/c/203062 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://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] FF Exception request for Templates for Networking feature
I agree here with Evgeniy. Even if it's not a trivial change, we cannot leave a new API in such shape. 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] talk proposal for Tokyo Summit: Interconnecting Neutron and BGP-based operator VPNs
Salut à tous, On propose un talk Interconnecting Neutron and BGP-based operator VPNs pour le summit de Tokyo. Ca aidera si on a des votes, merci d'avance ! ** https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/5747 http://email.openstack.org/wf/click?upn=KDXUwHsqj2QOekTYbWDSGOQec3b75Fovt3HVvm3PiyFsTeh9f03Hig50WTaMW6Vh9UXoSwNRuH08K4E0EcoOIkw4vHH2-2B8q1HiFESJ3lLmkd-2Bmh4RS9dNB-2BTdYVxI1o-2B_kO8kwhiD9hOkVQT6GsYQuqzD-2BTRmjelSvRh14-2FBDsNUKycmEvJ3wlDJ2ugmCO1hpAbo3k8ynzRCdVbeYMbiI6byGrOEMxCU17MpoT-2Btn6xqAUoFEMDsvEdYIxpmTrG9OmLbYunZTqdQAZcFHfntocgDpA7SM6SaQoh-2FeQtCCzdVcvX9vJpjrDc7S4G-2F-2FL2-2ByO6qIswAXtNNW8iVX3QW-2FC5nO4L90E-2Bw0UQHwu4o0ADiTpOPiBsQlRyfevNQmorduMkJuUi7yb59g7pJqIbVzaCCsIpDEL7hfzqaTujaaziIUw0NIz66BFodl9dFboSuLvG-2FH88234duhIW0ycMwdlN0DjQi7PFYQGQmLWmeoeyZhau0OWEyEsWxOT0a-2F4NMnZBZ87mTXb8Mcm8a4MJK6yg-3D-3D -Thomas _ 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
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On Friday 24 July 2015 09:29:32 Dave Walker wrote: On 24 July 2015 at 05:00, Julian Edwards bigjo...@gmail.com wrote: Tl;DR is that the *User* management can come from LDAP via the Identity driver, but the Project/Tenants and Roles on these come from the *Assignment* driver via SQL - almost as an overlay. This would seem to solve the issue you outline? As far as I understand the issue is that corps want to have users in read-only LDAP and have an ability to create groups outside of LDAP, in SQL. Am I right? -- Best regards, Boris Bobrov __ OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB
On 24 July 2015 at 15:26, Boris Bobrov bbob...@mirantis.com wrote: On Friday 24 July 2015 09:29:32 Dave Walker wrote: On 24 July 2015 at 05:00, Julian Edwards bigjo...@gmail.com wrote: Tl;DR is that the *User* management can come from LDAP via the Identity driver, but the Project/Tenants and Roles on these come from the *Assignment* driver via SQL - almost as an overlay. This would seem to solve the issue you outline? As far as I understand the issue is that corps want to have users in read-only LDAP and have an ability to create groups outside of LDAP, in SQL. Am I right? I think as you described can already be done. There are SQL and LDAP backends for both Assignment and Identity and a deployment can choose their own mix, including RO for LDAP. However, if you have an enterprise resource / entitlement management system which can map to OpenStack Assignments, but not exposed via SAML or LDAP - you either need to mirror in SQL or SOL. User authentication is pretty solid via the external Identity management as you can simply use anything that sets REMOTE_USER upstream in the web server (Kerberos or X.509 makes sense). The issue I wanted to solve was 'backend' AuthN and AuthZ integration to external systems. The current Federation mechanism relies on getting Assignment (Roles and Groups) from keystone edge service via SAML assertions. I needed to keep Keystone stateless, but use deployment specific plugin to grab User, Project and Role data from a third-party entitlement system at runtime (via a backend plugin). The direction of Keystone (based on the thread I linked to and summit conversations) is to embrace edge Federation more and reduce the backend integration. Which makes sense really.. but when hit with legacy enterprise resource, entitlement and access systems that don't support SAML, the need to absorb tech' debt is a balance. Thankfully, Keystone still makes it quite easy to maintain custom backend drivers. -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (not for 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] librarian-puppet integration, need help with build tasks for fuel-library
Just to followup since the required packages are finally available, the patches have been updated and are passing CI now. https://review.openstack.org/#/c/202763/ -Alex On Fri, Jul 24, 2015 at 8:32 AM, Alex Schultz aschu...@mirantis.com wrote: Unfortunately we got stuck with package availability issues. It was successful without using librarian packages for building, but since we need to leverage packages the work to get packaged versions of the code has unfortunately blocked this. I've got the packages built, but the time to get them to an publicly available mirror has killed this effort. Since it's now past FF, I don't think this will be for 7.0 but we should be in a good spot to start early for 8.0. Also I've switched to librarian-puppet-simple since it has far fewer dependencies and we only want to support git references for packages. Once that makes it to the mirror and can pass CI, this change would in theory be ready. I'm continuing to keep an eye on the changes so that we'll be ready to start running with them when the time comes. -Alex On Fri, Jul 24, 2015 at 1:41 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Do we have any success here.. ? On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz aschu...@mirantis.com wrote: Vladimir, Thanks. Can you point me to the error for perestroika? I'd be happy to take a look as well. I spent most of Friday throwing various options at the CI system to try and figure out how to get the spec to work with the CI fuel-library package building so perhaps there's a different way to handle this in the spec. -Alex On Mon, Jul 20, 2015 at 10:02 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, As I've just found out this package available here [1] is not actually build with your patch (instead it is from previous successful build). Looks like perestroika can not build this package due to some environment related issues. I've poked Dmitry Burmistrov to check it out. However, your patch is OK, make system can build this package and ISO passes BVT tests. [1] http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm Vladimir Kozhukalov On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Yes, spec is much better place to introduce this. BTW, perestroika builds new package for every commit and patch set and publishes them via HTTP. Please check here http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm if the package contains all necessary upstream modules. Vladimir Kozhukalov On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com wrote: Not until we start using it then any ci that tests with that module will validate the modules inclusion. You can check the output of the jobs as we are printing what modules are managed by librarian. -Alex On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote: Fantastic, do we have some way to validate that the module was pulled in properly as part of fuel-library CI? On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote: Hey All, I've figured it out without having to modify the fuel-main build code. I've updated the fuel-library spec with a build action that invokes the script to pull down external modules. Please take some time to review the two reviews out there for this change to see if there are any issues with the way it is implemented. https://review.openstack.org/#/c/202763/ https://review.openstack.org/#/c/202767/ This is a first step towards being able to pull in unmodified external puppet modules. Thanks, -Alex On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com wrote: On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Great that you did this. Now I think I can prepare fuel-main patch to invoke this script right before building fuel-library package. I'll add you to review it. Is it ok if I do this monday morning? Keep in minde we agreeded to a deadline to get this sorted and in shape to land by EOD monday or we will have to retain the old, and crappy fork method. If possible please work out how this needs to work as early as possible so Alex can continue. Vladimir Kozhukalov On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com wrote: Hey Vladimir, On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Alex, Gathering upstream modules certainly should be implemented as a separate script so as to make it possible to use it wherever we need this (tests, builds, etc.) According to builds there are two things 1) We have so called perestroika package build system (Dmitry Burmistrov is a main contributor here). By the end of next
[openstack-dev] OPENSTACK with CEPH storage backend cant down size an instance
Hi All I am having some trouble with down sizing an instance, I can resize the instance from say small flavour to medium flavour but when trying to resize the instance back from medium to small I get the following : Error: Failed to perform requested operation on instance jg-10, the instance has an error status: Please try again later [Error: Flavor's disk is too small for requested image.]. I am using ceph as the storage backend clustered over 3 nodes with 3 pools volumes vms images -- Regards, James This e-mail contains confidential information or information belonging to Servecentric Ltd and is intended solely for the addressee(s). The unauthorized disclosure, use, dissemination or copy (either in whole or in part) of this e-mail, or any information it contains, is prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Servecentric Ltd. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Servecentric shall not be liable for the contents of this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and of the email's deletion. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [requirements] propose adding Robert Collins to requirements-core
Requirements reviewers, I propose that we add Robert Collins (lifeless) to the requirements-core review team. Robert has been doing excellent work this cycle with updating pip and our requirements repository to support constraints. As a result he has a full understanding of the sorts of checks we should be doing for new requirements, and I think he would make a good addition to the team. Please indicate +1 or -1 with concerns on this thread, as usual. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance][api] Response when a illegal body is sent
On 7/23/15, 19:38, michael mccune m...@redhat.com wrote: On 07/23/2015 12:43 PM, Ryan Brown wrote: On 07/23/2015 12:13 PM, Jay Pipes wrote: On 07/23/2015 10:53 AM, Bunting, Niall wrote: Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This is an example of a GET however this also applies to other requests. What should Glance do rather than throwing a 500, should it return a 400 as the user provided an illegal body Yep, this. +1, this should be a 400. It would also be acceptable (though less preferable) to ignore any body on GET requests and execute the request as normal. Best, -jay i'm also +1 on the 400 band wagon 400 feels right for when Glance is operating without anything in front of it. However, let me present a hypothetical situation: Company X is operating Glance behind a load-balancing proxy. Most users talk to Glance behind the LB. If someone writes a quick script to send a GET and (for whatever reason) includes a body, they'll get a 200 with the data that would otherwise have been sent if they didn't include a body. This is because most such proxies will strip the body on a GET (even though RFC 7231 allows for bodies on a GET and explicitly refuses to define semantic meaning for them). If later that script is updated to work behind the load balancer it will be broken, because Glance is choosing to error instead of ignoring it. Note: I'm not arguing that the user is correct in sending a body when there shouldn't be one sent, just that we're going to confuse a lot of people with this. I'm also fine with either a 400 or a 200. __ OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700: Daniel P. Berrange wrote: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. Amen to that :) The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. +1 and IMHO if some driver needs some 'funky' new parameter that isn't getting passed previously, probably the driver may be built wrong, or it's not conforming to the API that is provided (and therefore either the API needs adjustments or the driver needs to be fixed); all the above IMHO is pretty standard OOP practices and I'd like to see more of it honestly :) While it's good to share common options as much as possible, there are a lot of perfectly legitimate reasons for drivers to need different configuration options. Different backends might use different authentication mechanisms, or need different ways to specify where the thing the driver is managing actually lives. The job of the driver API layer is to hide those differences so the application doesn't have to care about them. Pushing all of the options up to be API parameters defeats the purpose of that if not all drivers use all of the options. Doug Getting rid of the global CONF object usage in all these files trivially now solves the circular dependancy import problem, as well as improving the overall structure and isolation of our code, freeing all these methods from unexpected side-effects from global variables. Regards, Daniel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements] propose adding Robert Collins to requirements-core
+1 from me. Thanks for the hard work @lifeless -- dims On Fri, Jul 24, 2015 at 12:21 PM, Doug Hellmann d...@doughellmann.com wrote: Requirements reviewers, I propose that we add Robert Collins (lifeless) to the requirements-core review team. Robert has been doing excellent work this cycle with updating pip and our requirements repository to support constraints. As a result he has a full understanding of the sorts of checks we should be doing for new requirements, and I think he would make a good addition to the team. Please indicate +1 or -1 with concerns on this thread, as usual. 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 -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Aleksey, Yes, my point is those parts should be also included in the scope of FFE. Regarding to template format, it's easy to fix and after release you will not be able to change it, or you can change it, but you will have to support both format, not to brake backward compatibility. So I would prefer to see it fixed in 7.0. Thanks, On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin akasat...@mirantis.com wrote: I agree, guys, we need at least some basic validation for template when it is being loaded. Ivan Kliuk started to work on this task. And we agreed to test other types of delimiters (it is regarding ERB style template) but we have some more important issues. Evgeniy, is your meaning to include those to FFE ? Aleksey Kasatkin On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I agree here with Evgeniy. Even if it's not a trivial change, we cannot leave a new API in such shape. 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (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] [requirements] propose adding Robert Collins to requirements-core
Doug Hellmann wrote: Requirements reviewers, I propose that we add Robert Collins (lifeless) to the requirements-core review team. Robert has been doing excellent work this cycle with updating pip and our requirements repository to support constraints. As a result he has a full understanding of the sorts of checks we should be doing for new requirements, and I think he would make a good addition to the team. Please indicate +1 or -1 with concerns on this thread, as usual. +1 -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
I think the issue is groups are very nice for managing sets of users through the web ui but users can only be in groups maintained by the same backend, and ldap backends tend to be readonly. It would be very handy if groups could include users from other domains. Maybe the db could be extended to support a domain column for groups? Thanks, Kevin From: Steve Martinelli Sent: Thursday, July 23, 2015 9:50:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB The LDAP driver for identity shouldn't require write access to look up groups. It'll only require write access if you want to allow Keystone to create/delete/update new groups. Not sure what you mean by requires an LDAP admin to set up groups separately either. Have any more details you can share? Thanks, Steve Martinelli OpenStack Keystone Core Julian Edwards bigjo...@gmail.com wrote on 2015/07/24 12:00:33 AM: From: Julian Edwards bigjo...@gmail.com To: openstack-dev@lists.openstack.org Date: 2015/07/24 12:01 AM Subject: [openstack-dev] [keystone] LDAP identity driver with groups from local DB Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Cheers, Julian. __ OpenStack Development Mailing List (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] [CI] Jenkins jobs are not executed when setting up a new CI system.
Tang, Have you tried to look at the function registrations and gearman queue on the gearman server as i suggested? The instructions are in the wiki i referenced (in 'Starting the gearman workers' section). What you are seeing from the gear_client could also be from passing in a function name that does not exist. Unfortunately the simple gear_client does not check whether the passed in functions are valid so what you want to do is verify that the gearman functions have been registered by using the 'workers' command. On Fri, Jul 24, 2015 at 1:09 AM, Tang Chen tangc...@cn.fujitsu.com wrote: On 07/24/2015 03:36 PM, Tang Chen wrote: Hi Zaro, Thanks to reply. On 07/24/2015 03:06 PM, Zaro wrote: That is correctly, the Jenkins UI will not show any info about the gearman queue. If job is pending in Jenkins that means it's been added to the gearman queue and has been moved to the jenkins build queue. The jenkins UI will only show the job once it's in the jenkins queue. Hmm. What happens when you manually start a build by click on the build icon in the jenkins UI? If I click the build icon in the jenkins UI, the job can run. Wired, isn't it ? Thanks. I'm wondering if maybe your labels are configured correctly for your jobs and slaves. Are there any labels on the job or the nodes (master or slaves)? I think the jobs would be in a pending state if there are labels on nodes and jobs but they do not match. I would check to see if there are any labels on the jobs and if there are then I would remove all of the labels and try again. There are step by step directions on how to setup the gearman-plugin in the jenkins wiki[1] which also shows you how to debug by viewing the gearman server queue and function registrations. Try to make sure the functions are registered correctly and that the job is in the queue after you run the gear-client command. A couple of questions: What version of Jenkins are you running? I think openstack runs on 1.565.3 Also I don't think we've ever tested Jenkins and the gearman server running on the same machine or VM. Maybe one thing you can try is to run them on separate VMs? I don't have any label, and only a master, no slave. My jenkins is 1.609.1. The whole problem is described here: http://paste.openstack.org/show/405051/ Please help to check and see. BTW, I post the problem to #openstack-infra IRC channel. You can join into that meeting if you'd like to. Thanks. [1] https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin __ OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
Daniel P. Berrange wrote: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. Amen to that :) The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. +1 and IMHO if some driver needs some 'funky' new parameter that isn't getting passed previously, probably the driver may be built wrong, or it's not conforming to the API that is provided (and therefore either the API needs adjustments or the driver needs to be fixed); all the above IMHO is pretty standard OOP practices and I'd like to see more of it honestly :) Getting rid of the global CONF object usage in all these files trivially now solves the circular dependancy import problem, as well as improving the overall structure and isolation of our code, freeing all these methods from unexpected side-effects from global variables. Regards, Daniel __ OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
Excerpts from Daniel P. Berrange's message of 2015-07-24 15:11:19 +0100: On Fri, Jul 24, 2015 at 09:56:41AM -0400, Doug Hellmann wrote: Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. We've tried to do this in a lot of places throughout Oslo. It mostly works, until you hit a driver that uses options that the other drivers don't (oslo.messaging has this problem especially). We had a ConfigFilter class in oslo.config to enforce the isolation (an option registered on a filter object is only visible to the code that owns the filter). However, that causes challenges for value interpolation. A deployer doesn't know which options are visible to each other, and has a flat file where they can clearly see all of the values together, so they expect %(foo)s to work no matter where foo is defined. Until we solve those issues, the ConfigFilter isn't really supported. The best solution we've come up with so far is to isolate the options into groups based on the driver name, and then not allow code outside of the driver to access those options for any reason. To deal with import ordering issues, we pass ConfigObj instance around, and register options at runtime instead of import time, usually in an __init__ method. Registering an option more than once is fine. Yep, I would imagine that the nova/cmd/*.py command line entry points would trigger loading of the config file and pass the object into the service they run. The service may pass that config object on down to some classes, eg I'd expect the nova ComputeDriver to accept a config object in its constructor. Likewise the various manager classes like nova/compute/manager.py These would read the various config option values they care about and pass those into the various methods / objects that need them As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. There are, from time to time, specs proposed to provide ways for applications to reload their configuration settings without
Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API
On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote: On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? I prefer that the APIs be submitted in a spec, so that they are published on http://specs.openstack.org/openstack/neutron-specs/ At least there, changes can be reviewed by others - the problem with the wiki is it can be changed without any review. At least with neutron-specs it's versioned and there is discussion that is captured and preserved. I'm +1 on cleaning/deleting stuff from the wiki about the old SFC API -- Sean M. Collins __ OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
On Fri, Jul 24, 2015 at 2:19 PM, Doug Hellmann d...@doughellmann.com wrote: One idea I've tossed around a bit is having options defined in data files that ship with the code, rather than being inside the Python code itself. Maybe a first pass at that would be to offload the help to a separate file? If that seems interesting, I could experiment with adding some features to oslo.config to support it. So, that's kind of what I was trying out. One idea was to put the help strings in a separate module and just reference them in the source code. My concern however is that if they're not with the code they wont get updated which things change. Instead, if we move the entire flag people are still forced to notice the help string and that its wrong when they tweak things. Its not perfect though, and ideas are very welcome. The basic problem is that if you try to configure SSL, there are a whole heap of different options available, and its not clear how they interact and what you need to twiddle to make things work unless you read the code. Michael -- Rackspace Australia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][testing] How to modify DSVM tests to use a DevStack plugin?
Hi, I've created a DevStack plugin for the neutron-vpnaas repo. Now, I'm trying to remove the q-vpn service setup from the DevStack repo ( https://review.openstack.org/#/c/201119/). However, I'm hitting an issue in that (almost) every test that uses DevStack fails, because it is no longer setting up q-vpn. How should I modify the tests, so that they setup the q-vpn service, in light of the fact that there is a DevStack plugin available for it. Is there some common place that I can do the enable_plugin neutron-vpnaas... line? Thanks! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][testing] How to modify DSVM tests to use a DevStack plugin?
On Fri, Jul 24, 2015, at 02:05 PM, Paul Michali wrote: Hi, I've created a DevStack plugin for the neutron-vpnaas repo. Now, I'm trying to remove the q-vpn service setup from the DevStack repo ( https://review.openstack.org/#/c/201119/). However, I'm hitting an issue in that (almost) every test that uses DevStack fails, because it is no longer setting up q-vpn. How should I modify the tests, so that they setup the q-vpn service, in light of the fact that there is a DevStack plugin available for it. Is there some common place that I can do the enable_plugin neutron-vpnaas... line? Your devstack plugin should enable the service. Then in your jobs you just need to enable the plugin which will then enable the vpn service. There should be plenty of prior art with the ec2api plugin, glusterfs plugin, and others. Clark __ OpenStack Development Mailing List (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] [os-ansible-deployment] [openstack-ansible] [Searchlight] Specs for Liberty (v12.0.0)
Hey all, It looks like we've started accepting specifications for Liberty development. Is this accurate? If so, I'd like to start writing one to add Searchlight. Anyone experimenting with Glance's Catalog Index Search in Kilo will want Searchlight in Liberty. Cheers, Ian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API
Hi Paul, -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Thursday, July 23, 2015 7:46 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? Wiki page [1] largely duplicates the content of the spec in [2] I dislike duplication of information because it's likely to get out of sync. I'd rather use hyperlinks whenever possible. However, linking to a Gerrit review isn't the most end user friendly way of presenting an API. One option is to link to the GitHub version of the rendered RST file [3] but I'd like to know if there are any other preferred practices. Cathy Agree with you. Let's remove those duplicate sections and add the link to the rendered RST file [3] if there are no other preferred practices. Would you like to take care of this or I can clean this up? Thanks, Cathy [1] https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining [2] https://review.openstack.org/#/c/192933/ [3] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API
Hi Sean, -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: Friday, July 24, 2015 7:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote: On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? I prefer that the APIs be submitted in a spec, so that they are published on http://specs.openstack.org/openstack/neutron-specs/ At least there, changes can be reviewed by others - the problem with the wiki is it can be changed without any review. At least with neutron-specs it's versioned and there is discussion that is captured and preserved. Cathy +1. Cathy Do you know the process of getting the API spec published at http://specs.openstack.org/openstack/neutron-specs/? We can port the merged networking-sfc API spec and the latest patch over. Or we have to wait until we have some working codes for key functionality? I'm +1 on cleaning/deleting stuff from the wiki about the old SFC API Cathy +1 too. -- Sean M. Collins __ OpenStack Development Mailing List (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] talk proposal for Tokyo Summit: Interconnecting Neutron and BGP-based operator VPNs
You probably wanted to use another mailing-list (internal maybe?) but otherwise this ML is in English and do not promote talk proposals, but rather focus on OpenStack development. Though I'll vote for your talk, it looks really cool :-) On Fri, Jul 24, 2015 at 11:40 AM, thomas.mo...@orange.com wrote: Salut à tous, On propose un talk Interconnecting Neutron and BGP-based operator VPNs pour le summit de Tokyo. Ca aidera si on a des votes, merci d'avance ! http://email.openstack.org/wf/click?upn=KDXUwHsqj2QOekTYbWDSGOQec3b75Fovt3HVvm3PiyFsTeh9f03Hig50WTaMW6Vh9UXoSwNRuH08K4E0EcoOIkw4vHH2-2B8q1HiFESJ3lLmkd-2Bmh4RS9dNB-2BTdYVxI1o-2B_kO8kwhiD9hOkVQT6GsYQuqzD-2BTRmjelSvRh14-2FBDsNUKycmEvJ3wlDJ2ugmCO1hpAbo3k8ynzRCdVbeYMbiI6byGrOEMxCU17MpoT-2Btn6xqAUoFEMDsvEdYIxpmTrG9OmLbYunZTqdQAZcFHfntocgDpA7SM6SaQoh-2FeQtCCzdVcvX9vJpjrDc7S4G-2F-2FL2-2ByO6qIswAXtNNW8iVX3QW-2FC5nO4L90E-2Bw0UQHwu4o0ADiTpOPiBsQlRyfevNQmorduMkJuUi7yb59g7pJqIbVzaCCsIpDEL7hfzqaTujaaziIUw0NIz66BFodl9dFboSuLvG-2FH88234duhIW0ycMwdlN0DjQi7PFYQGQmLWmeoeyZhau0OWEyEsWxOT0a-2F4NMnZBZ87mTXb8Mcm8a4MJK6yg-3D-3D https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/5747 -Thomas _ 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 -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova
On Fri, Jul 24, 2015 at 09:56:41AM -0400, Doug Hellmann wrote: Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. We've tried to do this in a lot of places throughout Oslo. It mostly works, until you hit a driver that uses options that the other drivers don't (oslo.messaging has this problem especially). We had a ConfigFilter class in oslo.config to enforce the isolation (an option registered on a filter object is only visible to the code that owns the filter). However, that causes challenges for value interpolation. A deployer doesn't know which options are visible to each other, and has a flat file where they can clearly see all of the values together, so they expect %(foo)s to work no matter where foo is defined. Until we solve those issues, the ConfigFilter isn't really supported. The best solution we've come up with so far is to isolate the options into groups based on the driver name, and then not allow code outside of the driver to access those options for any reason. To deal with import ordering issues, we pass ConfigObj instance around, and register options at runtime instead of import time, usually in an __init__ method. Registering an option more than once is fine. Yep, I would imagine that the nova/cmd/*.py command line entry points would trigger loading of the config file and pass the object into the service they run. The service may pass that config object on down to some classes, eg I'd expect the nova ComputeDriver to accept a config object in its constructor. Likewise the various manager classes like nova/compute/manager.py These would read the various config option values they care about and pass those into the various methods / objects that need them As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. There are, from time to time, specs proposed to provide ways for applications to reload their configuration settings without restarting. So far we've said that was an application issue, because oslo.config can reload the files, but it doesn't know when (that's an app signal handling thing) and it doesn't know where
[openstack-dev] [Fuel] version.yaml in the context of packages
Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects
Hi There, I have been thinking that it would make a lot of sense to have separate launchpad projects for Fuel plugins. The main benefits I foresee…. - Fuel project will be less of a bottleneck for bug triage and it should be more effective to have team members do the bug triage. After all, they are best placed to make the required judgement call. - A feature can be spread across multiple plugins, like it’s the case with LMA toolchain, and so it would be better to have a separate project to regroup them. - It is counter intuitive and awkward to create blueprints for plugins in Fuel project itself in addition to making it cluttered with stuffs that unrelated to Fuel. Can you please tell me what’s your thinking about this? Thanks Patrick -- Patrick Petit Mirantis France __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cross-project] Admin ness not properly scoped
On 07/24/2015 05:10 AM, Thierry Carrez wrote: Adam Young wrote: [...] There should be no Global Admin Tokens. They are a security risk, and violate the principal of Least Privilege. https://en.wikipedia.org/wiki/Principle_of_least_privilege. Thanks for taking on this long-standing issue. Should we have some cross-project spec to scope the work needed in the various projects and track overall acceptance of the plan ? Yes, the is appropriate: https://review.openstack.org/#/c/205629/ __ OpenStack Development Mailing List (not for 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 with CEPH storage backend cant down size an instance
Excerpts from James Galvin's message of 2015-07-24 09:08:36 -0700: Hi All I am having some trouble with down sizing an instance, I can resize the instance from say small flavour to medium flavour but when trying to resize the instance back from medium to small I get the following : Error: Failed to perform requested operation on instance jg-10, the instance has an error status: Please try again later [Error: Flavor's disk is too small for requested image.]. I am using ceph as the storage backend clustered over 3 nodes with 3 pools volumes vms images In addition to the note already made about reducing filesystem sizes, I just want to reaffirm that resize is really not the way you want to be using clouds, and IMO should be removed from Nova (but there's enough people who disagree with me that it will probably stay). Anyway, I suggest never using resize, and just deploying new servers, running tests, and then deleting the old ones. Having cloud with flexibility and space for this is why you have a cloud. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On Fri, Jul 24, 2015 at 12:02 PM, Adam Young ayo...@redhat.com wrote: On 07/24/2015 12:00 AM, Julian Edwards wrote: Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) This has come up numerous times, as I am sure you are now aware by reading the rest of the thread. A couple points; I've been aware of the hybrid driver for several years. I feel it is a security mistake to copy the users from the system of record (LDAP) into a cache (Keystone) and then tro only trust the values in the cache; if I delete or disable a user in LDAP, that should be the state used, not the cached value. Disabled and deleted user cannot bind to the LDAP server. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
The fuelclient request was merged with all needed +1s. Known issues are filed to Launchpad: https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli So, we'll have a support of custom node labels both in Fuel UI and CLI in 7.0. Thank you guys all who contributed to the feature and helped with review and with everything else. Thanks Mike for granting the feature with an additional day to merge the latest patch. Will focus on the filed bugs for now. Regards, Julia On Fri, Jul 24, 2015 at 1:16 PM Andrey Danin ada...@mirantis.com wrote: I apologize for my hasty email earlier. Thank you all who tried to help me but I have to revoke my additions to this feature. I completely missed the fact that labels may be changed after the deployment is done. It creates inconsistency between label values and actual values in astute.yaml on the nodes. It's bad UX and it may break a cluster in some circumstances. Merging my code we just add a new tech dept into Fuel and it's not we want to do. So, thank you again, and I'll come up later with a better proposal for 8.0. On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone
Re: [openstack-dev] OPENSTACK with CEPH storage backend cant down size an instance
* James Galvin jgal...@servecentric.com wrote: Hi All I am having some trouble with down sizing an instance, I can resize the instance from say small flavour to medium flavour but when trying to resize the instance back from medium to small I get the following : Error: Failed to perform requested operation on instance jg-10, the instance has an error status: Please try again later [Error: Flavor's disk is too small for requested image.]. I am using ceph as the storage backend clustered over 3 nodes with 3 pools volumes vms images Someone will correct me if I'm wrong, but I believe we do not support reducing the size of a volume, as this would require an FS resize. Shrinking a filesystem will often leave you with a suboptimal on-disk layout. I believe this is a general openstack rule, and not just specific to RBD volumes. -- Jon __ OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB
On 07/24/2015 12:00 AM, Julian Edwards wrote: Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) This has come up numerous times, as I am sure you are now aware by reading the rest of the thread. A couple points; I've been aware of the hybrid driver for several years. I feel it is a security mistake to copy the users from the system of record (LDAP) into a cache (Keystone) and then tro only trust the values in the cache; if I delete or disable a user in LDAP, that should be the state used, not the cached value. Groups are tricky things. While I've often toyed with what you suggest here, I always come back to the `group` being an identity attribute that exists outside of Keystone, and everything that we do inside of Keystone can be done with existing mechanisms in Keystone itself, especially now that we have Hierarchical Multitenantcy. The most common reason for a group is to be able to share access to multiple tenants. This is broken up into a handful of use cases: 1. All in one organization, multiple projects 2. Users from a remote organization get mapped in to a local set of projects (but not all...) 3. A virtual organization I'd like to see the problems you are dealing with to evaluate if splitting groups from users makes sense. However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Cheers, Julian. __ OpenStack Development Mailing List (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] [glance][api] Response when a illegal body is sent
Excerpts from Ian Cordasco's message of 2015-07-24 08:58:06 -0700: On 7/23/15, 19:38, michael mccune m...@redhat.com wrote: On 07/23/2015 12:43 PM, Ryan Brown wrote: On 07/23/2015 12:13 PM, Jay Pipes wrote: On 07/23/2015 10:53 AM, Bunting, Niall wrote: Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This is an example of a GET however this also applies to other requests. What should Glance do rather than throwing a 500, should it return a 400 as the user provided an illegal body Yep, this. +1, this should be a 400. It would also be acceptable (though less preferable) to ignore any body on GET requests and execute the request as normal. Best, -jay i'm also +1 on the 400 band wagon 400 feels right for when Glance is operating without anything in front of it. However, let me present a hypothetical situation: Company X is operating Glance behind a load-balancing proxy. Most users talk to Glance behind the LB. If someone writes a quick script to send a GET and (for whatever reason) includes a body, they'll get a 200 with the data that would otherwise have been sent if they didn't include a body. This is because most such proxies will strip the body on a GET (even though RFC 7231 allows for bodies on a GET and explicitly refuses to define semantic meaning for them). If later that script is updated to work behind the load balancer it will be broken, because Glance is choosing to error instead of ignoring it. Note: I'm not arguing that the user is correct in sending a body when there shouldn't be one sent, just that we're going to confuse a lot of people with this. I'm also fine with either a 400 or a 200. Nice succinct description of an interesting corner case. This is indeed one of those scenarios that should be defended against at the edges, but it's worth considering what will make things simplest for users. If we believe in Postel's robustness principle[1], then Glance would probably just drop the body as something we liberally accept because it doesn't harm anything to do so. If we don't believe thats a good principle, then 400 or maybe 413 would be the right codes I think. So the real question is, do we follow Postel's principle or not? That might even be something to add to OpenStack's design principles... which I seem to remember at one time we had written down somewhere. [1] https://en.wikipedia.org/wiki/Robustness_principle __ OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
Doug Hellmann wrote: Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700: Daniel P. Berrange wrote: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. Amen to that :) The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. +1 and IMHO if some driver needs some 'funky' new parameter that isn't getting passed previously, probably the driver may be built wrong, or it's not conforming to the API that is provided (and therefore either the API needs adjustments or the driver needs to be fixed); all the above IMHO is pretty standard OOP practices and I'd like to see more of it honestly :) While it's good to share common options as much as possible, there are a lot of perfectly legitimate reasons for drivers to need different configuration options. Different backends might use different authentication mechanisms, or need different ways to specify where the thing the driver is managing actually lives. The job of the driver API layer is to hide those differences so the application doesn't have to care about them. Pushing all of the options up to be API parameters defeats the purpose of that if not all drivers use all of the options. I get what u are saying, but at that point it does make me wonder what the API that is being provided really is, if the API is trying to hide those differences, and all drivers are different (and/or require different options via config) then I'm not really sure u can call that a common/shared API, especially if the sole option the API takes is a config object. I reckon this to usage of void* pointer in c/c++ (where the void* is nearly equivalent to the config object we pass around), having an API that takes a single void* pointer and then lets other functions do things/anything with it isn't exactly a API (by my definition). But if the API expects some standard arguments, and then as a final parameter takes a extra void* pointer, then this starts to become more acceptable IMHO (the extra void* pointer could be considered equivalent to **kwargs in python and the
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0. Regards, Alex On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, I vote -1 for the same reasons. Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. So, the next steps as I see them are: 1) Freeze feature in fuel 2) Submit a spec to openstack puppet to make the feature completed (address revocation, expiration, rotation of the fernet tokens). This also seems related to the already existing blueprint for fuel [1] and the mail thread [2] 3) Implement the feature upstream 4) Backport this to fuel fork in 8.0, or consume it upstream directly in the case the related blueprint [3] will be already implemented by that time. [0] https://review.openstack.org/185441 [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova
Excerpts from Joshua Harlow's message of 2015-07-24 10:09:10 -0700: Doug Hellmann wrote: Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700: Daniel P. Berrange wrote: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. Amen to that :) The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. +1 and IMHO if some driver needs some 'funky' new parameter that isn't getting passed previously, probably the driver may be built wrong, or it's not conforming to the API that is provided (and therefore either the API needs adjustments or the driver needs to be fixed); all the above IMHO is pretty standard OOP practices and I'd like to see more of it honestly :) While it's good to share common options as much as possible, there are a lot of perfectly legitimate reasons for drivers to need different configuration options. Different backends might use different authentication mechanisms, or need different ways to specify where the thing the driver is managing actually lives. The job of the driver API layer is to hide those differences so the application doesn't have to care about them. Pushing all of the options up to be API parameters defeats the purpose of that if not all drivers use all of the options. I get what u are saying, but at that point it does make me wonder what the API that is being provided really is, if the API is trying to hide those differences, and all drivers are different (and/or require different options via config) then I'm not really sure u can call that a common/shared API, especially if the sole option the API takes is a config object. I reckon this to usage of void* pointer in c/c++ (where the void* is nearly equivalent to the config object we pass around), having an API that takes a single void* pointer and then lets other functions do things/anything with it isn't exactly a API (by my definition). But if
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
Thanks guys. Feature Freeze exception request is declined then. Let's polish this work before the next release, merge changes to upstream puppet-openstack, and then just use librarian in the next release. I'd like to comment Bogdan's email - unless we fully switch to librarian, I don't agree with: Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. We can do whatever we need to do based on immediate needs for Fuel, but with the converging plan. We can't break something in Fuel, for example, just because we need to fix it puppet upstream first. On a separate note, any idea why this email appeared in a new thread in my inbox, not in the original one? My suspect is that Bogdan's client does something weird with email headers... On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko adide...@mirantis.com wrote: Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0. Regards, Alex On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, I vote -1 for the same reasons. Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. So, the next steps as I see them are: 1) Freeze feature in fuel 2) Submit a spec to openstack puppet to make the feature completed (address revocation, expiration, rotation of the fernet tokens). This also seems related to the already existing blueprint for fuel [1] and the mail thread [2] 3) Implement the feature upstream 4) Backport this to fuel fork in 8.0, or consume it upstream directly in the case the related blueprint [3] will be already implemented by that time. [0] https://review.openstack.org/185441 [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova
On Fri, Jul 24, 2015 at 12:29:56PM -0400, Doug Hellmann wrote: Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700: Daniel P. Berrange wrote: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. Amen to that :) The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. +1 and IMHO if some driver needs some 'funky' new parameter that isn't getting passed previously, probably the driver may be built wrong, or it's not conforming to the API that is provided (and therefore either the API needs adjustments or the driver needs to be fixed); all the above IMHO is pretty standard OOP practices and I'd like to see more of it honestly :) While it's good to share common options as much as possible, there are a lot of perfectly legitimate reasons for drivers to need different configuration options. Different backends might use different authentication mechanisms, or need different ways to specify where the thing the driver is managing actually lives. The job of the driver API layer is to hide those differences so the application doesn't have to care about them. Pushing all of the options up to be API parameters defeats the purpose of that if not all drivers use all of the options. Agreed, that's why I suggested the ComputeDriver constructor would probably just accept a config object - each subclass has valid reasons for wanting its own set of config parameters in this case. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
Mike, Thanks! +1 to Let's polish this work before the next release, merge changes to upstream puppet-openstack, and then just use librarian in the next release. -- dims On Fri, Jul 24, 2015 at 1:39 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Thanks guys. Feature Freeze exception request is declined then. Let's polish this work before the next release, merge changes to upstream puppet-openstack, and then just use librarian in the next release. I'd like to comment Bogdan's email - unless we fully switch to librarian, I don't agree with: Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. We can do whatever we need to do based on immediate needs for Fuel, but with the converging plan. We can't break something in Fuel, for example, just because we need to fix it puppet upstream first. On a separate note, any idea why this email appeared in a new thread in my inbox, not in the original one? My suspect is that Bogdan's client does something weird with email headers... On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko adide...@mirantis.com wrote: Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0. Regards, Alex On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, I vote -1 for the same reasons. Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. So, the next steps as I see them are: 1) Freeze feature in fuel 2) Submit a spec to openstack puppet to make the feature completed (address revocation, expiration, rotation of the fernet tokens). This also seems related to the already existing blueprint for fuel [1] and the mail thread [2] 3) Implement the feature upstream 4) Backport this to fuel fork in 8.0, or consume it upstream directly in the case the related blueprint [3] will be already implemented by that time. [0] https://review.openstack.org/185441 [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT?
On 07/24/2015 08:17 AM, Miyagishi, Takanori wrote: Dear Carl, Thank you for your information! I checked the etherpad, and I propose a new idea of Distributed SNAT implementation. Following figure is my idea, Shared SNAT Address per Tenant per Compute Node. I think this is the One IP Address per Router per Host item in the etherpad since each distributed router will consume one IP. +---+---+--+ | |eth| TenantA : TenantB | | +-+-+ : external-network| | | : 10.0.0.0/24 | | +--++--- | || : || ||10.0.0.100: |10.0.0.101 | |+---+ +-+-+ +---+ : +--+---+ +---+ | ++ || R | | SNAT| | R | : | SNAT | | R | | || |+-+-+ +-+---+-+ +-+-+ : +--+---+ +-+-+ | ... || | | | | |: | || || | | | | |: | || ++ | ---+--+--+-- --+--+--+--- : ---+---+--- | Compute Node N | | | : || | +--+--+ +--+--+: +--+--+ | | | VM1 | | VM2 |: | VM3 | | | +-+ +-+: +-+ | +--+ Compute Node 1 * R = Router This picture doesn't look right, there should only be one Router for TenantA even with two VMs on a compute node. You can verify this by looking at how many qrouter namespaces are created, but I only see one on my system. In this idea, SNAT will be created for each tenant. So, IP consumption of this case is: [number of tenant] * [number of compute node] Therefore, this idea can be reduction in IP consumption than create per router per compute node. This is a huge increase in IP consumption from today though, which is only [number of tenants], I'm not sure most deployers have [tenants * compute nodes] IPs at their disposal. And in the worst-case this becomes Assign a Floating IP to all VMs. -Brian And, can be avoid security concerns because don't share SNAT between tenant. I'd like to implement SNAT for Liberty cycle with this idea. Best regards, Takanori Miyagishi -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, July 07, 2015 2:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT? Hi, There was some discussion a while back on this subject. Some alternatives were captured on etherpad [1] with pros and cons. Sorry for the delay in responding. The initial implementation of DVR went with centralized SNAT to reduce the scope of the effort and because of a lack consensus around which alternative to choose. Carl [1] https://etherpad.openstack.org/p/decentralized-snat On Fri, Jun 26, 2015 at 5:02 AM, Miyagishi, Takanori miyagish...@jp.fujitsu.com wrote: Hi all, I'm Takanori Miyagishi. I and Yushiro Furukawa, my co-worker, are planning to implement Distributed SNAT in Liberty cycle. So, I looking for information about Distributed SNAT implementation. For now, I got some information from openstack-dev ML[1][2][3] and etherpad[4]. Would you please let me know if you have any other information. Best regards, Takanori Miyagishi [1] Fwd: [Neutron][DVR]Neutron distributed SNAT: http://lists.openstack.org/pipermail/openstack-dev/2015-February/0564 1 5.html [2] About DVR limit: http://lists.openstack.org/pipermail/openstack-dev/2015-January/05440 7 .html [3] [neutron] dvr l3_snat: http://lists.openstack.org/pipermail/openstack-dev/2014-November/0498 9 3.html [4] https://etherpad.openstack.org/p/YVR-nova-network _ _ OpenStack Development Mailing List (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:
Re: [openstack-dev] [glance][api] Response when a illegal body is sent
On 7/24/15, 13:16, Clint Byrum cl...@fewbar.com wrote: Excerpts from Ian Cordasco's message of 2015-07-24 08:58:06 -0700: On 7/23/15, 19:38, michael mccune m...@redhat.com wrote: On 07/23/2015 12:43 PM, Ryan Brown wrote: On 07/23/2015 12:13 PM, Jay Pipes wrote: On 07/23/2015 10:53 AM, Bunting, Niall wrote: Hi, Currently when a body is passed to an API operation that explicitly does not allow bodies Glance throws a 500. Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This is an example of a GET however this also applies to other requests. What should Glance do rather than throwing a 500, should it return a 400 as the user provided an illegal body Yep, this. +1, this should be a 400. It would also be acceptable (though less preferable) to ignore any body on GET requests and execute the request as normal. Best, -jay i'm also +1 on the 400 band wagon 400 feels right for when Glance is operating without anything in front of it. However, let me present a hypothetical situation: Company X is operating Glance behind a load-balancing proxy. Most users talk to Glance behind the LB. If someone writes a quick script to send a GET and (for whatever reason) includes a body, they'll get a 200 with the data that would otherwise have been sent if they didn't include a body. This is because most such proxies will strip the body on a GET (even though RFC 7231 allows for bodies on a GET and explicitly refuses to define semantic meaning for them). If later that script is updated to work behind the load balancer it will be broken, because Glance is choosing to error instead of ignoring it. Note: I'm not arguing that the user is correct in sending a body when there shouldn't be one sent, just that we're going to confuse a lot of people with this. I'm also fine with either a 400 or a 200. Nice succinct description of an interesting corner case. This is indeed one of those scenarios that should be defended against at the edges, but it's worth considering what will make things simplest for users. If we believe in Postel's robustness principle[1], then Glance would probably just drop the body as something we liberally accept because it doesn't harm anything to do so. If we don't believe thats a good principle, then 400 or maybe 413 would be the right codes I think. So the real question is, do we follow Postel's principle or not? That might even be something to add to OpenStack's design principles... which I seem to remember at one time we had written down somewhere. [1] https://en.wikipedia.org/wiki/Robustness_principle Just to throw a monkey-wrench in, https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 __ OpenStack Development Mailing List (not for 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] Nominating Vladimir Kozhukalov to core reviewers of fuel-main
If there will be no objections Vladimir will became core reviewer for fuel-main from Monday, 27th On Fri, Jul 24, 2015 at 4:10 PM, Vladimir Sharshov vshars...@mirantis.com wrote: +1 On Fri, Jul 24, 2015 at 2:58 PM, Andrey Danin ada...@mirantis.com wrote: +1 On Fri, Jul 24, 2015 at 2:00 AM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: +1 2015-07-24 1:56 GMT+03:00 Sergey Vasilenko svasile...@mirantis.com: +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (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] [neutron] 'routed' network type, DHCP agent + devstack support - review requested
On 20/07/15 18:50, Ian Wells wrote: On 20 July 2015 at 10:21, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: Hi Ian, On 20/07/15 18:00, Ian Wells wrote: On 19 July 2015 at 03:46, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: The change at [1] creates and describes a new 'routed' value for provider:network_type. It means that a compute host handles data to/from the relevant TAP interfaces by routing it, and specifically that those TAP interfaces are not bridged. To clarify that, the user uses provider:network_type in the API to request a 'routed' network be created, and the Neutron plugin either implements that or rejects the create call? Or something else? Yes, I believe so. Could it be otherwise? We can make it work any way you like if you'we willing to spend the rest of your life writing it. ;) It depends rather on how you picture this working. As described you've made it so that networks would be routed if the admin created them and specifically flagged them as routed, which useful for testing, or if the mechdriver is the default, which is probably the most useful way in production. I think the thing that we'll be missing long term is a means to explicitly request an L2 domain - as that's the special case that you might explicitly want, the general case is 'with IP addresses my VMs can talk to each other' - and that would require more than Neutron currently provides and would require work. Thanks Ian. When I wrote Could if be otherwise? above, I meant in the narrow sense of If you've configured a particular ML2 mechanism driver, and that driver can't handle a particular network_type, can it do anything other than reject the network creation call?. But, in the light of the discussion in the Representing a networks connected by routers thread (starting at [1]), I guess you were thinking more broadly, and it seems clear now that more thinking is needed about the best way to model this 'routed' networking idea, consistent with existing Neutron concepts. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html Some suggestions, from those discussions: - A Neutron network is fundamentally an L2 thing, so maybe it's wrong to model this as multiple VMs attaching to a new kind of Neutron network. - As the concept is of VMs attaching to a L3 domain, perhaps that should be modelled as attaching to a subnet, or subnet pool, or address scope. Perhaps with a null network in places where a network is currently required. Two other ideas that occur to me: - Actually each VM port does still attach to a L2 network (as least in the sense that the IP is still over Ethernet) - but it's a L2 network that contains only that port, and is terminated by the corresponding TAP interface on the compute host. Could it perhaps be useful to model this as a Neutron network per VM port? - Another possible modelling idea is to say that the VMs are being attached to a Router object. The Router could have an associated subnet pool, and then an IP address would be allocated from that pool, for each VM port. (Or 2 pools and 2 IP addresses, for v6 as well as v4.) Any further ideas and thoughts would be much appreciated here! Many thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-ansible-deployment] [openstack-ansible] [Searchlight] Specs for Liberty (v12.0.0)
On Friday, July 24, 2015, Ian Cordasco ian.corda...@rackspace.com wrote: Hey all, It looks like we've started accepting specifications for Liberty development. Is this accurate? Most certainly. We track master based on SHA updates typically once every two weeks, so if the code has merged upstream then you can already work on it from our master branch. :) If so, I'd like to start writing one to add Searchlight. Anyone experimenting with Glance's Catalog Index Search in Kilo will want Searchlight in Liberty. Go for it. I'd suggest also adding the review once submitted to the weekly meeting for the purpose of discussion and to open it up to questions. -- Jesse Pretorius mobile: +44 7586 906045 email: jesse.pretor...@gmail.com skype: jesse.pretorius __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Setting epoch in setup.cfg??
On 7/14/15, 10:41, Monty Taylor mord...@inaugust.com wrote: On 07/14/2015 11:08 AM, Ian Cordasco wrote: On 7/13/15, 16:19, Joshua Harlow harlo...@outlook.com wrote: Ian Cordasco wrote: On 7/13/15, 15:09, Dave Walkerem...@daviey.com wrote: On 13 Jul 2015 8:52 pm, Ian Cordascoian.corda...@rackspace.com wrote: On 7/13/15, 03:38, Thierry Carrezthie...@openstack.org wrote: SNIP By counter-productive, I meant: likely to generate more confusion than clarity. If you provide an epoch in the version and it doesn't match downstream packagers ones, it's hard to rely on it. I see what you mean now. The thing is that for Debian/Fedora the epoch syntax is different from PEP 440 For them it's [distro-epoch]:[upstream-version][otherstuff] PEP 440 epochs are separated by a !, so let's say $(distro) has an epoch value of 1 and we choose 2, for glance the version would look ugly but would be: 1:2!11.0.0 SNIP This would be a problem for at least Ubuntu and Debian as the version string is specifically not allowed to contain a '!'. The upstream_version may contain only alphanumerics and the characters . +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a digit. [0] Thanks for the input Dave. I didn't see that part since I was specifically looking for how epochs are denoted. I still am quite certain that we have no choice but to use the proper versioning tools upstream though and that means using ! to indicate the epoch in our version strings because these are fundamentally Python packages. +1 we produce python versions, and people use them (whether they are uploaded to pypi or not) so we should try to do the right thing here no matter what. If downstream distro (rh, ubuntu, other...) wants to convert that into its local epoch scheme that's cool (and I would expect them to do that in the correct manner that is appropriate for there packages). Since the mailing list reaches the largest number of people, I thought I'd continue some of this discussion here. Yesterday some further discussion happened in #openstack-infra (on IRC), and the crux of the argument against Epochs seems to be that they make it hard to deal with archives on the command line, e.g., you'd have an archive generated that looks like: nova-1!12.0.0.tar.gz Perhaps I'm misunderstanding, but any relatively modern shell that allows for tab completion will properly tab-complete that when using the filename. Another argument is that this is something ugly that we'll have to live with for the rest of OpenStack's life. Without it, however, we'll have to live with 12.0.0 (the last four years of version numbers) as a sorting mechanism as far as Python packaging is concerned. There's also the argument that (paraphrasing) this isn't really a problem for people using pip because you can do `pip install -U nova==12.0.0` once and you're done. Except that if you have a local package index and you're support reproducible builds of multiple versions, say, Juno (2014.2.x), Kilo (2015.1.y), Liberty (your version number depends on project but is strictly less than both Juno and Kilo), and M. If you upgrade a project from Liberty to M, you have to still use `pip install -U nova==13.0.0` because `pip install -U nova` will install Kilo because neither Liberty nor M are using an epoch. We're effectively saying if you support more than one release at a time using the python packaging ecosystem, you're a second class citizen in OpenStack. In other words, this will be an ongoing problem. Epochs are clearly a necessity, otherwise our downstream distributors wouldn't be using them and the PEP 440 authors wouldn't have included them. Epochs were designed exactly for this situation, and while they're ugly, they're the absolutely correct approach here. As a sidenote, in case people are wondering how epochs even work with pip, 2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher value than the implicit 0. 1!13.0.0 then defers to the rest of the version string because they belong to the same epoch. Those are all only physical manifestations of the concern I shared, not the concerns themselves. Here are my actual thoughts and concerns: pip is not a downstream distribution. It is not as rich as dpkg or rpm. The issues that they solve by using epochs are not the same problem space pip exists in. So, pip may not have as many features as dpkg or rpm. That said, it is (apparently) being chosen increasingly by operators over dpkg and rpm. There was a lot of talk at the last OPS mid cycle (in Philadelphia) about deploying from source (and using pip) from what I've heard about that midcycle. Granted, it's a mid cycle so not every operator will be able to attend (just like not every operator is able to attend the Summit). There was still a consensus to move towards installing
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Igor, https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the FFE if you think it's a feature. Networking is the most complicated and frustrating thing the user can work with. If we cant provide usable feedback from bad data in the template then the feature is useless. I could argue that its a critical UX defect. On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote: Aleksey, Yes, my point is those parts should be also included in the scope of FFE. Regarding to template format, it's easy to fix and after release you will not be able to change it, or you can change it, but you will have to support both format, not to brake backward compatibility. So I would prefer to see it fixed in 7.0. Thanks, On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin akasat...@mirantis.com wrote: I agree, guys, we need at least some basic validation for template when it is being loaded. Ivan Kliuk started to work on this task. And we agreed to test other types of delimiters (it is regarding ERB style template) but we have some more important issues. Evgeniy, is your meaning to include those to FFE ? Aleksey Kasatkin On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I agree here with Evgeniy. Even if it's not a trivial change, we cannot leave a new API in such shape. 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Fuel] FFE requests and status
Current FFE request status: FFE for bug/1475759 ceph generators - PENDING Approval FF Exception request for Fernet tokens support. - DECLINED FF Exception request for Custom node attributes feature - APPROVED, MERGED FF Exception request for Templates for Networking feature - APPROVED FF Exception for LP-1464656 fix (update ceph PG calculation algorithm) - PENDING Approval FF Exception request for Env Upgrade feature - APPROVED FF Exception request for Deploy nova-compute (VCDriver) feature - PENDING Approval On Thu, Jul 23, 2015 at 12:17 PM Mike Scherbakov mscherba...@mirantis.com wrote: Thanks Andrew. I'd like to add that after there is an announcement about FF, all core reviewers should stop getting patches into master which are parts of features or extensions. We expect only bugfixes. If there is anything else, we need to be very transparent about it, and have them in public place like here. In the past, we had a practice when developers would continue to work on enhancements instead of bugs, and cores would support it. And in fact, FF moves to SCF - and we have to slip our release. Let's not do this again. On Thu, Jul 23, 2015 at 11:56 AM Andrew Woodward xar...@gmail.com wrote: In case you missed it, feature freeze is today and in the rush to merge things, you may have had issues with getting everything landed. For those that are not familiar with the process, to request a feature freeze exception (FFE): * You will need to raise the request to the ML here and in such message - Include [Fuel] FFE request + feature name in the subject - Document what is outstanding (Link to CR's), what's their state - Link to blueprint - Document impact of outstanding changes - Document how long you expect before it can lang * You will also need to get two of the cores in the repo(s) impacted by outstanding reviews to sponsor reviewing the outstanding CR's * Finally PTL will approve each FFE request. Please do not ask for a FFE in this thread I will update this thread with approved FFE's as they occur -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
It looks like /etc/issue + an extraction from rpm db. On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward xar...@gmail.com wrote: Vladimir, I agree that the content of this file nearly completely depreciated, but slightly disagree with removing it entirely. I think the data should be moved from a single static file like you see here, to something that reads the data from the underlying packages and can still show all of the information in one place (/api/version). So we can, and should do away with this file but we need the data in the api response, and saved in the diag snapshot. So my comments below are about possibly keeping these around, but not in the file On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This should just be expressed as a value in the DB, it never made sense to store this in a file since it's runtime state 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. there is no longer not docker, so just drop it. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
[openstack-dev] [fuel] Acting PTL for Fuel - Dmitry Borodaenko
I'd like to point out as part of our on-going effort to more formally align with the openstack governance practices, Dmitry Borodaenko has taken up the reins as PTL for fuel as this aligns with his current leadership role in the project. We have agreed that we will open for nominations and voting After HCF (towards the end of the 7.0 release cycle in September) -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API
Hi Everyone, In our last networking-sfc project IRC meeting, an issue was brought up that the API proposed in https://review.openstack.org/#/c/186663/ has a lot of duplication to the SFC API https://review.openstack.org/#/c/192933/ that is being currently implemented. In the IRC meeting, the project team reached consensus that we only need one API and the service chain API can cover the functionality needed by https://review.openstack.org/#/c/186663/. Please refer to the meeting log http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html for more discussion info. Please let us know if you have different opinion. Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)
+1 for FFE Given how borken pg_num calculations are now, this is essential to the ceph story and there is no point in testing ceph at scale with out it. The only work-around for not having this is to delete all of the pools by hand after deployment and calculate the values by hand, and re-create the pools by hand. The story from that alone makes it high on the UX scale, which means we might as well fix it as a bug. The scope of impact is limited to only ceph, the testing plan needs more detail, and we are still comming to turns with some of the data format to process between nailgun calculating and puppet consuming. We would need about 1.2 week to get these landed. On Fri, Jul 24, 2015 at 3:51 AM Konstantin Danilov kdani...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for [1] fix. It requires changes in fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already tested, I'm fixing UT now. BP - [4] Code has backward-compatibility mode. I need one more week to finish it. Also I'm asking someone to be an assigned code-reviewer for this ticket to speed-up review process. Thanks [1] https://bugs.launchpad.net/fuel/+bug/1464656 [2] https://review.openstack.org/#/c/204814 [3] https://review.openstack.org/#/c/204811 [4] https://review.openstack.org/#/c/203062 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [fuel] FFE for bug/1475759 ceph generators
I'm writing to ask for a FFE for landing the ceph generators. It finally received core-reviewers attention late on Wednesday and Thursday and is ready to merge now. I'm only asking for FFE because reviewers are calling this a feature. Possible impact, none. This is not used by anything yet and should be merged. [1] https://bugs.launchpad.net/fuel/+bug/1475759 [2] https://review.openstack.org/#/c/203270/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
Evgeniy,
The replacement node use case seems significantly different from node
renaming
case to me. It's not only about the hostname of the node. I guess that
eventually
we'll have to invent a way to retain other metadata of the original node,
not only
a hostname. The described use case is more like 'node reinstallation'
feautre [1].
[1] https://blueprints.launchpad.net/fuel/+spec/mos-node-reinstallation
--
Best regards,
Oleg Gelbukh
On Fri, Jul 24, 2015 at 12:07 PM, Evgeniy L e...@mirantis.com wrote:
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
wants why there should be a constraint which is related to some internal id
in Nailgun database? For example if he deleted node-5 and then he wants
to replace this node with another one, he can and should be able to provide
for this replacement node hostname node-5, even if node's id in the
database
is 6.
Thanks,
On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward xar...@gmail.com wrote:
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com
wrote:
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames
in format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
How is this a main use case? This is exactly what we should not support.
If they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom
node naming in this case.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (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
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for 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][nova] Streamlining of config options in nova
Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100: On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote: Hi all, During development process in nova I faced with an issue related with config options. Now we have lists of config options and registering options mixed with source code in regular files. From one side it can be convenient: to have module-encapsulated config options. But problems appear when we need to use some config option in different modules/packages. If some option is registered in module X and module X imports module Y for some reasons... and in one day we need to import this option in module Y we will get exception NoSuchOptError on import_opt in module Y. Because of circular dependency. To resolve it we can move registering of this option in Y module(in the inappropriate place) or use other tricks. I offer to create file options.py in each package and move all package's config options and registration code there. Such approach allows us to import any option in any place of nova without problems. Implementations of this refactoring can be done piece by piece where piece is one package. What is your opinion about this idea? I tend to think that focusing on problems with dependancy ordering when modules import each others config options is merely attacking a symptom of the real root cause problem. The way we use config options is really entirely wrong. We have gone to the trouble of creating (or trying to create) structured code with isolated functional areas, files and object classes, and then we throw in these config options which are essentially global variables which are allowed to be accessed by any code anywhere. This destroys the isolation of the various classes we've created, and means their behaviour often based on side effects of config options from unrelated pieces of code. It is total madness in terms of good design practices to have such use of global variables. So IMHO, if we want to fix the real big problem with config options, we need to be looking to solution where we stop using config options as global variables. We should change our various classes so that the neccessary configurable options as passed into object constructors and/or methods as parameters. We've tried to do this in a lot of places throughout Oslo. It mostly works, until you hit a driver that uses options that the other drivers don't (oslo.messaging has this problem especially). We had a ConfigFilter class in oslo.config to enforce the isolation (an option registered on a filter object is only visible to the code that owns the filter). However, that causes challenges for value interpolation. A deployer doesn't know which options are visible to each other, and has a flat file where they can clearly see all of the values together, so they expect %(foo)s to work no matter where foo is defined. Until we solve those issues, the ConfigFilter isn't really supported. The best solution we've come up with so far is to isolate the options into groups based on the driver name, and then not allow code outside of the driver to access those options for any reason. To deal with import ordering issues, we pass ConfigObj instance around, and register options at runtime instead of import time, usually in an __init__ method. Registering an option more than once is fine. As an example in the libvirt driver. I would set it up so that /only/ the LibvirtDriver class in driver.py was allowed to access the CONF config options. In its constructor it would load all the various config options it needs, and either set class attributes for them, or pass them into other methods it calls. So in the driver.py, instead of calling CONF.libvirt.libvirt_migration_uri everywhere in the code, in the constructor we'd save that config param value to an attribute 'self.mig_uri = CONF.libvirt.libvirt_migration_uri' and then where needed, we'd just call self.mig_uri. There are, from time to time, specs proposed to provide ways for applications to reload their configuration settings without restarting. So far we've said that was an application issue, because oslo.config can reload the files, but it doesn't know when (that's an app signal handling thing) and it doesn't know where values might have been saved like you describe. I don't know if that's something the nova team wants to support. Now in the various other libvirt files, imagebackend.py, volume.py vif.py, etc. None of those files would /ever/ access CONF.*. Any time they needed a config parameter, it would be passed into their constructor or method, by the LibvirtDriver or whatever invoked them. Getting rid of the global CONF object usage in all these files trivially now solves the circular dependancy import problem, as well as improving the overall structure and isolation of our code, freeing all these methods from unexpected side-effects from global
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On Fri, Jul 24, 2015 at 1:10 AM, Henry Nash hen...@linux.vnet.ibm.com wrote: Matt, Your hybrid driver seems to be doing something different than what Julian was asking - namely providing some “automatic role assignments” for users stored in LDAP (unless I am not understanding your patch)? I guess you could argue that’s a restricted version of being able to create group memberships outside of LDAP (which is Julian what I think you are asking for….), but probably a somewhat different use case? Henry Henry, First to clarify I don't want to call it my driver since the guys at SuSe wrote it. It has 2 pieces, identity and assignment, we only use the identity driver. AFAIK Assignment via LDAP is being deprecated anyway. Since we have no ability to move users into LDAP groups and what not at our company, we only use the driver I mentioned to do an LDAP bind and everything else happens in mysql. On 24 Jul 2015, at 05:51, Matt Fischer m...@mattfischer.com wrote: Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind. I know some of the Keystone team has pretty strong opinions about this but it works for us. And nice to run into you again... On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards bigjo...@gmail.com wrote: Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Cheers, Julian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On Fri, Jul 24, 2015 at 1:01 AM, Julian Edwards bigjo...@gmail.com wrote: On 24 July 2015 at 14:51, Matt Fischer m...@mattfischer.com wrote: Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind. Oh cool, I'll check that out, thanks for the pointer. Ideally I'd like to get something in-tree, but this might be a good start. I do have Ubuntu packaging code in my branch if that helps you deploy it at all: https://github.com/matthewfischer/keystone-hybrid-backend/ I know some of the Keystone team has pretty strong opinions about this but it works for us. There's clearly a problem that needs solving, but I'd like to hear the opinions. And nice to run into you again... Likewise! Cheers. __ OpenStack Development Mailing List (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] [all] cross project communication: Return request-id to caller
Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +: Hi Devs, X-Openstack-Request-Id. We have analysed python-cinderclient, python-glanceclient, python-novaclient, python-keystoneclient and python-neutronclient to check the return types. There are 9 ways return values are returned from python clients: 1. List 2. Dict 3. Resource class object 4. None 5. Tuple 6. Exception 7. Boolean (True/False, for keystoneclient) 8. Generator (for list api's in glanceclient) 9. String (for novaclient) Out of 9 we have solution for all return types except generator. In case of glance-client list api's are returning generator which is immutable. So it is not possible to return request-id in this case, which is a blocker for adopting the solution. I have added detail analysis for above return types in etherpad [2] as solution #3. If you have any suggestion in case of generation type then please let me know. It should be possible to create a new class to wrap the existing generator and implement the iterator protocol [3]. [3] https://docs.python.org/2/reference/expressions.html#generator-iterator-methods Doug [1] http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-07-21.01.log.html [2] https://etherpad.openstack.org/p/request-id Thanks Best Regards, Abhishek Kekane __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Env Upgrade feature
Alexey, Thank you for the vote. We expect to spend 2 more days on patch [1] and [2], and then another 2 days to finish patch [3]. With reviewers help, [1] and [2] will land by Wednesday, while [3] is due Thursday. [1] https://review.openstack.org/#/c/202969/ [2] https://review.openstack.org/#/c/203537/ [3] https://review.openstack.org/#/c/203536/ -- Best regards, Oleg Gelbukh On Fri, Jul 24, 2015 at 3:26 PM, Aleksey Kasatkin akasat...@mirantis.com wrote: +1 for an exception. Do we have time estimate though? Aleksey Kasatkin On Fri, Jul 24, 2015 at 2:46 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this exception - as Evgeniy said it is developed not in the core but in extension and risk is low. 2015-07-24 10:17 GMT+02:00 Evgeniy L e...@mirantis.com: Hi, If we have a rule that feature freeze exceptions should have essential priority, I'm not sure if it matters how risky it's, the risk is low, but it's not zero. Thanks, On Thu, Jul 23, 2015 at 9:09 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Oleg, considering that your feature is essential for the release, sounds like there is no way we can't give an exception. I'm glad that it's perceived by low risk by core reviewer from Nailgun team (Evgeny). If there are no concerns from other, then we are giving FF exception. However, I'd like to understand how much it will take to finish this work and additional resources required. We need to switch to bugfix work, and the more we continue working on features / enhancements, the less confidence I have that we can meet HCF deadline. Thanks, On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote: Hi, The patch into Nailgun requires additional work to do, but as far as I can see it doesn't affect any other parts of the system, also it's implemented as an extension, which means if the feature will introduce bugs which we won't be able to fix in a required time, it can be easily disabled without removing from master with just removing one line from a file [1] (removing it from extensions list). So I think it's ok to accept environment upgrade feature as an exception for feature freeze. Thanks, [1] https://review.openstack.org/#/c/202969/7/nailgun/nailgun/extensions/base.py On Wed, Jul 22, 2015 at 10:18 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Environment Upgrade extensions added to the Nailgun API [1]. The Nailgun side of the feature is implemented in the following CRs: https://review.openstack.org/#/q/status:open+topic:bp/nailgun-api-env-upgrade-extensions,n,z These changes are implemented as an extension [2] to the Nailgun. It barely touches the core code and doesn't change the existing functionality. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://review.openstack.org/#/c/192551/ [2] https://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z -- Best regards, Oleg Gelbukh __ OpenStack Development Mailing List (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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
